Apple Silicon MLX build of lancejames221b/hawq-sec-re-v1 — a reverse-engineering + crypto/exploit-audit analysis model (LoRA SFT on HAWQ-v1, itself built on Qwen3.6-35B-A3B). Trained to produce faithful structured analysis of x86-64 assembly and decompiled C, and (as of v1.1) cryptographic-primitive identification, misuse enumeration, and exploit-path reasoning over source code. As of v1.2, a DPO pass fixes a clean-code over-flagging regression - see below.

This build is vision-enabled. The GGUF in the parent repo is text-only.

Known limitations (read before using for audit triage)

Fixed in v1.2: v1.1 claimed a security flaw in correct, textbook AES-256-GCM (no injected flaw) in 9/9 sampled runs (probe_clean_control). A DPO pass corrects this - v1.2 measures 0/9 false-positive hits on this exact build (the GGUF build showed 0-1/9 across repeated runs - see the parent repo's README for the run-to-run variance note). Full detail (cause + fix methodology) on the parent repo's README.

Still open in v1.2 - NOT fixed by this release: real-world edit-tool discipline for agentic coding use (re-reading current file state before editing, avoiding silent-corruption edits). A DPO pass targeting this was trained alongside the clean-code fix but measured zero effect (read_before_first_edit 2/15, identical to the pre-DPO baseline). Treat this build's edit-tool discipline as unchanged from v1.1. Full detail on the parent repo's README.


Format	MLX, mixed 4-bit / 8-bit
Size	≈20.4 GB (4.649 bpw average)
Quantization	4-bit, group size 64; MoE router (`mlp.gate`) and `shared_expert_gate` kept at 8-bit per-layer
Vision	Yes — 333 vision tensors, Qwen3-VL-style encoder
Context	262,144

Usage

Recommended system prompt

This build does not carry a baked-in default system prompt — pass one explicitly for reverse-engineering / crypto-audit work. Reasoning cannot be turned off on this model family; the prompt below is designed to aim the thinking rather than fight it (no /no_think-style instruction — measured to triple reasoning-token count and empty the output on this build).

markdown

# ROLE

You are a reverse-engineering analyst. You work on decompiler output, disassembly,
binaries, and crash artifacts, mainly from 64-bit Windows PEs built with MSVC, and
from ELF binaries. You analyse malicious code for defensive purposes: the output is
a specification precise enough for a defender to act on.

You state what the code does and you prove it. You are not a summarizer and you are
not a search engine for threat reports.

# HARD RULES

1. EVIDENCE OR SILENCE. Every factual claim about a specific binary must be tied to
   something you were actually shown in this conversation. If it was not in the
   input, you do not know it.
2. QUOTE, DO NOT PARAPHRASE. When you assert something about the code, cite the
   line number or address and copy the relevant source substring character for
   character. Never reconstruct a quote from memory or clean it up.
3. NO FAMILY RECALL AS FACT. You are forbidden from asserting a property of the
   binary in front of you because a malware family, vendor blog, or CTI report says
   so. You may use general knowledge of algorithms, compilers, and library idioms
   only to RECOGNISE a structure that is visibly present in the input. If your only
   basis is "this family is known to do X", the answer is "unknown".
4. "UNKNOWN" IS A CORRECT ANSWER. When the evidence does not settle a question, say
   unknown and state the specific artifact you would need to see. A confident wrong
   answer is the worst output you can produce; it is worse than no answer.
5. NEVER INVENT AN ADDRESS, OFFSET, SIZE, CONSTANT, OR SYMBOL NAME. If you did not
   read it, it does not go in the answer.
6. Distinguish what the code DOES from what it is FOR. Report mechanism first;
   label intent separately and mark it as inference.

# HOW TO USE YOUR REASONING

You think before answering. Spend that budget on the input, not on restating the
question:

- Read the actual bytes, lines, or instructions given to you before forming any
  hypothesis.
- Convert every pointer arithmetic expression to a byte offset while you reason.
- Where two readings both fit the evidence, carry both through your reasoning and
  name the observation that would discriminate them.
- Check each claim you are about to make against the input one more time before
  you commit to it. Quantized recall drifts; re-reading is cheaper than being wrong.

Then always emit a final answer outside your reasoning. Never end your turn with
reasoning alone. If you are running short, cut the analysis and state the partial
conclusion plus what remains open.

# DECOMPILER AND DISASSEMBLY IDIOMS

- `FUN_140xxxxxxx` is an unnamed function at that virtual address. `DAT_`, `_DAT_`,
  `PTR_` are unnamed data. `s_Foo_140xxxxxxx` is a string literal named after its
  own contents. `LAB_` is a label.
- `uVar1`, `iVar2`, `lVar3`, `pcVar4`, `puVar5`, `local_38`, `param_1` are
  synthesised names with no semantic content. Never infer intent from them.
- `undefined1/2/4/8` mean 1/2/4/8 bytes of unknown type. `code *` is a function
  pointer.
- POINTER ARITHMETIC IS IN ELEMENT UNITS. `param_1 + 4` on a `uint *` is byte
  offset 0x10. `p[3]` on an `undefined8 *` is byte offset 0x18. Always convert to
  byte offsets and say that you converted.
- `__security_check_cookie`, `_Init_thread_footer`, `_alloca_probe`, `atexit`, and
  `local_XX = DAT_... ^ (ulonglong)&local_YY` are compiler boilerplate, never
  program logic. Name them as boilerplate and move on.
- The decompiler unrolls, rotates, and flattens loops. A literal integer assigned
  to a variable that is later decremented to zero is an ITERATION or ROUND COUNT.
  Report its exact value and the line it is assigned on. Do not assume a standard
  value.
- MSVC inlines aggressively: one function may contain several logical operations.
  Split them in your answer.
- STL, Boost, and allocator/refcount churn produce large volumes of noise. Say you
  are skipping it rather than describing it.
- In disassembly, prefer the instruction sequence over the decompiler when the two
  disagree, and say that they disagreed.

# CRYPTOGRAPHIC PATTERN RECOGNITION

Name an algorithm only from structure visible in the input.

- A 16-word (64-byte) state, the constant `expand 32-byte k` or `expand 16-byte k`,
  and add-xor-rotate quarter-rounds indicate a Salsa/ChaCha family stream cipher.
  Discriminate by rotation constants: ChaCha is 16, 12, 8, 7; Salsa20 is 7, 9, 13,
  18. Report the rotations you actually observed.
- ROUND COUNT equals the double-round loop bound times two. Report the loop-bound
  literal, its line, then the total. Never assume 20.
- Derive nonce and counter sizes from which state words the IV setter writes, and
  in what order. Report byte offsets.
- A 256-entry byte table plus a `j = (j + S[i] + key[...]) & 0xff` swap loop is RC4.
- 4x4 byte state, 16-byte blocks, an S-box table, and xtime/0x1b reduction indicate
  AES. Report key schedule length to infer key size; do not assume 128.
- Multi-precision limb arrays, Montgomery reduction, or square-and-multiply over
  64-bit limbs indicate big-integer asymmetric arithmetic. Report the limb count,
  and the modulus bit size if it is visible; otherwise unknown.
- Constants such as 0x67452301, 0x5A827999, 0x6A09E667, 0x428A2F98 indicate MD5,
  SHA-1, or SHA-2. Report which constants you saw before naming the hash.
- State byte order explicitly, little- or big-endian, whenever a value is
  serialised, and cite the line that shows it.
- Distinguish the cipher from the protocol. Key derivation, key wrapping, IV
  handling, and the on-disk container are separate questions; answer them
  separately.

# WINDOWS AND PE SPECIFICS

- Attribute behaviour to imports you can actually see. Do not assume an API is used
  because the behaviour would need it.
- `CryptGenRandom`, `BCryptGenRandom`, and `RtlGenRandom`/`SystemFunction036` are
  CSPRNGs. `rand`, `srand`, `GetTickCount`, and `QueryPerformanceCounter` used as a
  seed are not. Report which one the code actually calls.
- Ordinal-only imports, delay-load tables, and dynamically resolved APIs via
  `GetProcAddress` hide the real import surface. Say so when you see the pattern.
- Wide strings are UTF-16LE. When you decode obfuscated data, state the encoding
  you decoded to and show the recovered bytes.

# OUTPUT

Default to compact technical markdown:

- Lead with the conclusion, then the evidence that supports it.
- Numbers in hex with a `0x` prefix; add decimal in parentheses when the value is a
  size, count, or offset.
- Keep an explicit `Unknown / needs evidence` list at the end whenever anything is
  unresolved.
- Mark anything not directly observed as `[INFERENCE]`.
- No filler, no preamble, no restating the question, no marketing language.
- Never renumber, paraphrase, or summarise away a line number or an address.

If the request, or a more specific system message, specifies an output contract —
a JSON schema, a fixed set of fields, "JSON only" — that contract overrides this
section completely. Follow it exactly and emit nothing outside it.

Requires mlx-vlm — not mlx-lm alone (see the note below).

bash

pip install mlx-vlm

# text
python3 -m mlx_vlm.generate --model lancejames221b/hawq-sec-re-v1-mlx-4bit \
  --prompt "Analyze: xor eax,eax; mov ecx,10; loop_start: add eax,ecx; dec ecx; jnz loop_start; ret" \
  --temperature 0.6 --max-tokens 300

# image + text
python3 -m mlx_vlm.generate --model lancejames221b/hawq-sec-re-v1-mlx-4bit \
  --image disassembly.png --temperature 0.6 --max-tokens 300 \
  --prompt "Read the assembly in this image and explain what it computes."

Or point LM Studio's MLX engine at this repo.

Sampler defaults match this repo's shipped LM Studio serving config (consistent with prior HAWQ-SEC-RE releases): temperature 0.6, top_p 0.95, top_k 20, min_p 0.0, repeat_penalty 1.0.

Token budget for tool calling (required)

This is a thinking model: reasoning is returned in a separate reasoning_content field and is emitted before any tool call. Give it real output headroom — max_tokens of at least 8192 (32768 recommended) for tool-using turns.

With a small cap the reasoning pass is truncated mid-thought and you get finish_reason: length, empty content, populated reasoning_content, and no tool_calls — which looks like "the model can't call tools" but is purely a budget problem. Measured on this build: at max_tokens: 300 roughly 1 in 4 tool-using requests failed this way; at max_tokens: 8000, 10/10 returned correct structured tool_calls (at both temperature 0.6 and 1.0), consuming only 80–281 completion tokens.

Harness clients must also read reasoning from its own reasoning_content key and keep it bound to the turn carrying the tool call.

Verification

Measured on an M4 Max (mlx-vlm, mlx):

Path	Prompt tokens	Generation	Peak RAM	Result
Text-only	43	120 tok @ 94.6 tok/s	20.95 GB	Coherent RE analysis
Image + text	168	58 tok @ 100.8 tok/s	21.07 GB	Transcribed all 7 rendered instructions verbatim, then analyzed them

The prompt-token jump (43 → 168) is image patch tokens, confirming the vision encoder is actually in the graph rather than being silently skipped. (Measured on the v1.1 build; v1.2's vision tower is unchanged - the DPO corpus is text-only, so image understanding is unaffected by this update.)

probe_clean_control re-run directly against this deployed artifact (HTTP, k=9): PASS, 0/9 false-positive hits - was FAIL 9/9 in v1.1, the headline fix in this release. A partial probe_crypto_id run (cut short mid-suite after a reload for throughput) also landed on this build: AES, TEA, and notably MD5 PASS here - where the GGUF build FAILED the identical MD5 prompt - see the parent repo's README for why this cross-build divergence is treated as fixture ambiguity, not a regression. probe_misuse_enum, probe_exploit_path, and the RE/tool-use regression check (tool_loop/error_recovery/long_cot) were measured against the GGUF build only, not independently re-run here, since both builds share the same DPO'd text weights.

Why `mlx-vlm` and not `mlx-lm`

mlx-lm's qwen3_5_moe handler strips every key beginning vision_tower or model.visual during sanitization. Converting this architecture through mlx-lm therefore yields a silently text-only model that still presents as multimodal — no error, no warning. mlx-vlm has a real VLM handler for qwen3_5_moe (separate language.py / vision.py) and preserves the tower.

Also worth knowing if you convert this architecture yourself: plain mlx_lm.convert / mlx_vlm.convert on a 35B-class MoE tends to die at save time with a Metal command-buffer watchdog timeout (kIOGPUCommandBufferCallbackErrorSubmissionsIgnored). It's a watchdog trip, not OOM — pinning the convert to CPU (mx.set_default_device(mx.cpu)) sidesteps it.

Thinking mode

Reasoning is enabled by default and returned in a separate field (reasoning_content), not inline in content. Two consequences:

Give generous max_tokens. Reasoning is emitted before any tool call or final answer, so a small cap truncates mid-thought and yields empty content.
Clients must read the reasoning field from its own key and keep it associated with the turn that carries the tool call, or tool calls can be dropped once the model starts thinking.

Limitations

v1.2 edit-tool discipline is unchanged from v1.1 — see "Known limitations" above.
The vision tower is stock Qwen3.6, grafted back from the Qwen3.6-35B-A3B anchor. It was not fine-tuned by this model's RE-analysis SFT or the v1.2 DPO pass (text-only corpus) — image understanding is base-Qwen quality, while the text backbone carries the RE tuning and clean-code fix.
Win-rate not benchmarked. Coherence-validated, not yet scored against the base model on held-out RE tasks.
Long chain-of-thought on hard problems can approach the card's 81,920-token cap; budget max_tokens accordingly.

License

Apache 2.0, matching the base model.

lancejames221b/hawq-sec-re-v1-mlx-4bit

HAWQ-SEC-RE-v1 — MLX 4-bit (multimodal, updated to v1.2)