ntraidmode/laya-x64-v4

laya-x64

A local static-analysis model for x86-64 binaries. Reads a function's assembly (and optionally its resolved API imports) and answers a broad set of typed questions with calibrated confidences.

Built on Convai's Laya (ModernBERT-large encoder, 421M params, Apache-2.0). Single checkpoint, single download, one model — you don't need to switch models for different question types.

IDA plugin included. The ida-plugin/ folder in this repo is an IDA 9.4+ plugin: right-click a function to label it, or scan the whole binary in one click.

• License: Apache-2.0
• Format: Laya System-1 checkpoint (loads with pip install laya, laya.load(...)).
• Context: up to 1024 tokens (~300 instructions per function).

What the model can do

Everything below runs from the same checkpoint. Pick the state shape and the questions you want — the model routes itself based on the question definitions.

Function identification

State: {"function": "<asm>"}.

Question	Type	Answers
algorithm	choice (23)	crc32, fnv1a, djb2, sdbm, api_hash_ror13, murmur3, xor_cipher, rc4, tea, chacha_quarter, base64_encode, lcg_prng, xorshift_prng, pointer_encode, memcpy, memset, strlen, strcmp, strcpy, atoi, binary_search, bubble_sort, not_a_known_algorithm
category	choice (9)	hashing, encryption, encoding, prng, pointer_obfuscation, memory_op, string_op, sorting_searching, other

Library / purpose fingerprint

State: {"function": "<asm>", "calls": [...], "constants": [...]} (calls/constants optional, they help).

Question	Type	Answers
library	choice (9)	zlib, lz4, xxhash, cjson, monocypher, mbedtls, lua, sqlite, unknown (a fingerprint — high confidence means the code looks like that library's version, not proof that it came from there)
purpose	choice (15)	compression, cryptography, parsing, database, hashing, math, string, memory, language_runtime, data_structure, encoding, initialization, error_logging, io, other

Build fingerprint & similarity

Question	Type	Answers
compiler	choice (2)	clang, msvc
optimization	yes/no	Was the function built with optimizations enabled?
same_function	yes/no	Given function_a and function_b, do they come from the same source compiled differently? (BinDiff-style similarity primitive)

Vulnerability hints

Question	Type	Answers
vulnerable	yes/no	Does this function contain an exploitable bug?
bug_type	choice (11)	stack_or_heap_buffer_overflow, buffer_overread, format_string, integer_overflow_or_underflow, divide_by_zero, double_free, use_after_free, memory_leak, uninitialized_variable, null_pointer_dereference, none

Honest warning: trained on the NIST Juliet C/C++ suite, which has a distinctive coding style. Reliable on Juliet-shaped code, unreliable on hand-written buggy code. Treat vulnerable=yes as a lead for a human, never as proof.

Windows behavior detection — 28 yes/no tags

State (all keys optional except function):

{
  "function": "<asm>",
  "apis": ["OpenProcess", "VirtualAllocEx", "WriteProcessMemory", "CreateRemoteThread"],
  "api_docs": {
    "OpenProcess": "Opens an existing local process object.",
    "VirtualAllocEx": "Reserves, commits, or changes the state of a region of memory within the virtual address space of a specified process.",
    "WriteProcessMemory": "Writes data to an area of memory in a specified process.",
    "CreateRemoteThread": "Creates a thread that runs in the virtual address space of another process."
  }
}

Tag	Question
other_process	Opens or accesses another process
process_mem_read / process_mem_write	Reads / writes another process's memory
mem_alloc / mem_protect	Allocates memory / changes memory protection
create_thread / remote_thread	Creates a (remote) thread
create_process	Creates or launches a process
file_io / registry	File / registry access
network	Network communication (WinSock, WinInet, WinHttp, DNS)
dynamic_import	Resolves an API or module at runtime (LoadLibrary+GetProcAddress, LdrLoadDll, etc.)
enum_process	Enumerates processes, threads, or modules
keyboard_input / window_ui / clipboard	User input / window / clipboard
crypto	Uses the OS crypto APIs (CryptoAPI, BCrypt, NCrypt)
service / token_priv	Interacts with services / modifies tokens or privileges
sync / inspect_state / environment / shutdown_power	Sync primitives / debug/timing state / env vars / shutdown
driver_io / driver_object / driver_callback / kernel_sync / dpc_apc	Kernel-mode: IRPs/IOCTLs, kernel objects, notifications, spinlocks, DPCs/APCs/timers

Plus a bonus api_category classifier for asking about a single API name (15 categories: process_thread, memory, file, registry, network, crypto, service, security_token, synchronization, user_input_ui, system_query, dynamic_import, shutdown_power, kernel_driver, other).

Coverage: 629 Windows APIs mapped to the 28 behavior tags — Win32, User32, networking (WinSock, WinInet, WinHttp), CryptoAPI, BCrypt/NCrypt, Nt/Zw system calls, and kernel/driver families (Io*, Ex*, Ke*, Mm*, Ob*, Ps*, Cm*, Rtl*, Flt*, Wdf*). 542 of these ship with one-line Microsoft descriptions extracted from the official docs (CC BY 4.0) — the model reads them alongside the API name.

What this model does not answer

• Per-instruction facts for a single-instruction state (like "does add rax, rbx modify CF?"). That question shape isn't in this model's training set — it's the target for a future extension.
• Free-text explanations — Laya is a decision model; it picks from answer sets, it does not write prose.

Files in this repo

Path	What it is
model.safetensors, rl_agent_config.json, encoder/, tokenizer/	The checkpoint
README.md	This model card
NOTICE.md	Third-party attribution (required by CC BY 4.0 for the MSDN API docs)
helpers/	Small Python modules the questions use (api_knowledge.py, api_docs.py, build_labeling.py, build_labeling_v3.py, build_libs.py, gen_dataset.py, laya_x64.py)
ida-plugin/	IDA 9.4+ plugin: laya_plugin.py, server_func.py, ida-plugin.json, README.md
ask.py, ask_func.py, triage.py	CLIs — one-instruction, one-function, whole-object triage

Install and use

pip install laya

The helpers/ folder has the small Python modules the questions need. Drop it next to your script, or add it to sys.path.

Ask an algorithm-identity question:

import laya
from build_labeling import ALGO_OPTIONS, ALGO_Q

agent = laya.load("ntraidmode/laya-x64-v4", device="cuda")
q = {"algorithm": {"type": "choice", "instructions": ALGO_Q,
                   "criteria": {o: None for o in ALGO_OPTIONS}}}
r = agent.predict({"function": open("some_function.asm").read()}, q, max_len=1024)
print(r["answers"]["algorithm"]["choice"])   # e.g. -> crc32

Ask the 28 Windows-behavior tags from a function's imports:

import laya, api_knowledge, api_docs

agent = laya.load("ntraidmode/laya-x64-v4", device="cuda")

apis = ["OpenProcess", "VirtualAllocEx", "WriteProcessMemory", "CreateRemoteThread"]
state = {
    "function": open("some_function.asm").read(),
    "apis": apis,
    "api_docs": {a: api_docs.short_doc(a) for a in apis if api_docs.short_doc(a)},
}
questions = {f"tag_{t}": {"type": "noul", "instructions": api_knowledge.TAG_QUESTIONS[t]}
             for t in api_knowledge.TAGS}
answers = agent.predict(state, questions, max_len=1024)["answers"]

for t in api_knowledge.TAGS:
    a = answers[f"tag_{t}"]
    if a["noul"] >= 0.9:
        print(f"{t:20} yes  ({a['noul']:.0%})")

The IDA plugin does all of this automatically per function: resolves imports from IDA's IAT, looks up MSDN one-liners via api_docs.short_doc(), sends everything as one state object, and writes the labels as a comment on the function. Install steps in ida-plugin/README.md.

Assembly input format

The model expects x86-64 assembly in Intel syntax, one instruction per line, which is exactly what standard disassemblers produce.

mov rax, qword ptr [rsp+0x28]
xor eax, eax
call qword ptr [rip+CreateFileA]
jne short 0x140012340

• Intel syntax — destination first, then source. Not AT&T.
• Lowercase mnemonics and registers.
• Memory operands with an explicit size prefix — byte ptr, word ptr, dword ptr, qword ptr, xmmword ptr, ymmword ptr, zmmword ptr — and square brackets: qword ptr [rbx+rsi*4+0x10].
• Hex immediates with 0x prefix.
• IAT-indirect calls printed as call qword ptr [rip+ApiName]. That's how the model recognizes API calls in stripped code.
• Labels as L1:, L2: on their own line (optional).

The IDA plugin and the CLIs handle syntax normalization automatically — they run Capstone on the raw bytes and produce this format. If you're feeding the model manually, match the shape above.

Worked examples

1. Custom CRC32 (bit-by-bit)

mov eax, 0xffffffff
movzx ecx, byte ptr [rcx]
xor eax, ecx
mov ecx, 8
L1:
mov edx, eax
shr eax, 1
and edx, 1
neg edx
and edx, 0xedb88320
xor eax, edx
dec ecx
jnz L1
not eax
ret

Expected labels:

Question	Answer	Confidence
algorithm	crc32	~99%
category	hashing	~99%
vulnerable	no	~98%

The 0xedb88320 polynomial and shift/xor pattern are the model's dead giveaways. A one-liner CRC using a table (also in training) is recognized just as strongly.

2. FNV-1a hash

mov eax, 0x811c9dc5
test rdx, rdx
je L1
L0:
movzx ecx, byte ptr [rcx]
xor eax, ecx
imul eax, eax, 0x01000193
inc rcx
dec rdx
jnz L0
L1:
ret

Expected:

Question	Answer	Confidence
algorithm	fnv1a	~99%
category	hashing	~99%
library	(low confidence — this is a hand-rolled version)	~40%

The 32-bit FNV offset basis 0x811c9dc5 and prime 0x01000193 are the model's anchor. The 64-bit variant with 0xcbf29ce484222325 / 0x100000001b3 also resolves to fnv1a.

3. Remote-thread injection pattern

sub rsp, 0x40
mov rbx, rcx
mov ecx, 0x1fffff
xor edx, edx
mov r8, rbx
call qword ptr [rip+OpenProcess]
mov rdi, rax
mov r9d, 0x40
mov r8d, 0x3000
mov edx, 0x1000
xor ecx, ecx
mov rax, rdi
call qword ptr [rip+VirtualAllocEx]
mov rbp, rax
xor r9, r9
xor r8, r8
mov rdx, rbp
mov rcx, rdi
call qword ptr [rip+CreateRemoteThread]
add rsp, 0x40
ret

With state:

{
  "function": "<the asm above>",
  "apis": ["OpenProcess", "VirtualAllocEx", "CreateRemoteThread"]
}

Expected behavior tags at ≥ 90%:

Tag	Confidence
other_process	~99%
mem_alloc	~99%
mem_protect	~90% (because 0x40 = PAGE_EXECUTE_READWRITE)
create_thread	~99%
remote_thread	~99%
dynamic_import	no
file_io, registry, network, crypto	no

Notice the model uses both the imports (OpenProcess, VirtualAllocEx, CreateRemoteThread) and the assembly (0x40 constant = PAGE_EXECUTE_READWRITE, 0x1fffff = PROCESS_ALL_ACCESS) to reach these calls.

4. Ordinary code — should light up nothing

mov eax, ecx
add eax, edx
imul eax, 3
ret

Expected:

Question	Answer
algorithm	not_a_known_algorithm (low confidence)
category	other
All behavior tags	no

Reading the confidence

Every answer comes with a calibrated probability.

• >= 90% — trust it.
• 40 – 60% — the model is honestly unsure. Treat as "unknown".
• Treat any vulnerable = yes as a lead for a human, not proof.

Intended use

• Triaging stripped Windows binaries and drivers.
• Answering "does this function talk to another process / touch the registry / make network calls / do crypto?" on every function in a binary.
• Prioritizing which functions to look at first in a large reverse-engineering effort.
• First-pass classification before a slower generative model or a human.

Not a substitute for careful reverse engineering. Think of it as an automated first analyst that reads every function in the binary in milliseconds and surfaces the ones worth your attention.

Training

Fine-tuned on top of convaiinnovations/laya with a mix of:

• Function corpora compiled from 22 reference algorithm implementations (CRC32, FNV-1a, RC4, MurmurHash, TEA, ChaCha, base64, memcpy, strlen, PRNGs, …) across MSVC / clang and several optimization levels.
• Real functions from 8 open-source C libraries (zlib, lz4, xxHash, cJSON, Monocypher, mbedTLS 3.6.2, Lua, SQLite) with clang and MSVC, several -O levels — thousands of paired samples for the similarity question.
• NIST Juliet C/C++ suite (public domain) for the vulnerability questions.
• 58 non-functional C stubs calling representative Windows APIs for each behavior tag, compiled across 10 MSVC configs. Negatives from the library corpora.
• Microsoft API descriptions — one-line description: fields from MicrosoftDocs/sdk-api and windows-driver-docs-ddi (CC BY 4.0) — attached to each function's state at inference time.

Attribution

• Base model: convaiinnovations/laya (Apache-2.0).
• Encoder: ModernBERT-large by Answer.AI / LightOn (Apache-2.0).
• API descriptions: MicrosoftDocs/sdk-api and windows-driver-docs-ddi, © Microsoft, licensed under CC BY 4.0. Retained verbatim in helpers/api_docs.py. See NOTICE.md.
• Library sources used to generate training data: various permissive licenses (zlib, BSD, MIT, Apache-2.0, public domain). See NOTICE.md.
• Juliet C/C++ Test Suite v1.3 (public domain).
• Instruction database: uops.info (CC BY 4.0) + Intel XED (Apache-2.0) — used for compile-time analysis, not embedded in the checkpoint.