[GH-ISSUE #4538] [Feature] Inspect Android DEX debug metadata (lines, locals, parameter names) #2364

Open
opened 2026-10-17 21:03:46 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @FerroLx on GitHub (Oct 16, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4538

Before submitting

  • I searched the open and closed issues and pull requests for a related proposal.
  • I understand the contribution scope must be reviewed before integration; open questions are welcome here.
  • This request does not include credentials, private samples, or sensitive target data.

Area

Evidence, artifacts, or reconstruction

Current limitation

Before attaching a debugger to an Android app or trusting a decompilation, an analyst wants to know what debug metadata the DEX carries: line positions, local variable names and types, parameter names, source-file names. A release build (R8) usually keeps lines and strips locals, while a debug build keeps both. REA has no static answer to this question. #2377 covers the JVM .class side under #1558; DEX is the Android counterpart.

Use cases

  • Deciding whether source-level debugging or local-variable inspection is possible for an APK.
  • Recognising release vs debug builds and renamed source files (-renamesourcefileattribute).
  • Per-class detail for the classes an analyst is about to read.

Desired outcome and success criteria

A read-only inspect_dex_debug_metadata tool (CLI and MCP) for a local .dex or the DEX members Android auto-loads from an APK/ZIP. By default it returns a per-member readiness summary (line positions, local declarations, parameter names, source files, readiness label). With a class descriptor it returns per-method detail. Counts should match dexdump on real d8/R8 output. Unreadable structures are reported as unknown, never as stripped.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

Static parsing of DEX debug_info_items; no execution, no device or adb. Out of scope: odex/vdex/oat/cdex.

Verification available so far

I have a prototype or observed results

Verification

Prototype in #4473: a real-toolchain lane compiles Java with javac -g / -g:none, dexes it with d8, and cross-checks REA against dexdump through CLI and MCP. Multiple adversarial review rounds; real APKs give counts identical to dexdump.

Originally created by @FerroLx on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4538 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the contribution scope must be reviewed before integration; open questions are welcome here. - [x] This request does not include credentials, private samples, or sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Current limitation Before attaching a debugger to an Android app or trusting a decompilation, an analyst wants to know what debug metadata the DEX carries: line positions, local variable names and types, parameter names, source-file names. A release build (R8) usually keeps lines and strips locals, while a debug build keeps both. REA has no static answer to this question. #2377 covers the JVM `.class` side under #1558; DEX is the Android counterpart. ### Use cases - Deciding whether source-level debugging or local-variable inspection is possible for an APK. - Recognising release vs debug builds and renamed source files (`-renamesourcefileattribute`). - Per-class detail for the classes an analyst is about to read. ### Desired outcome and success criteria A read-only `inspect_dex_debug_metadata` tool (CLI and MCP) for a local `.dex` or the DEX members Android auto-loads from an APK/ZIP. By default it returns a per-member readiness summary (line positions, local declarations, parameter names, source files, readiness label). With a class descriptor it returns per-method detail. Counts should match `dexdump` on real d8/R8 output. Unreadable structures are reported as unknown, never as stripped. ### Expected interaction with targets Read existing files or captured data ### Target and scope details (optional) Static parsing of DEX `debug_info_item`s; no execution, no device or adb. Out of scope: odex/vdex/oat/cdex. ### Verification available so far I have a prototype or observed results ### Verification Prototype in #4473: a real-toolchain lane compiles Java with `javac -g` / `-g:none`, dexes it with `d8`, and cross-checks REA against `dexdump` through CLI and MCP. Multiple adversarial review rounds; real APKs give counts identical to dexdump.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#2364
No description provided.