ЛЛМ панове. Хочу зробити емулятор IL / .NET VM, наприклад для сендбоксінга малварі. Вирішим ось так зробити, взяти фазінг як процес загального контролю над якістю виконання.

Я бачу наступні процеси напівавтоматичного побудови емулятора

  • Процес контролю прогресу виконання
  • Процес реалізації
  • Процес контролю реалізації
  • Процес коригування багу
  • Процес ручного відновлення

Узагальнено процесс можна побачити таким чином.

flowchart TD
    classDef llmTask fill:orange,stroke:#333,stroke-width:4px,color:#333;
    classDef llmGeneratedScript fill:lightGreen,stroke:#333,stroke-width:4px,color:black;
    classDef humanCode fill:green,stroke:#333,stroke-width:4px,color:white;
    START([Початок])
    FINISH([Кінець])

    %% Загальний flow
    START --> Progress
    Progress -->|Реалізувати нову інструкцію| Impl 
    Progress -->|Немає нереалізованих інструкцій| FINISH 
    Impl -->|Успішно| Validation
    Impl -->|Не вийшло реалізувати| RecoveryProcess
    Validation -->|Помилки знайдено| BugFix
    BugFix -->|Успішно| Validation
    BugFix -->|Не вийшло реалізувати| RecoveryProcess
    Validation -->|Успішно| Progress
    Validation -->|Не вийшло реалізувати| RecoveryProcess

Процес контролю прогресу виконання

  1. Будую руками, або через простий скрипт сгенерований ЛЛМ список всіх IL інструкцій. Це буде ручний чекліст того що зроблено. Для кожної інструкції окрім мнемоніки також буде сгенерований опис того що вона робить. Такоже треба витягнути специфікацію поведінки інструкції із ECMA-335. Якщо не витягувати інструкції, а робити простий опис, то фаззер і реалізація буде складніше приходити до правильної поведінки.
  2. Якщо всі тести і фаззінг пройшли, я вважаю що інструкція реалізована і відмічаю це в чеклісті.

Процес реалізації

  1. На вхід ЛЛМ у вигляді промпта подається інструкція яку треба реалізувати, та опис семантичної поведінки цієї інструкції.
  2. Сгенерувати тести на базі специфікації інструкції.
  3. Вручну перевірити тести для інструкції на відповідніть специфікації
  4. Для смоук теста виконання промпта виконується тестові проекти. Якщо все пройшло успішно, чернова реалізація вважається закінченою успішно
  5. Після завершення єтапу потрібно записати результати фінансових витрат в файл фін аудіту скриптом.

Процес контролю реалізації

  1. Пишу руками фаззер який генерує послідовніть інструкцій із дозволеного списка інструкцій реалізованих, або тих які зараз будуть реалізовуватися. Фазер перевіряє виконання сгенерованої послідовністі на емуляторі, і на звичайному .Net рантаймі. Якщо щось відрізняється, це провал. Це рееструється, і із нагенерованої послідовності будується зменшений випадок. Цей зменшений випадок в якійсь мові програмування буде записано в файл.
  2. Якщо чернова реалізація має помилки і сгенерований файл із тесткейсом, то цей тесткейс додається в тестовий проект емулятора. Після чого запускається фаза виправлення багу
  3. Якщо чернова реалізація не має помилок то вважається що поточна реалізація інструкції сталася успішно, і можна вибирати наступну інструкцію для реалізації
  4. Після завершення єтапу потрібно записати результати фінансових витрат в файл фін аудіту скриптом.

Процес коригування багу

  1. ЛЛМ інструктується вирішити всі баги які знайдені в результаті запуску тестового проекту емулятора.
  2. Процес закінчується або через 10 ітерацій спроб виправити помилки, або коли всі помилки в тестовому проекті було виправлено.
  3. Після завершення єтапу потрібно записати результати фінансових витрат в файл фін аудіту скриптом.
  4. Після цього треба почати запуск Процесу контроля реалізації

Процес ручного відновлення

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

Тести які будуть генеруватися фазером

  • тест на індивідуальну інструкцію коли це можливо.
  • тести на генерування виразів
  • тести на завантаження констант
  • тести на контроль потоку виконнаня
  • тести на генерування захищеніх регіонів
  • тести на некоректну поведінку

Також потрібно мати наступні генератори значень

  • весь діапазон Int8/Int16/Int32/Int64/UInt8/UInt16/UInt32/UInt64
  • діпазон в UInt64 навкого UInt64.MaxValue
  • діпазон в UInt64 навкого Int64.MaxValue
  • діпазон в UInt32 навкого UInt32.MaxValue
  • діпазон в UInt32 навкого Int64.MaxValue
  • весь діпазон в Half/Single/Double
  • діпазон навкого 0.0 в Half/Single/Double
  • діпазон від 0.0 до 1.0 в Half/Single/Double
  • діпазон навколо +Inf в Half/Single/Double
  • діпазон навколо чисел із надвеликою експонентою в Half/Single/Double

Весь процесс можна побачити таким чином.

flowchart TD
    classDef llmTask fill:orange,stroke:#333,stroke-width:4px,color:#333;
    classDef llmGeneratedScript fill:lightGreen,stroke:#333,stroke-width:4px,color:black;
    classDef humanCode fill:green,stroke:#333,stroke-width:4px,color:white;
    START([Початок])
    FINISH([Кінець])

    %% Контроль прогресу
    subgraph Progress["Процес контролю прогресу виконання"]
        P1["Згенерувати список всіх IL інструкцій
(вручну або через LLM-скрипт)"]:::llmGeneratedScript P2["Для кожної інструкції:
- мнемоніка
- короткий опис поведінки"]:::llmGeneratedScript P3{"Всі тести та фаззінг пройшли?"} P4["Позначити інструкцію як реалізовану
в чеклісті"] P1 --> P2 --> P3 P3 -->|Так| P4 end %% Реалізація subgraph Impl["Процес реалізації"] I1["Передати в LLM:
- інструкцію
- опис семантики"] I2["Запустити смоук-тести
на тестових проектах"]:::llmTask I3{"Смоук-тести успішні?"} I4["Чернова реалізація завершена"] I5["Записати фінансові витрати
у файл фінансового аудиту"]:::llmGeneratedScript I1 --> I2 --> I3 I3 -->|Так| I4 --> I5 end %% Контроль реалізації subgraph Validation["Процес контролю реалізації"] V1["Фаззер генерує послідовність IL інструкцій"]:::humanCode V2["Порівняти виконання:
- емулятор
- .NET runtime"]:::humanCode V3{"Є відмінності?"} V4["Зареєструвати помилку"]:::humanCode V5["Побудувати minimized testcase"]:::humanCode V6["Записати testcase у файл"]:::humanCode V7{"Чернова реалізація має помилки?"} V8["Додати testcase
в тестовий проект емулятора"]:::llmTask V9["Реалізація інструкції успішна"] V10["Вибрати наступну інструкцію"]:::llmTask V11["Записати фінансові витрати
у файл фінансового аудиту"]:::llmGeneratedScript V1 --> V2 --> V3 V3 -->|Так| V4 --> V5 --> V6 --> V7 V3 -->|Ні| V7 V7 -->|Так| V8 V7 -->|Ні| V9 --> V10 --> V11 end %% Коригування багу subgraph BugFix["Процес коригування багу"] B1["LLM отримує інструкцію
виправити знайдені баги"] B2["Запустити цикл виправлення"]:::llmTask B3{"Всі помилки виправлено?"} B4{"Досягнуто 10 ітерацій?"} B5["Завершити процес виправлення"] B6["Записати фінансові витрати
у файл фінансового аудиту"]:::llmGeneratedScript B7["Повернутися до процесу
контролю реалізації"] B8{"Всі помилки виправлено?"} B1 --> B2 --> B3 B3 -->|Так| B5 B3 -->|Ні| B4 B4 -->|Ні| B2 B4 -->|Так| B5 B5 --> B8 -->|Так| B6 --> B7 B8 -->|Ні| RecoveryProcess[Процес відновлення] end %% Загальний flow START --> Progress Progress -->|Реалізувати нову інструкцію| Impl Progress -->|Немає нереалізованих інструкцій| FINISH Impl -->|Успішно| Validation Impl -->|Не вийшло реалізувати| RecoveryProcess Validation -->|Помилки знайдено| BugFix BugFix -->|Успішно| Validation BugFix -->|Не вийшло реалізувати| RecoveryProcess Validation -->|Успішно| Progress Validation -->|Не вийшло реалізувати| RecoveryProcess

Подивитися в редакторі

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

ОНОВЛЕННЯ [16-05-2026]: Я додав більш детальний опис того що будуть робити генератори тестів. Також додав потребу мати специфікацію на кожну інструкцію. Ця специфікація буде використовуватися для генерації тесті і реалізації.