AVOID — Stale and unlicensed — last commit 2y ago

• 17 active contributors
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Single-maintainer risk — top contributor 82% of recent commits
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows detected
• ⚠ Scorecard: marked unmaintained (0/10)
• ⚠ Scorecard: default branch unprotected (0/10)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against OpenSSF Scorecard}

smali/baksmali is an assembler/disassembler for Android's DEX (Dalvik Executable) bytecode format, the intermediate representation used by Android's Java VM. It allows developers to convert compiled .dex files into human-readable Smali assembly syntax and vice versa, enabling reverse engineering, analysis, and modification of Android apps. Multi-module Gradle build with two main components: smali/ (disassembler to human-readable Smali syntax) and baksmali/ (assembler from Smali back to DEX). The baksmali module contains Adaptors/ subdirectory organizing instruction formatting (Format/), debug info (Debug/), annotations, and method/class definitions. Core logic depends on dexlib2 (sister project) for DEX parsing; util/ provides shared utilities.

Android reverse engineers, security researchers, malware analysts, and APK modification tool developers who need to inspect or manipulate DEX bytecode at the assembly level. Also used by ROM developers and Android framework contributors who work below the Java source level.

Highly mature and production-grade. The repo shows ~6.5M lines of Java code, extensive DEX format coverage, and comprehensive feature support (annotations, debug info, line numbers, exception handlers). Last activity suggests active maintenance, with well-established command-line tools (baksmali for disassembly, smali for assembly). Widely used in real Android security tooling.

Low risk for a well-established project, but has single-maintainer dynamics (JesusFreke). Dependencies are minimal (guava, jcommander for CLI, dexlib2 internal library), reducing supply-chain risk. The DEX format specification is stable since it's defined by Google, so breaking changes to the format itself are rare. Main risk: community-driven maintenance; critical bugs may have delayed fixes.

Without explicit git history in the data, the active areas inferred from file structure are: method item formatting (MethodItem and subclasses), debug information rendering (Debug/ adaptor classes), and instruction disassembly logic (Format/InstructionMethodItem and factory). The codebase supports modern DEX features comprehensively, suggesting maintenance focus is on correctness and edge cases rather than new major features.

Check README for instructions.

Daily commands: Build: ./gradlew build. Run baksmali CLI: java -jar baksmali/build/libs/baksmali.jar disassemble [options] <dex-file>. Run smali assembler: java -jar smali/build/libs/smali.jar assemble [options] <smali-directory>. Test: ./gradlew test.

• baksmali/src/main/java/org/jf/baksmali/Main.java — Entry point for the baksmali CLI tool; all command routing and argument parsing begins here
• baksmali/src/main/java/org/jf/baksmali/Baksmali.java — Core disassembly engine; orchestrates the conversion of DEX bytecode to smali assembly format
• baksmali/src/main/java/org/jf/baksmali/Adaptors/ClassDefinition.java — Defines how a complete class (fields, methods, annotations) is formatted as smali output; fundamental to all disassembly operations
• baksmali/src/main/java/org/jf/baksmali/Adaptors/MethodDefinition.java — Handles method disassembly including instructions, registers, exceptions, and debug info; critical for correct bytecode representation
• baksmali/src/main/java/org/jf/baksmali/Adaptors/Format/InstructionMethodItem.java — Formats individual DEX instructions as human-readable smali mnemonics; core to instruction-level disassembly
• baksmali/src/main/java/org/jf/baksmali/BaksmaliOptions.java — Configuration container for all baksmali disassembly options; controls output behavior and feature flags
• baksmali/src/main/java/org/jf/baksmali/formatter/BaksmaliWriter.java — Low-level writer that handles formatting smali syntax (indentation, type annotations, registers); ensures consistent output

Add a new List command (e.g., list new DEX structure)

1. Create a new class extending ListCommand in baksmali/src/main/java/org/jf/baksmali/ (baksmali/src/main/java/org/jf/baksmali/ListCommand.java)
2. Implement the execute() method to query the DexFile and format results (baksmali/src/main/java/org/jf/baksmali/ListStringsCommand.java)
3. Register the command in Main.java's command map (baksmali/src/main/java/org/jf/baksmali/Main.java)

Add support for a new instruction format or DEX feature

1. Create a new MethodItem subclass in baksmali/src/main/java/org/jf/baksmali/Adaptors/ to format the new element (baksmali/src/main/java/org/jf/baksmali/Adaptors/MethodItem.java)
2. Update InstructionMethodItemFactory to instantiate your new formatter when appropriate (baksmali/src/main/java/org/jf/baksmali/Adaptors/Format/InstructionMethodItemFactory.java)
3. Add test case in baksmali/src/test/java/org/jf/baksmali/ to verify correct formatting (baksmali/src/test/java/org/jf/baksmali/DisassemblyTest.java)

Add a new disassembly option or configuration flag

1. Add the field to BaksmaliOptions class to store the new configuration (baksmali/src/main/java/org/jf/baksmali/BaksmaliOptions.java)
2. Update DexInputCommand or appropriate command class to parse the command-line argument (baksmali/src/main/java/org/jf/baksmali/DexInputCommand.java)
3. Modify the relevant Adaptor (ClassDefinition, MethodDefinition, etc.) to respect the flag during formatting (baksmali/src/main/java/org/jf/baksmali/Adaptors/ClassDefinition.java)

Add support for new debug info or annotation formatting

1. Create a new DebugMethodItem subclass in baksmali/src/main/java/org/jf/baksmali/Adaptors/Debug/ (baksmali/src/main/java/org/jf/baksmali/Adaptors/Debug/DebugMethodItem.java)
2. Update MethodDefinition to recognize and insert the new debug item when appropriate (baksmali/src/main/java/org/jf/baksmali/Adaptors/MethodDefinition.java)
3. Add test case to verify correct debug info output (baksmali/src/test/java/org/jf/baksmali/DisassemblyTest.java)

No major environment variables or external service dependencies. Gradle build may require Java 8+; verify with java -version. The project uses dexlib2 as an internal dependency (sister project); if making breaking changes to DEX parsing, coordinate across both repos. Smali syntax is tightly coupled to DEX format spec; deviations will silently produce invalid bytecode. No CI configuration visible in file list, so test coverage is your responsibility—many Adaptors lack unit tests.

• DEX (Dalvik Executable) format — The bytecode format that smali/baksmali reads and writes; understanding section offsets, type references, and instruction encoding is essential to contributing
• Dalvik bytecode instruction set — smali is syntax sugar for Dalvik ops; contributors fixing instruction formatting must understand opcode semantics and register/argument handling
• Visitor pattern (structural) — baksmali's Adaptors package uses visitor-like pattern where MethodItem subclasses visit instructions/labels and emit Smali syntax; essential for understanding how output is generated
• Register allocation — Smali exposes Dalvik register semantics (v0-vN for locals, p0-pN for parameters, result in v0); RegisterFormatter and debug local tracking depend on precise register semantics
• Type descriptors (JVM notation) — smali uses JVM-style type notation (Ljava/lang/String;, [I, V); AnnotationFormatter and method signatures depend on correct type descriptor parsing and emission
• Debug information encoding (Dalvik format) — The Debug/ adaptors reconstruct variable names, line numbers, and prologue/epilogue from compressed DEX debug sections; understanding this encoding is critical for debug output correctness
• Exception handling (try-catch blocks in DEX) — CatchMethodItem renders try-catch regions; smali syntax for exception handlers maps to DEX encoded_catch_handler structures with offset-based exception ranges

• google/android — Official Android source defines the DEX format specification and Dalvik bytecode semantics that smali/baksmali implements
• JesusFreke/dexlib2 — Sister library providing low-level DEX parsing and data structure representation; baksmali depends on dexlib2 for bytecode analysis
• google/android-gradle-plugin — Companion tool that produces DEX files from Java source; baksmali ingests the output of this build pipeline
• iBotPeaches/Apktool — Higher-level tool that uses smali/baksmali as its disassembly backend for full APK reverse engineering and repackaging
• skylot/jadx — Alternative DEX decompiler that produces Java source instead of Smali assembly; complementary approach to understanding APK behavior

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for baksmali/src/main/java/org/jf/baksmali/Adaptors/Format/ instruction formatters

The Format subdirectory contains critical instruction formatting logic (InstructionMethodItem, ArrayDataMethodItem, PackedSwitchMethodItem, SparseSwitchMethodItem, etc.) but there are only 3 test files in baksmali/src/test/java. These formatters are responsible for converting dex instructions back to human-readable smali syntax. Adding targeted unit tests would catch regressions in instruction formatting and improve coverage of edge cases in different instruction formats.

• [ ] Create baksmali/src/test/java/org/jf/baksmali/Adaptors/Format/InstructionMethodItemTest.java with tests for various instruction types
• [ ] Create baksmali/src/test/java/org/jf/baksmali/Adaptors/Format/ArrayDataMethodItemTest.java testing array data formatting
• [ ] Create baksmali/src/test/java/org/jf/baksmali/Adaptors/Format/SwitchMethodItemTest.java for packed/sparse switch formatting
• [ ] Add test fixtures in baksmali/src/test/resources/ with sample dex bytecode for each instruction format

Add unit tests for Debug adaptor classes (LineNumberMethodItem, StartLocalMethodItem, etc.)

The baksmali/src/main/java/org/jf/baksmali/Adaptors/Debug/ directory contains 8 classes responsible for formatting debug information (line numbers, local variable info, epilogue/prologue markers). Debug info formatting is complex and prone to off-by-one errors, but there are no dedicated tests for these formatters. Adding tests would ensure debug metadata is correctly disassembled.

• [ ] Create baksmali/src/test/java/org/jf/baksmali/Adaptors/Debug/DebugFormattingTest.java
• [ ] Add test cases for LineNumberMethodItem with various line number sequences
• [ ] Add test cases for StartLocalMethodItem and EndLocalMethodItem with different register/type combinations
• [ ] Add test cases for RestartLocalMethodItem and scope boundaries

Add GitHub Actions workflow for multi-JVM and multi-Android API level compatibility testing

The repo has no CI configuration files (.github/workflows/) visible. Given that smali/baksmali targets Android's dex format which varies across API levels, and the project supports multiple JVM versions (based on gradle usage), a CI workflow would catch platform-specific issues. This is especially valuable since the project has public issue tracking but no automated validation of pull requests.

• [ ] Create .github/workflows/gradle-build.yml with matrix testing across Java 8, 11, and 17
• [ ] Configure the workflow to run ./gradlew build and ./gradlew test on push and pull requests
• [ ] Add test reporting to surface failures in the PR interface
• [ ] Optionally add a separate workflow for building the distributable artifacts to validate baksmali/build.gradle produces correct outputs

• Add unit tests for CommentingIndentingWriter: baksmali/src/main/java/org/jf/baksmali/Adaptors/CommentingIndentingWriter.java handles indentation and comment output formatting but has no visible test coverage; add tests for edge cases like nested indentation and multi-line comments
• Document Smali syntax for lesser-used annotation features: AnnotationFormatter.java exists but the wiki/README doesn't clearly document how to read/write complex annotation syntax in Smali; add a guide with examples from actual DEX annotations
• Add RegisterFormatter tests for edge cases in wide registers: RegisterFormatter.java handles register formatting but lacks explicit test cases for 64-bit register pairs (v0:v1 syntax); add comprehensive tests to prevent register aliasing bugs

The smali/baksmali repository demonstrates a reasonable security posture as a development tool for DEX file manipulation. No critical vulnerabilities were identified in the static analysis. The main concerns are related to dependency management practices rather than application-level security flaws. The codebase is primarily a disassembler/assembler focused on Android DEX format processing, which has limited exposure to traditional web security risks like injection attacks or authentication vulnerabilities. The key recommendations are to: 1) Complete and validate the build configuration, 2) Implement explicit dependency versioning, and 3) Maintain regular dependency audits. The tool's security depends heavily on proper input validation when processing untrusted DEX files, which should be verified through code review of the parser implementations.

• Medium · Incomplete Dependencies Declaration — baksmali/build.gradle. The build.gradle file appears to have incomplete resource processing configuration. The line 'processResources.inputs.pro' is incomplete and cut off, which may indicate either a configuration error or incomplete build setup. This could lead to missing or misconfigured build artifacts. Fix: Complete the processResources configuration. Ensure all build.gradle files are properly formatted and validated.
• Low · Outdated or Potentially Vulnerable Dependencies — baksmali/build.gradle. The buildscript configuration references dependencies through a 'depends' object (e.g., depends.proguard_gradle, depends.guava, depends.jcommander) that are not explicitly versioned in the provided content. Without explicit version pinning, there is potential for transitive dependency vulnerabilities or unexpected behavior from version updates. Fix: Use explicit version pinning for all dependencies. Define a BOM (Bill of Materials) or explicitly specify versions. Regularly audit dependencies using tools like OWASP Dependency-Check or Snyk.
• Low · Test Dependencies in Classpath — baksmali/build.gradle - testImplementation section. Test dependencies (junit, antlr_runtime) are included but their versions are not specified in the provided snippet. Additionally, 'smali' project is included as a testImplementation dependency, which could potentially introduce unverified code into the test classpath. Fix: Explicitly version all test dependencies. Verify that test dependencies do not include unreviewed or untrusted code. Consider separating test and implementation dependencies more strictly.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/JesusFreke/smali shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live JesusFreke/smali repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/JesusFreke/smali.

What it runs against: a local clone of JesusFreke/smali — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in JesusFreke/smali | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 873 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of JesusFreke/smali. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/JesusFreke/smali.git
#   cd smali
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of JesusFreke/smali and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "JesusFreke/smali(\\.git)?\\b" \\
  && ok "origin remote is JesusFreke/smali" \\
  || miss "origin remote is not JesusFreke/smali (artifact may be from a fork)"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "baksmali/src/main/java/org/jf/baksmali/Main.java" \\
  && ok "baksmali/src/main/java/org/jf/baksmali/Main.java" \\
  || miss "missing critical file: baksmali/src/main/java/org/jf/baksmali/Main.java"
test -f "baksmali/src/main/java/org/jf/baksmali/Baksmali.java" \\
  && ok "baksmali/src/main/java/org/jf/baksmali/Baksmali.java" \\
  || miss "missing critical file: baksmali/src/main/java/org/jf/baksmali/Baksmali.java"
test -f "baksmali/src/main/java/org/jf/baksmali/Adaptors/ClassDefinition.java" \\
  && ok "baksmali/src/main/java/org/jf/baksmali/Adaptors/ClassDefinition.java" \\
  || miss "missing critical file: baksmali/src/main/java/org/jf/baksmali/Adaptors/ClassDefinition.java"
test -f "baksmali/src/main/java/org/jf/baksmali/Adaptors/MethodDefinition.java" \\
  && ok "baksmali/src/main/java/org/jf/baksmali/Adaptors/MethodDefinition.java" \\
  || miss "missing critical file: baksmali/src/main/java/org/jf/baksmali/Adaptors/MethodDefinition.java"
test -f "baksmali/src/main/java/org/jf/baksmali/Adaptors/Format/InstructionMethodItem.java" \\
  && ok "baksmali/src/main/java/org/jf/baksmali/Adaptors/Format/InstructionMethodItem.java" \\
  || miss "missing critical file: baksmali/src/main/java/org/jf/baksmali/Adaptors/Format/InstructionMethodItem.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 873 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~843d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/JesusFreke/smali"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.