Чи є якісь розумні випадки зміни коду виконання?

Чи можете ви придумати будь-які законні (розумні) використання для зміни коду виконання (програма, що модифікує власний код під час виконання)?

Сучасні операційні системи, схоже, нахмурилися на програми, які роблять це, оскільки віруси використовували цю методику, щоб уникнути їх виявлення.

Все, що я можу придумати, - це якась оптимізація виконання, яка видалила б або додала якийсь код, знаючи щось під час виконання, що не може бути відоме під час компіляції.

Існує багато дійсних випадків для зміни коду. Генерування коду під час виконання може бути корисним для:

• Деякі віртуальні машини використовують компіляцію JIT для підвищення продуктивності.
• Генерування спеціалізованих функцій на льоту вже давно поширене в комп'ютерній графіці. Див., Наприклад, Роб Пайк та Барт Локанті та Джон Різер апаратне програмне забезпечення для програмного забезпечення для графічних зображень на блиску (1984) або цю публікацію (2006) Кріс Леттнер про використання LLVM від Apple для спеціалізації коду виконання у своєму стеку OpenGL.
• У деяких випадках програмне забезпечення вдається до техніки, відомої як батут, яка передбачає динамічне створення коду на стеку (або іншому місці). Прикладами є вкладені функції GCC та механізм сигналу деяких Unices.

Іноді код перекладається в код під час виконання (це називається динамічним бінарним перекладом ):

• Емулятори, такі як Apple Rosetta, використовують цю техніку для прискорення емуляції. Інший приклад - програмне забезпечення, яке перетворює код Transmeta .
• Складні налагоджувачі та профілі, такі як Valgrind або Pin, використовують його для інструменту коду під час його виконання.
• До того, як розширення були зроблені до набору інструкцій x86, програмне забезпечення для віртуалізації, як VMWare, не могло безпосередньо запускати привілейований код x86 всередині віртуальних машин. Натомість їй довелося перекладати будь-які проблемні інструкції на льоту в більш відповідний спеціальний код.

Модифікація коду може бути використана для обходу обмежень набору інструкцій:

• Був час (давно, я знаю), коли комп'ютери не мали вказівки повертатися з підпрограми або непрямо звертатися до пам'яті. Самовиправляючий код був єдиним способом реалізації підпрограм, покажчиків та масивів .

Більше випадків зміни коду:

• Багато налагоджувачів замінюють інструкції щодо впровадження точок прориву .
• Деякі динамічні лінкери змінюють код під час виконання. Ця стаття надає деяку інформацію про переїзд DLL-файлів Windows, що фактично є формою модифікації коду.

Це було зроблено в комп'ютерній графіці, зокрема програмному забезпеченні для оптимізації. Під час виконання проаналізується стан багатьох параметрів і створюється оптимізована версія коду растерізатора (потенційно виключаючи багато умовних умов), що дозволяє візуалізувати графічні примітиви, наприклад трикутники, набагато швидше.

Однією з дійсних причин є те, що в наборі інструкцій ASM відсутні деякі необхідні інструкції, які ви могли б скласти самостійно. Приклад: На x86 немає способу створити переривання до змінної в регістрі (наприклад, зробити переривання з номером переривання в ax). Дозволені лише номери const, кодовані в коді. За допомогою самомодифікуючого коду можна наслідувати цю поведінку.

Деякі компілятори використовували його для ініціалізації статичної змінної, уникаючи вартості умовного для наступного доступу. Іншими словами, вони реалізують "виконати цей код лише один раз", замінивши цей код без відключення під час першого виконання.

Є багато випадків:

• Віруси зазвичай використовують самомодифікуючий код, щоб "знешкодити" свій код перед виконанням, але ця техніка також може бути корисною для розчарування зворотної інженерії, злому та небажаного хакерства
• У деяких випадках може бути певний момент під час виконання (наприклад, відразу після читання файлу конфігурації), коли відомо, що - протягом усього часу процесу - певна гілка завжди або ніколи не буде прийнята: а не без потреби. перевіривши якусь змінну, щоб визначити, яким способом розгалуження, саму інструкцію гілки можна було відповідно змінити
  • Наприклад, може стати відомо, що буде оброблятися лише один із можливих похідних типів, таким чином, щоб віртуальну відправлення можна було замінити конкретним викликом
  • Виявивши, яке обладнання доступне, використання відповідного коду може бути жорстко закодовано
• Непотрібний код можна замінити на інструкції без використання або перестрибувати його, або перенести наступний біт коду прямо на місце (простіше, якщо використовувати незалежні від позиції опкоди)
• Код, написаний для полегшення власної налагодження, може ввести інструкцію щодо пастки / сигналу / переривання, очікуваної налагоджувачем у стратегічному місці.
• Деякі вирази предикатів, засновані на введенні користувача, можуть бути складені у власний код бібліотекою
• Вкладені кілька простих операцій, які не видно до часу виконання (наприклад, з динамічно завантаженої бібліотеки) ...
• Умовно додаючи кроки самоінструментації / профілювання
• Тріщини можуть бути реалізовані як бібліотеки, які змінюють код, який завантажує їх (не "само" змінюючи точно, але потребують однакових методів та дозволів).
• ...

Деякі моделі безпеки ОС означають, що самовиправляючий код не може працювати без привілеїв root / admin, що робить його недоцільним для загального використання.

З Вікіпедії:

Прикладне програмне забезпечення, що працює в операційній системі зі строгим захистом W ^ X, не може виконувати вказівки на сторінках, на які дозволено записувати, - лише сама операційна система має змогу як вводити інструкції в пам'ять, так і пізніше виконувати ці інструкції.

У таких ОС навіть такі програми, як Java VM, потребують привілеїв root / admin для виконання свого JIT-коду. (Докладніші відомості див. На веб-сайті http://en.wikipedia.org/wiki/W%5EX )

Синтез OS в основному частково оцінив програму за викликами API, і замінити код ОС з результатами. Основна перевага полягає в тому, що багато перевірок помилок пішло (адже якщо ваша програма не буде просити ОС зробити щось дурне, це не потрібно перевіряти).

Так, це приклад оптимізації виконання.

Багато років тому я провів ранок, намагаючись налагодити якийсь код, що змінюється, одна інструкція змінила цільову адресу наступної інструкції, тобто я обчислював адресу філії. Він був написаний мовою асемблера і прекрасно працював, коли я переходив через програму по одній інструкції за раз. Але коли я запустив програму, це не вдалося. Врешті-решт я зрозумів, що машина отримує 2 вказівки з пам’яті і (як інструкції були викладені в пам’яті), інструкція, яку я змінював, вже була отримана, і, отже, машина виконує немодифіковану (неправильну) версію інструкції. Звичайно, коли я налагоджував, то робив лише одну інструкцію за раз.

Моя думка, самовимінюючий код може бути дуже неприємним для тестування / налагодження і часто має приховані припущення щодо поведінки машини (будь то апаратне чи віртуальне). Більше того, система ніколи не може ділитися кодовими сторінками між різними потоками / процесами, що виконуються на (тепер) багатоядерних машинах. Це позбавляє багатьох переваг віртуальної пам’яті тощо. Це також призведе до скасування оптимізації гілок, зроблених на апаратному рівні.

(Примітка - я не включаю JIT до категорії коду, що змінюється. JIT перекладається з одного представлення коду на альтернативне представлення, воно не змінює код)

Загалом, це лише погана ідея - дійсно акуратне, дійсно незрозуміле, але насправді погано.

Звичайно - якщо у вас є лише 8080 та ~ 512 байт пам'яті, можливо, вам доведеться вдатися до подібних практик.

З точки зору ядра операційної системи кожен Just In Time Compiler та Linker Runtime виконує самомодифікацію тексту програми. Видатним прикладом може бути перекладач сценаріїв V8 ECMA від Google.

Ще одна причина самовиправляючого коду (насправді "самогенеруючий" код) - це реалізація механізму компіляції Just-In-Time для продуктивності. Наприклад, програма, яка зчитує алгебричний вираз і обчислює його на діапазоні вхідних параметрів, може перетворити вираз у машинний код перед тим, як заявити обчислення.

Ви знаєте старий каштан, що між технічним і програмним забезпеченням немає логічної різниці ... можна також сказати, що між кодом і даними немає логічної різниці.

Що таке самозмінний код? Код, який містить значення в потоці виконання, щоб його можна було сприймати не як дані, а як команду. Звичайно, є теоретична точка зору у функціональних мовах, що насправді немає різниці. Я кажу про те, що це може зробити прямо в мовних імперативних мовах та укладачах / перекладачах без презумпції рівного статусу.

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

Тому навіть у звичайному випадку, коли компілятор створює кодовий простір і посилається на повністю окремий простір даних (купу), все одно можна змінювати дані, щоб явно змінити шлях виконання.

Я реалізував програму, використовуючи еволюцію, щоб створити найкращий алгоритм. Він використовував самомодифікуючий код для модифікації проекту ДНК.

Одним із випадків використання є тестовий файл EICAR, який є законним виконуваним файлом COM для DOS для тестування антивірусних програм.

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Він повинен використовувати модифікацію самокодування, оскільки виконуваний файл повинен містити лише символи ASCII, що можна друкувати / вводити, у діапазоні [21h-60h, 7Bh-7Dh], що суттєво обмежує кількість інструкцій, що кодуються

Деталі пояснюються тут

Він також використовується для диспетчеризації операцій з плаваючою комою в DOS

Деякі компілятори будуть випромінювати CD xxз xx в межах від 0x34-0x3B в місцях x87 інструкцій з плаваючою комою. Оскільки CDє опкодом для intнавчання, він перескочить на переривання 34h-3Bh та емулює цю інструкцію в програмному забезпеченні, якщо копроцесор x87 недоступний. В іншому випадку обробник переривання замінить ці 2 байти на 9B Dxтак, що пізніші виконання будуть оброблятися безпосередньо x87 без емуляції.

Що таке протокол емуляції з плаваючою крапкою x87 в MS-DOS?

Ядро Linux має Офлайн модулі ядра , які роблять саме це.

Emacs також має цю здатність, і я її постійно використовую.

Все, що підтримує динамічну архітектуру плагінів, істотно модифікує її код під час виконання.

Я запускаю статистичний аналіз на основі постійно оновлюваної бази даних. Моя статистична модель записується і переписується щоразу, коли код виконується для розміщення нових даних, які стають доступними.

Сценарій, за якого це можна використовувати, - це програма навчання. У відповідь на введення користувача програма вивчає новий алгоритм:

1. він шукає існуючу базу коду для аналогічного алгоритму
2. якщо аналогічного алгоритму немає в базі коду, програма просто додає новий алгоритм
3. якщо існує аналогічний алгоритм, програма (можливо, за допомогою допомоги користувача) змінює існуючий алгоритм, щоб він міг обслуговувати як стару, так і нову мету

Виникає питання, як це зробити на Java: Які можливості для самомодифікації коду Java?

Найкращою версією цього може бути Lisp Macros. На відміну від макросів C, які є лише препроцесором, Lisp дозволяє вам мати доступ до всієї мови програмування в усі часи. Це про найпотужнішу особливість у Lisp і не існує жодної іншої мови.

Я ні в якому разі не експерт, але змусити когось із хлопців, що розмовляють, про це говорять! Є причина, по якій вони кажуть, що Лісп - це найпотужніша мова навколо, а розумні люди не так, що, мабуть, вони праві.