mgaldys4
mgaldys4 on Hacker News
Shameful. First time I've seen prompt injection shipped in a product's privacy policy. Before this I only saw it in academic papers, like light-colored text or text only OCR can read. Now WhatsApp has industrialized it. What a "progress."
In case you're not aware: my tool got accepted to Black Hat Europe 2026 and sparked discussion in the reversing community, the Black Hat committee said "your tool is very very highly rated", at Pwn2Own 2026 the Samsung RCE winner ch0pin personally recommended my tool, Chrome vulnerability researcher eternalsakura13 posted on X saying they used droidasc to find a bunch of vulnerabilities, and even just now, I'm still using droidasc to hunt for bugs in Honor. I think it has at least contributed something to the community, so what's wrong with me recommending this tool to others and helping others improve their reversing workflow?
Posted by
mgaldys4 on Saturday October 10, 2026 @05:44AM
from the justice.gov dept.
Yes! APKMirror is a good choice. AndroZoo works too, but it's academic and you need to apply for API access.
Slightly off topic. I looked at REA's Android reversing support and found it still uses jadx mcp. That kills large scale APK reversing. jadx takes tens of minutes to preprocess an APK, build a code relationship database, etc. Even headless mcp is no exception. I basically can't use it to analyze APKs at scale, like 100 large commercial APKs in a pipeline, or 100 preinstalled APKs from a phone ROM to hunt bugs.
So I built droidasc. No memory bloat, no parsing slowdown. Analysis is in milliseconds. Global xref on a 300MB APK takes 1.5 seconds. I used it with codex to analyze phones from 3 different brands and found 2 RCEs and 5 root bugs in a few days. I plan to detail these at Black Hat Asia 2027. A friend used droidasc to scan various bug bounty targets at scale and found 10+ RCEs. Way, way faster than jadx.
https://github.com/MG1937/ASC
Posted by
mgaldys4 on Thursday September 24, 2026 @01:01AM
from the medium.com dept.
My only edit was to continue refuting at the beginning of the sentence that Claude Code's use of remote control to control agent.md is still incorrect. The rest is identical to the original, and my attitude before and after has not changed.
As for whatever "had enough" he mentioned, I'm not sure whether he said it on purpose or genuinely misremembered.
Since that's how he remembers it, so be it. I can't be bothered to explain anymore.
In terms of international game theory, this is entirely expected. No action would be the anomaly.
At least in my country, a job posting that stays up forever isn't a ghost job. It's a company that can't keep people. Either the conditions are brutal or the pay is garbage.
JADX's memory management has long been a serious problem, and many people in the mobile reverse engineering community have suffered from it. Hope this helps optimize everyone's reverse engineering pipeline.
Posted by
mgaldys4 on Wednesday September 23, 2026 @12:24PM
from the show-hn dept.
https://github.com/MG1937/ASC
A few days ago, I was using JADX MCP to analyze my phone, but JADX MCP was just too laggy. I had a large number of APKs to analyze, and nearly every one of them required spinning up a new JADX process. With just two or three of them, my computer ran out of memory. The efficiency was terribly low, so I came up with an idea and wrote a script.I built a on-demand Android decompiler called Droid...
Posted by
mgaldys4 on Wednesday September 23, 2026 @11:34AM
from the blackhat.com dept.
I'd like to share my own experience, which perfectly illustrates Paul Graham's point.
I was trying to fix a bug in ART using Frida. I admitted I knew nothing about the intricate details or tricks of ART. I couldn't even understand why the original author wrote the code in a certain way. Feeling lost, I turned to GPT. But because I couldn't understand the AI's complex reasoning, I couldn't guide it. The AI stubbornly blamed a conflict between Frida and JVMTI and ran in the wrong direction for an hour with zero progress.
Eventually, I gave up on the AI and decided to debug it myself. I couldn't afford to read the whole ART codebase to understand the full context. But in the AI era, the cost of getting a quick summary is near zero. With AI helping me grasp the big picture, I pinpointed the actual bug: a compilation callback issue during ART's transition between runnable and native states.
Before, finding this bug would have required days of reading ART's code. Now, with AI helping me understand something I'm completely unfamiliar with, it took just 1 hour.
My key takeaway: AI is incredibly useful, but if you just say "I don't understand, you keep going," you'll be stuck forever. You still need to learn things.
This is exactly why we should still learn to code. AI is a powerful tool for lowering the cost of understanding, but it cannot replace the human ability to judge, guide, and intervene. You need to know enough to be the manager.
Even if this was an honest rollout mistake, the design is indefensible. Reading a local file should never depend on a remote feature flag, and silently skipping it with no warning is worse. I've tried to give Claude Code the benefit of the doubt, but this crosses a line.
This is a market and competition driven race to the bottom, a vicious cycle. Everyone knows what is wrong, but nobody dares bet that the other side will slow down. Slow down and you are instantly out. The pace is now measured in weeks or even days. Personally reviewing code or trying to ensure code quality has become a kind of leisure activity, like playing the piano or painting.
Data-only attacks are somewhat low-hanging fruit. Classical static analysis could already find them before AI got this strong, and LLMs make identification even easier. But the real threat is risk buried in business logic, especially abuse of normal business logic. Take e-commerce refund abuse. Bug hunters would not even call it a risk, yet fraud rings have arbitraged millions off this kind of logic. And because the logic is legitimate business logic, it is very hard to detect.
Put it bluntly: the weavers who could be replaced by the spinning jenny were clearly doing repetitive labor. People writing code and maintaining project pipelines a few years ago relied heavily on experience, but in a sense that was also "repetitive labor." Replacing repetitive labor and freeing up productivity is of course progress.
But reform always has its victims. Like the textile workers who starved in the streets centuries ago, and me, kicked to death in the street by AI today...
I think that's right. Expert experience used to be almost the most precious and valuable part of the computer field, but today that experience has been "distilled" into SOTA models.
Even the Millennium Prize Problems have, in a way, become benchmarks for model companies to prove themselves. The smartest individuals among humans are becoming replaceable. Intelligence has become a product you can quantify and buy with electricity. That feels awful.