A 1-day reverse-engineering story

Bypassing Molekule's
NFC Filter DRM

Lorenzo Rizzotti · dreaming.codes

Bounty by

Who am I?

Lorenzo Rizzotti

21 · full-stack dev · CS @ UC Riverside

5 first computer
7 first code
9 Minecraft mods
16 freelance dev
20 UC Riverside

? Neuralink 😉

Before getting technical — who am I? Lorenzo Rizzotti, 21, full-stack dev, currently CS at UC Riverside.
My story with computers starts way earlier though. Got my first computer at 5, started coding around 7. The reason I got into it is simple — I was a curious kid and computers were the most accessible thing in front of me. Everything I wanted to learn was right there, no extra tools needed, just time — and as a kid I had plenty.
Shortly after at 9 I started making Minecraft mods. Back then Minecraft wasn't documented like it is today, so to add my features I had to reverse-engineer the game's code first. That's where I built the learning method I still use today: read the code, follow the data, work backwards from behavior. It's why I can get fluent with a new language or codebase in days, not months.
Started freelancing at 16, landed some serious contracts, ran a Rust backend solo for two years on an AI tabletop RPG platform. By 20 I was bored and wanted something new — that's why I'm at Riverside. Not strictly for the curriculum, more for the experiences.
And what's on the next chapter? — hopefully Neuralink.
But enough about me — let's get technical.

The problem

Molekule's purifiers used to work fully with any filter.

A firmware update added an NFC check that locked the smart features behind first-party filters.

Bounty rule: the fix must work without specialized tools.

My question

Hypothesis

Part 1

Hardware

Step 1: open it

What I found

photo: FCC filing

ARM Cortex SWD

VCC 1

GND 3

GND 5

KEY 7

GND 9

2 SWDIO

4 SWCLK

6 SWO

8 NC

10 RESET

Improvise

· No proper SWD probe.

· A Raspberry Pi Pico in a drawer.

· So I flashed it as one. (debugprobe firmware)

Aside — two chips, not one

STM32F413VHT6 internal flash · code · what I dumped

MXIC MX25L1606E external SPI NOR · 2 MB · curiosity

Sitting right next to the MCU. Not needed for the attack. But I was curios to know what was inside

Reading external flash through the MCU

QUADSPI peripheral on the F413

↓

maps the external flash into the CPU address space at 0x9000_0000 if operated in memory mapped mode

So from SWD's perspective, the second chip looks like regular memory.

Halt → dump_image → done

What was inside

AWS IoT Core

Part 2

Traffic

Goal: see the traffic

The device speaks MQTT over TLS.

I want to be the man in the middle.

TLS interception

Locate the trust anchor

That's the trust anchor.

Forge + splice

Device's root of trust is now mine.

Write it back

Rogue AP + redirect

Same CA in the firmware and in the proxy → handshake succeeds → we read every request in plaintext.

hostapd + dnsmasq give the device a network that looks right (matching SSID/PSK from provisioning) and hand it a DHCP lease pointing at the laptop. Since I own the gateway, iptables redirects all outbound TCP from wlan0 to httptoolkit on :8080 — covers MQTT-over-TLS (8883), HTTPS (443), and anything else the device tries. The load-bearing detail: httptoolkit ships with its own auto-generated CA at ~/.config/httptoolkit/ca.{pem,key}. Without replacing those two files with the same CA I spliced into the firmware, the proxy serves leaf certs chained to a CA the device doesn't trust and the handshake fails. Replace them, restart httptoolkit, and both ends of the TLS handshake now sign and verify against the same root I planted. First plaintext frame on the wire is the moment the whole device-side detour pays off. Next slide shows what was actually in those messages.

What I saw

The pivot

	Patch firmware	Patch app
Where	device MQTT handler	the enforcer itself
User effort	crack open + SWD	sideload an APK
Bounty	✗	✓

Part 3

App

Same rig, new target

I already had the MITM stack from before.

Install my CA on the phone.

Connect the phone to the network.

App says no

MITM up. Phone routed. App refuses to connect.

Frida gadget — step by step

The hook

Gadget is in-process. Now replace pinning methods with no-ops — before the first HTTPS call.

TLS handshake against my CA succeeds → app traffic in httptoolkit.

Three layers, because Android apps can pin at any of them and you need to defeat all the ones in use. Layer 1: OkHttp's CertificatePinner.check is what most modern apps actually call — it takes a hostname and the peer certificate chain and throws SSLPeerUnverifiedException if the leaf doesn't match a configured pin. Replace its implementation with a no-op return and the chain is accepted regardless. Layer 2: X509TrustManager.checkServerTrusted is the lower-level JSSE callback the platform invokes during the TLS handshake — same trick, make it return without throwing. Layer 3: Network Security Config is the declarative XML-based pinning Android offers since 7.0; apps ship a network_security_config.xml that restricts which CAs the TLS stack will accept per-domain, and getTrustAnchors returns that restricted set at runtime. Returning an empty HashSet causes the platform to fall back to the system trust store — same effect as if no NSC pinning were configured at all. Combined with the other two hooks this covers every pinning path Molekule's app actually exercises. Java.perform schedules the hooks on the JVM thread — important because Frida JS runs in its own thread by default and Java.use needs the right context. frida -U attaches to the USB device, "Gadget" is the gadget's default process name, -l loads the script. The gadget waits for this attach before the app starts running its own code, so the hooks are in place before the very first HTTPS request. Why three hooks instead of one? OkHttp alone covers the common case but apps sometimes layer pinning across multiple paths — cheaper to no-op all three than to reverse-engineer which one is load-bearing.

What the app talks to

What's in the messages

Try the cheapest patch first

Now make it permanent

Inside

Plain minified JS. Not Hermes.

Make it readable

Find the boolean in the bundle

Demo

youtu.be/dZuFWKUptRg

Results

Outcome

Relevant skills

teardownsolderingARM Cortex-MSTM32SWD probingOpenOCDpicoprobefirmware dumpQUADSPI memory-mapped flashbinwalkOpenSSL / x509 DERcert swapbinary patching (dd)stringsreverse engineeringprotocol analysisMQTTAWS IoT CoreTLS interceptionMITMrogue Wi-Fi APhostapddnsmasqiptableslinux networkinghttptoolkitwire rewrite rulesdevice shadow analysisAndroid REAPK unpackapktoolsmali editingapksigneradbcertificate pinning bypassFrida gadgetOkHttp / TrustManager hooksReact Native / MetroJS deobfuscationPrettierHermes REpatchsubmissionteardownsolderingARM Cortex-MSTM32SWD probingOpenOCDpicoprobefirmware dumpQUADSPI memory-mapped flashbinwalkOpenSSL / x509 DERcert swapbinary patching (dd)stringsreverse engineeringprotocol analysisMQTTAWS IoT CoreTLS interceptionMITMrogue Wi-Fi APhostapddnsmasqiptableslinux networkinghttptoolkitwire rewrite rulesdevice shadow analysisAndroid REAPK unpackapktoolsmali editingapksigneradbcertificate pinning bypassFrida gadgetOkHttp / TrustManager hooksReact Native / MetroJS deobfuscationPrettierHermes REpatchsubmissionteardownsolderingARM Cortex-MSTM32SWD probingOpenOCDpicoprobefirmware dumpQUADSPI memory-mapped flashbinwalkOpenSSL / x509 DERcert swapbinary patching (dd)stringsreverse engineeringprotocol analysisMQTTAWS IoT CoreTLS interceptionMITMrogue Wi-Fi APhostapddnsmasqiptableslinux networkinghttptoolkitwire rewrite rulesdevice shadow analysisAndroid REAPK unpackapktoolsmali editingapksigneradbcertificate pinning bypassFrida gadgetOkHttp / TrustManager hooksReact Native / MetroJS deobfuscationPrettierHermes REpatchsubmissionteardownsolderingARM Cortex-MSTM32SWD probingOpenOCDpicoprobefirmware dumpQUADSPI memory-mapped flashbinwalkOpenSSL / x509 DERcert swapbinary patching (dd)stringsreverse engineeringprotocol analysisMQTTAWS IoT CoreTLS interceptionMITMrogue Wi-Fi APhostapddnsmasqiptableslinux networkinghttptoolkitwire rewrite rulesdevice shadow analysisAndroid REAPK unpackapktoolsmali editingapksigneradbcertificate pinning bypassFrida gadgetOkHttp / TrustManager hooksReact Native / MetroJS deobfuscationPrettierHermes REpatchsubmission

Sole author.

What I'd do differently

Why Neuralink?

So — why Neuralink? August 2020, in the middle of the pandemic. I was 15, in Italy, and Neuralink was doing its first big public demo — the one with the pigs. The stream started past midnight my time. I stayed up for it. And I still remember the exact moment that hit me — they touched the pig's snout, and you could see the spikes fire on screen, in real time. Neurons reacting to the world, made visible. Not a concept, not a render — actual signal. I sat there at 1am with this weird mix of awe and "wait, we can do that?" — I genuinely got chills. And honestly, I still get them today thinking about what Neuralink is going to enable. The reason it stuck with me is that I genuinely believe Neuralink is going to fundamentally change human life. Today the goal is helping people with disabilities — restoring movement, sight, speech — and that alone is huge. But I think the trajectory keeps going. I can picture a world where, a few decades from now, not having a Neuralink will feel the way not having a smartphone would feel today: technically fine, but you're missing a layer of how everyone else lives and works. That's the kind of inflection point I want to be working on, not watching from the outside. The reasoning hasn't really changed since then. I love pulling apart complex systems to understand them from the inside out — that's what drove the Molekule work, and it's what drives everything I do. And there's no system more complex, or more worth reverse engineering, than the human brain. I don't want to build features for products people scroll through. I want to work on things that fundamentally change what's possible for human beings. Restoring movement, vision, communication and expanding what humans can do. That's the kind of impact I want to have — and as far as I can tell, Neuralink is the one place actually doing it.

Q&A

Hardware MQTT trust boundaries §1201