Good morning fellow readers,
Preface
I decided to write another beginner tutorial before we’re stepping into deeper water, so everyone who’s interested in following has basically the same knowledge base when it’s getting more complex. If you’re more advanced and already know what I’m writing about now I’d still appreciate some feedback about the writing itself.
Intro
Last time we got to know the Bus Pirate who can be seen as a “stupid doer”. He does what you are telling him to do, much like the cool kids in high school who stole the car because they wanted to belong to the cool gang./s
This time we’re taking a closer look at the silent kid in the back row. He’s the thinker and he tries to understand his surroundings.
Some people may think now? “What the heck is he talking about?” “Am I still on 0x00sec?” Don’t worry friend you’re in the correct place.
So what am I talking about?
The answer is the logic analyzer. He can be seen as the pre-step before communicating with hardware e.g. through the Bus Pirate.
Excursion
So before we can connect a gadget(e.g.: Bus Pirate, Logic Analyzer) to a debug port we have to find one of those right? Since this is a basic step and most likely not worth an article on its own, due to the fact that most of the work done here is trying and researching yourself. Hence I’ll add this little section here.
So the question is How to find a debug port? I’ll give a short step by step list I usually take. It may vary when the complexity of the hardware rises.
1.) Open the casing. Duh…
2.) Try to identify common debug ports on the mainboard.
2.1) But How? Well e.g.: UART or JTAG are fairly easy to spot right away due to their mostly used standard pinout. See below for more information.
2.1.0) Always try to identify a GND pin first using a multimeter!
3.) Try to find eye-catching/suspicious looking pinouts
3.1) If you found some use a multimeter/oscilloscope to find a data signal. Then it’s fairly easy to tell what Port you’re having in front of you depending on the amount of other pins next to the data signal pin.
4.) If you’re not making any progress try looking for a mainboard label and find a datasheet!
UART:
JTAG:
The Logic Analyzer
(Here is another affordable one I used myself at the beginning: Open Bench Logic Sniffer
So what is a logic analyzer? In the end it’s nothing more than a gadget who captures digital signals and forwards them to a software on your computer (Hardware -> logic analyzer -> PC). As I tried to depict just now, there’s NO communication happening between them, just listening.
Depending on the software you can analyze the captured signal further by selecting common protocols, adding start and end points, etc. The software then tries to make any sense out of your choices and the signal it received.
If it does make sense you will be rewarded with a decoded signal. This will usually be in ASCII or Hexadecimal.
So what?
A decoded signal can be enough to determine to plan the next steps in the reversing process, since the boot procedure you may have captured has “sensitive” information as learned last time already:
- You wanna read from the Flash chip but don’t know at which address? The boot log may reveal this
- You wanna know which architecture is used ? The boot log may reveal this.
- You wanna know what processes are started? the boot log may reveal this!
- …
As you can see even when having no possibility to communicate with the hardware, a decrypted data signal can expose the hardware you’re looking almost fully!
Demo
To show you a first short example: I had a router and identified a typical looking UART debug port, so I connected my logic analyzer. Basically just the data signal pin (TxD) is needed. That explains why I have just one channel in the picture below:
First I configured my UART protocol to match the BAUD rate and set most of the other values to standard values:
The BAUD rate plays an important role. If it’s set wrong one may NOT see any useful decodings.
As one can see I have captured a nice looking data signal and for each section the logic analyzer software already tried to decode the UART protocol in hex format. That doesn’t look very helpful does it? Wrong, just converting the hex to ASCII and add the decoded characters together makes a nice looking text full of information:
As one can see its a router by AVM with a 2.6.32.60 Linux kernel and MIPS architecture. Also lots of hardware related information already can be extracted from the except. The whole log is a lot longer until it reaches a point where is written: “Press Enter to active console”.
Conclusion
As you can see being able just to understand what is going wile your hardware boots can be of major interest. It’s much like you have binary blob and trying to make any sense of the unpacked binaries/files or any source code you found inside just by looking at it.
In the end the procedure I gave here should not be seen as ‘fix’. Everyone has their own way of doing things and this is what worked for me in the past.
) you may include the maximum sample rate, number of channels, input voltages… A quick summary of the relevant information within the post will be useful.
who knows 
.
