[GH-ISSUE #4537] [Feature] Inspect APK signature schemes, signers and rotation lineage statically

bsakaguchi commented

2026-10-17 21:03:45 +00:00

Owner

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

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

REA can inventory and decode an APK, but it cannot tell an analyst how the APK is signed: which schemes (v1 JAR, v2, v3, v3.1, source stamp) are present, which signer certificate each one names, whether a key rotation (proof-of-rotation lineage) is declared, and whether the declared content digests match the bytes. Today that needs the Android SDK's apksigner. androidApplication.ts already notes that an empty signing array does not mean unsigned. Related: #717 (APK roadmap).

Use cases

Triage: is this APK signed by the expected developer certificate, or re-signed (repackaged) without a covering rotation lineage?
Comparing two versions of an app: did the signer change?
Agent workflows that cannot assume an Android SDK on the host.

Desired outcome and success criteria

A read-only inspect_apk_signature tool (CLI and MCP) that, for a selected local APK, returns per scheme: presence, signers (certificate SHA-256 fingerprint, subject, validity, key algorithm), signature algorithm IDs with digest algorithm, v3/v3.1 min/max SDK ranges, rotation lineage nodes and capabilities, and source-stamp presence. It also says whether each declared content digest matches the bytes. That check is explicitly not signature verification. Success means these fields match apksigner verify --print-certs / apksigner lineage --print-certs on real and generated APKs. Malformed or ambiguous archives are refused, never reported as unsigned.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

Static, read-only parsing of the APK Signing Block and META-INF entries; no execution, no device, no network, no trust or validity verdicts. Non-goal: cryptographic signature verification (possible follow-up).

Verification available so far

I have a prototype or observed results

Verification

Prototype in #4158: a real-toolchain lane builds APKs with aapt2 and signs them with apksigner (default, v1-only, rotated lineage, v3.1, source stamp, tampered), and cross-checks CLI and MCP output with apksigner. Adversarial reviews covered malformed and ambiguous archives.

Originally created by @FerroLx on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4537 ### 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 REA can inventory and decode an APK, but it cannot tell an analyst how the APK is signed: which schemes (v1 JAR, v2, v3, v3.1, source stamp) are present, which signer certificate each one names, whether a key rotation (proof-of-rotation lineage) is declared, and whether the declared content digests match the bytes. Today that needs the Android SDK's `apksigner`. `androidApplication.ts` already notes that an empty signing array does not mean unsigned. Related: #717 (APK roadmap). ### Use cases - Triage: is this APK signed by the expected developer certificate, or re-signed (repackaged) without a covering rotation lineage? - Comparing two versions of an app: did the signer change? - Agent workflows that cannot assume an Android SDK on the host. ### Desired outcome and success criteria A read-only `inspect_apk_signature` tool (CLI and MCP) that, for a selected local APK, returns per scheme: presence, signers (certificate SHA-256 fingerprint, subject, validity, key algorithm), signature algorithm IDs with digest algorithm, v3/v3.1 min/max SDK ranges, rotation lineage nodes and capabilities, and source-stamp presence. It also says whether each declared content digest matches the bytes. That check is explicitly not signature verification. Success means these fields match `apksigner verify --print-certs` / `apksigner lineage --print-certs` on real and generated APKs. Malformed or ambiguous archives are refused, never reported as unsigned. ### Expected interaction with targets Read existing files or captured data ### Target and scope details (optional) Static, read-only parsing of the APK Signing Block and META-INF entries; no execution, no device, no network, no trust or validity verdicts. Non-goal: cryptographic signature verification (possible follow-up). ### Verification available so far I have a prototype or observed results ### Verification Prototype in #4158: a real-toolchain lane builds APKs with `aapt2` and signs them with `apksigner` (default, v1-only, rotated lineage, v3.1, source stamp, tampered), and cross-checks CLI and MCP output with `apksigner`. Adversarial reviews covered malformed and ambiguous archives.

bsakaguchi commented

2026-10-17 21:03:45 +00:00

Author

Owner

@uyg7x commented on GitHub (Oct 16, 2026):

Hey @FerroLx , Can I Work on this Issue .

@uyg7x commented on GitHub (Oct 16, 2026): Hey @FerroLx , Can I Work on this Issue .

bsakaguchi commented

2026-10-17 21:03:46 +00:00

Author

Owner

@FerroLx commented on GitHub (Oct 17, 2026):

@uyg7x Thanks for the interest! I'm already working on this one: draft PR #4158 implements it (static APK signature inspection: v1/v2/v3/v3.1 schemes, signers, rotation lineage and digest self-consistency). It's in final review before I mark it ready for the maintainers.

A full review would be very welcome! The most useful ways to help:

Review the diff on #4158. Comment on anything unclear, wrong or fragile, or use GitHub's "suggest changes" for concrete fixes.
Test it on real APKs, especially unusual signing setups (key rotation, v1-only, source stamps, multiple signers). Report any case where the output disagrees with apksigner verify --print-certs.
For larger changes, open a PR against my branch FerroLx/rea:feat/apk-signature so I can review it and fold it in.

@FerroLx commented on GitHub (Oct 17, 2026): @uyg7x Thanks for the interest! I'm already working on this one: draft PR #4158 implements it (static APK signature inspection: v1/v2/v3/v3.1 schemes, signers, rotation lineage and digest self-consistency). It's in final review before I mark it ready for the maintainers. A full review would be very welcome! The most useful ways to help: - **Review the diff on #4158.** Comment on anything unclear, wrong or fragile, or use GitHub's "suggest changes" for concrete fixes. - **Test it on real APKs**, especially unusual signing setups (key rotation, v1-only, source stamps, multiple signers). Report any case where the output disagrees with `apksigner verify --print-certs`. - **For larger changes**, open a PR against my branch `FerroLx/rea:feat/apk-signature` so I can review it and fold it in.

bsakaguchi referenced this issue

2026-10-31 00:29:41 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi closed this issue

2026-10-31 00:33:01 +00:00

bsakaguchi commented

2026-10-31 00:33:03 +00:00

Author

Owner

@uyg7x commented on GitHub (Oct 17, 2026):

Hey @FerroLx, I was looking into this issue and wanted to help test it out.
I pulled your feat/apk-signature branch and ran the tests on Windows. The src/domain/apkSignature/apkSigningBlock.test.ts suite passed all 12 tests cleanly. I also threw a dummy ZIP file (renamed to .apk) at the CLI, and it gracefully rejected the malformed input without crashing, which is great.
Let me know if there are any specific edge cases or documentation files you'd like an extra pair of eyes on. Happy to help!

@uyg7x commented on GitHub (Oct 17, 2026): Hey @FerroLx, I was looking into this issue and wanted to help test it out. I pulled your feat/apk-signature branch and ran the tests on Windows. The src/domain/apkSignature/apkSigningBlock.test.ts suite passed all 12 tests cleanly. I also threw a dummy ZIP file (renamed to .apk) at the CLI, and it gracefully rejected the malformed input without crashing, which is great. Let me know if there are any specific edge cases or documentation files you'd like an extra pair of eyes on. Happy to help!

bsakaguchi commented

2026-10-31 00:33:03 +00:00

Author

Owner

@uyg7x commented on GitHub (Oct 17, 2026):

Hey @FerroLx, I've been testing this feature on Windows to help out.
While the CLI hung silently on my end (likely just a local environment/compiled binary quirk), I bypassed it and ran the core provider tests directly to verify the logic.
As you can see in the screenshot below, all 21 tests in ApkSignatureProvider.test.ts passed perfectly. The tool correctly handles unsigned ZIPs, refuses non-ZIP files, and bounds inflation properly. The core logic is rock solid on Windows!
Let me know if you'd like me to review the documentation or test any other specific edge cases. Happy to help!

@uyg7x commented on GitHub (Oct 17, 2026): Hey @FerroLx, I've been testing this feature on Windows to help out. While the CLI hung silently on my end (likely just a local environment/compiled binary quirk), I bypassed it and ran the core provider tests directly to verify the logic. As you can see in the screenshot below, all 21 tests in ApkSignatureProvider.test.ts passed perfectly. The tool correctly handles unsigned ZIPs, refuses non-ZIP files, and bounds inflation properly. The core logic is rock solid on Windows! Let me know if you'd like me to review the documentation or test any other specific edge cases. Happy to help! <img width="835" height="521" alt="Image" src="https://github.com/user-attachments/assets/8503862c-1f35-4b2d-9512-a30eebacf628" />

bsakaguchi commented

2026-10-31 00:33:04 +00:00

Author

Owner

@FerroLx commented on GitHub (Oct 17, 2026):

Thanks a lot @uyg7x, Windows coverage is really valuable since I can only test on Linux here! 🙏

The silent CLI hang is the most interesting part. It might be a real Windows issue rather than your setup, so could you share:

The exact command you ran, and your Windows and Node.js versions (node --version; the repo pins Node 24 in .nvmrc).
Whether you built first (npm ci then npm run build:cached) and ran it via node scripts/rea.mjs inspect-apk-signature <file> --format json.
Does node scripts/rea.mjs --help return? Does another command hang too, e.g. node scripts/rea.mjs inspect-artifact <file>?
Run it again with REA_LOG_LEVEL=debug set and paste whatever it prints before it stops (or say if it prints nothing).
Whether the file was on a local drive, a network share, OneDrive, or a path with a symlink or junction.

Also, please pull again first: the branch has moved on a lot (v1 signer certificates, apksig-parity fixes), and the current tests are npm run test:local -- src/domain/apkSignature/*.test.ts src/apkSignature/*.test.ts. If you have unusual real APKs (key rotation, v1-only, multiple signers), comparing against apksigner verify --print-certs -v would be great too.

@FerroLx commented on GitHub (Oct 17, 2026): Thanks a lot @uyg7x, Windows coverage is really valuable since I can only test on Linux here! 🙏 The silent CLI hang is the most interesting part. It might be a real Windows issue rather than your setup, so could you share: 1. The exact command you ran, and your Windows and Node.js versions (`node --version`; the repo pins Node 24 in `.nvmrc`). 2. Whether you built first (`npm ci` then `npm run build:cached`) and ran it via `node scripts/rea.mjs inspect-apk-signature <file> --format json`. 3. Does `node scripts/rea.mjs --help` return? Does another command hang too, e.g. `node scripts/rea.mjs inspect-artifact <file>`? 4. Run it again with `REA_LOG_LEVEL=debug` set and paste whatever it prints before it stops (or say if it prints nothing). 5. Whether the file was on a local drive, a network share, OneDrive, or a path with a symlink or junction. Also, please pull again first: the branch has moved on a lot (v1 signer certificates, apksig-parity fixes), and the current tests are `npm run test:local -- src/domain/apkSignature/*.test.ts src/apkSignature/*.test.ts`. If you have unusual real APKs (key rotation, v1-only, multiple signers), comparing against `apksigner verify --print-certs -v` would be great too.

bsakaguchi commented

2026-10-31 00:33:04 +00:00

Author

Owner

@uyg7x commented on GitHub (Oct 17, 2026):

Hey @FerroLx,
Yeah, the CLI hang is definitely weird. I was just running npx tsx src/cli.ts inspect-apk-signature and it completely froze. No output, nothing. Same thing happened with src/main.ts.
For context, I'm on Windows 11 (Build 26200.9550) running Node v24.22.0. I did run npm ci and npm run build:cached first, and the file was just a local path on my C: drive (no symlinks or OneDrive stuff).
I just pulled your latest commits and ran the full test suite for the apkSignature modules. All 109 tests passed clean on Windows.

.
Want me to try firing it up with $env:REA_LOG_LEVEL="debug" to see where it's actually choking? Or I can try the node scripts/rea.mjs command you mentioned. Let me know what you want to try next.

@uyg7x commented on GitHub (Oct 17, 2026): Hey @FerroLx, Yeah, the CLI hang is definitely weird. I was just running npx tsx src/cli.ts inspect-apk-signature <file> and it completely froze. No output, nothing. Same thing happened with src/main.ts. For context, I'm on Windows 11 (Build 26200.9550) running Node v24.22.0. I did run npm ci and npm run build:cached first, and the file was just a local path on my C: drive (no symlinks or OneDrive stuff). I just pulled your latest commits and ran the full test suite for the apkSignature modules. All 109 tests passed clean on Windows. <img width="701" height="244" alt="Image" src="https://github.com/user-attachments/assets/51b06ddc-9939-490a-8ab4-05519c69c847" /> . Want me to try firing it up with $env:REA_LOG_LEVEL="debug" to see where it's actually choking? Or I can try the node scripts/rea.mjs command you mentioned. Let me know what you want to try next.

bsakaguchi commented

2026-10-31 00:33:04 +00:00

Author

Owner

@FerroLx commented on GitHub (Oct 17, 2026):

Thanks @uyg7x, that's really helpful, and great to see all 109 pass on Windows! 🎉

I think I see it: src/cli.ts and src/main.ts aren't meant to be run directly. On Linux, npx tsx src/cli.ts … also prints nothing and just exits. The supported entry is the built launcher:

node scripts/rea.mjs inspect-apk-signature C:\path\to\app.apk --format json

Could you try that? If it still hangs, please run it with $env:REA_LOG_LEVEL="debug" and paste what it prints (or say if it prints nothing). If it prints a JSON result, then there's no Windows bug, and the output on a couple of real APKs, compared with apksigner verify --print-certs -v, would be awesome.

@FerroLx commented on GitHub (Oct 17, 2026): Thanks @uyg7x, that's really helpful, and great to see all 109 pass on Windows! 🎉 I think I see it: `src/cli.ts` and `src/main.ts` aren't meant to be run directly. On Linux, `npx tsx src/cli.ts …` also prints nothing and just exits. The supported entry is the built launcher: ```powershell node scripts/rea.mjs inspect-apk-signature C:\path\to\app.apk --format json ``` Could you try that? If it still hangs, please run it with `$env:REA_LOG_LEVEL="debug"` and paste what it prints (or say if it prints nothing). If it prints a JSON result, then there's no Windows bug, and the output on a couple of real APKs, compared with `apksigner verify --print-certs -v`, would be awesome.

bsakaguchi commented

2026-10-31 00:33:05 +00:00

Author

Owner

@uyg7x commented on GitHub (Oct 17, 2026):

Hey @FerroLx,
I gave the launcher command a shot, but it looks like the CLI routing isn't picking up the new feature yet.

When I ran node scripts/rea.mjs inspect-apk-signature --format json, it threw a COMMAND_NOT_FOUND and suggested
inspect-signature instead. I tried that, but it just fell back to the old Hopper tool and threw a native-macos error.

I double-checked with node scripts/rea.mjs --help, and inspect-apk-signature isn't registered in the list at all.
Did the command name change in this draft, or is the CLI wiring still a WIP? Happy to help wire it up if you point me to the right file.

@uyg7x commented on GitHub (Oct 17, 2026): Hey @FerroLx, I gave the launcher command a shot, but it looks like the CLI routing isn't picking up the new feature yet. When I ran node scripts/rea.mjs inspect-apk-signature <file> --format json, it threw a COMMAND_NOT_FOUND and suggested inspect-signature instead. I tried that, but it just fell back to the old Hopper tool and threw a native-macos error. I double-checked with node scripts/rea.mjs --help, and inspect-apk-signature isn't registered in the list at all. Did the command name change in this draft, or is the CLI wiring still a WIP? Happy to help wire it up if you point me to the right file.

bsakaguchi commented

2026-10-31 00:33:05 +00:00

Author

Owner

@FerroLx commented on GitHub (Oct 18, 2026):

Thanks @uyg7x! The command is registered on the branch: at 6913c2e86, node scripts/rea.mjs --help lists inspect-apk-signature. The tests run from source, but the CLI runs the built dist/, so I think your build predates the pull. Could you run:

git checkout feat/apk-signature
git pull
git log -1 --oneline   # should show 6913c2e86
npm ci
npm run build:cached
node scripts/rea.mjs inspect-apk-signature C:\path\to\app.apk --format json

No wiring is needed. If it still says COMMAND_NOT_FOUND after that, please paste the git log -1 line and the build output.

@FerroLx commented on GitHub (Oct 18, 2026): Thanks @uyg7x! The command is registered on the branch: at `6913c2e86`, `node scripts/rea.mjs --help` lists `inspect-apk-signature`. The tests run from source, but the CLI runs the built `dist/`, so I think your build predates the pull. Could you run: ```powershell git checkout feat/apk-signature git pull git log -1 --oneline # should show 6913c2e86 npm ci npm run build:cached node scripts/rea.mjs inspect-apk-signature C:\path\to\app.apk --format json ``` No wiring is needed. If it still says COMMAND_NOT_FOUND after that, please paste the `git log -1` line and the build output.

bsakaguchi commented

2026-10-31 00:33:05 +00:00

Author

Owner

@uyg7x commented on GitHub (Oct 18, 2026):

Hey @FerroLx,
I hard-reset to 6913c2e86, ran npm ci and npm run build:cached, but it's still throwing COMMAND_NOT_FOUND.
I checked the --help output for "apk" and saw stuff like inspect-android-package, but inspect-apk-signature is completely missing from the registry.
Any chance build:cached only builds the skills and skips the main CLI binary? Or is there a newer commit I missed? Happy to run a different build script or help wire it up if you point me to the right spot!

@uyg7x commented on GitHub (Oct 18, 2026): Hey @FerroLx, I hard-reset to 6913c2e86, ran npm ci and npm run build:cached, but it's still throwing COMMAND_NOT_FOUND. I checked the --help output for "apk" and saw stuff like inspect-android-package, but inspect-apk-signature is completely missing from the registry. Any chance build:cached only builds the skills and skips the main CLI binary? Or is there a newer commit I missed? Happy to run a different build script or help wire it up if you point me to the right spot!

bsakaguchi commented

2026-10-31 00:33:05 +00:00

Author

Owner

@FerroLx commented on GitHub (Oct 18, 2026):

Thanks for digging in! On Linux at 6913c2e86 the command is registered and listed, and scripts/rea.mjs only loads dist\cli-runtime\cli.js from the same checkout. So I suspect the checkout isn't at that commit. It only exists on my fork, so on an upstream clone git reset --hard 6913c2e86 fails and leaves you on main, which has inspect-signature but not this command. Could you run these from the repo root and paste the output?

git log -1 --oneline                      # expect 6913c2e86 or newer (now 76445a83c)
git cat-file -t 6913c2e86                 # "commit"; if it errors:
#   git fetch https://github.com/FerroLx/rea.git feat/apk-signature; git checkout FETCH_HEAD
Select-String -Path src\cliCommandNames.ts -Pattern inspect-apk-signature
Select-String -Path dist\cli-runtime\cli.js -Pattern inspect-apk-signature -List
Get-Item dist\cli-runtime\cli.js | Select-Object LastWriteTime
Get-Command rea -All -ErrorAction SilentlyContinue

If src has it but dist doesn't: close any running rea/MCP server, then Remove-Item -Recurse -Force .\dist; npm run build, then node scripts\rea.mjs --help | Select-String apk.

@FerroLx commented on GitHub (Oct 18, 2026): Thanks for digging in! On Linux at `6913c2e86` the command is registered and listed, and `scripts/rea.mjs` only loads `dist\cli-runtime\cli.js` from the same checkout. So I suspect the checkout isn't at that commit. It only exists on my fork, so on an upstream clone `git reset --hard 6913c2e86` fails and leaves you on `main`, which has `inspect-signature` but not this command. Could you run these from the repo root and paste the output? ```powershell git log -1 --oneline # expect 6913c2e86 or newer (now 76445a83c) git cat-file -t 6913c2e86 # "commit"; if it errors: # git fetch https://github.com/FerroLx/rea.git feat/apk-signature; git checkout FETCH_HEAD Select-String -Path src\cliCommandNames.ts -Pattern inspect-apk-signature Select-String -Path dist\cli-runtime\cli.js -Pattern inspect-apk-signature -List Get-Item dist\cli-runtime\cli.js | Select-Object LastWriteTime Get-Command rea -All -ErrorAction SilentlyContinue ``` If `src` has it but `dist` doesn't: close any running `rea`/MCP server, then `Remove-Item -Recurse -Force .\dist; npm run build`, then `node scripts\rea.mjs --help | Select-String apk`.

bsakaguchi commented

2026-10-31 00:33:06 +00:00

Author

Owner

@uyg7x commented on GitHub (Oct 18, 2026):

Hey @FerroLx,

PS> git log -1 --oneline
f0a48e480 docs: fix minor grammar in apk-signature guide

PS> git cat-file -t 6913c2e86
commit

PS> Select-String -Path src\cliCommandNames.ts -Pattern inspect-apk-signature
src\cliCommandNames.ts:9: inspectApkSignature: "inspect-apk-signature",

PS> Select-String -Path dist\cli-runtime\cli.js -Pattern inspect-apk-signature -List
(No output)

PS> Get-Item dist\cli-runtime\cli.js | Select-Object LastWriteTime
18-10-2026 01:45:59

As you can see, src has the command, but dist is completely missing it (and the file is still dated Oct 18).
I'm going to nuke the dist folder and run a full npm run build right now. I'll drop an update here once it's rebuilt and tested!

@uyg7x commented on GitHub (Oct 18, 2026): Hey @FerroLx, PS> git log -1 --oneline f0a48e480 docs: fix minor grammar in apk-signature guide PS> git cat-file -t 6913c2e86 commit PS> Select-String -Path src\cliCommandNames.ts -Pattern inspect-apk-signature src\cliCommandNames.ts:9: inspectApkSignature: "inspect-apk-signature", PS> Select-String -Path dist\cli-runtime\cli.js -Pattern inspect-apk-signature -List (No output) PS> Get-Item dist\cli-runtime\cli.js | Select-Object LastWriteTime 18-10-2026 01:45:59 As you can see, src has the command, but dist is completely missing it (and the file is still dated Oct 18). I'm going to nuke the dist folder and run a full npm run build right now. I'll drop an update here once it's rebuilt and tested!

bsakaguchi commented

2026-10-31 00:33:06 +00:00

Author

Owner

@uyg7x commented on GitHub (Oct 18, 2026):

Hey @FerroLx,
That was it. Nuking the dist folder and manually running npx tsc -p tsconfig.build.json followed by node scripts/bundle-runtime.mjs fixed it. Looks like the standard npm run build script was skipping the CLI runtime compilation.
The command is running clean on Windows now. I tested it against a real APK, and it works perfectly. It correctly parsed the v1/v2/v3 schemes, extracted the certificate details (subject, issuer, and SHA-256 fingerprint), and accurately flagged self_consistent: true and schemes_agree_on_signer: true.
Let me know if you want me to throw any other edge cases at it (key rotation, v1-only, etc.) to cross-check against apksigner. Happy to keep testing.

@uyg7x commented on GitHub (Oct 18, 2026): Hey @FerroLx, That was it. Nuking the dist folder and manually running npx tsc -p tsconfig.build.json followed by node scripts/bundle-runtime.mjs fixed it. Looks like the standard npm run build script was skipping the CLI runtime compilation. The command is running clean on Windows now. I tested it against a real APK, and it works perfectly. It correctly parsed the v1/v2/v3 schemes, extracted the certificate details (subject, issuer, and SHA-256 fingerprint), and accurately flagged self_consistent: true and schemes_agree_on_signer: true. Let me know if you want me to throw any other edge cases at it (key rotation, v1-only, etc.) to cross-check against apksigner. Happy to keep testing.

bsakaguchi commented

2026-10-31 00:33:06 +00:00

Author

Owner

@FerroLx commented on GitHub (Oct 25, 2026):

Thanks @uyg7x for the Windows test and the stale-dist diagnosis, and for the grammar fixes. inspect-apk-signature is now in main through #4158, with follow-up work from @gensokyo-dev.

If you still want to throw edge cases at it, please test against current main. The ones that matter most, each compared with apksigner verify --print-certs -v (plus apksigner lineage --print-certs for rotation), are:

a key rotation (a v3 lineage with two signers);
a v1-only APK;
an APK re-signed with a different key and no lineage;
one byte changed in a ZIP entry after signing.

Please open a new issue for any mismatch you find.

@FerroLx commented on GitHub (Oct 25, 2026): Thanks @uyg7x for the Windows test and the stale-`dist` diagnosis, and for the grammar fixes. `inspect-apk-signature` is now in `main` through #4158, with follow-up work from @gensokyo-dev. If you still want to throw edge cases at it, please test against current `main`. The ones that matter most, each compared with `apksigner verify --print-certs -v` (plus `apksigner lineage --print-certs` for rotation), are: - a key rotation (a v3 lineage with two signers); - a v1-only APK; - an APK re-signed with a different key and no lineage; - one byte changed in a ZIP entry after signing. Please open a new issue for any mismatch you find.

bsakaguchi commented

2026-10-31 00:33:06 +00:00

Author

Owner

@uyg7x commented on GitHub (Oct 25, 2026):

Awesome, glad I could help get the Windows build sorted and the docs polished! I'll keep an eye out for those edge cases (key rotation, v1-only, tampered, etc.) as I use the tool, and I'll open a new issue if I spot any mismatches against apksigner. Great work getting this merged!

@uyg7x commented on GitHub (Oct 25, 2026): Awesome, glad I could help get the Windows build sorted and the docs polished! I'll keep an eye out for those edge cases (key rotation, v1-only, tampered, etc.) as I use the tool, and I'll open a new issue if I spot any mismatches against apksigner. Great work getting this merged!

bsakaguchi referenced this issue

2026-10-31 01:04:37 +00:00

[PR #2359] [MERGED] fix(adb): count requested permissions that the device marks restricted #5185

Rows
Columns

[GH-ISSUE #4537] [Feature] Inspect APK signature schemes, signers and rotation lineage statically #2359

Before submitting

Area

Current limitation

Use cases

Desired outcome and success criteria

Expected interaction with targets

Target and scope details (optional)

Verification available so far

Verification