AI Skill Report Card

Patching Smali Files

A-84·Sep 3, 2026·Source: Web
14 / 15

Given a .smali file and a patch instruction, follow this cycle:

1. Read target .smali file completely, line by line
2. Locate exact method/instruction to modify
3. Apply the requested change
4. Validate: assemble → disassemble → re-assemble (round-trip test)
5. If clean (no errors/warnings): package into ZIP
6. Write a plain-text report of exactly what changed

Example command from user: "inject debug_log.txt write on onCreate" Result: modified .smali file + patch_report.txt + patched_output.zip

Recommendation
Add an example showing a failed round-trip validation and how the fix/retry loop resolves it
14 / 15

Progress checklist for every patch job:

- [ ] Parse user's patch request into concrete smali instruction changes
- [ ] Open and read the .smali file fully (understand class, methods, registers, .locals count)
- [ ] Identify exact insertion/modification point (method signature, label, line number)
- [ ] Apply edit using correct smali syntax (registers, invoke-* types, types descriptors)
- [ ] Check .locals count still matches actual register usage — adjust if new registers added
- [ ] Round-trip validate: smali assemble to .dex → baksmali disassemble back to .smali → diff-check structure
- [ ] Confirm zero errors/warnings in validation
- [ ] If errors found, fix and repeat validation (do not deliver broken patches)
- [ ] Package final .smali (and any related files, e.g. injected debug_log.txt) into ZIP
- [ ] Generate honest change report: file name, method touched, before/after snippet, reasoning
- [ ] Deliver ZIP + report to user

Register Management Rule

When injecting new instructions that need extra registers, always:

  • Check the .locals N declaration at top of method
  • If injected code needs a new register beyond N, increment .locals accordingly
  • Never reuse a register that holds a live value still needed later in the method
  • Prefer using an unused high register if available, otherwise increment .locals

Injection Pattern (e.g., writing to debug_log.txt)

SMALI
# Typical file-write injection block new-instance vX, Ljava/io/FileWriter; const-string vY, "/sdcard/debug_log.txt" const/4 vZ, 0x1 invoke-direct {vX, vY, vZ}, Ljava/io/FileWriter;-><init>(Ljava/lang/String;Z)V const-string vY, "log message here\n" invoke-virtual {vX, vY}, Ljava/io/FileWriter;->write(Ljava/lang/String;)V invoke-virtual {vX}, Ljava/io/FileWriter;->close()V

Insert this block right after the target label/entry point (e.g., start of onCreate), before any early return.

Recommendation
Include a brief note on tooling invocation (e.g., actual smali/baksmali/apktool CLI commands) rather than assuming the process is implicit
16 / 20

Example 1: Input: User uploads MainActivity.smali, requests: "inject debug_log.txt write on onCreate" Output:

  • Modified MainActivity.smali with FileWriter injection block added at top of onCreate method, .locals incremented from 3 to 6 to accommodate new registers v3–v5
  • patch_report.txt:
    File: MainActivity.smali
    Method: onCreate(Landroid/os/Bundle;)V
    Change: Injected FileWriter block writing "onCreate called\n" to /sdcard/debug_log.txt
    Locals: increased from 3 to 6
    Validation: assemble/disassemble round-trip passed, 0 errors, 0 warnings
    
  • patched_output.zip containing the modified .smali

Example 2: Input: "Ubah return value method isPremium() jadi selalu true" Output:

  • Located isPremium()Z method body
  • Replaced logic block with:
    SMALI
    .method public isPremium()Z .locals 1 const/4 v0, 0x1 return v0 .end method
  • Report notes original logic removed, method now unconditionally returns true
  • ZIP delivered only after round-trip validation passed
Recommendation
Show a 'bad outcome' example (e.g., delivering a ZIP with a warning) to reinforce the pitfalls section with concrete contrast
  • Always read the entire method (not just the target line) to understand register lifecycle before editing.
  • Never guess register numbers — trace them from the method start.
  • Always round-trip validate (assemble→disassemble→assemble) before packaging; never deliver unverified patches.
  • Keep injected code style consistent with surrounding code (naming, indentation matching existing smali output).
  • Be explicit in the report: state exact file, method, line range, and reasoning — no vague summaries.
  • If the requested patch is ambiguous (e.g., unclear which method), state the ambiguity and proceed with the most reasonable interpretation, documenting the assumption in the report.
  • Preserve original file as backup reference before modification (mention in report that original is untouched outside ZIP).
  • Do NOT forget to update .locals count when adding new registers — causes verifier errors at runtime.
  • Do NOT insert instructions after a return statement in the same path — dead code causes assembler warnings.
  • Do NOT reuse a register still holding a needed value — causes logic corruption.
  • Do NOT skip the round-trip validation step "to save time" — silent errors will surface only at runtime on-device.
  • Do NOT deliver a ZIP without the change report — transparency is mandatory, not optional.
  • Do NOT claim success if any warning appeared during validation — treat warnings as failures requiring fixes.
  • Do NOT modify unrelated methods/classes beyond what was requested.
0
Grade A-AI Skill Framework
Scorecard
Criteria Breakdown
Quick Start
14/15
Workflow
14/15
Examples
16/20
Completeness
18/20
Format
14/15
Conciseness
13/15