Русский дизассемблер

Дизасемблювання - невід'ємна частина світу програмування, як археологія, історія в світі людському. І якщо друге пройшло вже кілька етапів розвитку - від машинного кодування до блочно модульного в мовах високого рівня, а тепер перейшло і на рівень системного програмування в візуал-мовах, то перше досі тупцює на першому етапі. Адже до сих пір згадують SOURSER. І в тій же IDA PRO, яка вважається найкращою, людині досі доводиться вирішувати елементарні завдання - в ручну визначати, де байти, а де коди. Але ж пора б перейти і на блочно-модульне дизасемблювання з виходом на тексти мови високого рівня. Причиною тупцювання на місці вважаю невдалу ідеологію дизассемблирования (лінійну) в цих, та й інших дизассемблера теж. Представляючи свій дизассемблер RD16.exe, намагаюся продемонструвати і нову ідеологію дизассемблирования (мозаїчну), яка дозволяє більш ефективно і більш якісно вирішувати ті ж завдання. Вважаю, що і перспектива розвитку дизассемблирования відкривається інша.

Історія народження

Походження Російського дизассемблера досить давнє. Це почалося ще в Радянські часи, коли IBMок у нас ще й не було, але з'явилися перші аматорські комп'ютери. Зокрема "Спеціаліст", якщо хтось ще пам'ятає. Тоді на його базі я зробив свій комп'ютер "Спеціаліст_МХ", з RAMDISKом, з "операційною системою" за зовнішнім подобою "Нортона", з дисками. Встиг по тиражувати по країні. Ось тоді я і зіткнувся з потребою дизассемблирования. З одного боку це чудова практика пізнання ассемблерного мови, і школа навчання писати на ньому. З іншого боку це зручний спосіб адаптації програм до нових потреб. А коли справа дійшла до великих програм типу LAYOUT, BASIC, то потрібен був дизассемблер більш потужний. Ось тоді я і написав свій перший дизассемблер. Саме в ньому я тоді застосував і відпрацював свою ідеологію дизассемблирования і вельми успішно. Правда, тоді я не думав, що вона якась особлива, вважав само собою зрозумілою.

Однак настав час, "Спеціаліст" тихо пішов з життя. І я перейшов уже на більш сучасну техніку. Так вже вийшло, що перше, з чим я познайомився, виявився дизассемблер SOURSER. Ох вже й поплювавши я тоді. Покласти в основу автоматичного дизассемблирования абсолютно невірну ідеологію, буквально з точністю до навпаки. Втім, до першопрохідців все одно треба ставитися з повагою. Їм завжди важче. Ось тоді я і вирішив не дати померти своєю ідеєю, перекласти її на сучасний комп'ютер.

Шлях був не легкий і не швидкий. Писати бібліотеку команд тоді було просто немислимо. Інформації явно не вистачало. Довелося взяти з SOURSERa версії 1.07. Дизасемблювати її за допомогою версії 3.07. Угробити купу тижнів, перш ніж отримав прийнятний текст. Та й далі досить довго багато шматки програм не можна було чіпати, поки не утряс все OFFSETи та інше.

В результаті народився RD16, в якому від SOURSERa залишилася тільки бібліотека команд. Набір процесорів теж збережений, правда, все їх не перевіряв, не було на чому. Однак тепер тип процесора визначається автоматично. В результаті тепер на RD16 ту ж саму роботу можна зробити і за один вечір. До речі, свої програми не погано перевіряти дизассемблером. Видно стають багато помилок в програмі. Та й сміття випливає багато. Трапляється, процедури, раніше використовувані, а потім вимкнені, залишаються.

Ідеологія дизассемблирования

У SOURSERe основна увага була приділена першої функції - автоматичності. Однак ефективність машинної роботи була низька. Та й звідки вона могла взятися за примітивному лінійному алгоритмі - суціль декодуючими все байти файлу, а потім гадай, де реальні коди, а де помилкові. Навіть людині не просто вирішити цю задачу. І він то, найчастіше, застосовує метод "наукового тику", з натхнення. А як машину навчити цьому натхнення?

У IDA PRO увагу вже приділили другої функції - інтерактивності. І напрацювали потужний ресурс для ручної роботи. Однак примітивний алгоритм машинної роботи залишився в загальному колишнім. І тому чимала частина цього ресурсу спрямована на компенсацію неефективною машинної роботи.

Всі програми складаються з двох частин - області коду і області даних. І завдання дизассемблирования насамперед розібратися - що і де. Навантажувати людини цією роботою нерозумно. Надто вже вона рутинна і об'ємна. Тому поділ праці має бути не тільки кількісне, а, перш за все, якісне. Ясно, що людина розумніша будь-якої машини. Тому і займатися він повинен найрозумнішою роботою, залишивши машині всю примітивну і рутинну. Інакше кажучи, машина повинна виявляти машинну функцію байтів коду, а людина її смислове функцію.

Головною частиною програми, звичайно, є код, а область даних, як додаток до нього і тому як би вторинна. Саме це уявлення зіграло злий жарт з розробниками дизассемблеров. Вони своє уявлення передали і дизассемблера у вигляді узагальненого принципу. Вся дізассембліруемая програма є ОБЛАСТЮ КОДА, і завдання машини в автоматичному режимі виявити області даних. А для того щоб машина вирішила завдання в цьому режимі чітко і однозначно, їй повинні бути надані також чіткі і однозначні інструкції. А їх на жаль, просто не існує при тій ідеології. Тому світ дизассемблирования і тупцює на місці.

Російська ідеологія

Крім основного процесу є і попутні, паралельні. Наприклад, не маловажной завданням є виявлення OFFSETних міток. Тут дизассемблера дана інструкція - при зустрічі команд звертаються до пам'яті, зверни увагу на регістр слова використовується для цього. Потім озирнися назад і знайди місце, де була остання завантаження в цей регістр, і в цьому місці залиш самому собі додаткову інструкцію - автоофсет. На наступному проході вона буде відпрацьована. Зрозуміло, машині не завжди вдається вирішити цю задачу, тому на другому проході машині дана інструкція - все місця завантаження регістрів без автоофсета познач, як проблемні, на допомогу людині.

Схожі статті