AI Skill Report Card
Patching Smali Files
Quick Start14 / 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
Workflow14 / 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 Ndeclaration at top of method - If injected code needs a new register beyond N, increment
.localsaccordingly - 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
Examples16 / 20
Example 1:
Input: User uploads MainActivity.smali, requests: "inject debug_log.txt write on onCreate"
Output:
- Modified
MainActivity.smaliwith FileWriter injection block added at top ofonCreatemethod,.localsincremented 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 warningspatched_output.zipcontaining the modified.smali
Example 2: Input: "Ubah return value method isPremium() jadi selalu true" Output:
- Located
isPremium()Zmethod 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
Best Practices
- 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).
Common Pitfalls
- Do NOT forget to update
.localscount when adding new registers — causes verifier errors at runtime. - Do NOT insert instructions after a
returnstatement 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.