Path to hardware and firmware reverse engineering?

I’m really interested in diving deeper into hardware reverse engineering. I’ve worked briefly in firmware, and my active job is based in C++. I have a mastery of CAD/CAM and at least a good grip on EE. Education is in Computer Science and ECE.

Throw me in the deep end, what courses, material, books, tools, etc. would you recommend?

In particular, I never really got the Linux device tree, or how on Earth you would construct one given a board.

Don’t know what BusyBox really is and why it shows up in embedded systems so much.

I have no idea what actually goes into driver development, or how to get started. I certainly would be lost trying to recreate a driver for existing hardware.

Every time I open EagleCAD I get my butt kicked. It seems so simple, but even selecting a resistor kills me. I was trying to design a replacement board for the laser diode found in a Form 1+ 3D printer. That board had three components and I couldn’t do it. Just finding an SMD resistor with the value I needed in Eagle ended me, and with limited online resources that was it. For Eagle I think the answer is to just find a mentor and ask them the stupid questions, hard to do but - it’s doable. But for the more general reserving of hardware I think I lack some background, or I’m trying to punch way above my league.

It’s questions like these that bug me. Even after 8 years in college in CS and ECE, reversing hardware still seems like dark magic to me.

Am I missing something obvious?
What resources could help bridge the gap between general CS knowledge, to embedded, to reversing?

1 Like

Welcome! I am also new to the Openglow scene, but I have been reverse engineering stuff for a long time. It is an important aspect of good engineering, in my opinion. Sometimes you can’t build something new without understanding how existing things work.

The only way to learn it is to dive in and pick something apart. Reverse engineering is more art than science. You pry something open, look at the pieces, and try to understand why they go together the way they do. I used to do a lot of picking apart undocumented file formats.

For reverse engineering of software, one tool I found to be massively useful was a simple hex dump program. Take whatever binary files are sitting around and convert them into an ascii file, then dig through it to understand file formats, etc. At one point I wrote a reversible hex dump utility that allowed me to dump a file, annotate it with comments, make edits, and then convert back to binary form. If I can dig up the sources, maybe I’ll share it.

This was more useful in the days before XML became widespread, since it is already in a human-readable form of sorts.

One of my favorite projects involved vintage arcade video games. I converted an old assembler that I wrote for the Hitachi H8 into a 6502 assembler, disasssembler, emulator, and debugger. Then I loaded up some old game ROMs and watched memory locations, etc. to figure out how they worked. I ended up with a Windows program that could run Asteroids along with a few other Atari classics. Once I understood how things worked, I was able to add features to the game by hot-patching the code at runtime, or by modifying memory at the end of every screen refresh cycle. My favorite hack added friction to the asteroids so they would slow to a complete halt after you shoot them.

I was a DOS/Windows guy for a long time, and though I have used a mac for my daily driver for at least ten years, I still have a lot of trouble understanding linux system architecture. Scary, since my job in IoT requires a lot of linux. Get yourself a Raspberry Pi, and don’t be afraid to brick it.

Circuit design is also a deep subject. I taught myself how to use Eagle and designed a few circuit boards. The trick to Eagle is remembering that you have both a schematic and a physical layout. A resistor on the schematic can be implemented as a 1/4 or 1/8 watt thru–hole component, or as any of a number of surface mount sizes. I generally left the trace routing to the auto-router, but there are instances where you need to tweak a layout to avoid interference or power problems.

Anyway, welcome to the party. This board seems to be pretty quiet in terms of daily traffic, but there is clearly some deep work going on here. I am working through some of the Openglow how-to’s while I come up to speed on the project. That is probably a good place to start.

Yes that’s starting to become pretty obvious. Question, how do you go about identifying PCB connectors? I always struggle with this. I am familiar with Digikey and have managed to figure out some connectors off 3D printers in the past, mostly by Googleing. But I see that the GF has a lot of ribbon connectors and I really don’t have a lot of experience with those.

It can be confusing. Like most things, you have to break it down into digestible pieces. Further complicating things are the fact that the resulting definition is made of many layers of include files. This is a fact of life with most things kernel related, so you need to get used to it.

I have yet to find a decent resource that explains it well, and I’ve just sort of absorbed an understanding of it through the process of developing kernel modules that rely on it to get their configuration settings.

The two best books I have are *Linux Device Driver Development* by John Madieu and Linux Driver Development for Embedded Processors by Alberto Liveral de los Rios. (these are NOT affiliate links).

The first is bit easier for the novice, but suffers from a lack of proofreading. The second is more in-depth, but tailored more toward experienced developers.


If you are lucky, there is a manufacturer mark on the connector. That can give you a head start.

Short of that, you need to break out a pair of calipers and spend a lot of time searching through the DigiKey’s of the world and comparing data sheets.

Finding part numbers for unpopulated components is even harder. It took me a good 4-5 hours of datasheet spelunking to ID the part number for the SD card slot.

There really are no other short cuts that I know of.

Lucky for you, I’ve already identified all the connectors on the Glowforge. :slight_smile:

1 Like

I was an avid Eagle user for many years. Then I discovered Kicad. After getting over the initial learning curve, there was no turning back.

1 Like

Thank you, bought both. Will take me a while to get through them, busy onboarding at Google ATM.

Yes, I saw that, thank you so much for posting that!

:////// But Fusion 360 integrated with Eagle…