Scramblepad Teardown Reveals Complicated, Expensive Innards

What’s a Scramblepad? It’s a type of number pad in which the numbers aren’t in fixed locations, and can only be seen from a narrow viewing angle. Every time the pad is activated, the buttons have different numbers. That way, a constant numerical code isn’t telegraphed by either button wear, or finger positions when punching it in. [Glen Akins] got his hands on one last year and figured out how to interface to it, and shared loads of nice photos and details about just how complicated this device was on the inside.

Just one of the many layers inside the Scramblepad.

Patented in 1982 and used for access control, a Scramblepad aimed to avoid the risk of someone inferring a code by watching a user punch it in, while also preventing information leakage via wear and tear on the keys themselves. They were designed to solve some specific issues, but as [Glen] points out, there are many good reasons they aren’t used today. Not only is their accessibility poor (they only worked at a certain height and viewing angle, and aren’t accessible to sight-impaired folks) but on top of that they are complex, expensive, and not vandal-proof.

[Glen]’s Scramblepad might be obsolete, but with its black build, sharp lines, and red LED 7-segment displays it has an undeniable style. It also includes an RFID reader, allowing it to act as a kind of two-factor access control.

On the inside, the reader is a hefty piece of hardware with multiple layers of PCBs and antennas. Despite all the electronics crammed into the Scramblepad, all by itself it doesn’t do much. A central controller is what actually controls door access, and the pad communicates to this board via an unencrypted, proprietary protocol. [Glen] went through the work of decoding this, and designed a simplified board that he plans to use for his own door access controller.

In the meantime, it’s a great peek inside a neat piece of hardware. You can see [Glen]’s Scramblepad in action in the short video embedded below.

Continue reading “Scramblepad Teardown Reveals Complicated, Expensive Innards”

Reverse Engineering Reveals EV Charger Has A Sense Of Security

As more and more electric vehicles penetrate the market, there’s going to have to be a proportional rise in the number of charging stations that are built into parking garages, apartment complexes, and even private homes. And the more that happens, the more chargers we’re going to start seeing where security is at best an afterthought in their design.

But as this EV charger teardown and reverse engineering shows, it doesn’t necessarily have to be that way. The charger is a Zaptec Pro station that can do up to 22 kW, and the analysis was done by [Harrison Sand] and [Andreas Claesson]. These are just the kinds of chargers that will likely be widely installed over the next decade, and there’s surprisingly little to them. [Harrison] and [Andreas] found a pair of PCBs, one for the power electronics and one for the control circuits. The latter supports a number of connectivity options, like 4G, WiFi, and Bluetooth, plus some RFID and powerline communications. There are two microcontrollers, a PIC and an ARM Cortex-A7.

Despite the ARM chip, the board seemed to lack an obvious JTAG port, and while some unpopulated pads did end up having a UART line, there was no shell access possible. An on-board micro SD card slot seemed an obvious target for attack, and some of the Linux images they tried yielded at least a partial boot-up, but without knowing the specific hardware configuration on the board, that’s just shooting in the dark. That’s when the NAND flash chip was popped off the board to dump the firmware, which allowed them to extract the devicetree and build a custom bootloader to finally own root.

The article has a lot of fascinating details on the exploit and what they discovered after getting in, like the fact that even if you had the factory-set Bluetooth PIN, you wouldn’t be able to get free charging. So overall, a pretty good security setup, even if they were able to get in by dumping the firmware. This all reminds us a little of the smart meter reverse engineering our friend [Hash] has been doing, in terms of both methodology and results.

Thanks to [Thinkerer] for the tip.

An iPhone sits in a users hand open to the YouTube app. What is unusual is that the iPhone is bent in an L shape and is still functioning properly.

First Folding IPhone Doesn’t Come From Apple

Folding phones are all the rage these days, with many of the major smartphone manufacturer’s having something in this form factor. Apple has been conspicuously absent in this market segment, so [KJMX] decided to take matters into their own hands with the “iPhone V.” (YouTube – Chinese w/subtitles via MacRumors).

Instead of trying to interface an existing folding phone’s screen with the iPhone, these makers delaminated an actual iPhone X screen to use in the mod. It took 37 attempts before they had a screen with layers that properly separated to be both flexible and functional. Several different folding phones were disassembled, and [KJMX] found a Motorola Razr folding mechanism would work best with the iPhone X screen. Unfortunately, since the iPhone screen isn’t designed to fold, it still will fail after a relatively small number of folds.

Other sacrifices were made, like the removal of the Taptic Engine and a smaller battery to fit everything into the desired form factor. The “iPhone V” boasts the worst battery life of any iPhone to date. After nearly a year of work though, [KJMX] can truly claim to have made what Apple hasn’t.

Curious about other hacks to let an iPhone do more than Apple intended? Check out how to add USB-C to an iPhone, try to charge it faster, or give one a big memory upgrade.

IR Remote tester in use, showing a remote control lighting up an LED and screenshots of the Arduino serial terminal

IR Remote Tester Helps You Crack The Code

Even though some devices now use WiFi and Bluetooth, so much of our home entertainment equipment still relies on its own proprietary infrared remote control. By and large (when you can find them) they work fine, but what happens when they stop working?  First port of call is to change the batteries, of course, but once you’ve tried that what do you do next? [Hulk] has your back with this simple but effective IR Remote Tester / Decoder.

IR remote tester schematic showing arduino, receiver, LED and resistor
How to connect the TSOP4838 to an Arduino to read the transmitted codes

By using a cheap integrated IR receiver/decoder device (the venerable TSOP4838), most of the hard work is done for you! For a quick visual check that your remote is sending codes, it can easily drive a visible LED with just a resistor for a current-limit, and a capacitor to make the flickering easier to see.

For an encore, [Hulk] shows how to connect this up to an Arduino and how to use the “IRremote” library to see the actual data being transmitted when the buttons are pressed.

It’s not much of a leap to imagine what else you might be able to do with this information once you’ve received it – controlling your own projects, cloning the IR remote codes, automating remote control sequences etc..

It’s a great way to make the invisible visible and add some helpful debug information into the mix.

We recently covered a more complex IR cloner, and if you need  to put together a truly universal remote control, then this project may be just what you need.

Continue reading “IR Remote Tester Helps You Crack The Code”

Showing a car dash screen with options menu, showing a "Steering" entry and a bunch of options one can change, i.e. Normal, Sport, offroad, Eco etc.

Your Car Has Driving Profiles – Here’s How To Change Them

Just like mobile phones of yesteryear, modern cars have profiles. They aren’t responsible for the sounds your car produces, however, as much as they change how your car behaves – for instance, they can make your engine more aggressive or tweak your steering resistance. On MQB platform cars, the “Gateway” module is responsible for these, and it’s traditionally been a black box with a few user-exposed profiles – not as much anymore, thanks to the work of [Jille]. They own a Volkswagen hybrid car, and had fun changing driving modes on it – so naturally, they decided to reverse-engineer the configuration files responsible.

Now, after two years of experimentation, tweaking values and observing changes, there’s quite some sense made of the configuration binaries. You can currently edit these binaries, also referred to as datasets, in a hex editor – there’s profiles for the 010 hex editor that make sense of the data you load, and explanation of the checksums involved. With this, you are no longer limited by profiles the manufacturer composed – if a slightly different driving combination of parameters makes more sense to you, you can recombine them and have your own profile, unlock modes that the manufacturer decided to lock out for non-premium cars, and even fix some glaring oversights in factory modes.

This is pretty empowering, and far from ECU modifications that introduce way more fundamental changes to how your car operates – the parameters being changed are within the range of what the manufacturer has implemented. The smarter our cars become, the more there is for us hackers to tweak, and even in a head unit, you can find things to meaningfully improve given some reverse-engineering smarts.

The SSD described, a green board with a ZIP connector, a controller chip and two out of four NAND chips populated. There's traces of flux on the chip, as it hasn't been washed after soldering yet.

ZIF HDDs Dying Out? Here’s An Open-Source 1.8″ SSD

A lot of old technology runs on parts no longer produced – HDDs happen to be one such part, with IDE drives specifically being long out of vogue, and going extinct to natural causes. There’s substitutes, but quite a few of them are either wonky or require expensive storage medium. Now, [dosdude1] has turned his attention to 1.8 ZIF IDE SSDs – FFC-connected hard drives that are particularly rare and therefore expensive to replace, found in laptops like the Macbook Air 1,1 2008 model. Unsatisfied with substitutes, he’s designed an entire SSD from the ground up around an IDE SSD controller and NAND chips. Then, he made the design open-source and filmed an assembly video so that we can build our own. Take a look, we’ve put it below the break!

For an open-source design, there’s a respectable amount of work shared with us. He’s reverse-engineered some IDE SSDs based on the SM2236 controller to design the schematic, and put the full KiCad files on GitHub. In the video, he shows us how to assemble this SSD using only a hot air station and a soldering iron, talks about NAND matching and programming software intricacies, and shows the SSD working in the aforementioned Macbook Air. Certainly, assembly would have been faster and easier with a stencil, but the tools used work great for what’s a self-assembly tutorial!

Continue reading “ZIF HDDs Dying Out? Here’s An Open-Source 1.8″ SSD”

The Meraki AP PCB on a desk, case-less, with three USB-UARTs connected to its pins - one for interacting with the device, and two for monitoring both of the UART data lines.

Flashing Booby-Trapped Cisco AP With OpenWrt, The Hard Way

Certain manufacturers seriously dislike open-source firmware for their devices, and this particular hack deals with quite extreme anti-hobbyist measures. The Meraki MR33, made by Cisco, is a nice access point hardware-wise, and running OpenWrt on it is wonderful – if not for the Cisco’s malicious decision to permanently brick the CPU as soon as you enter Uboot through the serial port. This AP seems to be part of a “hardware as a service” offering, and the booby-trapped Uboot was rolled out by an OTA update some time after the OpenWrt port got published.

There’s an older Uboot version available out there, but you can’t quite roll back to it and up to a certain point, there was only a JTAG downgrade path noted on the wiki – with its full description consisting of a “FIXME: describe the process” tag. Our hacker, an anonymous user from the [SagaciousSuricata] blog, decided to go a different way — lifting, dumping and modifying the onboard flash in order to downgrade the bootloader, and guides us through the entire process. There’s quite a few notable things about this hack, like use of Nix package manager to get Python 2.7 on an OS which long abandoned it, and a tip about a workable lightweight TFTP server for such work, but the flash chip part caught our eye.

The flash chip is in TSOP48 package and uses a parallel interface, and an iMX6.LL devboard was used to read, modify and flash back the image — hotswapping the chip, much like we used to do with old parallel-interface BIOS chips. We especially liked the use of FFC cables and connectors for connecting the flash chip to the devboard in a way that allows hotswapping – now that we can see it, the TSOP 0.5 mm pitch and 0.5 mm FFC hardware are a match made in heaven. This hack, of course, will fit many TSOP48-equipped devices, and it’s nice to have a toolkit for it in case you don’t have a programmer handy.

In the end, the AP got a new lease of life, now governed by its owner as opposed to Cisco’s whims. This is a handy tutorial for anyone facing a parallel-flash-equipped device where the only way appears to be the hard way, and we’re glad to see hackers getting comfortable facing such challenges, whether it’s parallel flash, JTAG or power glitching. After all, it’s great when your devices can run an OS entirely under your control – it’s historically been that you get way more features that way, but it’s also that the manufacturer can’t pull the rug from under your feet like Amazon did with its Fire TV boxes.

We thank [WifiCable] for sharing this with us!

(Ed Note: Changed instances of “OpenWRT” to “OpenWrt”.)