Debugging – Low Level Software Analysis

Anybody there? Yeah I know, it’s been a while… Unfortunately in my current position I haven’t had one single opportunity to debug applications, which is why I’ve not been writing new blog articles. I have to admit I miss troubleshooting and debugging applications a lot! Hope to do that soon again.

However, recently there have been teammates asking me to give a presentation about debugging, so I took the opportunity to get back into the game. ;-)

My audience was composed of engineers with strong infrastructure skills (Network/Windows/SQL Server) and great at thinking high level (architecture, big picture).

Likewise, most don’t have a background in development, so my goal was not to teach debugging or reverse engineering but to:

-  Demonstrate the power of debugging.

-  Demonstrate the importance of thinking low level while debugging.

  • By that I mean the importance of thinking in terms of the application internals and sometimes at the machine code level.

Most people think that to know how to debug applications you only need to learn how to use a debugger. But in fact, learning how to use a debugger is just part of what is needed to tackle complex software problems, as I explained in this article. Because of that I felt it was important to explain how thinking low level is fundamental when working with application problems like hangs, crashes, memory leaks, application errors and performance problems.

Speaking about misconceptions related to debugging and troubleshooting applications, you might find this post interesting.

Back to the subject, I created a PowerPoint presentation that you can download here to be delivered by someone with debugging skills to an audience that might not have knowledge about the subject.

The highlight of the presentation is the demo, divided in 4 parts. Instead of using a typical demo with an application that simulates a problem, I decided that I should do something more hardcore to attract my audience, so I decided to hack Minesweeper for Windows 8.

For those who follow my blog (or used to since it’s been a long time since I blogged), I did the same trick back in 2007 where I cheated on Minesweeper for Windows XP.

So the idea, like before, is to display all the hidden mines when you start to play the game.

Thus, going from this:

 

To this:

 

However, keep in mind that back then:

-  I didn’t share the steps I took to hack Minesweeper. I only shared the script and I know that some folks would have liked to see the whole process.

-  I didn’t use symbols. None. Just attached the debugger to the game because I wanted to force myself to read disassembled code.

Minesweeper for Windows XP was based on Native Code only.

Minesweeper for Windows 8 is a whole different animal and it uses Managed Code.

For the spoiled folks out there using IDA PRO toreverse engineer code, I just want to say two things:

a)  I’m jealous. IDA PRO has awesome reverse engineering features.

b)  My goal was to debug using only WinDbg for many obvious reasons.

As you will see in the PowerPoint presentation, I got lucky during the debugging session. I found something unexpected during my debugging session that made my life easier. Huge shortcut!

Notice that the debugging session used in the demos mentioned in the presentation and the script to cheat on Minesweeper will be blogged in 2 days maximum. That means you will need to return to my blog. ;-)

Another thing: my goal was not to find out the keys to activate cheats, but to make the application surrender and do what I wanted. Not to mention that this is way more fun :-)

For those who want to learn more about debugging books, check this out. I personally like the books from Mario Hewardt, John Robbins, and Dmitry Vostokov. Dmitry wrote this book with me. Mario’s books are always with me throughout my debugging sessions.

Use the link below to download the PPT.

Enjoy!

 

Debugging Overview.pptx