While I was checking binary-auditing.com's package , I found one interesting unpack_me challenge .\nSo I made up my mind to to give a try as it is recommended by many dudes.\n\nWell , apparently our mission is to unpack the binary and change the message it outputs ("UNREGISTERED") in order to validate the task .\n\n\n\nAt this point , you can use plenty of tools and olly scripts that are dedicated for unpacking purposes such as IMPrec Universal OEPfinder , but I took a different approach and I managed to unpack it manually by taking a deep look at the behaviour of the unpacker .\n\n\nAfter loading it in olly , the first CALL is a decryption loop that XORes the first 0x312 bytes starting from 0x0047E340 with 0x62 as a key .Next function iterates over a range of memory addresses to find the base address of KERNEL32.DLL module . \n\n\nSo , we step out to find another interesting CALL at 0x0047E254 which loops through kernel32.dll memory region and does a manual import of some APIs (LoadLibrary ,IsDebuggerPresent , VirtualAlloc, GetTickCount , CreatThread) that are needed for the unpacker stub.\nAs we proceed , we will encounter IsDebuggerPresent() and calls to GetTickCount() , it seems that it checks whether the process is not being debugged otherwise it calls ExitProcess() . \n\nIn function 0x0047E144 , there is something that we need to pay attention to . there are two consecutive calls to VirtualProtect() api that contain instructions like REPE MOVS and SCAS ,STOS .. etc. As expected , this a self-modifying code that changes various opcodes in a .code section . If you look a little deeper ,you will notice that it destroyes the unpacking stub .\n\n\n\nWe keep stepping out until we face obfuscated opcodes that reside within the .klizma section , to make the raw data readable , we click on "remove analysis from module". It turns out that we have long decryption loop that aims to unpack the first part of the binary . \n The decryption procedure is so long and it does not seem to end as we might have thought . Therefore we have to find a strategy to find out where this loop ends . Since we are dealing with a packer , we are pretty sure that a call to GetProcAdress() api is going to take place , so let's set a breakpoint on it and press F9 . As expected !! \n\n\n\nMany procedures that are related to text , image drawing(imagelist_drawEx , GetbitmapBits) have been imported and written to a memory region where EDI points to .Normally it is building the IAT block of the binary .\n After the binary is unpacked , we search for the string "UNREGISTERED" in the dump , and voilà !!\n\n\nWe set a hardware breakpoint on it with execution option , and we notice instantly that it is going to be accessed by REP MOVS [EDI],[ESI] we follow ESI in dump and then change the string to whatever we want it to output . \n\n\n\n\n