Skip to content

P0: Typed reads (int/string/struct) + consistent address semantics#207

Closed
mahaloz wants to merge 1 commit into
feat/cli-globals-signaturesfrom
feat/cli-typed-reads
Closed

P0: Typed reads (int/string/struct) + consistent address semantics#207
mahaloz wants to merge 1 commit into
feat/cli-globals-signaturesfrom
feat/cli-typed-reads

Conversation

@mahaloz

@mahaloz mahaloz commented Jul 17, 2026

Copy link
Copy Markdown
Member

What & why

Two related P0 gaps:

  1. DecLib only exposed raw bytes — no typed reads (integers, strings, structs).
  2. Absolute addresses double-added the image base: Ghidra rejected 0x402320 while accepting the image-relative 0x2320, because the backend adds the base to whatever it's given.

New capabilities

  • decompiler read int|string|struct <addr> — decoding happens client-side over read_memory, so every backend is supported:
    • int — decode N bytes (default = pointer size); --size, --signed, --endian.
    • string — NUL-terminated C string; --max-len, --encoding.
    • struct <name> — read a defined struct's bytes and decode each member (offset, name, type, value, hex).
  • Consistent address semantics — every address argument (here, plus read_memory, comment, global, ...) accepts lifted (0x2320), absolute (0x402320), or decimal. _to_lifted_addr rebases absolute addresses (>= image base) to the backend's lifted form, so both refer to the same byte. read_memory now normalizes too — fixing the double-base-add.

Example

$ decompiler read int 0x0 --size 4 --endian big
value: 2130640198          # 0x7f454c46 == "\x7fELF"
$ decompiler read string 0x8e0
Welcome to the admin console, trusted user!
$ decompiler create-type "struct ElfMagic { int magic; short type; }"
$ decompiler read struct 0x0 ElfMagic
struct ElfMagic @ 0x0 (size 8):
  +0x0   magic            int               = 1179403647  (7f454c46)
  +0x4   type             short             = 2           (0200)

# absolute and lifted now agree (was: Ghidra rejected the absolute form)
$ decompiler read_memory 0x402320 4 --format hex
$ decompiler read_memory 0x2320 4 --format hex     # same bytes

Tests

Backend-parametrized: test_read_int_elf_magic (both endians), test_read_string, test_read_struct (decodes the ELF header through a user struct), and test_read_memory_absolute_and_lifted_agree (the double-base-add regression). All pass on IDA, Ghidra, and angr. Tests use isolated project dirs so an interrupted run can't poison the shared Ghidra cache.

CLI-only change — no per-backend code needed, since typed decoding is client-side and address normalization is in the CLI.


Fourth PR in the IDALib-parity series. Based on feat/cli-globals-signatures (#206).

🤖 Generated with Claude Code

https://claude.ai/code/session_01HfZHdprXg38re1XyKxzGg5

Two related P0 gaps: DecLib only exposed raw bytes, and absolute addresses
double-added the image base (Ghidra rejected 0x402320 but accepted the
image-relative 0x2320).

- New `decompiler read int|string|struct <addr>`:
  - `int`  — decode N bytes (default pointer size), --signed/--endian.
  - `string` — NUL-terminated C string, --max-len/--encoding.
  - `struct <name>` — read a defined struct's bytes and decode each member.
  Decoding is client-side over read_memory, so all backends are supported.
- Address normalization: every address argument now accepts lifted,
  absolute, or decimal. `_to_lifted_addr` rebases absolute addresses (>=
  image base) so `read_memory 0x402320` and `0x2320` hit the same byte.
  Applied to read_memory and the new typed reads.
- Tests: read int (ELF magic, both endians), read string (Welcome), read
  struct (decode ELF header via a user struct), and an absolute-vs-lifted
  agreement regression — all pass on IDA, Ghidra, and angr. (Tests use
  isolated project dirs so a killed run can't poison the shared cache.)
- SKILL.md / docs / CLI docstring updated.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HfZHdprXg38re1XyKxzGg5
@mahaloz
mahaloz deleted the branch feat/cli-globals-signatures July 17, 2026 16:35
@mahaloz mahaloz closed this Jul 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant