Перейти до контенту

IT Технології

Код після ШІ-декомпіляції проходить тести, але поводиться інакше

Іван Характерник 5 хв читання
Два однакові лекала на столі майстерні, поруч три однакові сорочки, на правій золотою лінією позначено шов, що зсунувся
Перевірка проходить на обох, але на рідкісній тканині один відновлений варіант дає інший шов, і без тестів цього не побачити.

ШІ-декомпілятори сьогодні оцінюють за двома ознаками: чи збирається відновлений код і чи проходить він вбудовані тести. Дослідження в arXiv Чана Лю, Едварда Раффа і Крістофера Мічинскі, опубліковане у вересні 2026 року, показує, що цього недостатньо. Автори взяли 12 133 результати ШІ-декомпіляції, які пройшли всі вбудовані тести. Це результати восьми систем у дев’яти конфігураціях на стандартних тестових корпусах. Близько 4,9% із них на інших вхідних даних поводяться інакше. Із цих відмінностей 77% — це зміна результату без жодного краху.

Для компаній, які тримають старі програми без вихідного коду, з цього випливає неприємний висновок: декомпіляція дешевшає, а перевірка того, що відновлений код робить те саме, що й оригінал, лишається дорогою. Питання про те, кому належить результат, який згенерувала модель, ми розбирали в матеріалі про авторське право на ШІ-генерації.

Чому успішна компіляція не доводить, що ШІ-декомпіляція працює

Декомпіляція відновлює читабельний код з бінарного файлу. У дослідженні як базу порівняння беруть Ghidra і Hex-Rays. Навіть вони не завжди дають код, який збирається: частка успішних збірок у Ghidra на тестових даних становить 75%, у Hex-Rays — 81%. LLM-декомпілятори намагаються покращити результат, і їх оцінюють переважно за тими ж двома показниками.

Автори показують, що ці показники можуть хибно оцінювати результат. Функція збирається, проходить усі тести і все одно розходиться з оригіналом на інших вхідних даних. Вбудовані тести цього не помічають. Уразливість, відома з оригіналу, може зникнути з перекомпільованого коду без видимого краху, і лише уважна перевірка це покаже.

Скільки ШІ-декомпільованого коду поводиться як оригінал

Для перевірки на реальному коді дослідники взяли близько 300 бібліотечних функцій з GitHub і 287 функцій, пов’язаних з CVE. На GitHub-функціях найсильніший інструмент доопрацювання на основі LLM, LLM4Decompile, підняв частку функцій, які збираються після Ghidra, з 75% до 90%. Водночас частка функцій, поведінка яких збіглася з оригіналом, упала з 74% до 62%. Більше коду збирається, але менше з нього поводиться як оригінал.

Автори також зазначають, що для однієї з систем розходження сягає 13%. Цифра залежить від інструменту і набору даних, тож загальні 4,9% не варто переносити на будь-який проєкт без перевірки.

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

Реставрація старих ігор і програм за допомогою ШІ

Ручні проєкти на кшталт декомпіляції Super Mario 64 роками доводять відновлений код до побайтової відповідності оригіналу. Код там розповсюджується під CC0, а ігрові ресурси в репозиторій не входять: для збірки потрібна власна копія гри.

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

Чи законна декомпіляція в Україні: що каже стаття 25

Закон про авторське право і суміжні права № 2811-IX, чинний з 1 січня 2023 року, у статті 25 дозволяє законному користувачу комп’ютерної програми декомпілювати її без дозволу правовласника. Але лише за чотирьох умов:

  • Лише для взаємодії. Мета має бути одна: отримати інформацію, потрібну для досягнення взаємодії з іншою незалежно розробленою програмою.
  • Лише те, чого немає у відкритому доступі. Інформація раніше не мала бути доступною цій особі з інших джерел.
  • Лише потрібні частини. Декомпілювати можна тільки ті частини програми, які потрібні для взаємодії.
  • Без передачі і без подібної програми. Отриманою інформацією можна користуватися лише для цієї взаємодії, не можна передавати її іншим особам, крім випадків, коли це потрібно для взаємодії, і не можна використовувати її для створення програми, суттєво подібної за своїм виразом до декомпільованої.

Та сама стаття дозволяє законному користувачу виготовити резервну копію, якщо це необхідно для використання програми. Окремо дозволено спостерігати і досліджувати роботу програми, щоб визначити закладені в ній ідеї і принципи, але лише в процесі звичайних дій із завантаження, показу, функціонування чи збереження програми. Ще одна норма дозволяє вносити зміни, які необхідні виключно для належного використання копії за призначенням, зокрема для виправлення помилок, якщо договором не передбачено інше.

Окремої норми про «право на ремонт» програм у статті 25 немає. Є лише дозвіл виправляти помилки за наведених умов. Загальна норма статті 22 дозволяє відтворювати твір у зв’язку з демонструванням, налаштуванням або ремонтом обладнання, але лише коли перевірити його роботу без використання твору неможливо. Ця норма стосується ремонту обладнання, а не самої програми.

Стаття 25 не згадує штучний інтелект. Стаття 33, яка стосується неоригінальних об’єктів, згенерованих комп’ютерною програмою, теж не називає ШІ, хоча описує результат роботи програми без безпосередньої участі фізичної особи. Тому відкрите питання: чи поширюється виняток для взаємодії на декомпіляцію, виконану LLM, і як оцінювати суттєву подібність, якщо код згенерувала модель. Роз’яснень, які б відповіли на це питання, ми не знайшли. Ширше питання, кому належать права на згенероване ШІ, ми розбирали в матеріалах про захист авторського права на ШІ-генерації і права на ШІ-творчість. Про те, які практики може заборонити закон про ШІ, ми писали окремо: закон про ШІ в Україні.

Декомпіляція legacy-систем: що перевірити ІТ-відділу

Для бізнесу з програмами, написаними десятиліття тому, є інша сторона питання. Thoughtworks описує пілотний проєкт для великого автовиробника: систему з 15 мільйонів рядків COBOL і IDMS. За їхніми даними, аналіз 10 000 рядків, який раніше займав близько шести тижнів двох штатних спеціалістів і експерта-рев’ювера, скоротився приблизно до двох тижнів. Це результат компанії, яка продає такі рішення, і він стосується аналізу вихідного коду, а не декомпіляції бінарників. Це інша задача, ніж у дослідженні вище.

Для ІТ-відділу з цього випливають три кроки:

  • перевірити, чи є у вас законне право на аналіз системи: ліцензія, умови постачальника і стаття 25, якщо йдеться про взаємодію з іншою програмою;
  • порівнювати відновлений код з оригіналом на реальних даних і сценаріях, а не лише за тим, чи він збирається;
  • особливо уважно перевіряти місця, де відмінності не дають видимої помилки.

Ширший огляд ШІ-інструментів для бізнесу — у хабі про штучний інтелект.

Чого поки не відомо

Перевіреної практики ШІ-декомпіляції для державних систем чи 1С-рішень в Україні ми не знайшли. Якщо ваша команда вже пробувала відновлювати такі системи за допомогою LLM, напишіть нам: результати порівняння з оригіналом цікавіші за будь-який демо-кейс постачальника.

Поділитися матеріалом

Два однакові лекала на столі майстерні, поруч три однакові сорочки, на правій золотою лінією позначено шов, що зсунувся Код після ШІ-декомпіляції проходить тести, але поводиться інакше IT delo.net.ua

Куди поділитися