Super Mario Bros. 35 Lives Again With A Fan-Made Server

June 13, 2021 by Jenny List 27 Comments

If you liked playing Super Mario Bros. 35, the unique multiplayer battle royale Mario game that Nintendo released last year on the Switch to celebrate 35 years since the original NES version of Super Mario Bros, then it’s likely that you have been disappointed since April. The gaming giant ended support and removed the game’s servers once their 35 year celebrations were over, leaving the game’s players hanging. Happily there’s a solution, because [Kinnay] has presented a reverse-engineered Nintendo game server replacement along with a game patch, that should keep gamers in multi-Mario fun forever.

While it’s a boon for fans of this particular game, the real value here is in introducing us to the reverse engineering work on those Nintendo servers. We learn about their various foibles over several generations of console, and perhaps most importantly we learn something of their inner workings.

Usually when a game server is turned off it’s because the platform it supports is so ancient as to have hardly any users. This time-limited game on an up-to-date platform is unusual then, but since it was made available to subscribers to Nintendo’s online service for free it’s less of a surprise. Certainly not in the same class as the loss of servers for an entire platform.

Thanks [Digiaap] for the tip.

Header image: Elvis untot, CC BY-SA 4.0.

An Exercise In Firmware Dumping With The GreatFET

June 4, 2021 by Tom Nardi 4 Comments

Looking to hone his hardware hacking skills, [James Chambers] recently set out to reverse engineer a common cheap wireless keyboard: the Logitech K360. The chipset it uses has already been fairly well explored (and exploited) by security researchers, but the goal here was more about gaining some practical hands-on experience than it was breaking any new ground.

The first post in what we’re sure will be a fascinating series deals with dumping the board’s firmware using the GreatFET. We actually haven’t seen too many projects that showcase the capabilities of this highly capable open hardware multi-tool, so the post serves as a nice demonstration of how one goes about writing the necessary Python scripts to put it to work in a practical scenario.

Of course, even with the best of tools, there’s always a few stumbling blocks. After identifying what was clearly some kind of programming header on the K360’s diminutive PCB, it took a few failed attempts at reading the firmware before [James] realized he needed to tap into more pins on the keyboard’s nRF24LE1 microcontroller. Once everything was physically wired up, he wrote some code for the GreatFET that would perform the proper incantations on the chip’s PROG and RESET pins to enable its programming interface.

[James] goes on to explain how you can pull some extended chip information out of the hardware and verify the contents of the firmware dump with Gihdra, but any more advanced analysis will have to wait until the next post in the series. In the meantime, if you like reading about hardware hacking from this “over the shoulder” viewpoint, you should check out some of the fantastic work that [wrongbaud] has sent in over the last year or so.

Investigating A New Chip In A Minimalist LED Lamp

May 27, 2021 by Danie Conradie 8 Comments

Teardowns of cheap electronic devices can produce results that are interesting, horrifying, or both, especially when mains power is involved. [bigclivedotcom] gave a minimalist LED lamp his reverse engineering treatment, and discovered a new chip that requires only four additional passive components to run LEDs on AC power.

The chip in question is a Joulewatt JWB1981, for which no datasheet is available on the internet. However, there is a datasheet for the JW1981, which is a linear LED driver. After reverse-engineering the PCB, [bigclivedotcom] concluded that the JWB1981 must include an onboard bridge rectifier. The only other components on the board are three resistors, a capacitor, and LEDs. The first resistor limits the inrush current to the large smoothing capacitor. The second resistor is to discharge the capacitor, while the final resistor sets the current output of the regulator.

It is possible to eliminate the smoothing capacitor and discharge resistor, as other LED circuits have done, which also allow the light to be dimmable. However, this results in a very annoying flicker of the LEDs at the AC frequency, especially at low brightness settings.

As always, this is a very informative video from [bigclivedotcom], and it was all done based on a single picture of the PCB sent in by a viewer. He also mentions that the lifespan of the lamp would likely be increased by swapping out the current setting resistor for a larger one.

We’ve covered several [bigclivedotcom]’s videos, covering topics from self-powered wireless switches to filling up fake capacitors with electrolyte.

Continue reading “Investigating A New Chip In A Minimalist LED Lamp” →

ESP8266 Adds WiFi To A 433 MHz Weather Station

May 26, 2021 by Tom Nardi 7 Comments

There’s no shortage of cheap weather stations on the market that pull in data from several wireless sensors running in the 433 to 900 MHz range and present you with a slick little desktop display, but that’s usually where the flow of information stops. Looking to bridge the gap and bring all that local climate data onto the Internet, [Jonathan Diamond] decided to reverse engineer how his weather station worked.

The first phase of this project involved an RTL-SDR receiver, GNURadio, and a sprinkling of Python. [Jonathan] was able to lock onto the signal and piece together the data packets that reported variables such as temperature, wind speed, and rainfall. Each one of these was a small puzzle in itself, and in the end, there’s still a few bits which he hasn’t quite figured out. But he at least had enough to move onto the next step.

Now at this point, he could have pulled the data right out of the air with his RTL-SDR. But looking to push his skills to the next level, [Jonathan] decided to open up the base station and isolate its receiver. Since he already decoded the packets on the RF side, he knew exactly what he was looking for with his oscilloscope and logic analyzer. Once he was tapped into the feed coming from the radio, the final step was writing some code for the ESP8266 that could listen on the line, interpret the data packets, and push the resulting variables out over the network.

In this case, [Jonathan] decided to funnel all the data into Weather Underground by way of the Personal Weather Station API. This not only let him view the data through their web interface and smartphone application, but brought their hyperlocal forecasting technology into the mix at no extra charge. If you’re not interested in sharing your info with the public, it would be a trivial matter to change the firmware so the data is published to a local MQTT broker, or whatever else floats your proverbial boat.

If you’re really lucky, your own weather station may already have an ESP8266 onboard and is dumping all its collected data to the serial port. But if not, projects like this one that break down how to reverse engineer a wireless signal can be a great source of inspiration and guidance should you decide to try and crack the code.

Reverse-Engineering An Unknown Microcontroller In E Ink Displays

May 15, 2021 by Bryan Cockfield 11 Comments

For a monochrome display where refresh rate isn’t particularly important, there’s almost no better option than an E Ink display. They’re available in plenty of sizes and at various price points, but there’s almost no option cheaper than repurposing something mass-produced and widely available like an E Ink (sometime also called eInk or ePaper) price tag. At least, once all of the reverse engineering is complete.

[Dmitry Grinberg] has been making his way through a ton of different E Ink modules, unlocking their secrets as he goes. In this case he set about reverse engineering the unknown microcontroller on the small, cheap display show here. Initial research showed an obscure chip from the ZBS24x family, packaged with a SSD1623L2 E Ink controller. From there, he was able to solder to the communications wires and start talking to the device over ISP.

This endeavor is an impressive deep dive into the world of microcontrollers, from probing various registers to unlocking features one by one. It’s running an 8051 core so [Dmitry] gives a bit of background to help us all follow along, though it’s still a pretty impressive slog to fully take control of the system.

If you happen to have one of these price tags on hand it’s an invaluable resource to have to reprogram it, but it’s a great read in general as well. On the other hand, if you’re more interested in reverse-engineering various displays, take a look at this art installation which spans 50 years of working display technologies.

Using CanoPy To Visualize The CAN Bus

May 8, 2021 by Stephen Ogier 11 Comments

As cars have become more sophisticated electronically, understanding the CAN bus that forms the backbone of automotive digital systems has become more and more important for hacking cars. Inexpensive microcontroller CAN interfaces have made obtaining the raw CAN bus traffic trivial, but interpreting that traffic can be pretty challenging. In order to more easily visualize CAN traffic, [TJ Bruno] has developed CanoPy, a Python tool for visualizing CAN messages in real time.

A basic PC CAN interface simply dumps the bus’s message traffic into the terminal, while more sophisticated tools organize messages by the address of their intended recipients. Both of these approaches digitally lift the hood and let you examine what your car is thinking, but the wall-of-numbers approach makes finding the patterns that hold the keys to reverse engineering difficult. Automatically plotting the data with CanoPy makes finding correlations much easier, after which the text-based tools can be used to focus in on a few specific addresses.

Continue reading “Using CanoPy To Visualize The CAN Bus” →

VME Reverse Engineering

May 5, 2021 by Chris Lott 28 Comments

With some free time on his hands waiting for delayed parts to arrive, [Rik] set out to reverse engineer an old VME system he had acquired. VMEbus computers are based on the standard Eurocard PCB format, which defines a wide range of card sizes — the most common being 6U height like [Rik]’s system. They usually consist of a rack-mounted card cage with a passive backplane. Originally, Motorola 68000-based CPU cards were used in VMEbus systems, but any processor could be used as long as you provided the right signals and timings to the system bus. Eurocard systems are less common these days, but are still used in some applications. In fact, if you’re into synthesizers, you may be using Eurocards today — the Eurorack standard is based on the standard 3U card size.

Back to [Rik]’s project, he had no idea what this system was nor how to use it. A bit of probing around and he found two UARTs, a system monitor, and a way to load and dump S-record files. He documents the process quite well, as the internal layout and memory map of the system is unlocked piece by piece. We also like his method of instrumenting the VMEbus signals — logic analyzers are so small today, you can just mount one inside the rack.

Spoiler alert: [Rik] succeeds in mapping out the memory, writes some small programs in 68k assembly language, and even builds his own LED accessory card so he can blink some lights (as one must do).

We wrote about modularity recently, and VMEbus + Eurocard systems are good examples of modular design. You could quickly put together a robust assembly using entirely off-the-shelf cards, or mix in your own custom cards. But technology advancements in clock speeds and miniaturization have made these card cage, passive backplane systems less and less relevant today. Do any of you still use the VMEbus, or have you designed with them in the past? Let us know down in the comments below.