Reverse Engineered Grill Controller Gets Open Firmware

If you are a regular reader, then the odds are you have taken apart an electronic gadget, either for a fix, or simply because your curiosity got the better of you. Once inside, it’s all but impossible to help yourself from doing at least a little reverse engineering. That’s what happened when [PRBS23] took a look inside a MasterBuilt Gravity 800 Grill for a simple wire fix. But one thing led to the next, and now open source firmware for the grill is freely available!

Control board schematic.
Control board schematic.

The first order of business in creating the firmware is reverse engineering the original controller. Opening it up immediately reveals an ESP-32 and a well-labeled programming port. The rest of the control board is equally simple, including connectors for four thermistor temperature sensors, lid open/close switch, fan driver, 16 segment LCD, piezo buzzer, and some physical inputs.

The thermistor along with the physical inputs are connected to a 16 pin chip, interfacing with the MCU over a 9600 baud UART connection. [PRBS23] cannot determine an ADC chip meeting these specifications, so the most likely answer is a cheap MCU programmed to act as a simple analog fronted.

The neatly labeled programming header is used to quite easily dump the firmware with the espflash utility. Analyzing this dump reveals a rather strange ADC correction function used by the original firmware. The necessity and overall utility of this function remains unclear, does corrects a maximum of around 40 degrees Fahrenheit.

Most of the other features ended up being at least somewhat easier. The CS1621 segmented display driver is reasonably well documented with datasheets making its implementation far easier. Likewise, the other odds and ends were implemented in a far more normal manner compared to the thermistors.

All this reverse engineering work got tied together into a neat little firmware package. It comes with over the air updates PID controlled temperature, and a real-time web interface. This also isn’t the first time we have seen an IoT device liberated from proprietary firmware, and this remains one of our favorite uses of reverse engineering!

 

Running DOOM On A Cheap 104-in-One Handheld

Taking a break from putting DOOM on devices that absolutely were never conceived for use as gaming devices, [Aaron Christophel] recently got enticed by some cheapo handheld gaming systems at his local Action budget store. One is a controller-shaped ‘mini game console’ with 104 games from the 1980s and 1990s, while the other is simply a Pac-Man handheld in a more typical rectangular form factor. Although this brings to mind basic blob chips and limited hacking potential, as it turns out they’re actually quite nice inside.

As also covered in the demonstration video, rather than said nasty blob chip, both handhelds turned out to use the same unmarked MCU in QFN48 packaging. Some prodding and poking confirmed that it’s a typical ARM core, specifically a Cortex-M33 compatible STAR-MC1 ARMv8-M from an unknown manufacturer. Without a datasheet to go by, its limitations had to be discovered experimentally.

Of those, the biggest were a clock speed of 62 MHz – instead of the typical 194 MHz – as well as a lack of sound. This latter issue might be fixable with a better understanding of what appears to be a quirky DMA-fed DAC. Beyond this you’re also dealing with limited memory and of course just 4 MB of flash, though the chip for this might be upgradable if the MCU can map more. You do get a 320×240 display and a lot of buttons, which is admittedly nice.

As for the price difference of around $8/€7 for the Pac-Man version, this appears to be due to it running an officially licensed Bandai Namco arcade emulator as firmware, while the 104-in-one unit runs FlyThings/ZKSWE with a NES emulator.

Continue reading “Running DOOM On A Cheap 104-in-One Handheld”

Teardown Of An Oxford Nanopore MinION DNA Sequencer

Detail of the nanopore chip. (Credit: mikeselectricstuff, YouTube)
Detail of the nanopore chip. (Credit: mikeselectricstuff, YouTube)

For most people the term ‘DNA sequencing’ probably brings to mind large, expensive laboratory equipment in sterile rooms, but over the past decades technological progress really has had its way with it, to the point where it’s now just another small portable device. Something like the Oxford Nanopore MinION unit that [Mike] recently took to bits to ogle at the intricate insides.

This device was trialed in 2014 in a limited release before its commercial release in 2015, with this paper by [Miten Jain] et al. in Genome Biology detailing the workings of this nanopore sequencer. At a mere $2,000 it’s rather remarkable how affordable it is, though this comes with the caveat of the consumables, which are also shown in the video. These come in at a cool £690 per unit, can sequence either RNA or DNA and can be used at most a few times before they need to be replaced.

The main unit is fairly simple, featuring a Xilinx Spartan 6 FPGA and a rather nice slim fan-based cooling solution. For the nanopore unit you get the typical microfluidics system, to guide the deposited fluid containing the genetic material to sequence over the nanopore system. In here we see the actual magic as well, in the form of the high-density pitch ICs on both sides of the PCB inside the consumable sequencer unit.

Although this particular unit got discontinued already, the consumables are still available for it if you are feeling the sequencing itch. Of course, we’re likely to see the costs for DNA and RNA sequencing to keep plummeting, as what were once complex chips get overtaken once again by the progress of technology.

Continue reading “Teardown Of An Oxford Nanopore MinION DNA Sequencer”

Iz in ur Tenda AC10V6, hax0ring your printf output. (Credit: Low Level, YouTube)

Hacking A Tenda AC1200 Wi-Fi Router With A CVE Combo

It’s rather awkward when you buy a piece of hardware like a sketchy router to make a video about its hidden admin password backdoor – known as CVE-2026-11405 – only to discover that you bought the wrong Tenda router, namely the AC10V6 model. After making this mistake, [Low Level] did the only reasonable thing one ought to do in this case, and try to find an exploit in this ‘wrong’ router as well.

The obvious start here is to do the same as with the other exploit, in that you download a firmware image from the manufacturer’s website, then pluck it apart using binwalk to do an initial check for juicy files. After that tools like Ghidra can be used to do a more in-depth analysis of any binary files, with a special focus on things like user-facing elements like login screen, as input validation will likely forever remain the number one type of exploited CVE.

One major change that Tenda made here was to encrypt the firmware image, which seemed suspicious. With that easy path blocked, the research of others on different Tenda routers was looked at, including the AC20 with the fascinating Telnet exploit in the form of CVE-2025-9090 where merely poking a file on the device turned on the Telnet service. This left the minor issue of finding a password to log into said Telnet session.

Continue reading “Hacking A Tenda AC1200 Wi-Fi Router With A CVE Combo”

Re-Testing An Apollo Guidance Computer Module That Failed Certification Testing

After getting his hands on a rope driver module from the Apollo project era that had a big ‘Scrapped Module’ stamped on it, [Mike Stewart] was naturally left curious as to what exactly had failed in this module. Originally destined for the Apollo Guidance Computer, these Raytheon-manufactured modules were the pinnacle of space-grade high-tech of the 1960s, with requisite acceptance testing so as to not endanger a very expensive space mission.

The cool part here is that the acceptance documents for the module in question (B16-B17) have been scanned in and can be found on the Internet Archive. With the part itself being potted and very much inaccessible, this document helpfully lays out the expected measurements on the module’s pins, as well as schematics and mechanical drawings. Unfortunately the reasons for the rejection were not recorded, so replicating the failing test results is required to understand the reason.

NASA Rope Driver Module with suspicious exploration marks. (Credit: Mike Stewart, YouTube)
NASA Rope Driver Module with suspicious exploration marks. (Credit: Mike Stewart, YouTube)

A slight complication here is that the testing procedure doesn’t just involve hooking up a multimeter for some voltage and capacitance measurements. There are also temperature and voltage extremes, and vibration tolerance involved, which would be somewhat complex to test, but most of all risk damaging a historical artefact. Thus a somewhat conservative testing procedure was chosen, even if this may not reveal the actual fault.

As noted in the video, sometimes modules were also rejected because someone simply dropped it on the floor along the way. However, generally if a module was found to be faulty they would open it to diagnose said fault, with a closer look at this module indeed revealing suspicious marks in the potting compound where it was apparently opened and conceivably repaired. This also might explain why they also put the ‘For engineering use only’ on it.

With multiple of such locations visible in the potting compound, these locations were mapped to the schematics for the module, to get some idea of what may have been accessed. After this, basic testing was performed on the module, as per the acceptance testing document.

Along the way an error was detected in said document, in the form of the wrong pin number. In table 4-2 the input pin 269 was mistakenly listed as having output pin number 169 when it should have been pin 168. Pin 169 is chassis ground, so this was presumably fixed in a later version of the document.

After all the testing with just stationary, room-temperature conditions, everything appeared to check out. This means that likely this was indeed a repaired module that got subsequently used for engineering purposes rather than installed in flight-ready hardware. The only issue found was that channels were out of calibration, but whether this was an original flaw or due to the module being half a century old is hard to tell in the absence of repair logs.

Overall it’s an exciting opportunity to document another part of history, since so many of the details pertaining to these original modules and related technologies got lost or muddled over the decades.

Continue reading “Re-Testing An Apollo Guidance Computer Module That Failed Certification Testing”

Wireless LCD Streaming For The ANENG AN870 Multimeter

Having the information shown on the display of a digital multimeter also recorded off-screen can be incredibly useful, but unless the device exposes something like SCPI on a network interface, you will have to get creative. In the case of the budget ANENG AN870 digital multimeter (DMM), [Bits und Bolts] really wanted to show its display clearly as an overlay in OBS instead of just the camera view, but with said DMM not offering an easy way he had to resort to just copying the data sent to its multiplexed LCD.

The GitHub project page contains the background information, as well as the instructions if you too have this DMM. It might of course also be useful as the jumping off point for your own DMM modification. In total the project requires three modules: an RP2040 Zero and HC-12 433 MHz transceiver on the DMM side, and another HC-12 plus ESP32-C3 module on the receiving side. A boost module is also added to generate 3.3 V out of the 2.4 V – 3 V provided by the meter’s two AA cells.

To be able to read the LCD signal lines, a custom PCB was created that is installed inside the DMM. With the LCD’s segments mapped, this meant being able to send a perfect copy of the display’s state to the ESP32-C3 and from there making it available via WiFi.

Continue reading “Wireless LCD Streaming For The ANENG AN870 Multimeter”

Making A Locked Down Wearable Work Without A Subscription

WHOOP does not have the presence in the wearable space as other brands, but in certain circles, it’s a household name. Their business model requires you to have a yearly app subscription to use their fitness tracker, but here at Hackaday, we are big fans of actually owning the devices you buy — which is why we were happy to hear about an open source and subscription free WHOOP compatible app!

The goal of the so-called OpenStrap project is not to re-create the WHOOP app. Rather, the algorithms and processing methods are developed from scratch, based on public research. It’s all calculated locally on a 1 Hz interval, based on the data the WHOOP 4.0 device feeds the app. As such, the health data collected from the watch, never leaves the phone. While not the main goal of the project, the privacy improvement of the app’s serverless nature cannot be overstated. However, to display metrics, you first need to get data off the WHOOP to begin with.

The crux of the issue with making the WHOOP 4.0 work without the official app is the reliance on proprietary Bluetooth protocols. Fortunately, the protocol itself ended up being relatively simple. The WHOOP 4.0 amounts to little more than a series of sensors that sit on the user’s wrist. As such, the app can subscribe to the Bluetooth feed and decode the data, right? Well, the devil is always in the details with such things, and the protocol came with its fair share of quirks. The hardware clock needs to be synchronized, or it simply defaults to zero Unix time. Moreover, the analog sensors like, ambient temperature are given in relative ADC values, and are not terribly useful without calibration. Regardless, the result of the reverse engineering effort speaks for itself with the OpenStrap app able to recreate much of the functionality in WHOOP’s official app.

Quite often, devices reliant on proprietary apps are little more than manufactured e-waste. While we don’t expect many of you to actually own a WHOOP 4.0, we do hope to see the OpenStrap project keep at least a few out of the landfill in the future.