krxi/asmsenseModelo de linguagem pequeno que nomeia e descreve funções em binários x86-64 despojados, com um conjunto de dados aberto, baselines e experimentos de ajuste fino LoRA.
Inglês · Turco
Um pequeno modelo de linguagem que analisa uma função em um binário sem símbolos e lhe dá um nome significativo e uma breve descrição.
O conjunto de dados v4 contém 228.177 funções de 341 projetos em 5 níveis de otimização e está publicado no Hugging Face sob a configuração v4. O script Ghidra está pronto. O melhor modelo pequeno até agora, Qwen3-8B + LoRA treinado com os dados v5 (descrição primeiro, depois nome), alcança F1 de nome 0,124 na amostra de teste v4 fixa e 0,155 no eval_115; o melhor modelo grande com contexto de chamadas pontua 0,167 na mesma amostra de teste. Veja Resultados, seção 6. O modelo escreve uma descrição de uma frase em inglês e em turco junto com o nome. O adaptador está no Hugging Face: krxi123/asmsense-qwen3-8b-lora.
Abra um programa sem símbolos no Ghidra ou IDA e você verá centenas de funções chamadas FUN_00401a30. Grande parte da engenharia reversa consiste em entender e nomear essas funções uma a uma. Este projeto visa ensinar a um modelo esse primeiro passo:
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.
Modelos grandes de propósito geral conseguem lidar com esta tarefa até certo ponto, mas são lentos, caros e hospedados na nuvem. O objetivo é responder a esta pergunta:
Um modelo pequeno treinado com dados criados especificamente para esse fim consegue igualar ou até superar modelos grandes nesta tarefa—enquanto roda em um laptop?
Três níveis são avaliados no mesmo conjunto de teste:
| Nível | Modelo | Papel |
|---|---|---|
| Teto | Modelos abertos grandes (DeepSeek, GLM, MiMo, Gemma, Qwen) | O melhor atualmente alcançável com modelos prontos para uso |
| Linha de base | Modelo aberto pequeno, antes do fine-tuning | Ponto de partida |
| Este projeto | O mesmo modelo pequeno + LoRA neste conjunto de dados | A contribuição do projeto |
Geração de dados (cikar.py): Projetos C de código aberto são compilados para x86-64 em diferentes níveis de otimização (-O0, -O2). O assembly de cada função é extraído. O ground truth—o nome original da função—vem diretamente do código-fonte, então nenhuma rotulagem manual é necessária. projeler.json registra o commit e as flags do compilador usados para cada projeto.
Simulando um binário sem símbolos: A saída se assemelha ao que o Ghidra mostra para uma função em um binário sem símbolos:
sub_01a3, e dados globais se tornam dat_0042 (os números são embaralhados, com namespaces separados para -O0 e -O2),loc_1 e loc_2,memcpy, __stack_chk_fail) e literais de string (; -> "out of memory") permanecem visíveis porque também são visíveis em um binário real.Se o nome real da função aparecer em seu próprio assembly—por exemplo, em uma mensagem de erro—a linha é marcada como sizinti e excluída do conjunto de teste.
Avaliação (taban.py): O modelo recebe apenas o assembly e é solicitado a prever um nome. As previsões são pontuadas por sobreposição de tokens (F1), então respostas próximas, como crc32_update e update_crc, recebem crédito parcial.
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
| Projetos | Funções (-O0 + -O2) | |
|---|---|---|
| Treino | zlib, libpng, sqlite, lua, mbedtls, zstd, libsodium, expat, brotli, jansson, lz4, libyaml, xxhash, cJSON | 16.804 |
| Teste (resistente à memorização) | tomlc17, cyaml, mu_json_x, sajs, picomatch | 777 → conjunto de avaliação 115 |
O conjunto de dados está disponível no Hugging Face: krxi123/asmsense (16.804 exemplos de treino, 777 exemplos de teste, o conjunto de avaliação eval_115 e textos de licença). Também está espelhado no Kaggle: krxiii/asmsense.
Projetos C com licenças permissivas (MIT, BSD, Apache-2.0, ISC, zlib) selecionados do GitHub com olcekle.py foram compilados em -O0/-O1/-O2/-O3/-Os usando cikar_bin.py (dylib real + strip -x). Os scripts de build dos projetos não foram executados; os arquivos foram compilados individualmente com clang, e arquivos ou projetos que falharam na compilação foram ignorados. As linhas foram deduplicadas por hash de assembly normalizado. Linhas com assembly idêntico aos dados de validação/teste foram removidas do treino, enquanto cópias vendorizadas cujos pares (arquivo, nome) apareciam no treino foram removidas da validação/teste. Cada linha possui um campo lisans.
| Divisão | Projetos | Linhas | Funções-fonte únicas |
|---|---|---|---|
| Treino | 290 | 196.117 | 72.179 |
| Validação | 23 | 19.770 | 6.667 |
| Teste (pouco conhecidos, ≤200 estrelas, 2024+) | 28 | 12.290 | 4.685 |
De 473 projetos, 352 produziram linhas e 120 falharam na compilação (código de kernel, embarcado ou dependente de plataforma). Apenas clang foi usado. Os dados são mantidos fora do Git e podem ser regenerados com python3 aday_bul.py e python3 olcekle.py hepsi.
A divisão treino/teste é estritamente em nível de projeto: nenhuma função de um projeto pode aparecer em ambos os lados. Os projetos de teste foram deliberadamente escolhidos por serem pouco conhecidos (2-190 estrelas), e a maioria foi iniciada em 2024-2025, tornando muito menos provável que modelos grandes os tenham encontrado durante o treino do que uma biblioteca como zlib. Licenças: veri/LISANSLAR.md.
Exceção conhecida: código vendorizado. Uma auditoria independente dos dados v6 publicados (rapor/arastirma/V6_VERI_DENETIMI.md, veri_denetim_v6.py) confirmou que nenhum projeto, id ou (projeto, arquivo, nome) aparece em ambos os lados, mas o projeto de teste snkv incorpora o SQLite sob seus próprios nomes de arquivo, enquanto sqlite é um projeto de treino. Na amostra fixa de 2.000 linhas de teste, 217 linhas (10,85%) têm um nome idêntico a uma função de treino do SQLite. Todos os modelos pontuam mais baixo nessas linhas, portanto elas não inflam os resultados; elas estreitam a diferença entre pequeno e grande (ver Resultados, seção 6). A amostra de validação valid_300 contém 16 linhas semelhantes (5,3%).
F1 médio de nomes (1,0 = correspondência exata). Na coluna "F1 com prefixo removido", o prefixo comum de cada projeto (cyaml_, mu_, sajs_) é removido de ambos os lados; o modelo não pode inferir esse prefixo a partir do assembly.