Reverse Engineering The Apple Lightning Connector

February 22, 2023 by Chris Lott 7 Comments

A frequent contributor to the hacker community, [stacksmashing] has prepared an excellent instructional video on reverse engineering Apple’s Lighting connector proprietary protocol. The video begins by showing how to gain physical access to the signals and hooking them up to a logic analyzer. He then notes that the handshaking uses only a single signal and proposes that Apple isn’t going to re-invent the wheel (perhaps a risky assumption). Using a ChatGPT search, obligatory these days, we learn that Dallas Semiconductor / Microchip 1-wire is probably the protocol employed.

Which embedded single-wire busses exist that encode bits with different lengths of low and high signals?

At the basic level, 1-wire and protocols like Texas Instruments SDQ operate in a similar manner. It turns out that [stacksmashing] already wrote a SDQ analyzer module for the Saleae logic analyzer. Aided by this tool, he digs deeper and learns more about the kinds of messages and their contents. For example, upon being plugged in, the host system queries the accessory’s serial number, manufacturer, model number, and product description. Finally, he introduces the CRC reverse engineering tool reveng to determine which CRC polynomial and algorithm the protocol uses to frame each packet.

Even if you have no interest in Lightning cables, this video is a great tutorial on the types of things you need to do in order to make sense of an unknown communications protocol. Gather what information you can, make some educated guesses, observe the signals, revise your guesses, and repeat. In part two, [stacksmashing] will show how to build a homemade iPhone JTAG cable.

We wrote in more detail about cracking the Lightning interface back in 2015. The Lightning interface may have been a good solution in its day, foreshadowing some of the features we now have in USB-C. But its proprietary and closed nature meant it wasn’t used outside of the Apple ecosystem. With the proliferation and capabilities of USB-C, not to mention various legislative edicts, Lightning’s days seem numbered. Is the industry finally settling on one interface? Let us know your thoughts in the comments below.

Continue reading “Reverse Engineering The Apple Lightning Connector” →

Taking A Deep Dive Into SPI

September 16, 2021 by Jim Heaney 9 Comments

With the prevalence of libraries, it has never been easier to communicate with hundreds of different sensors, displays, and submodules. But what is really happening when you type SPI.begin() into the Arduino IDE? In his most recent video, [Ben Eater] explores the Serial Peripheral Interface (SPI) and how it really works.

Most Hackaday readers probably know [Ben] from his breadboard-based computers, such as the 6502 build we featured in 2019. Since then he has been hard at work, adding new and interesting additions to his breadboard computer, as well as diving into different communication protocols to better understand and implement them. For this video, [Ben] set the goal of connecting the BME280, a common pressure, temperature, and humidity sensor with an SPI interface, to his breadboard 6502 computer. Along the way, [Ben] discusses how exactly SPI works, and why there is so much conflicting nomenclature and operations when looking at different SPI devices.

If breadboard computers aren’t your thing, there are tons of other uses for the BME280, such as helping to modernize a Casio F-91W.

Continue reading “Taking A Deep Dive Into SPI” →

Understanding Custom Signal Protocols With Old Nintendos

July 2, 2021 by Bryan Cockfield 5 Comments

For retro gaming, there’s really no substitute for original hardware. As it ages, though, a lot of us need to find something passable since antique hardware won’t last forever. If a console isn’t working properly an emulator can get us some of the way there, but using an original controller is still preferred even when using emulators. To that end, [All Parts Combined] shows us how to build custom interfaces between original Nintendo controllers and a PC.

The build starts by mapping out the controller behavior. Buttons on a SNES controller don’t correspond directly to pins, rather a clock latches all of the button presses at a particular moment all at once during each timing event and sends that information to the console. To implement this protocol an Adafruit Trinket is used, and a thorough explanation of the code is given in the video linked below. From there it was a simple matter of building the device itself, for which [All Parts Combined] scavenged controller ports from broken Super Nintendos and housed everything into a tidy box where it can be attached via USB to his PC.

While it might seem like a lot of work to get a custom Nintendo controller interface running just because he had lost his Mega Man cartridge, this build goes a long way to understanding a custom controller protocol. Plus, there’s a lot more utility here than just playing Mega Man; a method like this could easily be used to interface other controllers as well. We’ve even seen the reverse process where USB devices were made to work on a Nintendo 64.

Continue reading “Understanding Custom Signal Protocols With Old Nintendos” →

The Seedy World Of Message Serialization

June 10, 2020 by Kerry Scharfglass 26 Comments

Look, I’ve been there too. First the project just prints debug information for a human in nice descriptive strings that are easy to understand. Then some tool needs to log a sensor value so the simple debug messages gain structure. Now your debug messages {{look like : this}}. This is great until a second sensor is added that uses floats instead of ints. Now there are sprinklings of even more magic characters between the curly braces. A couple days later and things are starting to look Turing complete. At some point you look up and realize, “I need a messaging serialization strategy”. Well you’ve come to the right place! Continue reading “The Seedy World Of Message Serialization” →

Reverse Engineering Saves Trashed LED Panels

May 9, 2020 by Tom Nardi 8 Comments

While out riding his bike, [Hammond Pearce] came across a dumpster overflowing with large LED panels. Despite the fact that the model numbers didn’t reveal anything helpful after some online searching, he decided to pedal off with as many as he could safely carry. The COVID-19 lockdown left him with only a limited set of tools, be he still managed to crack the protocol used to control his e-waste score and document it for our reading pleasure.

Between the helpful labels on the PCB silkscreen and the advice of a friend that used to work on digital road signs, it didn’t take [Hammond] long to get a general idea of what the panels were looking for in terms of power and control. Especially once he noticed the MBI5024 shift registers dotting the board.

The next step was to take an ATmega328PB based development board and start throwing data at the panel’s input lines to see if he could elicit a response. With careful attention and some custom code, he eventually figured out that each byte of data sent down the line would control a 4 x 2 section of LEDs.

Once he had the basics down, the next step was to start expanding his code to handle things like shapes, text, and daisy-chained panels. After posting some of his work to Reddit, cyber-sleuths determined that the protocol appeared to be some variation of HUB75, which gave [Hammond] hints on what some of the other pins in the connector might be used for. He’s released all of his code online for anyone who might find it useful, but since he still doesn’t know who made these panels and why there’s really no telling how many of them are actually floating around out there.

Figuring out how to talk to an unknown or undocumented piece of hardware can be intimidating, but success stories like these are reminders of why it’s worth putting the effort in. As we’ve seen, the difference between trash and treasure is often a keen eye and a few lines of code.

Milspec Teardown: ID-2124 Howitzer Data Display

August 19, 2019 by Tom Nardi 28 Comments

It’s time once again for another installment in “Milspec Teardown”, where we get to see what Uncle Sam spends all those defense dollars on. Battle hardened pieces of kit are always a fascinating look at what can be accomplished if money is truly no object. When engineers are given a list of requirements and effectively a blank check, you know the results are going to be worth taking a closer look.

Today, we have quite a treat indeed. Not only is this ID-2124 Howitzer Deflection-Elevation Data Display unit relatively modern (this particular specimen appears to have been pulled from service in June of 1989), but unlike other military devices we’ve looked at in the past, there’s actually a fair bit of information about it available to us lowly civilians. In a first for this ongoing series of themed teardowns, we’ll be able to compare the genuine article with the extensive documentation afforded by the ever fastidious United States Armed Forces.

For example, rather than speculate wildly as to the purpose of said device, we can read the description directly from Field Manual 6-50 “TACTICS, TECHNIQUES, AND PROCEDURES FOR THE FIELD ARTILLERY CANNON BATTERY”:

The gun assembly provides instant identification of required deflection to the gunner or elevation to the assistant gunner. The display window shows quadrant elevation or deflection information. The tenths digit shows on the QE display only when the special instruction of GUNNER’S QUADRANT is received.

From this description we can surmise that the ID-2124 is used to display critical data to be used during the aiming and firing of the weapon. Further, the small size of the device and the use of binding posts seem to indicate that it would be used remotely or temporarily. Perhaps so the crew can put some distance between themselves and the artillery piece they’re controlling.

Now that we have an idea of what the ID-2124 is and how it would be used, let’s take a closer look at what’s going on inside that olive drab aluminum enclosure.

Continue reading “Milspec Teardown: ID-2124 Howitzer Data Display” →

Getting MIDI Under Control

July 15, 2019 by Brian McEvoy No comments

When [Mr. Sobolak] started his DIY Midi Fighter he already had experience with the MIDI protocol, and because it is only natural once you have mastered something to expand on the success and build something more impressive, more useful, and more button-y. He is far from rare in this regard. More buttons mean more than extra mounting holes, for example an Arduino’s I/O will fill up quickly as potentiometers hog precious analog inputs and button arrays take digital ones. Multiplexing came to the rescue, a logic-based way to monitor or control more devices, in contrast to the serial protocols used by an IO expander.

Multiplexing was not in [Mr. Sobolak]’s repertoire, but it was a fitting time to learn and who doesn’t love acquiring a new skill by improving upon a past project? All the buttons were easy enough to mount but keeping the wires tidy was not in the scope of this project, so if you have a weak stomach when it comes to a “bird’s nest” on the underside you may want to look away and think of something neat. Regardless of how well-groomed the wires are, the system works and you can listen to a demo after the break. Perhaps the tangle of copper beneath serves a purpose as it buoys the board up in lieu of an enclosure.

We are looking forward to the exciting new versions where more solutions are exercised, but sometimes, you just have to tackle a problem with the tools you have, like when the code won’t compile with the MIDI and NeoPixel libraries together so he adds an Uno to take care of the LEDs. Is it the most elegant? No. Did it get the job done? Yes, and if you don’t flip over the board, you would not even know.

Continue reading “Getting MIDI Under Control” →