Работа компилятора в картинках-3
А пока, воодушевленный новым прочтением старой статьи Криса Касперски (известного хакера) о разборе условных выражений, решил я затронуть более интересную тему. А именно: возможно ли все-таки превратить скомпилированную exe программу в ее исходный код? Желание обладать такой программой сродни желанию найти Чашу Грааля (кто не знает, эта та посуда, в которую капала кровь Христа; утерянная христианская святыня). Интерес понятен – оставить разработчиков программ «без штанов», изучить алгоритмы работы особо хитрых программ.
Считается, что таких программ-декомпиляторов даже в теории быть не может. Речь идет именно о программах, выдающих «нативный», т.е. родной машинный код. Всякие там СУБД и .NET языки, работающие с промежуточным и байт-кодом, не в счет. Конечно, автор статьи в свое время тоже потратил некоторое время, забавляясь этой тематикой, ничего не добился, но кое-какие новые мысли появились.
Например, оформилось четкое впечатление об используемых библиотеках. Любая программа, какой бы она ни была, нуждается в библиотеках – для расчета математических выражений, для вывода строки на экран, для записи в файл. Даже если программа пишется без учета особенностей операционной системы (например, загрузчик ОС), все равно в ней присутствует вызов библиотек BIOS. Таким образом, будем называть «штатные», т.е. стандартные библиотеки RTL – исполняющей средой, в отличие от пользовательских библиотек. Заметим еще, что RTL библиотеки могут иметь свои начальные настройки, обращаться к RTL более высокого или низкого уровня. Таким образом, любая программа состоит из собственно программы, ее библиотек и RTL. И последняя, будучи стандартной, всегда может быть однозначно идентифицирована. Как в примере из первой статьи, где вызов call [xxxx:0116] всегда означает вызов завершения программы. Точно также, имеются известные адреса, по которым можно понять вызовы readln, writeln, sin и т.д. Важный момент: у того же Паскаля модули crt, graph, dos, printer и другие присоединяются к программе «как есть».
Написав об этом в первый раз, я долго искал технические данные, но не нашел их: возможно, что некоторые функции и процедуры стандартных библиотек импортируются отдельно, по мере использования, но это не столь принципиально. В конце концов, их «узнавание» можно проводить и по кодовым последовательностям (сигнатурам) – точно так же, как раньше антивирусы определяли наличие вирусов. Как вы видели из прошлых статей, сама программа имеет довольно короткий размер (если речь идет об учебном материале). При этом большинство конструкций генерируются в код типичным образом. Более того, они узнаются глазами при анализе кода! Так почему же нельзя свернуть машинный код обратно в исходный? Все же кажется, что можно, но только это будет не автоматическое распознавание, а полуавтоматическое, т.е. оператору-программисту придется на каждом шаге восстановления «поправлять» полученный код, приводя его к исходному. К примеру, различая типы integer и word – знаковые и беззнаковые целые числа длиной в 16 бит. Наличие остальных стандартных примитивных типов тоже не должно вызывать особых трудностей: по коду видно, как компилятор обращается к типу longint (4 байта), real (3 байта) и т.д. В уточнении будут нуждаться составные структуры – record, array, set.
Таким образом, останется свернуть конструкции условных выражений и циклов, определиться с типами переменных и структур, разделить вызовы пользовательских и RTL библиотек, а в последних выявить точки входа для заранее известных подпрограмм. Известных – то есть мы должны знать механизм передачи данных для каждой подпрограммы, т.е. API. И все это построить в виде Мастеров, способных перенастраиваться на предыдущие шаги для коррекции результатов. И такие декомпиляторы придется писать не только для каждого языка с его реализацией, но и для каждой версии компилятора. Трудно? Чудовищно трудно. Но результат, даже половинчатый, многократно окупит все затраты на разработку. Подумайте над этим. | 
