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”.)

Protected Mode On A Z80! (Almost)

The microprocessor feature which probably most enables the computing experience we take for granted today is protected mode. A chip with the required hardware can run individual software processes in their own environments, enabling multitasking and isolation between processes. Older CPUs lacked this feature, meaning that all the resources were available to all software. [Andy Hu] has done the seemingly impossible with a Zilog Z80, enabling a protected mode on the chip for the first time in over four decades. Has he found an elusive undocumented piece of silicon missed by every other researcher? Not quite, but it is a clever hack.

The Z80 has two address spaces, one for memory and the other for I/O. He’s taken the I/O request line and fed it through a flip-flop and some logic to call a hardware interrupt the first time an I/O call is made or when a RST instruction is executed. Coupled with a small piece of memory for register contents, and he’s made a Z80 with a fully-functional protected mode, for the cost of a few logic chips. It’s explained in the video below the break, and we hope you agree that it’s rather elegant given the resources in hand. It’s too late for the commercial 8-bit machines of the past, but it would be interesting to see what today’s retrocomputer designers make of it.

Continue reading “Protected Mode On A Z80! (Almost)”

When [Elon] Says No, Just Reverse Engineer The Starlink Signal

We all know that it’s sometimes better to beg forgiveness than ask permission to do something, and we’ll venture a guess that more than a few of us have taken that advice to heart on occasion. But [Todd Humphreys] got the order of operations a bit mixed up with his attempt to leverage the Starlink network as a backup to the Global Positioning System, and ended up doing some interesting reverse engineering work as a result.

The story goes that [Todd] and his team at the University of Texas Austin’s Radionavigation Lab, on behalf of their sponsors in the US Army, approached Starlink about cooperating on a project to make their low-Earth orbit constellation provide position, navigation, and timing capabilities. Although initially interested in the project, Starlink honcho [Elon Musk] put the brakes on things, leaving [Todd]’s team high and dry. Not to be dissuaded, they bought a Starlink user terminal, built what amounts to a small radiotelescope — although we’ve seen something similar done with just an RTL-SDR — and proceeded to reverse-engineer the structure of Starlink’s Ku-band downlink signal. The paper (PDF link) on their findings is densely packed with details, such as the fact that Starlink uses an orthogonal frequency-division multiplexing (OFDM) scheme.

It’s important to note that their goal was not to break encryption or sniff in on user data; rather, they wanted access to the synchronization and timing signals embedded in the Starlink data structures. By using this data along with the publically available ephemera for each satellite, it’s possible to quickly calculate the exact distance to multiple satellites and determine the receiver’s location to within 30 meters. It’s not as good as some GPS-Starlink hacks we’ve seen, but it’s still pretty good in a pinch. Besides, the reverse engineering work here is well worth a read.

Thanks to [Adrian] for the tip!