Однако, есть один минус — он плохо показывает содержимое объектов. Точнее, он их не показывает, пишет просто [object] и все. Кажется, авторы jerry здесь как-то поленились и не довели передачу информации до конца. Что ж, не страшно, добавим сами!
Также в процессе тестирования мы реализовали атаки, позволяющие получить:
* местоположение абонента с точностью до сектора базовой станции;
* модель телефона;
модель телефона? или IMSI записана все-таки в базе? Почему спрашиваю, в GSM сетях не передается модель, может в новых что-то поменялось
Развивая атаку и сформировав еще несколько сигнальных сообщений, мы выполнили от имени абонента-жертвы отправку СМС и USSD-запросов, изменение профиля услуг. Кроме того, этот вектор атаки можно использовать для DOS всех сервисов абонента.
А для DOS не малова то будет абонентов?
Другая группа атак осуществляется, когда абонент находится в реальном, а не фейковом, VLR.
Выяснив VLR, в котором находится абонент, и представившись HLR’ом, злоумышленник может изменить его профиль в этом VLR
Самое интересное как выяснить какой gt у нужного VLR
Скажу честно очень вкусное название и совсем нет вкусных подробностей…
В ответ получили ошибку, но вместе с ней мы узнали адрес HLR. Далее, атакуя непосредственно HLR
У оператора база HLR торчит напрямую в сеть?
Зная IMSI абонента и используя MAP-операцию Update Location, мы «перенесли» абонента-жертву в свою фейковую сеть
Можно подробнее про эту операцию?
Вообще странно как так получается, абонент не уходил со станции оператора, он ее видит в своей сети и все равно куда-то перемещает?
AI-модель и вправду наверное кажется тут излишней)
Я бы предложил другую схему динамической архитектуры сжатия, типа как JS компилируется в движке V8.
Вначале происходит быстрая компиляция без оптимизаций, а дальше если происходит частое обращение к кода, то применяются повторные компиляции.
И аналогично здесь сделать для сжатия, сжимать вначале быстро и не сильно. А потом делать немножко наоборот, если данные горячие и идет частое обращение, то оставляем как есть или вообще к примеру убираем сжатие, а если данные холодные и не часто требуются, то пробуем ужимать еще больше.
Но на словах это конечно, просто звучит. Но на сколько это совместимо с архитектурой тарантула, мне сложно говорить.
Спасиб за статью!
Не смотрел код, поэтому мои вопросы могут показаться капитанскими
А анализируется как нибудь размер сжатых данных, могут быть настолько рандомные данные, сжатие будет мизерное. Только тратится лишнее время на сжатие и разжатие. На моей практике все что выше 0.8 от изначального объема не имеет смысла сжимать, только ухудшаем скорость доступа.
-
Наверное каждый четный, Яркость по картинке с нулевой позиции идет
произойдет все равно return false;
Хотя оригинальный код такое не предусматривает
Но тем не менее эти 64 Мб они же транслируются в физическую память
пусть даже и в swap
… если я не ошибаюсь
Получается простой «Hello World» может есть минимум 64 Мб
Если происходит аллокация, а судя по этому
Она происходит
К примеру из недавно встретившегося
github.com/NVIDIA/nvcomp/blob/branch-2.2/src/RunLengthEncodeGPU.cu#L162
Я правильно понял, это все сделано в условиях вашей «синтетической» уязвимости?
Так и злоумышленник может посчитать эту длину пакета)
А вам в итоге удалось починить отладку?
Не сталкивался до этого с Diameter-сетью. Поэтому интересно как происходит доступ к Diameter? через SS7?
модель телефона? или IMSI записана все-таки в базе? Почему спрашиваю, в GSM сетях не передается модель, может в новых что-то поменялось
А для DOS не малова то будет абонентов?
Самое интересное как выяснить какой gt у нужного VLR
Не знал про это, мне казалось что светить своей базой HLR в общую сеть ss7 бессмысленно для оператора, только расширять поверхность атаки
А не уж то не используют никакого черного списка с этими операторами для жесткой фильтрации запросов?
У оператора база HLR торчит напрямую в сеть?
Можно подробнее про эту операцию?
Вообще странно как так получается, абонент не уходил со станции оператора, он ее видит в своей сети и все равно куда-то перемещает?
Вы задавались вопросом, чем она полезна?!
Я бы предложил другую схему динамической архитектуры сжатия, типа как JS компилируется в движке V8.
Вначале происходит быстрая компиляция без оптимизаций, а дальше если происходит частое обращение к кода, то применяются повторные компиляции.
И аналогично здесь сделать для сжатия, сжимать вначале быстро и не сильно. А потом делать немножко наоборот, если данные горячие и идет частое обращение, то оставляем как есть или вообще к примеру убираем сжатие, а если данные холодные и не часто требуются, то пробуем ужимать еще больше.
Но на словах это конечно, просто звучит. Но на сколько это совместимо с архитектурой тарантула, мне сложно говорить.
Не смотрел код, поэтому мои вопросы могут показаться капитанскими
А анализируется как нибудь размер сжатых данных, могут быть настолько рандомные данные, сжатие будет мизерное. Только тратится лишнее время на сжатие и разжатие. На моей практике все что выше 0.8 от изначального объема не имеет смысла сжимать, только ухудшаем скорость доступа.
На нашел прайс на докер для винды
Можно ссылку пожалуйста?)
Расскажите о своем опыте, будет интересно