Комментарии 20
Мне почему-то кажется что
To figure out the alignment of an unknown file, I turn to an age-old trick – resizing a text window until the line-wrap length matches the file alignment.
должно переводится немного не как
Чтобы выяснить размерность неизвестного файла, я воспользовался старым трюком — изменял размер текстового окна, пока длина переноса строк не стала соответствовать размеру файла.
Причём тут размер файла? Скорее всего имеется в виду именно alignment, то есть выравнивание, чтобы это окно редактора на экране с текстом было в виде правильного параллелепипеда, а не параллелепипеда «с хвостиком» внизу.
To figure out the alignment of an unknown file, I turn to an age-old trick – resizing a text window until the line-wrap length matches the file alignment.
должно переводится немного не как
Чтобы выяснить размерность неизвестного файла, я воспользовался старым трюком — изменял размер текстового окна, пока длина переноса строк не стала соответствовать размеру файла.
Причём тут размер файла? Скорее всего имеется в виду именно alignment, то есть выравнивание, чтобы это окно редактора на экране с текстом было в виде правильного параллелепипеда, а не параллелепипеда «с хвостиком» внизу.
Да, вы правы, исправлю.
> изменял размер текстового окна, пока длина переноса строк не стала соответствовать выравниванию.
Это первое что взорвало мозг ) Что вообще это значит? Что такое «длина переноса строк»?
А к оригиналу вопрос (может кто нибудь объяснит) — почему 20, а не например 10 или 45 (должен быть делителем 20 (ширина выровненного окна))?
Это первое что взорвало мозг ) Что вообще это значит? Что такое «длина переноса строк»?
А к оригиналу вопрос (может кто нибудь объяснит) — почему 20, а не например 10 или 45 (должен быть делителем 20 (ширина выровненного окна))?
В файле не может быть полубайтов, а все 0 и 1 — это биты. То есть если при перетаскивании вправо в последней строчке не остаётся пустого места, мы нашли длину строки, кратную длине байта. Допустим, длина «байта» — 5 бит.
Имеем вот такую картину:
00000111111
00101001101
11011000 < — в конце есть три пустых места, значит, выровняли неверно
Сдвигаем окно на символ вправо, получаем:
0000011111
1001010011
0111011000 < — значит, 10 нацело делится на длину байта в битах.
Имеем вот такую картину:
00000111111
00101001101
11011000 < — в конце есть три пустых места, значит, выровняли неверно
Сдвигаем окно на символ вправо, получаем:
0000011111
1001010011
0111011000 < — значит, 10 нацело делится на длину байта в битах.
Гм, а не проще было разложить длину файла в произведение простых чисел?
> значит, 10 нацело делится на длину байта в битах.
Это я как раз понял, но почему в статье 20, а не 10 или 45?
Это я как раз понял, но почему в статье 20, а не 10 или 45?
Можно и 10, но что если «байт» 12-битный (в статье написано, что в древних архитектурах такая размерность использовалась)? Может возникнуть ситуация 10 * 6 = 12 * 5, и мы упустим нужную величину. Почему не 45? Процессор старый, так что в нём вряд ли использовалась хотя бы 32-битная архитектура. Взяли что-то среднее, с запасом.
> Можно и 10, но что если «байт» 12-битный
Так 12 не делится на 10 или 5 )
Но посыл понял — просто первое попавшееся число из диапазона 10-20 (навскидку) на которое делится размер файла нацело.
> вряд ли использовалась хотя бы 32-битная архитектура
Мы про размер «байта». Что в x86 что в x86_64 (что в куче других) байт состоит из восьми бит.
Так 12 не делится на 10 или 5 )
Но посыл понял — просто первое попавшееся число из диапазона 10-20 (навскидку) на которое делится размер файла нацело.
> вряд ли использовалась хотя бы 32-битная архитектура
Мы про размер «байта». Что в x86 что в x86_64 (что в куче других) байт состоит из восьми бит.
Потому что именно при размере 20 проявляется заметная глазу структура на гифке из статьи.
При размере строки 6:
Какая-то мешанина нулей и единиц.
При размере строки 20:
Уже явно какая-то регулярная структура.
При размере строки 6:
...
(1800) 110111
(1806) 100001
(1812) 001011
(1818) 110000
(1824) 011000
(1830) 010010
(1836) 111100
(1842) 000110
(1848) 001001
(1856) 110001
...Какая-то мешанина нулей и единиц.
При размере строки 20:
...
(1800) 11011110000100101111
(1820) 00000110000100101111
(1840) 00000110001001110001
(1860) 00000110000100101111
(1880) 00000110000100101111
(1900) 00000110000100101111
(1920) 00000110001010110011
(1940) 00000110000100101111
(1960) 00000110000100101111
(1980) 00000110000100101111
...Уже явно какая-то регулярная структура.
Так если количество символов кратно 20, то оно кратно и 2, и 5, и 10. То есть если раздвинуть окно на 5 или 10 символов, в последней строчке места тоже не останется.
Очень крутой реверс-инжиниринг — уровень Бог!
Спасибо за перевод.
Спасибо за перевод.
полностью неизвестной архитектуры ЦП без какой-либо документации
Утверждается, что машина имеет 4 регистра общего назначения, 1 кибибайт памяти данных и 32 кибибайта памяти команд
Смешно, в итоге для эксплойта оказались не очень-то нужны результаты реверсинга, его почти наверняка можно было сделать и так. Но само исследование, конечно же, интересное.
А как сама игра работала, на чём? На сервере был какой то эмулятор, который имитировал этот процессор?
После окончания CTF организаторы выложили исходники: github.com/koriakin/cpuadventure. Да, эмулятор.
Заметил в первом параграфе главы «Реверс-инжиниринг архитектуры неизвестного процессора» непонятную формулировку «В первую очередь я начал повторяющиеся части кода».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реверс-инжиниринг неизвестного процессора по единственной программе