RGB Graphics On A DEC Rainbow With Reverse-Engineered Monitor

One of the delights of the boring pre-VGA era is that you get to express your creativity when it comes to making a random color CRT work with an equally exciting dual CPU computer like the DEC Rainbow 100. This is the situation that the folk over at Usagi Electric found themselves in with a recent project. The Rainbow 100 is an interesting computer in that it can boot not only DOS with its 8088 processor, but also CP/M on the Z80 processor. Although generally used in monochrome mode, it supports a color graphic card to output RGB signals via its male DB15 connector.

DEC Rainbow 100 to Princeton Ultrasync adapter. With strain-relief zip tie.
DEC Rainbow 100 to Princeton Ultrasync adapter. With strain-relief zip tie.

Unfortunately, the target monitor – a Princeton Ultrasync – featured a female DB25 connector that obviously wasn’t going to connect directly, thus requiring a spot of reverse engineering. Making this very easy, the PCB containing the input connector had the traces clearly marked with the intended signal, which just left the mapping of the two connectors. One complication here was with the Rainbow 100 outputting an RGB signal with sync-on-green, whereas the monitor expected a separate synchronization signal.

Fortunately, most analog monitors aren’t particularly fussy so long as they get the expected signal somewhere in the input, which just left the final issue, of the Rainbow 100 outputting the monochrome signal on a special monochrome pin. This allowed everything to work as it should, and leaving those of us who joined the computing era in the 90s appreciative of standard VGA cables, other than for those weird Sun and Apple systems with their proprietary connectors.

Continue reading “RGB Graphics On A DEC Rainbow With Reverse-Engineered Monitor”

An Unexpected Appearance Of An Iconic Motorola Chip

Big Clive's reverse-engineered schematic of the USB charger containing the MC34063 IC.
Big Clive’s reverse-engineered schematic of the USB charger containing the MC34063 IC.

Generally when you crack open a cheap car-to-USB charger unit that came with some widget, you do not expect to find anything amazing inside. That’s why it was such a surprise to [Big Clive] when said car USB charger revealed a blast from the past in the form of an MC34063. This is a switching regulator that supports buck, boost and inverting topologies, but perhaps it most notable feature is that it was first produced by Motorola in the early 1980s.

This particular IC is marked as having been produced by ON Semiconductor which means that it’s technically still manufactured by Motorola – with ON Semiconductor being the Phoenix division that was spun off in 1999 – but it’s somewhat remarkable that this particular chip isn’t only produced by ON Semi today, but also by Texas Instruments. Much like the venerable NE555 timer IC and Intel’s 8051 MCU architecture, it would seem that certain chips and designs are simply made to become commodities in the future.

This appears to be the case for the MC34063 as well, which may lack some niceties of more modern ICs, such as built-in thermal protection, and it switches at only up to 100 kHz, but it can be bought for peanuts, has a wide input voltage range of 3 to 40 V, can switch up to 1.5 A and supports multiple common topologies. Often a 100 kHz switching regulator is all you need, in which case it’s handy to have a stack of such commodity chips lying around, plus the MC34063 comes in PDIP packaging as well, which is a boon for prototyping.

Continue reading “An Unexpected Appearance Of An Iconic Motorola Chip”

Decompiling Sonic Runners

Usually, when you hear about games being decompiled and rebuilt, the games are often decades-old relics, loving and saved from the ravages of time. [MattKC] recently set out to decompile the 2015 game Sonic Runners.

The game was a 2D endless runner released on mobile platforms. Despite getting praise for the gameplay, it received mixed reviews for the pop-up ads and pay-to-play elements. A little over a year later, the game was discontinued. However, the game required a constant online connection, so once the servers were offline, it rendered the over five million downloads unplayable.

A team of developers worked to reverse engineer the server, and with a little bit of binary hacking, the client could be patched to connect to a community-hosted server instead. However, as phones with notched displays came out and suggestions for improvements stacked up, the community realized a new client would bring immense benefits. Compared to many decompilation projects, Sonic Runners was pretty easy as it uses Unity, which means most of the code is in C#. Unfortunately, the build of Unity used by the game is from 2012, meaning many of the tools designed for much later versions of Unity were inoperable.

However, one native code library called UnmanagedProcess was designed to confuse reverse engineering efforts. The library handled AES encryption and communication with the server. Luckily, the library was a later addition, and earlier versions of its functions still lingered in the C# code. Since an open source server already existed, it was trivial to validate the changes. Additionally, all the shaders were in OpenGL Shading Language (GLSL), which meant rewriting them in High-Level Shading Language (HLSL) and checking that they matched the original GLSL when building for Android.

Now the client has new game modes, no ads, and a proper offline mode. The community continues adding new features and refining the game, which is very satisfying. If you’re curious about reverse engineering, [Matthew Alt] can help you get started.

Continue reading “Decompiling Sonic Runners

Heartbeat packets of LKV373

Audio, Not Video Over The LKV373 HDMI Extender

[eta] found herself in a flat with several LKV373 HDMI extenders. Find the corresponding transmitter, plug it into your device, and you’ve got a connection to the TV/sound system, no fussing with wires behind the TV. However, [eta] wanted to get rid of the need to plug in a laptop and start sending packets directly to play music. As her flatmate [dan] had already reverse-engineered the receiver, she tested her prototype against their virtualized receiver, de-ip-hmdi.

The actual sending of images was surprisingly straightforward — just a JPEG sliced into 1024 bytes chunks and sent over. However, early testing showed nothing on the receiver. The end of a frame needed marking by setting the most-significant bit of the chunk number to one. Now de-ip-hdmi showed the image, but the actual hardware would not. With something missing, [eta] returned to Wireshark to scan packets. Noticing some strange packets on port 2067, she analyzed the pattern to reveal it sent another packet just before a new frame and included the frame number. With this tweak, it was still not enough. Ultimately, heartbeat packets sent every second synchronize things, but compared to the noise of the video packets, they were easy to miss. Now [eta] had some functioning video streaming rust code.

In theory, audio for the LKV373 followed the same thought process as video. Two channels of 32-bit big Endian integers at 44,100 hz chunked into 992-byte sections and sent as a packet formed the audio stream. With only 992 bytes, two streams, and 4 bytes per sample, each packet only held 2.812 milliseconds of sound. The first tests resulted in no audio output or distorted crunchy sound. Of course, this was every audio engineer’s worst nightmare: jitter. With a spin loop and an efficient ring buffer, the audio packets were soon slinging across the network reliably.

The code is available on a hosted version of GitLab. It’s a beautiful journey through reverse engineering some obscure but relatively cheap hardware. Along the way, there is nicely annotated Rust code, which makes it all the better.

Closing In On A PC Enabled PSVR2

When the PlayStation VR2 headset was released, people wondered whether it would be possible to get the headset to work as a PC VR headset. That would mean being able to plug it into a PC and have it work as a VR headset, instead of it only working on a PS5 as Sony intended.

Enthusiasts were initially skeptical and at times despondent about the prospects, but developer [iVRy]’s efforts recently had a breakthrough. A PC-compatible VR2 is looking more likely to happen.

So far [iVRy] is claiming they have 6 DOF SLAM (Simultaneous Localisation and Mapping), Prox sensor, and stereo camera data.

Most of the juicy bits are paywalled behind [iVRy]’s Patreon.  We’re hoping the jailbreak process will eventually be open-sourced.

The PS VR2 headset is quite unlike a PC VR headset in a number of ways, and it has not been historically easy to work with Sony’s products from a reverse-engineering perspective, whether it’s an attempt to improve the user experience of an annoying headset, or an attempt to understand the not-even-remotely-sanely-designed protocols behind the Sony Memory Stick. Getting the PS VR2 headset to work in a way it wasn’t intended was expected to be an uphill battle.

It’s not a finished job, but judging by the progress regularly shared on [iVRy]’s Twitter account, it might only be a matter of time.

Root, On An Amazon Echo Dot

The Amazon Echo has become an indispensable device for many people unconcerned by its privacy implications. It’s easy to forget that it’s not quite a new product anymore, with the oldest examples now long in the tooth enough to no longer receive security updates. A surprise is that far from being mere clients to Amazon cloud services, they in fact run a version of Android. This makes old dots interesting to experimenters, but first is it possible to gain root access? [Daniel B] has managed it, on a second-generation Echo Dot.

In a sense, this is nothing new, as root has previously been achieved on an Echo Dot through means of a patched kernel. Echo devices use a chain of trust boot process in which each successive step must verify the Amazon signing of the previous one. The kernel patch method breaks the ability to reboot the device with root access. [Daniel’s] method bypasses that chain of trust by using a custom pre-loader injected over USB through an exploit.

As an example, [Daniel] created a web server on his Dot, which can serve audio captured by the device. Don’t panic just yet — an analysis of the other security features suggests that this is not the dangerous exploit it might seem. It does however open up these powerful but now pretty cheap devices as potentially usable for other purposes, which can only be a good thing.

We’ve previously brought you [Daniel]’s work freeing the WiFi details from a Dot.

Reverse Engineering Reveals Hidden API In Abandonware Trail Camera

It sometimes seems like there are two kinds of cheap hardware devices: those dependent on proprietary software that is no longer available and those that are equally dependent but haven’t been abandoned just quite yet. But rest assured, abandonment is always on the table, and until then, you get to deal with poorly written apps that often suffer from a crippling lack of essential functionality.

Such was the case for the wireless game camera that [Chris Jones] scored on the cheap, but rather than suffering with the original software, he decided to reverse engineer the camera and turn it into something more useful. The eBay description was promising — Bluetooth LE! WiFi! — but the reality proved less so. To save the batteries, WiFi is off by default and can only be turned on by connecting to the camera via BLE using a janky and crash-prone Android app.

[Chris]’ first step in reverse engineering the camera was to snoop into the BLE by capturing the Bluetooth packets to a file and running them through Wireshark. This revealed a write command with the text “BT_KEY_ON” — very promising. After verifying that this command turned on the camera’s access point, [Chris] got to work capturing WiFi packets using PCAPDroid and analyzing the results, again with Wireshark. Using every function available in the OEM app eventually revealed the full API on the camera, which gives file system control, access to individual images, and even putting the camera into live video mode.

Continue reading “Reverse Engineering Reveals Hidden API In Abandonware Trail Camera”