DisplayPort: Tapping The Altmode

Really, the most modern implementation of DisplayPort is the USB-C DisplayPort altmode, synonymous with “video over USB-C”, and we’d miss out if I were to skip it. Incidentally, our last two articles about talking USB-PD have given a few people a cool new toy to play with – people have commented on the articles, reached out to me for debugging help, and I’ve even seen people build the FUSB302B into their projects! Hot on the heels of that achievement, let’s reach further and conquer one more USB-C feature – one that isn’t yet openly available for us to hack on, even though it deserves to be.

For our long-time readers, it’s no surprise to see mundane capabilities denied to hackers. By now, we all know that many laptops and phones let you get a DisplayPort connection out of a USB-C port. Given that the USB-C specifications are openly available, and we’ve previously implemented a PD sink using those specifications, you’d expect that we could do DisplayPort with the same ease. Yet, the DisplayPort altmode specification is behind a VESA membership paywall, with a hefty pricetag – a practice of theirs that has been widely criticized, counter to their purpose as a standards organization and having resulted in some of their standards failing.

Not to worry, however – we can easily find an assortment of PDFs giving a high-level overview and some details of the DisplayPort altmode, and here’s my favorite! I also have a device running MicroPython with a FUSB302 chip connected, and a few DisplayPort altmode devices of mine that I can disassemble. This, turns out, is more than enough for us to reverse-engineer our way into an open-source DisplayPort altmode library!

Continue reading “DisplayPort: Tapping The Altmode”

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.

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”

Sniffing Passwords, Rickrolling Toothbrushes

If you could dump the flash from your smart toothbrush and reverse engineer it, enabling you to play whatever you wanted on the vibrating motor, what would you do? Of course there’s no question: you’d never give up, or let down. Or at least that’s what [Aaron Christophel] did. (Videos, embedded below.)

But that’s just the victory lap. The race began with previous work by [Cyrill Künzi], who figured out that the NFC chip inside was used for a run-time counter, and managed to reset it by sniffing the password with an SDR as it was being transmitted. A great hack to be sure, but it only works for people with their own SDR setup.

With the goal of popularizing toothbrush-head-NFC-hacking, [Aaron] busted open the toothbrush itself, found the debug pins, dumped the flash, and got to reverse engineering. A pass through Ghidra got him to where the toothbrush reads the NFC tag ID from the toothbrush head. But how does it get from the ID to the password? It turns out that it runs a CRC on a device UID from the NFC tag itself and also a manufacturer’s string found in the NFC memory, and scramble-combines the two CRC values.

Sounds complicated, but the NFC UID can be read with a cellphone app, and the manufacturer’s string is also printed right on the toothbrush head itself for your convenience. Armed with these two numbers, you can calculate the password, and convince your toothbrush head that it’s brand new, all from the comfort of your smartphone! Isn’t technology grand?

We’re left guessing a little bit about the Rickroll hack, but we’d guess that once [Aaron] had the debug pins on the toothbrush’s microcontroller, he just couldn’t resist writing and flashing in a custom firmware. Talk about dedication.

[Aaron] has been doing extensive work on e-paper displays, but his recent work on the Sumup payment terminal is a sweet look at hacking into higher security devices with acupuncture needles.

Continue reading “Sniffing Passwords, Rickrolling Toothbrushes”

Tesla Door Phone Decoded (Not That Tesla)

[Danman] has digital door phones manufactured by Tesla — or at least, a Tesla, as they’re not to be confused with the carmaker, though. The problem is if someone comes to the door when no one’s home, there’s no remote indicator. The answer? Reverse engineer the protocol and fix it.

A quick dump on a storage scope showed the data clearly, but it wasn’t obvious what protocol it was using. After a little analysis, it proved the datastream used 4 PWM pulses as symbols with three symbols: one, zero, and stuffing sequence.

Once you can read the bits, it is easy to determine that each frame consists of a 16-bit destination and source address, along with a command byte and a checksum byte. Each station can have an ID from 000 to 999 although you can only dial up to number 323. Some nodes are special, and there are ways to address particular units.

Connecting to the hardware took a transformer for isolation. Honestly, unless you have this exact hardware, this isn’t likely to be something you can directly use. However, it is a great example of how you can figure out a specialized device and bend it to your will.

We love reverse engineering projects. In some cases, it is easier if you have a CT scan.

Reverse Engineering A Classic ThinkPad Battery

The ThinkPad 701 is an iconic laptop series from the mid-90s and is still highly sought after today because of its famous butterfly keybaord. The laptop itself is tiny even by the standards of the time, so in order to fit a full-size keyboard IBM devised a mechanism where the keyboard splits and slides over itself to hide away as the screen is closed. But, like most 30-year-old laptops, the original batteries for these computers are well past their prime. [polymatt] takes us through all of the steps needed in order to recreate a battery from this era down to the last detail.

He starts by disassembling an old battery with extensive damage from the old, leaky batteries. The first part of the recreation is to measure the battery casing so a new one can be modeled and printed. The control boards for the batteries of these computers were not too sophisticated, so [polymatt] is able to use a logic analyzer with a working unit to duplicate its behavior on an ATtiny microcontroller. With that out of the way, a new PCB is created to host the cloned chip and a new battery pack, made out of 9 NiMH cells is put together.

[polymatt] wanted this build to be as authentic as possible, so he even goes as far as replicating the label on the underside of the battery. With everything put together he has a faithful recreation of this decades-old battery for a famous retro laptop. ThinkPads are popular laptops in general, too, due to their fairly high build quality (at least for their enterprise lineups) and comprehensive driver support especially for Linux and other open-source software projects like coreboot and libreboot.

Thanks to [Roman UA] for the tip!

Continue reading “Reverse Engineering A Classic ThinkPad Battery”

Shall We Hack A Game?

A fantastic summertime game has consumed many of the kids in my neighborhood. It’s basically a treasure hunt, but the treasures are all shoebox-sized NFC readers that are “easily” findable on a map. Players all have a smart card and run around from box to box, collecting points that depend on how far apart the boxes are from each other. Walk, skate, or bike 1 km between check-ins, and ten points show up on the e-paper screen.

It’s been going on for a few weeks now, and it’s not uncommon to see a line of two or three kids at any given box, all with the purple lanyards and smart cards around their necks. So far, the highest-rated plausible single efforts have 450 km (280 miles) under their belt. My son’s grade-school average is 45 km (28 miles) over three weeks. The goal is getting kids out on the early summer afternoons, and that seems to be working!

Of course I had to reverse engineer the infrastructure, so here’s what I started with. Each box knows your point standing as soon as you tap the card, with a small delay. Scores appear online about every four hours. And the boxes are all ~1 km from each other or less.

My first thought was some kind of mesh network – that would be by far the coolest solution. Each box could simply report your card number to a central database, and the rest is a simple matter of software. LoRa radios rounded out my fantasy design.

But the length of time between getting the points and their appearance online suggests otherwise. And, a little bit of playing around with my cellphone’s NFC reader gives up the juice – they are MiFare Classic cards with data storage. So I got my own card, ran around town, and diffed the results. I haven’t cracked the location/time-stamping yet, but I know exactly where my total points are stored.

I’m going to keep observing until I’ve got it figured out completely, but I’m so tempted to tweak the points and see what happens. Are some of the digits in what I think are a timestamp in reality a checksum? Will I get disqualified? Or worse, what if I make a mistake and get myself publicly into first place? OK, better to sit this one out on the sidelines – I really don’t want to be the jerk who crashes a fantastic kid’s game. Sometimes you’ve gotta know when not to hack.