The Attack Shark is a modern keyboard with fancy magnetic keyswitches, macros, configurable blinky LEDs, and more. The problem is that the configuration software only works on Windows, so [JR Lanteigne] set out to fix that. Along the way, he completely worked out the configuration protocol that this keyboard needs, and wrote the comfortable sharkfin web-app so that you can flash yours too.

Don’t have an Attack Shark? Well, you might have one of the 522 other boards that are made on the same ROYUAN hardware, but are re-branded under 100 different names. Want to find out if yours is supported? Look it up in the list here, or just plug it in and find out.

[RJ]’s path to reverse engineering the config protocol wasn’t entirely straightforward, but since the “Windows only” application was actually an Electron app under the hood, he patched it to run on Linux and logged a few configuration sessions. Of course there are gotchas like two different firmware generations and the fact that writing to flash too fast put the keyboard into a boot loop, but after these problems were surmounted, it just remained to map all of the bytes out, and wrap it all up in a user-friendly application.

We don’t have one of these fancy-schmancy keyboards, but if we did, we’d certainly be glad to have the configuration protocol documented. Nothing is worse than finding out that the company that made your keyboard has gone belly-up, and you’re left with a backlight setup that doesn’t match your new deskpad. If you’re a keyboard-head and you don’t already follow [Kristina]’s series, well you should.

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.

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.

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.

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.

Having a pump in a remote location where you aren’t constantly monitoring it is a common scenario, which can be unfortunate when said pump runs into problems like a dry well, jammed impeller or power issues. This is where pump monitors like the older SymCom (now Littelfuse) PumpSaver Plus 233P will protect the pump if such conditions are detected. Of course, the infrared communication port on it uses an undocumented protocol that was meant to be used with a long-since discontinued handheld device. Ergo [Elizabeth Camporeale] saw fit to reverse-engineer this protocol.

In the installation manual for this device this Informer unit is briefly mentioned along with the information it will display on its screen, making it clear that it’s quite literally just there to act as a display for the information that’s constantly generated on this interface. Naturally, this is incredibly useful if you wish to tie the system into a wider monitoring and automation system.

Somewhat unusual, this IR interface on the used 233P-1.5 unit turned out to be use a 5,000 baud NRZ, MSB-first protocol, with the juicy details fully documented and a Python-based decoder implementation provided.

Naturally [Elizabeth] didn’t just reverse-engineer this for the fun of it, but also for ESPHome integration. This uses a setup as can be seen in the top image, with an ESP32-C6 module providing the processing power and Wi-Fi, with a standard phototransistor recording the data pumped out by the pump monitor.

Even with Amazon’s Echo Show devices running Linux in the form of the Android-derived FireOS, using them for non-Amazon approved purposes can be a chore at best. In the case of the Echo Show 8 even simple workarounds using ADB and the bootloader have been locked-down, requiring more drastic measures. Here [Vowed] over at the XDA forums shows off one such hack, involving directly tapping into the device’s eMMC.

Suffice it to say that this is not a hack for the faint of heart, with even the iFixit teardown guide for this device being rather daunting. Even after you get access to the mainboard, you still have to remove or cut open the metal can that covers the eMMC, so that you can unleash an eMMC programmer on it. It’s best to make sure to make a backup image of the original contents too, just in case you have to restore things.

With the shield out of the way you can solder fine wires to pads that connect to the eMMC to program it. You also have to solder wires to pads for the UART, though if you’re fancy you can also create a custom pogo pin adapter. With a serial connection established to the original firmware you can then enable features like ADB, and courtesy of the connected eMMC adapter it’s possible to directly alter system files to make rooting as easy as possible.

In addition to rooting the system you can also do a straight replacement of the eMMC contents, such as the demonstrated Debian installation. Even if not the most easy of mods, it’s good to see that it’s possible to repurpose these devices.

(Top image: Amazon Echo Show 8 3rd generation mainboard. Credit: iFixit, CC BY-NC-SA 3.0.)

Sold by German DIY store OBI, the OBI Energy Tracker is a €15 set of two devices, one of which you essentially stick on top of your existing electricity meter. This then allows for electricity usage to be measured and tracked, with the data sent to the second, gateway device. This latter cloud-bound device is linked to an OBI account via the heyOBI app. This correspondingly called for the gateway device to be reverse-engineered and freed from its cloud-based shackles, a task that [Aaron Christophel] happily took upon himself.

The whole process is also covered in two videos, with the first providing all the essentials on reprovisioning the original firmware for a local MQTT server in English, while the second, German-language video focuses on custom firmware for the ESP32-C3 inside of the gateway device.

Inside the reader device is a Cortex-M0+-based BAT32G135 MCU that communicates with the meter via its IR protocol. This is then communicated via 868 MHz LoRa to the gateway device that will be placed somewhere within Wi-Fi reach by the user. Inside this latter device is as mentioned the ESP32-C3, which by default runs firmware that communicates via secure MQTT with an AWS cloud instance for the typical cloud-based shenanigans.

The aforementioned reprovisioning option doesn’t require firmware flashing, just a handful of steps to follow. This involves fetching the 32-bit TEA key, generating your own PKI, running your own MQTTS-capable broker and having the provided Python script handle the rest from there.

Flashing custom firmware is the other option, with straightforward UART/JTAG reflashing sadly disabled by the manufacturer. With the effort required here you could perhaps argue that simply connecting the reader device to a custom gateway device might be a lot easier, especially if you already have a LoRa transceiver and associated hardware.