Level : beginner

Removing encrypted unregistered strings, and provide an inline patch for this target.

Multimedia Builder 4.9.0.1

Intro

Tools used: SoftIce Driver Studio 2.6.0 under Windows 5.1, WDasm 8.93, Hiew 6.04 (can be any hexeditor), UPX v.1.24 (for unpacking only)

Overview

A Windows-based multimedia authoring system that allows you to create autorun CD menus, Multimedia Applications on CD-ROM, Demos, Presentations, MP3 players and much more. The software is great for beginners as well as for advanced users. MB creates small stand-alone Windows exe applications and has all the bells & whistles you will ever need. You will love this easy-to-use, intuitive software. Program homesite: hxxp://www.mediachance.com Tutorial author: Wizard

Playing with registration information

Run MMB. Go into its menu Help/About... Push "Enter Reg Code" button. Now you can see three boxes: Name, Code, MP3 unlock code. Each of them must be filled with correct data. So, you can simple do a bpx GetWindowTextA and find out what all these Name & Codes are. You can make sure how simple to find them by yourself. The algorithm is quiet simple, even funny for such kind of program. Here it is: 1) The "Name" field may consist of any symbols, but it must contain "@" symbol anyway. It's for the first look only. But it must be exactly this: "cokebo@thebrabo" and no symbols more or less. Both those strings can be found in main MMB file (MMBuilder.exe) as "obarbeht" and "obekoc", the "@" symbol will be added in memory. 2) The "Code" field consists of next three things: "1-" + "xxxxxx" + "CRC", where first two symbols're constant, the next six're any numbers (you can use random generator), and the rest three're simple checksum, which is the sum of previous eight symbols, including "1-" and xes (six numbers). For example a valid code will be "1-123456-403", 403 is decimal representation of CRC: 31h+2Dh+31h+32h+33h+34h+35h+36h=193h=403. 3) The "MP3 unlock code" field. It's just a field on the form, which gets a string from user and it saves it registry. It doesn't even compare it with anything. That's a trick!

First impression

Having playing a while with these parameters I thought that I found a correct registration information. Yes it is so. But all that registration information I found is a fake. This conjecture can be proved very simple. Just click the icon second from the right of the panel, which's under the main menu. The hint of that icon says: "Compile and Run". As you can see the annoying string below the form, which says: "Created with unregistered version of Multimedia Builder". This's the first problem. The second problem is same, but for the final compilation, when you choose File/Compile... and then press Ok button & run it, we have the same bullshit. All above said means that program ain't registered yet, maybe author too smart, maybe cracker too stupid, I don't know, anyway it generates executable files with yellow inscription. So, what we gonna do in this case? Let's look at directory, when the main program is situated in. After a little investigation we can see the program (MMBuilder.exe) is written in MS Visual C++ language and not packed. But one interesting we can look on, it's "Player" directory, where situated files "Player.bin", "Player.exe" and "ecard.bin". All those files're packed with UPX v.1.24. There's need to be a prophet to suppose that "Player.bin" file concatenates to each compiled executable. The other two files are also in use. "Player.exe" is just a stand-alone player, which plays .mbd-files from commandline. "ecard.bin" is for E-cards generation. E-Card is a smaller stand-alone executable, which you can send to somebody via e-mail. The most important thing for e-card is the size, because it takes a while when you download files with e-mail client. For more information you can refer to MMB help.

Keep on digging

Make a copy of the original file, e.g. do "copy autorun.exe autorun.old". Let's find out how to remove this yellow string from a project form. Compile a new empty project (File/Compile.../Ok). Now we have a working executable file with yellow string at the bottom of the form. Unpack the exe file with "upx -d ", e.g. "upx -d autorun.exe". We do it, because disassembler won't work on a packed file. Disassemble it with WDasm. Look at the import functions list. What do you see, nothing interesting, except some functions from GDI32.dll (a cut from WDasm list): Addr:0010DBCC hint(0000) Name: CreateFontA Addr:0010DC8A hint(0000) Name: GetTextExtentPoint32A Addr:0010DD52 hint(0000) Name: BitBlt And many others. All they are seem so familiar to us, eah? First time I took BitBlt function, but after I traced the code once again, I saw there CreateFontA function. So do a "bpx CreateFontA". Run our unpacked project. SI will pop-up. Trace till this place: 00448F0F: 52 push edx 00448F10: 8BF8 mov edi,eax 00448F12: E87EF30800 call 004D8295 [1] 00448F17: 8D44241C lea eax, dword ptr [esp+1C] 00448F1B: 8BCE mov ecx,esi 00448F1D: 50 push eax [2] 00448F1E: E89DFCFEFF call 00438BC0 00448F23: 8B00 mov eax,dword ptr [eax] 00448F25: 8D542424 lea edx,dword ptr [esp+24] 00448F29: 52 push edx [1]: As you can see eax points to the crypted magic string, which looks exactly like this: ASCII !thhqjwE$fjfhqnunxQ%gq#rtjuui{!fhvjuulkjspx$mukz$ifvdiwD" HEX 21 74 68 68 71 6A 77 45 24 66 6A 66 68 71 6E 75 6E 78 51 25 67 71 23 72 74 6A 75 75 69 7B 21 66 68 76 6A 75 75 6C 6B 6A 73 70 78 24 6D 75 6B 7A 24 69 66 76 64 69 77 44 22 Trace along till [2], in here the magic string will be totally decrypted. Let's get into the call. Trace till here: [1] 00438BDA: 33F6 xor esi,esi ; assigns zero to esi ... ... ... skipped 00438C04: 8B442428 mov eax,dword ptr [esp+28] 00438C08: BB01000000 mov ebx,00000001 ; starts from first symbol [2] 00438C0D: 3970F8 cmp dword ptr [eax-08],esi ; compares a string length with 0, because esi here's ALWAYS zero 00438C10: 7E4F jle 00438C61 ; jumps over the decryption routine 00438C12: 8B0DACA05200 mov ecx,dword ptr [0052A0AC] 00438C18: 894C240C mov dword ptr [esp+0C],ecx [3] 00438C1C: 8A0406 mov al,byte ptr [esi+eax] ; moves to al next symbol 00438C1F: 8D4C240C lea ecx,dword ptr [esp+0C] [4] 00438C23: 2AC3 sub al,bl ; subtracts value from symbol code ... ... ... skipped 00438C39: E8FAFC0900 call 004D8938 ; adds symbol to the end of a new string [5] 00438C3E: 43 inc ebx ; eax contains a pointer to a new string 00438C3F: 83FB05 cmp ebx,00000005 ; for each 5 symbols [6] 00438C42: 7E05 jle 00438C49 00438C44: BB01000000 mov ebx,00000001 ; drops the value ... ... ... skipped 00438C5C: 3B70F8 cmp esi,dword ptr [eax-08] [7] 00438C5F: 7CB1 jl 00438C12 ; is all symbols encrypted 00438C61: 8D4C2408 lea ecx,dword ptr [esp+08] ; [esp][8] cell contains a pointer to a new string [8] 00438C65: E823FE0900 call 004D8A8D ; last decryption routine The decryption algorithm of the magic string is simple. According to [3]..[7] it can be described as follow: Original ASCII !thhqjwE$fjf... ...and so on till string ends HEX 21 74 68 68 71 6A 77 45 24 66 6A 66... Subtract HEX 01 02 03 04 05 01 02 03 04 05 01 02... Result HEX 20 72 65 64 69 6C 75 42 20 61 69 64... Now we have half decrypted string, which looks like this: ASCII rediluB aidemitluM fo noisrev deretsigernu htiw detaerC HEX 20 72 65 64 69 6C 75 42 20 61 69 64 65 6D 69 74 6C 75 4D 20 66 6F 20 6E 6F 69 73 72 65 76 20 64 65 72 65 74 73 69 67 65 72 6E 75 20 68 74 69 77 20 64 65 74 61 65 72 43 20 The last step of decryption is [8]. If you'll trace that call you find out what that routine reverses the whole string, e.g. was 'tset', will be 'test'. According to that rule our string now should look like this: ASCII Created with unregistered version of Multimedia Builder HEX 20 43 72 65 61 74 65 64 20 77 69 74 68 20 75 6E 72 65 67 69 73 74 65 72 65 64 20 76 65 72 73 69 6F 6E 20 6F 66 20 4D 75 6C 74 69 6D 65 64 69 61 20 42 75 6C 69 64 65 72 20 It's now fully encrypted and gonna be showed on the form. To predict it you can find the magic sequence in file and patch it according to algorithm like this: Original Replaced 20 43 72 65 61 74 65 64 20 77... 00, 01, 02, 03, 04, 00, 01, 02, 03, 04, and so on for all 57 characters But the most easiest way to do it is patch of [1]: The patch table Original Replaced 00438C0D: 3970F8 cmp dword ptr [eax-08], esi 8970F8 mov dword ptr [eax-08],esi 00438C10: 7E4F jle 00438C61 EB4F jmp 00438C61 This path allow the program to jump over decrypting routine, and also it replaces string length to zero, which's use in next routines after the last decryption call. The main part of cracking is over. All we have to do now is an executable patch. But don't forget about one little thing - the program is packed. This is not so terrible as it looks like, because executable packed with UPX and we can patch it very simple.

Making an inline patch

Overwrite backup copy to original file, e.g. autorun.old to autorun.exe. Now open file in your favourite hexeditor. We're gonna search the instructions, where the packer gives over the control to unpacked routine. But before it our patch will make our business. Let's search for last unpacker code, it should look like this: Operation code Mnemonics 61 popad E9XXXXXXXX jmp XXXXXXXX 0000 add [eax],al 0000 add [eax],al ... ... So, we're gonna search for two bytes: 61,E9. As a rule those bytes are always somewhere at the end, and you can search till your hexeditor won't say: "Target not found" (it's from Hiew) or something like that. After you find those two instructions you'll see a lot of zeroes below the last instruction. If they're there that means you found correct address, if they aren't there, then keep on searching. I've found those bytes in autorun.exe at address: 00079C3B. By the way, if you're cracking version 4.9.0.1, then your autorun.exe must be exactly 509,545 bytes long and as follow all addresses will be the same. The representation of what I've found in executable: 00079C2A: 09C0 or eax,eax 00079C2C: 7407 je 000079C35 00079C2E: 8903 mov [ebx],eax 00079C30: 83C304 add ebx,004 00079C33: EBD8 jmp 000079C0D 00079C35: FF96B8421800 call d,[esi][0001842B8] 00079C3B: 61 popad 00079C3C: E92DEAF3FF jmp 0FFFB866E 00079C41: 0000 add [eax],al 00079C43: 0000 add [eax],al ... ... ... and so on zeroes continue Below the "popad" instruction you can see "jmp 0FFFB866E", remember or better write it address to a paper. Now we're gonna add a patch to executable according to the patch table from address that I was marked with blue. The final crack should look like this: 00079C3C: C6050D8C430089 mov b,[000438C0D],089 mov dword ptr [eax-08],esi 00079C43: C605108C4300EB mov b,[000438C10],0EB jmp 00438C61 00079C4A: E91FEAF3FF jmp 0FFFB866E jump to OEP Now you can run the application. Behold! It runs without the annoying message. We did crack only for our project. And now we've to crack "Player.bin", because you can always find it in any generated file, e.g. our autorun.exe. So if we'll patch "Player.bin" file, all generated files run without the nag string.

Patching the program files

Let's go to the "Player" directory. Player.bin. Make a copy of "Player.bin". Unpack a copy. Find our magic bytes in it: 39,70,F8,7E, but without 4F. Those bytes're marked with red in the "Original" column of the patch table. I've found it at address 00038C0D in file, that means the address we're gonna specify as the memory patch address, it'll be 00038C0D + ImageBase = 00038C0D + 00400000 = 00438C0D. You can kill a copy. Now search in packed file another magic sequence, which is: 61,E9. The address is 00079C3B. Remeber the jump address, it's 0FFFB866E. Believe it or not, but the patch will be ABSOLUTELY THE SAME as the above table. Actually there's nothing amazing in that, because as I said already this file is a part of any compiled project. Player.exe. The address to patch in memory is 00038F0D + IB = 00438F0D. All in patch will be the same, except addresses. Check it out: 00079AEC: C6050D8F430089 mov b,[000438F0D],089 00079AF3: C605108F4300EB mov b,[000438F10],0EB 00079AFA: E9AFEAF3FF jmp 0FFFB85AE Comment: even if this ain't showing the nag, it contains it, so how do you think what for? ecard.bin. The address to patch in memory is 00024597 + IB = 00424597. The inline patch: 00050DBC: C6059745420089 mov b,[000424597],089 00050DC3: C6059A454200EB mov b,[00042459A],0EB 00050DCA: E97171F8FF jmp 0FFFD7F40 Comment: to get this file type you've got to go to File/Compile.../Choose "E-card" radio button/press Ok.

The final step

Run MMB (if not running). Press "Compile and Run" button. It's still show the yellow string. Close MMB (if it runs). Open its executable (MMBuilder) with a hexeditor. Search 39,70,F8,7E. I've found those bytes at addresses 0002D5FA, 00031C0D and 000D438D. Merde!!! The magic piece of code is in the three places and it's exactly the same. What does it mean? It means the program author did a smart move. He made three inline copies of the magic decryption procedure. So, patch them all directly to be sure no more thricks will arrive during the user work. As you can see the file is naked (it ain't packed at all), and we can patch it directly. The patch itself: 0002D5FA: 8970F8 0002D5FD: EB51 00031C0D: 8970F8 00031C10: EB4F 000D438D: 8970F8 000D4390: EB4F After you patch the program, run it. Press the sneaky button, I guess now it isn't sneaky anymore, because it runs well without any annoying message below the form. Also you can check File/Compile...(choose Full or E-card type), press Ok, run it. Everything runs well without nag. Are we done? Yes we are! We finally did it. Welldone! That means our essay is over. All rights reversed (c)2003 - BiW Reversing - http://www.reversing.be - The challenge is yours