# retdec recipe — 01_memset

retdec runs fully automated — hand it the binary, ask for C.

## Invocation (on the decompme container at pve4, or wherever retdec lives)

```
retdec --mode raw --arch arm --endian little --bit-size 64 \
    --raw-entry-point 0x0aac \
    --raw-section-vma 0x0aac \
    func.bin -o retdec.c
```

The flags:
- `--mode raw` — input is a flat binary, no PE/ELF headers.
- `--arch arm --endian little --bit-size 64` — AArch64 LE.
- `--raw-entry-point 0x0aac` — tell retdec where execution starts.
- `--raw-section-vma 0x0aac` — load the binary at address 0x0aac so
  branch targets resolve correctly.

Output goes to `retdec.c`. retdec emits a .ll (LLVM IR) and a .dsm
(disasm) alongside — all useful for comparison.

## What to expect

retdec is the least "smart" of the three tools. For a raw 28-byte blob
with no headers, it will:
- Detect the function at 0x0aac.
- Produce a C function named `function_aac` or similar.
- Often inserts pseudo-intrinsics like `__asm_mov(x3, 0)` for instructions
  it doesn't fold into C. For this tiny loop it usually manages clean C.

## Benchmark notes

- Strength: zero-touch, scriptable, good for bulk processing.
- Weakness: no interactive refinement — you get what you get. Type
  inference is conservative (`int32_t *` instead of `void *` / `uint8_t *`).
- Often emits control flow as `goto` rather than structured loops.