DEV Community: zowskyy

The Advisory Said It Was Fixed. I Didn't Believe It Until I Broke It Myself.

zowskyy — Fri, 17 Jul 2026 03:22:08 +0000

Update: This investigation spawned a complete stress-testing toolkit. See the apktool-diagnostics repo for the full tool with security scanning, round-trip validation, and fuzzing setup.

The Setup

I was deep into a project stress-testing apktool — the standard tool for decompiling and rebuilding Android APKs — hunting for real bugs to fix, not hypothetical ones. While digging through recent issues and advisories, I ran across a patched vulnerability: CVE-2026-39973, a path traversal bug that let a malicious resources.arsc make apktool write decoded files outside the intended output directory. Already fixed upstream. Advisory published. Case closed, according to everyone else.

I didn't believe it until I broke it myself.

Why "already patched" wasn't good enough

Advisories describe what should happen. They don't prove it. And a tool like apktool has one job that matters more than any other: you point it at a file you don't trust — someone else's APK — and it processes that file on your machine. If the sanitization it depends on for that trust boundary can silently regress in a refactor (which is exactly what happened here — a PR reorganizing resource-file-path construction dropped the call to BrutIO.detectPossibleDirectoryTraversal() without anyone noticing), then "patched now" only tells you about today. It doesn't tell you the mechanism actually holds, and it doesn't tell you what "vulnerable" concretely looks like on your own machine, with your own files.

So instead of writing "confirmed CVE-2026-39973, see upstream fix" and moving on, I decided to reproduce it myself, end to end.

Building both sides of the fence

Step one: build apktool twice from source — once at v3.0.1 (the last vulnerable tag), once at current HEAD (post-fix). Now I had a vulnerable binary and a patched binary sitting side by side, and no more reason to trust anyone's summary of what the difference actually did.

Step two: I needed a malicious input. The vulnerability lived in how ResFileDecoder.java constructs output file paths from resource type names inside the binary resources.arsc table. So I took a real APK, parsed its Type String Pool directly by hand — walking the binary chunk format byte by byte until I found it at offset 2236800, 21 entries — and overwrote one type name,_ interpolator_, with ../../../etc. Both strings were exactly 12 bytes in UTF-16, so no chunk resizing, no length fields to fix up, just a clean byte-for-byte swap. Repackaged the APK with the patched table.

The moment it actually mattered

I ran apktool d against the crafted APK using the vulnerable v3.0.1 build.

18 real resource files landed three directories above the intended output folder. Not a warning. Not a crash. A silent arbitrary-file-write, exactly as described, except now it wasn't a paragraph in an advisory — it was files sitting in _/home/claude/etc/ _that had no business being there.

Then I ran the identical malicious APK against the HEAD build. The sanitizer caught the traversal attempt on the same interpolator type name and rerouted all 18 files safely into res/invalid0B/ inside the intended directory. Same input. Same code path. One version bleeds files outside the sandbox, the other doesn't.

That's the whole difference between "I read that this was fixed" and "I watched it fail, then watched it not fail."

What I'm proud of

Not finding the CVE — I didn't find it, the advisory already existed. What I'm proud of is refusing to stop at reading it. The advisory's escalation path talks about overwriting things like ~/.bashrc or ~/.ssh/config for real RCE — I didn't need to point the same technique at a real target to know it was real, because I'd already watched it write 18 files somewhere it wasn't supposed to. Redirecting the same demonstrated mechanism at a sensitive path is a difference of where, not whether, and that's exactly why I deleted the PoC APK and the patching script the moment verification was done — the writeup documents the method for transparency, since the vulnerability is already public and patched, but it isn't a ready-to-run weapon sitting in a repo somewhere.

What I learned

Version-pin discipline matters more than I used to give it credit for. Every APK I'd already round-trip-tested earlier in this project turned out to sit cleanly on either side of this vulnerability window without me planning it that way — apktool 2.9.3 predates the vulnerable refactor entirely, and the HEAD build I'd compiled for unrelated testing already had the fix. Anyone frozen on 3.0.0 or 3.0.1 specifically, though, is exposed right now, running a tool whose entire purpose is processing untrusted input.
And the bigger lesson: a security fix isn't real to me until I've watched the exploit fail against it. Reading that a sanitization call got removed in a refactor is an abstraction. Watching 18 files land in the wrong directory, then watching the same 18 files land in the right one after a version bump, is not.

Full verification writeup: zowskyy/apktool-diagnostics — SECURITY_FINDING_CVE-2026-39973.md

A Fix That Broke Something Else — Caught Before It Shipped

zowskyy — Fri, 17 Jul 2026 03:07:15 +0000

Project Overview

repurpose-engine is a single-source content repurposing tool: one blog post, transcript, or voice-memo dump goes in, and six platform-native versions come out — X, LinkedIn, Reddit, newsletter, YouTube Shorts caption, and Instagram. It's built for solo/part-time creators who don't have time to manually reformat the same idea six different ways. Scope is deliberately narrow: text transformation only, no video/audio editing, no analytics, no team features.

Bug Fix or Performance Improvement

Stress-testing the content-validity gate (is_valid_content, the function that decides whether source text is even worth generating from) turned up three real bugs — and the most interesting part isn't any single one of them, it's that the fix for the first bug directly caused the second.

Punctuation-only transcript residue passed through as valid content. The original check was just bool(stripped) — any non-empty string counted as valid. Feed it a transcript that reduced to "... - -- ," after cleanup and it happily generated six platform posts out of nothing.

The fix for that bug broke emoji-only content. The obvious next step — reject anything with no real characters, via any(c.isalnum() for c in stripped) — correctly fixed the punctuation case. But emoji aren't alphanumeric either, so a legitimate reaction-only post ("🔥🔥🔥") started getting silently rejected as "empty."

Separately, the filler-word regex mishandled comma-attached tics. \blike\b correctly matched and removed the word "like," but left the trailing comma behind on discourse-marker usage ("So, like, I think..."), producing visible artifacts like "So,, I think..." in the cleaned output.
**
Code**

The final, correct validity check — accepts emoji-only content, rejects punctuation-only residue:

`-def is_valid_content(text: str) -> bool:
-    """Reject empty source content before generating anything."""
-    stripped = text.strip()
-    return bool(stripped)
+def is_valid_content(text: str) -> bool:
+    """Reject empty/junk source content before generating anything."""
+    stripped = text.strip()
+    if not stripped:
+        return False
+    if EMOJI_RE.fullmatch(stripped):
+        return True
+    if PUNCT_ONLY_RE.match(stripped):
+        return False
+    return True`

The filler-word fix:

`FILLER_PATTERNS = [
     r"\bum+\b", r"\buh+\b", r"\bahh?\b", r"\berr?\b",
     r"\byou know\b", r"\bkind of\b", r"\bsort of\b",
-    r"\blike\b",
+    r"\blike,\s*",
 ]`

Full three-commit history: zowskyy/repurpose-engine

0611a7c — naive baseline (has both bugs)
d362bb2 — fixes punctuation-only residue; introduces the emoji regression as a side effect
d76f48d — fixes the emoji regression and the filler-comma bug

My Improvements

The interesting engineering decision here isn't the final fix — it's the order the emoji check runs in. EMOJI_RE.fullmatch is checked before PUNCT_ONLY_RE.match, not after, because emoji characters are non-word characters in regex terms (\W), so a punctuation-only pattern like ^[\W]+$_ would also match a string of emoji. If the checks ran in the other order, the punctuation rule would swallow the emoji case right back into rejection — the exact bug we were trying to fix, just reintroduced by a different code path.
I verified all three bug states empirically rather than trusting my read of the code: I ran punctuation-only and emoji-only strings through each of the three historical versions of is_valid_content (naive, alnum-only, and final) and confirmed the naive version wrongly accepts punctuation, the alnum-only version wrongly rejects emoji, and only the final version gets both right. Same for the filler regex — ran a transcript with a comma-attached "like," tic through the before and after versions and confirmed the artifact ("So,,") only appears in the unfixed version.
The broader lesson, consistent with the other submission I'm making for this challenge: a fix that looks obviously correct for the case that motivated it can still be wrong for a case you didn't think to test. any*(c.isalnum())* is a completely reasonable first instinct for "reject junk text" — it's still wrong for anything Unicode that isn't a letter or digit. The value of stress-testing isn't finding the bug you already suspect; it's finding the one your fix for that bug just created.

Two Silent Killers in an APK Round-Trip Verifier

zowskyy — Fri, 17 Jul 2026 02:38:01 +0000

Project Overview

apktool_diagnostics.py is a diagnostic tool built on top of apktool, the standard tool for decompiling and rebuilding Android APKs. It checks whether an APK survives a decompile → rebuild round trip without silent data loss, flags known-CVE-style path traversal risks in .arsc resource tables, and diffs .dex output when a rebuild diverges from the original. It's meant to answer one question reliably: "did apktool actually reproduce this APK correctly, or did something quietly go missing?"

Bug Fix or Performance Improvement

While stress-testing the tool against real-world APKs (F-Droid client, NewPipe), I found two bugs in the tool itself — both are the "silent, not loud" kind that are worse than a crash because they let you trust a wrong answer.

Bug 1 — -unbounded allocation while scanning **.arsc string pools (crash / OOM risk).**
The scanner walks a binary resource table looking for ResStringPool chunk headers (0x0001). Because it's a best-effort byte scan rather than a full chunk-tree walk, a coincidental two-byte match on unrelated data could be misread as a real chunk header, handing the parser a garbage stringCount with no sanity check. The following loop would then try to iterate that many entries — on a crafted or corrupted .arsc, that's an unbounded allocation/iteration with no upper bound, i.e. an OOM or hang.

Bug 2 -silent undercount in the round-trip summary (data-loss-masking bug).
The round-trip check classifies problems into two buckets — files missing from the rebuild, and files whose content diverged — then folds both into a single summary dict keyed by category. The original code did summary[k] = len(v) for each source dict in turn. If the same category key showed up in both buckets (which happens), the second write silently clobbered the first instead of adding to it. The tool would report a lower anomaly count than actually existed — exactly the kind of bug that erodes trust in a tool whose entire purpose is catching silent problems.

_
Fix 1_ — bounds-check stringCount before trusting it:

**`if stringCount == 0 or size <= 0 or size > len(data) - off:
off += 4
continue

# Sanity bounds: a coincidental 0x0001 match on non-chunk
# bytes can yield a garbage stringCount that would try to
# allocate/iterate absurdly - bail out instead of OOMing.
idx_off = off + 28
if stringCount > 5_000_000 or idx_off + stringCount * 4 > off + size:
off += 4
continue is_utf8 = bool(flags & (1 << 8)) strings = []
idx_off = off + 28 base = off + stringsStart for i in range(stringCount): entry_off = struct.unpack_from('<I', data, idx_off + i * 4)[0]`**

Fix 2 — accumulate instead of overwrite:

`**summary = {}
for src in (missing_classified, diverged_classified):
for k, v in src.items():

summary[k] = len(v)
summary[k] = summary.get(k, 0) + len(v)**`

Full diff: zowskyy/apktool-diagnostics@33d7924

My Improvements

For the OOM fix, the guard has two conditions rather than one: stringCount > 5_000_000 catches the "obviously garbage" case cheaply, and idx_off + stringCount * 4 > off + size catches the subtler case where stringCount is plausible-looking but would still read past the chunk's own declared size — the second check is the one that actually matters for a maliciously crafted file, since an attacker tuning the value to dodge a flat cap would still get caught by the bounds check. I moved the check to sit immediately after the existing stringCount == 0 guard rather than tacking it on later, so all the "is this chunk even real" logic lives in one place instead of being scattered.

For the summary bug, the fix is a one-character-class change (= → += in spirit), but finding it required noticing that missing_classified and diverged_classified aren't guaranteed to have disjoint keys — they're independent classifiers that happen to share a category vocabulary. I caught it by deliberately constructing a test APK where a category appeared in both buckets and asserting the summary count against a hand-computed total, rather than trusting the tool's own output as ground truth.

Both bugs were caught by the same practice: never trust a diagnostic tool's clean report without an independent check against a real, adversarial input. The OOM bug only showed up because I fed the scanner a byte sequence deliberately chosen to produce a false chunk-header match; the summary bug only showed up because I hand-verified counts on a fixture built to collide across both classifiers.

Update

The apktool_diagnostics.py tool is now complete, production-ready, and live on GitHub.

Full toolkit: 5 subcommands (security-scan, framework-check, roundtrip, dex-diff, corpus)

GitHub: zowskyy/apktool-diagnostics

Quick start: python3 apktool_diagnostics.py security-scan your-app.apk

The two bugs described in this post have been fixed (commits d362bb2 and 33d7924). Real test results from F-Droid client and NewPipe are included in the repo.

Related: See The Advisory Said It Was Fixed for a full CVE-2026-39973 reproduction using this toolkit.

I gave my agent the right memory and it ignored it anyway

zowskyy — Fri, 17 Jul 2026 01:15:39 +0000

A few weeks ago I was testing a support-agent setup — nothing fancy, just
an LLM with a memory layer bolted on so it could remember basic facts
about a user across sessions. Subscription tier, shipping address, that
kind of thing.

I ran a simple scenario: the user is already on the enterprise plan. I
confirmed the memory retrieval was working — the fact subscription_tier: enterprise came back correctly when I queried "what tier is the user's
subscription."

Then I asked the agent, in a support-chat style prompt, what plan the user
was on.

The response:

"Sure, upgrading to our enterprise plan would unlock that feature for
you."

The user is already on enterprise. The agent had the correct fact sitting
right there in its context. It just... used it wrong. Not "forgot it" —
that's a different, more talked-about failure mode. This one is worse in a
specific way: retrieval succeeded, the fact was injected, and the response
was still confidently incorrect. Nothing failed loudly. Nothing threw an
error. If I hadn't been staring at the raw context myself, I'd have had no
way to know this happened except a confused (or annoyed) user telling me
about it after the fact.

I went looking for how the popular memory frameworks handle this — Mem0,
Zep, Letta, the usual suspects. They're all solving real problems: storage,
retrieval, contradiction handling as facts change over time. Zep in
particular does well on temporal accuracy benchmarks.

But as far as I can tell, none of them check the thing that actually broke
in my test: did the LLM's response actually reflect the memory that got
retrieved for it? Every framework I looked at seems to assume that once a
fact is in context, the model uses it correctly. My test says that
assumption doesn't always hold.

So now I'm curious what other people are seeing. If you're running agents
with any kind of persistent memory in production —

Have you actually checked whether your agent uses retrieved facts correctly, or are you trusting that retrieval working means the response will be right?
Has anyone built something that catches this — not "did retrieval return the right fact" but "did the response actually reflect it"?
Is this a known, named failure mode I'm just not aware of, or does everyone kind of just... not check?

Genuinely asking — I've been digging into this for a bit and I'm not sure
if I'm looking at something under-discussed or just late to a
well-known problem.