Friday, May 06 2005 @ 11:50 AM CEST Contributed by: wizard Views: 8988
Level : beginner
Removing encrypted unregistered strings, and provide an inline patch for this target.
SoftIce Driver Studio 2.6.0 under Windows 5.1,
Hiew 6.04 (can be any hexeditor),
UPX v.1.24 (for unpacking only)
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.
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:
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!
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.
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):
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:
lea eax, dword ptr [esp+1C]
mov eax,dword ptr [eax]
lea edx,dword ptr [esp+24]
: As you can see eax points to the crypted magic string, which
looks exactly like this:
The last step of decryption is . 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:
Created with unregistered version of Multimedia
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
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 :
The patch table
cmp dword ptr [eax-08], esi
mov dword ptr [eax-08],esi
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.
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:
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 220.127.116.11, then your autorun.exe must
be exactly 509,545 bytes long and as follow all addresses will be the
The representation of what I've found in executable:
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:
mov dword ptr [eax-08],esi
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.
the program files
Let's go to the "Player" directory.
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.
The address to patch in memory is 00038F0D + IB = 00438F0D.
All in patch will be the same, except addresses. Check it out:
Comment: even if this ain't showing the nag, it contains it, so
how do you think what for?
The address to patch in memory is 00024597 + IB = 00424597.
The inline patch:
Comment: to get this file type you've got to go to File/Compile.../Choose
"E-card" radio button/press Ok.
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:
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