Реверс-инжиниринг

[metaclass]

Посетила мысль, что реверс-инжиниринг форматов файлов при наличии проги работающей с ними, можно было бы автоматизировать, имея виртуальную машину с функцией "пометить область данных тэгом" и затем рассматривать продвижение оного тэга по памяти, вплоть до отображения результата на экране.
Частичный вариант оного - менять ручками байты в файле и смотреть как это отражается на работе программы.

Comments

[1ceheart.livejournal.com]

Ну это нужно instruction-level эмулятор, потому что, грубо говоря, мы делаем "mov eax, [esi]; mov [edi], eax" и эмулятору надо будет понимать, что вот, если esi показывает в "помеченную область", то потом eax тоже надо пометить, а потом пометить [edi]. При этом отследить логические связи вообще малореально - например, мы делаем "xor eax, eax; mov [edi], eax" - и формально содержимое [edi] взялось из ниоткуда, но при этом логически оно может быть связано с [esi], т.к. до этого мы сделали "cmp [esi], ebx; jnz l1". В общем, в лучшем случае удастся относительно надежно отслеживать тупое копирование.

А реверс-инжиниринг формата чаще делается все равно наоборот (если есть возможность): т.е. в проге делаются небольшие изменения в данных и смотрится, что поменялось в файле. Это проще. Впрочем, от формата зависит тоже и от проги :)

[metaclass.livejournal.com]

Да, кстати, вторая возможность у меня имеется, хехе.

[vp.livejournal.com]

Задолбаться можно, честно говоря, меняя входной поток данных смотреть на то, что изменится в работе "черного ящика".

[inhate.livejournal.com]

А зачем вообще реверс-инжинирить-то? Не проще ли просто взять описание формата и реализовать его...

[metaclass.livejournal.com]

Есть проприетарные форматы и есть описанные так, что без реверс-инжиниринга не разберешься.