krxi/asmsenseKleines Sprachmodell, das Funktionen in gestrippten x86-64-Binärdateien benennt und beschreibt, mit einem offenen Datensatz, Baselines und LoRA-Fine-Tuning-Experimenten.
Englisch · Türkçe
Ein kleines Sprachmodell, das eine Funktion in einer gestrippten Binärdatei betrachtet und ihr einen aussagekräftigen Namen sowie eine kurze Beschreibung gibt.
Das v4-Dataset enthält 228.177 Funktionen aus 341 Projekten über 5 Optimierungsstufen hinweg und ist auf Hugging Face unter der v4-Konfiguration veröffentlicht. Das Ghidra-Skript ist fertig. Das bisher beste kleine Modell, Qwen3-8B + LoRA, trainiert auf den v5-Daten (zuerst Beschreibung, dann Name), erreicht einen Name-F1 von 0,124 auf der festen v4-Teststichprobe und 0,155 auf eval_115; das beste große Modell mit Call-Kontext erreicht 0,167 auf derselben Teststichprobe. Siehe Ergebnisse, Abschnitt 6. Das Modell schreibt neben dem Namen eine englische und eine türkische Ein-Satz-Beschreibung. Der Adapter ist auf Hugging Face verfügbar: krxi123/asmsense-qwen3-8b-lora.
Öffnet man ein gestripptes Programm in Ghidra oder IDA, sieht man Hunderte von Funktionen mit Namen wie FUN_00401a30. Ein Großteil des Reverse Engineerings besteht darin, diese Funktionen eine nach der anderen zu verstehen und zu benennen. Dieses Projekt zielt darauf ab, einem Modell diesen ersten Schritt beizubringen:
input (stripped x86-64) target output
───────────────────────────── ──────────────────────────────────────────────
movzx eax, byte ptr [rsi] name: adler32_update
lea rdx, [rdi + rax] description: Computes the Adler-32 checksum
cmp rdx, 0xfff1 ← 65521 over the bytes of a buffer.
... # TR: Tampondaki baytlar üzerinden Adler-32
# sağlama toplamı hesaplar.
Große Allzweckmodelle können diese Aufgabe bis zu einem gewissen Grad bewältigen, aber sie sind langsam, teuer und in der Cloud gehostet. Das Ziel ist es, diese Frage zu beantworten:
Kann ein kleines Modell, das auf zweckgebauten Daten trainiert wurde, bei dieser Aufgabe mit großen Modellen mithalten oder sie sogar übertreffen – und dabei auf einem Laptop laufen?
Drei Stufen werden auf demselben Testsatz evaluiert:
| Stufe | Modell | Rolle |
|---|---|---|
| Obergrenze | Große offene Modelle (DeepSeek, GLM, MiMo, Gemma, Qwen) | Das derzeit Beste, was mit handelsüblichen Modellen erreichbar ist |
| Baseline | Kleines offenes Modell, vor dem Fine-Tuning | Ausgangspunkt |
| Dieses Projekt | Dasselbe kleine Modell + LoRA auf diesem Datensatz | Der Beitrag des Projekts |
Datengenerierung (cikar.py): Open-Source-C-Projekte werden für x86-64 mit verschiedenen Optimierungsstufen (-O0, -O2) kompiliert. Der Assembly-Code für jede Funktion wird extrahiert. Die Ground Truth – der ursprüngliche Funktionsname – stammt direkt aus dem Quellcode, sodass keine manuelle Kennzeichnung erforderlich ist. projeler.json zeichnet den Commit und die Compiler-Flags auf, die für jedes Projekt verwendet wurden.
Simulieren einer gestrippten Binärdatei: Die Ausgabe ähnelt dem, was Ghidra für eine Funktion in einer gestrippten Binärdatei anzeigt:
sub_01a3, und globale Daten werden zu dat_0042 (die Nummern werden gemischt, mit separaten Namensräumen für -O0 und -O2),loc_1 und loc_2,memcpy, __stack_chk_fail) und String-Literale (; -> "out of memory") bleiben sichtbar, da sie auch in einer echten Binärdatei sichtbar sind.Wenn der echte Name der Funktion in ihrer eigenen Assembly erscheint – zum Beispiel in einer Fehlermeldung – wird die Zeile als sizinti markiert und aus dem Testsatz ausgeschlossen.
Evaluierung (taban.py): Das Modell erhält nur die Assembly und wird gebeten, einen Namen vorherzusagen. Vorhersagen werden anhand der Token-Überlappung (F1) bewertet, sodass nahe Antworten wie crc32_update und update_crc teilweise angerechnet werden.
loc_6:
movzx r9d, byte ptr [rsi + rdx]
add rdi, r9 ← adler32_z (-O2), as the model sees it
add rcx, rdi
inc rdx
cmp rax, rdx
jne loc_6
| Projekte | Funktionen (-O0 + -O2) | |
|---|---|---|
| Training | zlib, libpng, sqlite, lua, mbedtls, zstd, libsodium, expat, brotli, jansson, lz4, libyaml, xxhash, cJSON | 16.804 |
| Test (memorierungsresistent) | tomlc17, cyaml, mu_json_x, sajs, picomatch | 777 → Evaluierungsset 115 |
Der Datensatz ist auf Hugging Face verfügbar: krxi123/asmsense (16.804 Trainingsbeispiele, 777 Testbeispiele, das eval_115-Evaluierungsset und Lizenztexte). Er ist auch auf Kaggle gespiegelt: krxiii/asmsense.
Permissiv lizenzierte (MIT, BSD, Apache-2.0, ISC, zlib) C-Projekte, die mit olcekle.py von GitHub ausgewählt wurden, wurden mit cikar_bin.py (echte dylib + strip -x) bei -O0/-O1/-O2/-O3/-Os kompiliert. Projekt-Build-Skripte wurden nicht ausgeführt; Dateien wurden einzeln mit clang kompiliert, und Dateien oder Projekte, die nicht kompiliert werden konnten, wurden übersprungen. Zeilen wurden nach normalisiertem Assembly-Hash dedupliziert. Zeilen mit Assembly, die mit Validierungs-/Testdaten identisch war, wurden aus dem Training entfernt, während vendored Kopien, deren (Datei, Name)-Paare im Training auftraten, aus der Validierung/dem Test entfernt wurden. Jede Zeile hat ein lisans-Feld.
| Split | Projekte | Zeilen | Eindeutige Quellfunktionen |
|---|---|---|---|
| Training | 290 | 196.117 | 72.179 |
| Validierung | 23 | 19.770 | 6.667 |
| Test (wenig bekannt, ≤200 Sterne, 2024+) | 28 | 12.290 | 4.685 |
Von 473 Projekten erzeugten 352 Zeilen und 120 konnten nicht kompiliert werden (Kernel-, Embedded- oder plattformabhängiger Code). Es wurde nur clang verwendet. Die Daten werden außerhalb von Git gehalten und können mit python3 aday_bul.py und python3 olcekle.py hepsi neu generiert werden.
Der Trainings-/Test-Split ist strikt projektebene: Keine Funktion eines Projekts darf auf beiden Seiten erscheinen. Testprojekte wurden bewusst wenig bekannt gewählt (2-190 Sterne), und die meisten wurden 2024-2025 begonnen, wodurch es weit unwahrscheinlicher ist, dass große Modelle ihnen während des Trainings begegnet sind, als bei einer Bibliothek wie zlib. Lizenzen: veri/LISANSLAR.md.
Bekannte Ausnahme: vendored Code. Ein unabhängiges Audit der veröffentlichten v6-Daten (rapor/arastirma/V6_VERI_DENETIMI.md, veri_denetim_v6.py) bestätigte, dass kein Projekt, keine id oder kein (Projekt, Datei, Name) auf beiden Seiten erscheint, aber das Testprojekt snkv SQLite unter seinen eigenen Dateinamen einbettet, während sqlite ein Trainingsprojekt ist. In der festen 2.000-Zeilen-Teststichprobe haben 217 Zeilen (10,85 %) einen Namen, der mit einer SQLite-Trainingsfunktion identisch ist. Jedes Modell erzielt auf diesen Zeilen niedrigere Werte, sodass sie die Ergebnisse nicht aufblähen; sie verringern stattdessen die Lücke zwischen klein und groß (siehe Ergebnisse, Abschnitt 6). Die Validierungsstichprobe valid_300 enthält 16 ähnliche Zeilen (5,3 %).
Mittlere Name-F1 (1,0 = exakte Übereinstimmung). In der Spalte „Prefix-stripped F1" wird das gemeinsame Namenspräfix jedes Projekts (cyaml_, mu_, sajs_) von beiden Seiten entfernt; das Modell kann dieses Präfix nicht aus der Assembly ableiten.