The Outline team and Shadowsocks community made a number of improvements that strengthened Shadowsocks beyond the censor's current capabilities. ... Shadowsocks remains our protocol of choice because it's simple, well understood and very performant.
Интересно, насколько сложно отреверсить все эти потерянные исходники, особенно с учётом памяти разработчика.
Про качество интересно, конечно — декодеры, удовлетворяющие спецификации, не должны работать абсолютно одинаково? Или это всё про детали вида "использовал float" или "какой-то бит потерялся при работе с целыми числами", в предположении, что отсутствуют тестовые вектора для декодеров.
На софтварном уровне, думаю, видели продолжающийся многолетний ресёрч процов Intel от Positive Technologies, где они уже до микрокода дошли. Хардварный реверс вряд ли возможен без гигантских затрат.
Пару лет назад какое-то время наблюдал обратный эффект: в каршеринге яндекса можно было нажать на машину, посмотреть цену, после чего ещё несколько раз её открыть — всегда, рано или поздно, цена становилась меньше. Потом пофиксили, конечно :)
В Windows 10 есть новые алгоритмы сжатия файлов, однако галочка «Сжимать содержимое» фактически использует старый алгоритм NTFS-LZNT1. Можете попробовать вот эту тулзу для использования новых методов сжатия. На практике, в среднем, от них можно ожидать сжатия в 30-50% на всяких пакетах ПО.
Да ладно, особых изменений в интерфейсе между 6.1 и 7.3 не было, для начала сойдёт. В гуе много неочевидных мест есть, а с API и так надо всегда быть готовым к изменениям.
Достаточно подробно и понятно описано, спасибо. Замечу несколько вещей:
1. В функциях decode_hash_4s и get_hash_2b описана просто кодировка/декодировка байтов в hex
2. То, что у вас описано в sub_E3E, является, на самом деле, вычислением CRC-16 в варианте CRC-16-IBM.
3. В целом, вся вторая часть была архивом известного формата, как я понял, и тулзы для работы с ним можно найти у того же человека, который делал модули для иды, и который разработал задание: rnc_propack_source. Я нашёл этот репозиторий только после сдачи задания, и не проверял, что эти сорцы действительно полезные, но формат архива явно тот же самый, совпадает magic.
Если интересно, моё решение можно найти тут. Я там зачем-то переписал всю логику работы с этим RNC архивом, надо было тоже из дебаггера вытащить сразу нужные оффсеты, конечно.
В двух словах, лишний log log n возникает, потому что считается битовая сложность, то есть сложность базовых операций типа сложения и умножения не равна 1, а зависит от битовой длины элементов. Здесь (2.3) объяснено подробнее.
Данная атака, даже со скоростью 1 бит/с, может быть применима в браузерных эксплоитах. Для обхода ASLR, например, достаточным может оказаться узнать всего несколько байт.
Вот вы как перевели это предложение: «Simply add a b before any string, and it will do nothing»?
"Просто добавьте b перед любой строкой, и ничего не произойдёт".
Смысл тот же самый, а смотрится уже не так коряво.
Он работает так, вы ожидаете, то есть добавляя элемент с правой части в левую частью массива.
Этот перевод просто неверный, в оригинале написано про массив слева, а не про левую часть массива. Перевести всё вместе можно как "Он работает так, как вы и ожидаете — добавляет элемент справа в массив слева".
Я неправильно выразился, имел в виду, что впатчивать ассемблерный код достаточно долго. Чтобы не потратить время на впиливание патча, который по какой-то причине окажется неправильным, можно сначала делать патчи, например, на Javascript, как во фриде, а потом уже удачные варианты оформлять в виде бинарного патча.
авторы на гитхабе пишут про это https://github.com/Jigsaw-Code/outline-server#shadowsocks-resistance-against-detection-and-blocking
Разработчиик утверждают, что в гидроаккумуляторе дороже хранить энергию. Они каким-то образом используют один двигатель на несколько сотен грузов.
Интересно, насколько сложно отреверсить все эти потерянные исходники, особенно с учётом памяти разработчика.
Про качество интересно, конечно — декодеры, удовлетворяющие спецификации, не должны работать абсолютно одинаково? Или это всё про детали вида "использовал float" или "какой-то бит потерялся при работе с целыми числами", в предположении, что отсутствуют тестовые вектора для декодеров.
На софтварном уровне, думаю, видели продолжающийся многолетний ресёрч процов Intel от Positive Technologies, где они уже до микрокода дошли. Хардварный реверс вряд ли возможен без гигантских затрат.
Действительно, для примера по смещению 0x100
>>> struct.unpack('<4f', bytes.fromhex('fa2d343e5f5c333ef0f3363e5911233e'))(0.1759566366672516, 0.17515705525875092, 0.1786649227142334, 0.15924586355686188)
Соответствует строкам 389-392 в CSV.
То же самое в виде одного листа для uBlock Origin: https://github.com/quenhus/uBlock-Origin-dev-filter
Обе эти функции не из стандартной библиотеки C, на Windows, например, они не существуют.
Должен заметить, что мне поддержка Hex-Rays (в том числе и Ильфак) всегда помогала быстро и по делу.
1. В функциях
decode_hash_4sиget_hash_2bописана просто кодировка/декодировка байтов в hex2. То, что у вас описано в
sub_E3E, является, на самом деле, вычислением CRC-16 в варианте CRC-16-IBM.3. В целом, вся вторая часть была архивом известного формата, как я понял, и тулзы для работы с ним можно найти у того же человека, который делал модули для иды, и который разработал задание: rnc_propack_source. Я нашёл этот репозиторий только после сдачи задания, и не проверял, что эти сорцы действительно полезные, но формат архива явно тот же самый, совпадает magic.
Если интересно, моё решение можно найти тут. Я там зачем-то переписал всю логику работы с этим RNC архивом, надо было тоже из дебаггера вытащить сразу нужные оффсеты, конечно.
"Просто добавьте
bперед любой строкой, и ничего не произойдёт".Смысл тот же самый, а смотрится уже не так коряво.
Этот перевод просто неверный, в оригинале написано про массив слева, а не про левую часть массива. Перевести всё вместе можно как "Он работает так, как вы и ожидаете — добавляет элемент справа в массив слева".