Patching Security Holes With OllyDbg (Part 1/3)

This entry is part 1 of 3 in the series OllyDbg

OllyDbg is a 32-bit assembler level analyzing debugger for Microsoft Windows. This machine level debugger is created by Oleh Yuschuk for the 80×86. OllyDbg traces registers, recognizes procedures, loops, API calls, switches, tables, constants and strings. These features can be utilized to understand how an application internals.

Introduction

Ollydbg mainly has 4 windows in the default layout. CPU Window, Registers, Memory Stack and HEX Dump window. We will be working on CPU window most of the time.

ollydbgrefscreen

OllyDbg Download : [dl u=”http://www.ollydbg.de/download.htm”]

A set of 3 tutorials illustrated here explains on how effectively can OllyDbg be used to identify the security holes and to ensure that the code written is healthy.

Tutorial 1 – Unpack the compressed exe & Find the hardcoded password

First step is to get a picture of how application works by submitting some random data, understanding the sequence of dialog boxes displayed and analyzing it. This might serve useful at later point of time. Enter some random test string in the CrackMe application and click ‘Check the Serial’. Note down the message displayed in the alert box.

1a_crackme_ss

Drag and Drop the CrackMe app to OllyDbg to disassemble the binary. As a thumb rule, always do Right click – Search for – All referenced text strings, first, to obtain any text string being used in the application so that we can directly jump into the required memory location. The ‘messages’ displayed in the alert box while a wrong key is entered, or any other info displayed while navigating the application are nothing but plain strings stored and being referred by a particular instruction which can be called as required.

Once the search is complete, results are displayed; and unfortunately displays no useful info after disassembling the app. Ideally it should have the message displayed, while that wrong value was entered, referred somewhere in the application. You must have noticed that an alert was displayed when the app was opened in OllyDbg which gives some hint that the application is compressed. This is the reason why Ollydbg is not disassembling the code properly.

So inorder to proceed further, we must uncompress/unpack the application. Here, UPX is used for packaging the app so we must use an option in UPX to decompress the app. (Download the UPX from here)

Unpacking with UPX

Copy the app exe into the same folder where UPX exe is present.

Open cmd and use the ‘decompress’ option

upx -d CrackMe2.exe

1b_unpackconsole

Try ‘Search for’ – ‘All referenced text strings’ again.
1a_searchrefstringsmenu

Now we can see the comments and referenced string values in the results window. Scroll down to location where you can see these strings in the below screenshot. Double click to get to the location in the CPU main window. If you reverse engineer the logic we can find that ‘12011982‘ is the string which is compared before ‘Trial CrackMe Cracked‘ is displayed or called. (Check the tutorial found in the app zip for detailed info). Even otherwise, on the first shot itself we can do a ‘Trail and Error’ method and guess that ‘12011982’ is the key.

1a_searchrefstrings

Conclusion : Never hardcode the static key in the code to compare the user input key.

CrackMe app download : [dl u=”http://www.box.net/shared/hpty9zus1z”] Alt: [dl u=”http://dl.getdropbox.com/u/259868/Tutorial1.zip”]

Video

[youtube w=600 h=385]http://www.youtube.com/watch?v=jeAyaNjTrEA[/youtube]

Series NavigationPatching Security Holes With OllyDbg (Part 2/3)