Well, that escalated quickly.

In Part 1 of this investigation, I went down a rabbit hole after reading about some absolutely fascinating work being done to unlock NVIDIA GPUs through voltage fault injection, eFuse manipulation, and early-boot firmware modifications.

To reiterate the question I'm broadening the existing research to:

Can we identify and potentially recover disabled hardware on an older NVIDIA GPUs, purely to increase consumer performance? Specifically my disposable PNY GTX 1650?

I spent some time building a dedicated Arch Linux research environment, reading hardware registers, poking around Nouveau's driver initialization process, and generally bullying a depressed graphics card.

And guess what?

WHAT! New NVIDIA hacks are dropping?!

This came across my feed, as a newish drop from another hobby reverse engineer out there in the world. Then I saw more information about it in a drop from Tom's Hardware.

The claim seemed too good to be true, a 10x memory increase with just software induced hardware changes from eFuses?! So I got to reading and quickly made sense of what was going on, the HBM2 & HBM memory modules from this gen were just binned different based on addressable memory reliability and economics seemingly.

Now I don't have any HBM or stacked die GPUs to play with. But it made me realize something; in this world of AI delegation and the ever increasing breakdown of interfaces between hardware security and software security, surely I can use other researchers findings to check if there's similarly unlockable or differently binned features on other GPUs that were binned from higher spec dies?

I Tried to Dump the Firmware From a UE Wonderboom. I Found 2.4 Seconds of Sound Effects Instead.

The story of reverse-engineering a first-generation Bluetooth speaker, one mystery test pad, improvised SPI programmer, and 1 tiny puff of magical electric smoke at a time.

Project: Ultimate Ears Wonderboom (Gen 1)
Main SoC: Airoha AB1520
External flash: Fudan FM25Q08A, 8 Mbit / 1 MiB SPI NOR
Research: October 2026
Status: External flash dumped and decoded; main firmware still evades extraction so far

Reverse engineering is something I have been learning for years, most reverse engineering projects when you're learning end in confusion, destroyed devices, and breaking things to figure them out...

I wish I started my journey with this project! By the end of the first day, I had a root shell, a full extracted firmware filesystem, the stock update image unpacked, the bootloader command list, the actual compressed kernel, several device trees, and a much better sense of what not to type into CFE, (CFE is Broadcom's network device firmware and bootloader for ARM SBCs).

The short version is: this router is a surprisingly capable ARM Linux system wrapped in several layers of Broadcom and Netgear boot infrastructure. Though, there is also no security??

Let's start from the beginning,

I'm a tech hoarder with a penchant for collecting embedded development hardware and coming up with projects that force me to learn, often I find myself flipping through projects and leaving things for an extended period when they get hard. After several months, I will face a harder problem as I progress, and looking for respite, I eagerly pick up the original project. Hopefully having a blog will help me launch back in from my drop-off points in the future.

Such is the case with my e-ink display, several months ago I picked up an 800x480p 7-color e-ink from a local retailer after doing minimal research (Unaffiliated link to the display from Pimoroni); when I went to use it I was surprised to see they only included a Python library! My original use was to have a slow refresh calendar that would update by push from a local server that sent bitmaps to a Raspberry Pi Nano.

Napkin math makes me reckon that the 800x480 display in a frame buffer would have to represent 512,000 pixels. So with the 264KB of onboard RAM on the Pico I would have to be careful since even a byte per pixel, (512KB), is just under double the total RAM available before even writing any code. Even still, I also presumed that I could use 3 bits for each pixel and have a 154KB data structure for a frame buffer that would also be quicker to iterate through when needed.

The Python library was a heartbreaker because I would have to use MicroPython. #1, I'm not even sure that's possible, #2, if it is possible I'm still not doing that when there is a wonderful C/C++ SDK for the device. I ended up getting a basic grasp for the few supported use cases of a 45-second refreshing, Python-driven display (with a glass panel, excellent resolution, and color clarity) with Python3 on Pi Zero W.

Fast Forward to Today

The Problem

For the last two days, I have been reconfiguring my personal network infrastructure to create a complete, secure, and coherent solution for my needs. For context, this server is running systemd Gentoo Linux with +march=native and standard stable compile flags, testing packages are not allowed globally, the kernel is manually configured, it was compiled and installed 12/31. Special care was used to ensure I selected compatible kernel options matching the Gentoo Wiki's article on Docker.

This issue took longer than I care to admit because of a couple now glaringly obvious red herrings. I was able to emerge and install Docker without a problem, but when I attempted to run the service I received the following error:

Dec 31 10:34:56 gentoo systemd[1]: Starting Docker Application Container Engine...
Dec 31 10:34:56 gentoo dockerd[134836]: time="2024-12-31T10:34:56.093036541Z" level=info msg="Starting up"
Dec 31 10:34:56 gentoo dockerd[134836]: time="2024-12-31T10:34:56.280360174Z" level=info msg="[graphdriver] using prior storage driver: overlay2"
Dec 31 10:34:56 gentoo dockerd[134836]: time="2024-12-31T10:34:56.280599062Z" level=info msg="Loading containers: start."
Dec 31 10:34:56 gentoo dockerd[134836]: time="2024-12-31T10:34:56.282787923Z" level=warning msg="Running modprobe bridge br_netfilter failed with message: modprobe: WARNING: Module bridge not f>
Dec 31 10:34:56 gentoo dockerd[134836]: time="2024-12-31T10:34:56.287999183Z" level=info msg="unable to detect if iptables supports xlock: 'iptables --wait -L -n': `modprobe: FATAL: Module ip_t>
Dec 31 10:34:56 gentoo dockerd[134836]: time="2024-12-31T10:34:56.340305545Z" level=info msg="stopping event stream following graceful shutdown" error="<nil>" module=libcontainerd namespace=moby
Dec 31 10:34:56 gentoo dockerd[134836]: failed to start daemon: Error initializing network controller: error obtaining controller instance: failed to register "bridge" driver: failed to create >
Dec 31 10:34:56 gentoo dockerd[134836]: iptables v1.8.11 (legacy): can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Dec 31 10:34:56 gentoo dockerd[134836]: Perhaps iptables or your kernel needs to be upgraded.
Dec 31 10:34:56 gentoo dockerd[134836]:  (exit status 3)
Dec 31 10:34:56 gentoo dockerd[134836]: time="2024-12-31T10:34:56.340724371Z" level=info msg="stopping event stream following graceful shutdown" error="context canceled" module=libcontainerd na>
Dec 31 10:34:56 gentoo systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE
Dec 31 10:34:56 gentoo systemd[1]: docker.service: Failed with result 'exit-code'.

This is where I went naive, the error there clearly indicates iptables is not working properly and the docker service can't properly register it's network configuration causing it to fail. Working through that error log from the bottom up, reviewed all the wiki entries on iptables & ip_tables, I emerged iptables again and once it was finished I attempted to run "iptables -L" which met me with another error shown below. One thing I learned through this is that ip_tables, and iptables, are two related but different things (ip_tables is a kernel module and iptables is a front-end for the module).