Hi Everyone,

Maybe you've seen the little conversation with me and Kayaker in "The Newbies Forum" about a new Project
We need to get things going in here
And so, i was thinking for a new Project about my latest CrackMe (A PatchMe named: Re-Move).
Maybe you want to take a look at it and solve it
It has some weird things, as ussual with my CrackMe's
You can get the CrackMe here:

http://codeinside.freeservers.com/Crackmes/CoDeCrk18.zip

Have Fun.

Cya...

CoDe_InSiDe

Hi Everyone,

Hmm.. that link didn't work, strange
Try to get it from here:

http://codeinside.cjb.net

And look in the "CrackMe's and ReverseMe's" Section.
CrackMe 18 is the one we need

Cya...

CoDe_InSiDe

Hiya CoDe_InSiDe & Kayaker,

Thanks guys for getting another project rolling. It sure is good to see something happening in the project forum again :-)

I'll d/l the target and let you know my findings soon...

Cheers,
Clandestiny

It's the funniest PE Header I've seen so far ;D

WTF ??? ^_^

Hi Guys,

HAHAHA

I don't know if it's for Newbies, but that doesn't matter as long as you have fun with it
As i told you before it's a bit weird CrackMe (Err PatchMe)

Cya...

CoDe_InSiDe

Hi CoDe_InSiDe,

LOL, I think I kinda cracked your crackme by default :-D ...Though after going back and looking closely at the code I think I understand how it works. Its definately an interesting crackme...but IMO you need to patch it so as to protect it against people like me who inadvertently remove the protection before even loading it up into SICE :-)

Now I'm sure you're curious how this happened so here goes...

Generally my first appoach when cracking or reversing any target is to get a dead listing. Following this, I attempted to load your crackme up into WDASM. Of course it did not disassemble and this was a dead give away that the proggy was packed or encrypted in some way. Realizing this, I opened it up in PE editor hoping to get a clue about what it was packed with. Now, as Jimmy Clif mentioned, the header looked a little strange. First, there were no section names ! Also, I noticed that all three sections had the characteristics E0000040. This had to be corrected right away for the SICE loader to break correctly. Using PE Editor, I changed the characteristics for the first section to E0000020 (Executable, Read, Write). Now, I loaded it up into SICE and it broke at the entry point as expected. At this point I traced the target once through just to get a feel for the flow of the code...and Lo and Behold it was cracked !!! WTF, I was wondering... I haven't even really patched anything and its already telling me Contratulations I did it !!!

So now, I figure I'm going to have to go back and find out how I cracked it :-D

Running another copy of the exe whose section characteristics had not been modified let me know that patching the characteristics of the section was the key. Needless to say, I'd just stumbled on the solution due to the standard investigations I make before unpacking a proggy .

With these thoughts in mind, tracing the code in SICE began to make some sense.

...continued

...continued

PE INFO:
entry point: F0090
size of image: 7F1000
image base: 0040000

017F:004F0090 BE00114000 MOV ESI,00401100 017F:004F0095 8BFE MOV EDI,ESI
017F:004F0097 33C0 XOR EAX,EAX
017F:004F0099 B930030000 MOV ECX,00000330 // raw size of first section
017F:004F009E 33DB XOR EBX,EBX //clear ebx
017F:004F00A0 33D2 XOR EDX,EDX //clear edx
017F:004F00A2 AC LODSB //load byte starting at address 00401100
017F:004F00A3 01C3 ADD EBX,EAX //decrypt routine
017F:004F00A5 2C1F SUB AL,1F
017F:004F00A7 01C2 ADD EDX,EAX
017F:004F00A9 AA STOSB
017F:004F00AA E2F6 LOOP 004F00A2
017F:004F00AC 2BDA SUB EBX,EDX
017F:004F00AE 93 XCHG EAX,EBX
017F:004F00AF 3DD01B0000 CMP EAX,00001BD0
017F:004F00B4 7506 JNZ 004F00BC //if != 0, jmp good guy; else bad guy
017F:004F00B6 6800114000 PUSH 00401100
017F:004F00BB C3 RET
017F:004F00BC BF00004000 MOV EDI,00400000
017F:004F00C1 BED2004F00 MOV ESI,004F00D2
017F:004F00C6 33C9 XOR ECX,ECX
017F:004F00C8 B12E MOV CL,2E
017F:004F00CA F3A4 REPZ MOVSB
017F:004F00CC 6800004000 PUSH 00400000
017F:004F00D1 C3 RET

...So from the above code it seems that the first section of the .exe is encrypted. The decryption begins at address 00401100 and proceeds byte by byte until the end of the first section of the PE file is reached. This will occur when ecx = 0 since ecx was initially loaded with the raw size of the section before decryption began. The result of the decryption is finally found in eax and must be dependent on the characteristic flags of the first section.

017F:004F00AC 2BDA SUB EBX,EDX
017F:004F00AE 93 XCHG EAX,EBX
017F:004F00AF 3DD01B0000 CMP EAX,00001BD0

If eax = 1BD0, the PE header has not been edited and the proggy executes the "bad guy" MessageBox. If, however, section characteristics were changed, then eax will not = 1BD0 and the comparison will fail and consequently execute the "Congratulations" message box.

Well, thats about as far as I investigated. I'm sure someone else will have something constructive to add to the above explanation :-)

Cheers,
Clandestiny

Ouch Clandestini

I wonder, I've been tracing thru this code for exactly 2h 59 mins... See above... I edited my
message after I finally made it *hehehe* to know the time difference *g*

But I had to deal with SoftIce checks, the int 68 in the code (EC87) [one is copyied into
00401500 after awhile]

How come you could correct the PE using a PE Editor? My PE was all grabbled up and I had
to use a hex editor for it... And then there was that bloody cmp byte ptr [XßX],CC check
which searched for a breakpoint, and then this bloody code copying itself over and over
again before spitting out the congrats message...

And don't tell me... I traced this all (/me slaps myself)

Oh well, reading your solution, I might have choosen the hard path... but it worked too

-J-

Hey Jimmy Clif,

Wow !!! SoftIce checks ? Breakpoint scanning code ? You started making me wonder if I d/l the wrong crackme ;-) But nope... crackme # 18 called ReMove... unless we got different versions or something ???

No anti SICE checks at all. Well I didn't encounter any anyway. And as for breakpoint scanning code, I suspected the possibility when SICE refused to break on MessageBoxA...but had no need to persue it further since my little proggy essentially cracked itself when I changed the section characteristics. I know it seems too good to be true...but I swear it worked !!!! Just ran my little .exe again and its still cracked. Unbelievable, huh?

Hey, I'm interested in the details of your solution since you clearly put out a lot more effort than I.

Cheers
Clandestiny

Heya Clandestini,

Yeah... I wondered too if you had a wrong CrackMe.. but nope.. it must be the same... after all it's called the same (this is brutal reverser logic *jk*)

I remember bit and pieces.. and I don't really want to open this one again (jeeesuss - no way) ;D

So, when I got it I opened it into my PEDitor (by Yoda) - (Procdump failed, but I guess that's another story) and all I've seen was this:

Section Names : Nothing
VS : Nothing
VO : At two of them E000040
RS & RO : Nothing
Caracteristics : 300 (first) 200 (2nd) and 000 (3rd)

I opened my Hexeditor and searched for E0 (three instances) and changed the 40 into a 20.
SI breaked at startup where it encrypts +/- 350 (i don't remeber that well) bytes into 00401100.

then the
push 00401100
ret

I quickly found out that this jumptable in the first call was more or less unimportant.. oh well, I haven't even had much looking at it *hehehe* I didn't want to confuse myself too much for the beginning.

So, I enetered this call and F12'd until I came up to a push 00400000 and a ret... Here's where my action started... After a two more of these push - rets .. I came to a place copying always just 1 byte into 00401500... So after a few of these loops I bmp'd on that adress a little further... Althogether it copies 12 bytes there... which it calls right after this:
(I still have noted these values down)
33 C0 B4 44 CD 68 66 3D 30 13 C3 (the 13 may be a 12.. erm my handwriting)
And this translates to this after the call:
xor ax,ax
mov ah,44h
int 68
cmp ax,4300
ret

Froggy told me this
=> Re-move
** SOFTICE DETECTION ** code 07, at 018F:004011A2
Interrupt:68h >eax=00004300h ebx=00000000h ecx=00000000h
edx=00000000h esi=00401430h edi=00401430h ebp=00E2FF78h

[but that's not the only one - I don't tell all *g*]
[and I don't know if this is only some cracker confusion code... If I see an Int - I patch it black and blue - this is habit not thinking]

Later on, I passed this cmp byte ptr [xßx],CC thing which checked quite a big bunch of bytes for "int3" - I passed this one by reseting ecx which was used as a counter...

Here my memory gets vague... I don't think much happened, but suddenly I was in a loop copying always the same bytes it was in a few bytes below itself and then executing itself again until esi was a specific number... Somehow I didn't dare to fiddle with this one as I was sick being on the push "Hmmm..." so I bravely executed it using F10 and F8.

After the conditions were met, (I guess I could have saved me all this work, but I didn't trust him... I bet he would have been so mean, going to a "One little problem" if I changed his esi to early *g* ) I was already at the push "Congratulations" message.

I tried you method now.. but I still have no clue how in this world you could have used a PE-Editor making this...

My Re-Move me has just 5 bytes patched inside... for the other ones I would need to get back inside SI *g*

Woopy,
Jimmy

Hi Again Jimmy,

Thought you might be interested in comparing notes...

This is bizarre. After unzipping the CoDeCrk18.zip, I opened it up in the PE Editor of ProcDump. The version I'm using is 1.6.2 , btw and there were no problems opening it. Here's what I got...and dare I say its quite a bit better than what you reported for your PE

Before Any Corrections:

Section Names
none

Virtual Size
2000
400
400

Virtual Offset
1000
F000
0

Raw Size
2000
1000
1000

Raw Offset
300
200
0

Characteristics
E0000040
E0000040
E0000040

After changing the characteristics of the first section to E0000020 (executable code, read, write) and applying the changes to the entire PE file I have:

Section Names:
none

Virtual Size
2000
400
400

Virtual Offset
7000
F000
0

Relative Size
330
400
400

Relative Offset
1000
2000
3000

Characteristics
E0000020
E0000040
E0000040

Amazingly, it was cracked after this !!!

From there I loaded it up in the SICE loader, traced it through a couple of times and determined that the first section (335 bytes) was being decrypted in that LOOP. From there I could see that the results of the decryption determined which MessageBox would be shown and then realized that the final sum contained in eax must be dependent on the section characteristics flag. Didn't exactly do a whole lot as you can see ;-)

As for anti-sice, I had IceDump protection loaded so possibly that could account for my lack of anti-debugger problems ???

It'll be interesting to see what CodeInside has to say about our header problems - or lack thereof -

I think I'll trace a little further tomorrow and see if I can locate a few of the scenic landmarks like that int 68 I missed out on today . For now though I'm off to the sleepy Land of Nod

Hey did you ever consider the possiblity that the header might have got corrupted in the download ?

Cheers,
Clandestiny

Hi Clandestiny & JimmyCliff,

HAHAHAHA

Now that's some awesome Solution
Did it really work???
Hmm... so it's a little bit too easy, eh?
I don't know what to say about this, but it's damn funny

Btw, have you seen some other protections then those "int xx" ???

Cya...

CoDe_InSiDe

Clandestiny:
I just thought I upload a pic of my PE-Header *g* Repairing the PE as you have it there just seems to crash Re-Move at my machine.

Code-Inside:
Quote : have you seen some other protections then those "int xx"

You mean inside Re-Move? Nope, that all I've seen and then I got the Congrats message.
I was wondering nonetheless about that cmp,4300 because the "Z"-Flag got set but then the return?

Besides the cmp byte ptr [iueoa],CC which never got me out of this loop without showing the "Bad Boy" MessageBox (even when no breakpoint was set) there was nothing

-----
So.. I'd really want to do it the "Clandestine-way"... how come our PE headers differ that much???
-----

Hi Clandestiny,

Hmm.. i tried it a little bit about what you said with the PE header, but no luck
Please send the working .exe to my Email
Thx.

Cya...

CoDe_InSiDe

hmmm activating frogsice, run the crackme twice and the success msgbox appears. That is going to be a very short tutorial
At least it indicates what have to be patched.

I like stepping though the code and see how much effort code_inside has put into making stepping a nightmare, especially the JMP section. OK after a while it gets boring. It took me some time to make a working deadlisting and to break on program entry.

Hi Guys,

"hmmm activating frogsice, run the crackme twice and the success msgbox appears."

Hmm.. some weird kind of solutions do you all have
If i try that with FrogsICE it doesn't work, the Bad Message Box pops up and a beep follows

Cya...

CoDe_InSiDe

P.S. nice isn't it, that JMP Section

Hehe... I'm glad you're getting a laugh out of my solution ;-) Too easy ? Heh, yeah thats what I thought...BUT I swear it works. I'll tell ya, it was downright unbelievable to me too... Trust me, I tried it on 3 different copies of the unzipped file before posting the solution !!! Tried it on another one this morning and it still works I don't know what to say either except to assure you for what its worth that I would not post something that I 'd not tested first.

1) Patched a working .exe 4 times now
2) Anti Sice tricks are certainly present since I did find the INT 68 Jimmy mentioned when I did a back trace. Also, going back to the unfixed copy, I realized that SICE loader will not break at the entry point unless ICE DUMP's protection is loaded so there is definately anit-sice code. Works fine once ICE DUMP is loaded though and there are absolutely no other ill effects for my fixed .exe since the fixed .exe works perfectly regardless of the anti-sice code. As they say "if it ain't broke, don't fix it"...LOL
3) I redownloaded the file from CodeInside's site and unzipped it again with the exact same results - this makes the 5th working .exe
4) As a *very* wild guess I theorized that my PE was somehow getting fixed in the extraction process since I'm using WinRar and it has some file repair capabilites (in spite of the fact I was just performing a plain unzip). Well, to be thorough and test out all possiblies I d/l a simple little unzip program from a shareware site and extracted it using that. The PE header was unchanged. A long shot I know

So I guess my question is : Is the PE header supposed to look like what Jimmy got ? Mine simply doesn't, plain and simple...

I suppose the best I can do to prove it is to send a before / after picture from the PE header like Jimmy did and then send the working .exe. I suppose the joke will really be on me if this only works on my machine

So check your mail CoDe_InSiDe and Jimmy. You'll find 3 attachments...

1) Before picture of the PE header (jpg)
2) After picture of the PE header (jpg)
3) The working .exe

BTW, Code_Inside I stepped through the code some more and I want to congratulate you on a job well done for the obsfucation. Those useless jmp loops make tracing terrible :-)

Regards,
Clandestiny

Useless jump loops *gulps* No, just kidding... I had a quick look but never done them... I
F12'd just thru *g*

But I got a question too now:

- What's the point? (Not that I'm getting pissed off)

but what's the point, telling me after a hard trace - Congratulations when the real answer is
supposed to be something different ? I received Clandestiny's version... and it says what I
guess to be the real answer for it !

So, I'm kinda confused... two possible solutions ? Or did I just do sthg never expected ?
I'd love to know

I think I go download Procdump again... maybe that's the key to the mistery here...

Anyway... it's the strangest CrackMe I've seen so far ...

Regards,
JClif

PS: And I've tried this FrogIce thing - doesn't work.. maybe I should just reformat again...
(My Windows folder is dated 17.07.00) *g*

Hi Clandestiny & JimmyCliff,

Hmm... now i've tried to change the PE Header exactly as it was shown on the picture (from ProcDump) and now i got a Message Box
It shows:

Title: You did it...
Caption: it...

That's not completely correct
But it shows an Message Box, hehe pretty weird.
I traced it and in the beginning it just Encrypts stuff, but the Checksum fails and then it's supposed to show the incorrect Message Box, but because the Sections are now different mapped in space, it shows part of the Good Message Box hehe...
(If i didn't put that Checksum in there then you were not yet finished ;-) )

"but what's the point, telling me after a hard trace - Congratulations when the real answer is
supposed to be something different ?"

Hmm... I'm sorry JimmyCliff but i don't get your question
What do you exactly mean with "something different" ?
The goal of this CrackMe is to get to the Congratulations Message Box
And that Message Box is supposed to show:

Title: Congratulations !!!
Caption: You made it now write a Tutorial on how you did it...

Cya...

CoDe_InSiDe

P.S. Clandestiny, i haven't recieved any Email from you

Erm.,..

Oops... I strated thinking Clandestiny's answer "You did it" was the good one and I'd just been on an rather long and brutal cracker joke tracing this

/me blushes

Hi CoDe_InSiDe,JimmyClif,Clandestiny,

Btw Clandestiny,whats your OS anyway ?
regards
stillnewbie

[QUOTE]CoDe_InSiDe (05-05-2001 05:44):
Hi CoDe,JimmyCliff,Clandestiny

Btw Clandestiny,
what Os are you using?

regards
stillnewbie

[QUOTE]CoDe_InSiDe (05-05-2001 05:44):
Hi Clandestiny,

what OS are you using ?
Btw hi CoDe
regards
stillnewbie

Hi CodeInside & Jimmy,

Somehow I had this feeling my little solution was too good to be true Now that you tell us what the MessageBox *should* say, I can see your point. Heh, its actually pretty funny that it almost worked... Fails the CRC and then goes on to execute part of the "good guy" message due to the way the section mapping has been changed... I'd be laughing if I wasn't contemplating tracing through that code again ...I'm sorely tempted adjust the string pointers a bit and call it quits, but I suppose that would be cheating, eh ? ;-)

Hey Jimmy... Good Job Looks like that hard trace paid off after all... screwy header and all!

Cheers,
Clandestiny

To Still Newbie:

I'm running Win 98 Second Edition since you're curious :-)

Cheers,
Clandestiny

Hey Clandestiny,

I'm sorry ;P ... but I really believed at some point that your answer was the correct one...
and I just made a fool out of myself tracing all this...

Imagine the real answer would have ben yours and the trace in itself would have been just
unimportant code... *hehehe*

Ah.. before I forget, the answer is Procdump... Procdump is the only PE-Editor I have
showing me the PE Headers as they should be... Why do they other fail tho ?

I'm running Win98SE too... (WinME crashes too often *g*)
Cheers -J-

Hi Clandestiny ,
what is your OS anyway


stillnewbie

Hi Clandestiny,

Btw what is the version of your OS?

regards
stillnewbie

Hello!I also downloaded code crackme!And i tryied doing the same as Clandestiny did but it fucked up exe!I got ErroR shut down!

I dont know if code fix the last one!But that what i got the Peheader is the same as in Clandestiny case i also did find any anti!

Bye NeO

Hello i tryied the Clandestiny solution of fixing the peheader but it did give me any solution!SO what i di i used Rebiuld Pe in procdump!That did the job only problem is that you dont see the whole congra.. message!!heh And also made the file much much bigger then it was before but it changed the box!!Like it shoulD!


But that shouldnt be the solution as i know Code he change evething in pe so the result is make pe working!


NeO'X'QuiCk

Sorry about the several post above :/
Hi Clandestiny,
I was curious about the Os cuz I'm using
win98 but not SE.it has anti-debugging
as JimmyClif as stated.I'm not doubt about
your unpacking skills btw .NeoXquick has also mention about Pe builder but he's right
too.
AnyWay cheers )))
cya
stillnewbie

Hi,

Hmmm, I've got little comment on this (yet) except that the good-boy MessageBox params are pushed here

:004012D6 6886124000 PUSH 00401286 ;Congratulations
:004012DB 689A124000 PUSH 0040129A ;You made it blah blah...
:004012E0 E9D7FEFFFF JMP 004011BC

and the jmp is back into the main bad-boy MessageBox call

:004011BC 6A00 PUSH 00
:004011BE FF1544004F00 CALL [USER32!MessageBoxA]

Even in the repeating SMC code at 4011A0, where you can set a bpm and check out 20 or so different code snippets, I can't see where you can remove any checks which will reach the above code.

That is the rules right, no patching allowed? I interpret this as either no traditional direct patching allowed, i.e. don't change a jmp to jump to 4012D6. Or, some type of patching is allowed of code which might change the result of a check or produce altered SMC. For example, I could probably alter the code so one of the SMC snippets produced at 4011A0 caused a jump to the good message, but this would still be "cheating", right? Or finally, I can only interpret the rules as to mean NO patching of any kind, but altering the file in some other way, such as changing the PE header IS allowed.

I'm just trying to clarify things towards a valid solution. I'm a little confused by the seemingly erratic behaviour of this crackme on different systems, for example why Clandestiny can get one result by changing the code characteristics, but no one else can.

...continued...

In any case, I was more interested in why PEditor doesn't generate valid section information while Procdump does. My guess was that Procdump was simply a bit more sophisticated and used other clues as to the PE Header structure, while PEditor was "expecting" a certain format, which this crackme certainly doesn't have

I found this out. The first odd thing about the file format is that it's missing the DOS Stub, which is that little section just before the PE header that usually says something like "This program cannot be run in DOS mode". Not a problem, it's sort of like your appendix, a PE file can live without it. Normally a PE file uses the final field in the DOS MZ Header, e_lfanew, which is an offset into the file where the PE File header is located. This offset is at byte 3C and points to 48h. This is where part of the problem with PEditor recognizing this crackme lies.

File Header

00000048 5045 0000 4C01 0300 0000 0000 0000 0000 PE..L...........
00000058 0000 0000 F000 0F01 ........

Notice the value at 5C, 00F0. This is the SizeOfOptionalHeader. A normal Optional header is supposed to be 224 or E0h bytes, not F0h bytes. Aha, something's afoot! Immediately following the Optional header is the Section header, which is where the Name, Virtual/Raw Offset and Size, Code Characteristics, and a couple of other bits of info are kept for each section. This is what's screwed up in PEditor.

If you select a block of E0 bytes (the proper size of an Optional header) starting immediately after the File header at byte 5C, you see there's 10 extra bytes of 0's which shouldn't be there. This is where PEditor thinks it should start processing the Section header, so it reads it wrong. Procdump must be smart (dumb?) enough to use the (wrong) SizeOfOptionalHeader field value of F0 as an offset and by dumb luck reads the Section header correctly.

So you can delete these 10 bytes, change the SizeOfOptionalHeader to the correct value of E0, and replace the 10 bytes *after* the Section header, but before the 1st section starts at byte 200. PEditor will now read the file correctly. You probably don't want to actually use PEditor to make any changes to the file anyway because it has this annoying habit of inserting 60 bytes of "advertising" which will overwrite the start of the 1st section in this crackme. So this is a good opportunity to learn a bit about manually editing the PE header. Also a good opportunity to reverse Yoda's truly wonderful PEditor tool so it doesn't insert its logo/web address in a file. (Hey, could this be catagorized as Adware?

There's lots of little things you can play with with this crackme. The Image size of 7F1000 can be changed to the correct size of 0F1000 with no ill effect. The OEP can be changed to 401090 since the opening code is duplicated here anyway after the decryption process.

What was the point of this crackme again? ^_^

Kayaker

*hehehe* Kayaker ,

I assume the point we took out of it is to learn a little bit more of a PE-Header than before...

I see the rules as patching is allowed.. but the simple way of jumping immediately to the good-boy push is forbidden... I just see it as a search and destroy obstacle chase...

Like an "huh, I need that ecx to be 1 and not 330 so that it gets out of the loop faster... and in case the loop turned out wrong I need the jnz to be always true so that I can go on for the next obstacle"

Only thing wich really kills my nerves is the adding 1F to every opcode... before patching.. My hp-calculator is in lack of batteries and using calc.exe 'erm' s*cks.

So, I was thinking on ripping out his crypted code, writing a little utility to sub 1F from every byte and saving it... This way it will be readable in hiew... (Maybe even print out ? +/- 350 bytes isn't that much... )

Well, thanks for the PE~Crash course

JimmyClif

Hi guys,

HAHAHA Kayaker

Well it's indeed what JimmyCliff said:

Patching is allowed (This CrackMe is meant to be Patched ) but not a direct Patch (I mean a Jump straight to the Good Message Box).
Just play with it as long as you want hehe (And solve it)...

Cya...

CoDe_InSiDe

P.S. i allready got a Solution to this CrackMe in my mail

Code Inside... here's you solution... somehow my mail box doesn't work...

I know the tut has been brutally nasty written but it's enough to follow...

Hey guys... this is not for anyone else then CodeInside - please don't cheat!

JimmyC

Hi JimmyCliff,

Whoah what kind of language is that?
Uhm i can't read it now, dunno what language it is, but thx anyway

Cya...

CoDe_InSiDe

LOL

Hi JimmyCliff,

Sorry i'm dumb now i see ;D Thx...

Cya...

CoDe_InSiDe

Hi JimmyCliff,

Sorry i'm dumb now i see ;D Thx...

Cya...

CoDe_InSiDe

LOL, that's funny Jimmy Cliff!

Hey, I say this projects not dead yet. JC had to tell me about it, but he encrypted his last post attachment. Howzabout patching Code_Insides crackme to decrypt and write a copy of Jimmy Cliffs attachment?

This would be a good opportunity to work on an inline patch. I figure you can use the MessageBox itself as the trigger to call your patch code. There's plenty of empty bytes in the file to place a patch. You can just redirect the jump after the MessageBox to your patch before it calls ExitProcess, decrypt and write the file, then jump back to program code. You can either Read the file or Map it and make the changes.

For Reading a file you'll need to study up on the usage of CreateFileA and ReadFile. To Map it you'll need CreateFileA, CreateFileMapping, MapViewOfFile, then call your patch, then UnmapViewOfFile and CloseHandle to close the mapping.

Just a thought for anyone wanting a bit of a new challenge. That, plus the wisdom of a quote after you've succeeded

('course you can just make a stand-alone proggy to decrypt it as well which, lame-ass that I am, is what I did

Regards,
Kayaker

Hi Kayaker,

Hehe you Lame-Ass

But maybe it's a nice thing yes, we'll see if anyone will do it

Cya...

CoDe_InSiDe

Well, I'd give it a go... even tho that I know coding one would be faster... actually I even
started but I stopped when I realized that his exe wasn't his exe anymore... at the point
where I landed I even had my handles and Flags section already *grin*

I'm, willing to start anew... but only if CodeInside is willing to teach :P

So, CodeInside... it's up to you.. let's assume you finished your CrackMe called Re-Move and
suddenly you realize that you forgot to insert a call to CreateFile...

(well, I'm prepared for some mindbreaking PE juggling)
JimmyClif *bg*

Hi CodeInside, Jimmy, Kayaker


hehehe that was really funny Jimmy ...




And you Kayaker... shame on you for laziness


As for me, I'm willing to give Kayaker's suggestion a try, but I'm going to need some help w/ the PE juggling since I am only a beginner to unpacking :-)

Writing the actual patch should be pretty easy, but unpacking this thing to get a working decrypted, disassemblable .exe that I can insert my patch into seems like its going to be quite a challenge. Perhaps one of the unpacking gurus around here will be so kind as to put me on the right track. I'll tell you what I've tried so far... I think I'm loosing sight of the forest for the trees since I've never tried to completely manually unpack and .exe section by section and then "glue" them all together again.

First off is the decryption routine which appears to be decrypting the first section of the PE:

017F:004F0090 BE00114000 MOV ESI,00401100 //program entry point
017F:004F0095 8BFE MOV EDI,ESI
017F:004F0097 33C0 XOR EAX,EAX
017F:004F0099 B930030000 MOV ECX,00000330
017F:004F009E 33DB XOR EBX,EBX //clear ebx
017F:004F00A0 33D2 XOR EDX,EDX //clear edx
017F:004F00A2 AC LODSB
017F:004F00A3 01C3 ADD EBX,EAX
017F:004F00A5 2C1F SUB AL,1F
017F:004F00A7 01C2 ADD EDX,EAX
017F:004F00A9 AA STOSB
017F:004F00AA E2F6 LOOP 004F00A2 //decryption loop
017F:004F00AC 2BDA SUB EBX,EDX
017F:004F00AE 93 XCHG EAX,EBX
017F:004F00AF 3DD01B0000 CMP EAX,00001BD0
017F:004F00B4 7506 JNZ 004F00BC
017F:004F00B6 6800114000 PUSH 00401100
017F:004F00BB C3 RET

Now after decryption is complete, I put the proggy in an infinite loop and go to Proc Dump where it is my intention to dump it. Alas the full dump doesn't work so I opt to dump it section by section and then "glue" it all back together.

...continued

...continued

In order to dump it I began each dump at the Image Base + Virtual Offset for each section and dumped a number of bytes corresponding to the Virtual Size.

Now I have 3 dumped sections sitting on my HD . Going to paste them together, I pasted in my 3rd dumped section which appears to be the PE header (with some problems). Following the header, I paste in the other 2 sections.

At this point, I realize that I need to fix entry point as well as the Raw Size and Raw Offset and of these sections... so I go try to load it up in Proc Dump again (crossing my fingers and toes) that it will recoginize my butchery of this PE file. Well, no such luck...

Looking at my dumped PE header... I can see it looks rather strange... ie. there is no DOS MZ header at all. Strangely, the original crypted file had an MZ header when opened up in a hex editor. So as a long shot I transplant the MZ header from the original file into my new glued together PE.

Now ProcDump actually opens it and I proceed to adjust Raw Sizes and Raw Offsets in my new .exe.

Finishing the task, I crossed my fingers and toes again, hoping (but not really thinking) it'd run for me. Well needless to say I wasn't much surprised when it didn't. In fact it greeted me with a nice friendly Invalid Page Fault

And here I am, not too sure at all about wtf I'm doing ??? as its the very first time I'm trying to piece together a PE all the way from scratch. Hopefully, at least a part of my above ramblings will make enough sense for someone to tell me if I'm on the right track (or not as the case may be).

Regards :-)
Clandestiny

Clandestiny,

To be honest... I'm lazy... The easiest method of getting this executable into something that
would be readable... or get close to an diassembled listing is:

To break at startup. F12 to the pushad. And dump 330 bytes of it.
Then you grab your hex editor and copy those bytes over the last 330 bytes.
So.. running it will fail as it tries to decrypt the already decrypted ones.. so to run it just nop
out his sub eax,1F and his jne... Alright, this is enough for Hiew...

Now to get this into Wdasm (IDA seems to be a little bit more sensitive here) is to take a
valid PE Header from an executable and paste all his code (starting from Offset 290) into the
code section of the valid PE-Header overwriting the old one

This disassembles but won't make it run... because all adresses are relative to the copy process he does.. and rewriting those .. Pfuhh... I won't go there

I just went half way and did the /dump copy-paste thing to be able to work my way around in Hiew...

Regards,
Jimmy

Hiyas,

Dump individual sections? Crazy Glue them together? White-Out code? Man, I MUST be a lazy-ass. I just raw dumped it after returning from the decryption process at 401100. You don't need to dump the whole 7F1000 size of the image as listed, 0F1000 works just as well. You could also get away with less since the code at the OEP of 4F0090 is repeated at 401090, but this just complicates fixing up the PE header.

With packed files I usually do a raw /DUMP with Icedump. Since this is an image dump of the file in memory, the Raw Size and Offset now need to be changed to the values of the Virtual Size and Offset. You can use the Dumpfixer option of PEditor 1.7 to do this. As I mentioned before, PEditor kind of overwrites a bit of what *used* to be code at offset 200h in the file, but after the raw dump and fix up, the real code now starts at 1000h and this earlier stuff is never used anyway.

I like doing raw dumps rather than using Procdump or Icedump's /pedump because WYSIWYG. An address in SoftIce or W32Dasm is the same as in a hexeditor. Really helps to find sections or the IAT or whatever.

So I dumped the file at 401100 with
/DUMP F1000 C:\filename.exe

This gave a working exe, but unrecognizable with WDasm. Then I fixed up the Optional header as I mentioned before, which screwed up PEditor (and WDasm) from interpreting the Section header properly. There's 10 bytes too many in the Optional header. Remove 10 bytes from 130h and insert them at 1E0h, then change the SizeOfOptionalHeader at 5Ch from F0 to E0.

That should give a file which can be disassembled. You get some screwy MessageBox text though because the 330 bytes are decrypted twice now, which includes the MessageBox strings at 4011C6 and 4011CD. So you can change the OEP to completely bypass the decryption routine and point it to elsewhere in the code, like 401100.

This should be OK for patching purposes. There's still some trimming which could be done of the F1000 file size, there's actually 3 Import tables, so you could point to the 1st one and delete some bytes. But that's just messing around.

...continued...

Here's my PE header (and we'll see if PRE formatting works):

<PRE>
00000040 B44C CD21 0000 0000 5045 0000 4C01 0300 .L.!....PE..L...
00000050 0000 0000 0000 0000 0000 0000 E000 0F01 ................
00000060 0B01 050C 0010 0000 0010 0000 0000 0000 ................
00000070 0011 0000 0010 0000 0010 0000 0000 4000 ..............@.
00000080 0010 0000 0010 0000 0400 0000 0000 0000 ................
00000090 0400 0000 0000 0000 0010 0F00 0004 0000 ................
000000A0 0000 0000 0200 0000 0000 1000 0010 0000 ................
000000B0 0000 1000 0010 0000 0000 0000 1000 0000 ................
000000C0 0000 0000 0000 0000 0000 0F00 3400 0000 ............4...
000000D0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000E0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000F0 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000100 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000110 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000120 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000130 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000140 2E74 6578 7400 0000 0020 0000 0010 0000 .text.... ......
00000150 0020 0000 0010 0000 0000 0000 0000 0000 . ..............
00000160 0000 0000 4000 00E0 2E69 6461 7461 0000 ....@....idata..
00000170 0004 0000 0000 0F00 0004 0000 0000 0F00 ................
00000180 0000 0000 0000 0000 0000 0000 4000 00C0 ............@...
00000190 2E77 7466 0000 0000 0004 0000 0000 0000 .wtf............
000001A0 0004 0000 0000 0000 0000 0000 0000 0000 ................
000001B0 0000 0000 4000 00C0 ....@...
</PRE>

SizeOfImage = F1000
OEP = 401100
.text VS = RS = 2000; VO = RO = 1000; Char=E0000040
.idata VS = RS = 400; VO = RO = F0000; Char=C0000040
.wtf VS = RS = 400; VO = RO = 0; Char=C0000040


I find the BEST util for learning about PE headers is PEBrowse Pro (h**p://www.smidgeonsoft.com/). Also comes in an interactive debug version, both freeware. Just start scoping out notepad and you'll quickly learn where everything is.

There's also a good summary by FatBoyJoe listing what each of the fields in the PE Header are as offsets within each section at
http://www.immortaldescendants.org./database/essays/fboyjoe/exe_hdr.html


Hope this helps confuse things a bit

Kayaker

Thanks Jimmy and Kayaker for your help

Jimmy: I really liked your practical mindset about just pasting in the decrypted code...

Kayaker: A very educational explanation (and works much better than my butchered attempt at gluing sections). Thanks. We couldn't pay you enough for all of your kind help ;-)

Regards,
Clandestiny

Yup, its me again

What a PE nightmare this has been... And its just got worse ! Of course on the bright side, this means I'm learning lot

Man, I thought I was home free after getting a working dump of this proggy. After all, there's plenty of room to insert my inline patch...

BUT, I sorta took the ability to add new API's to the import table for granted. Firing up IDD King to insert my new functions led me to a most unwelcome surprise. Apparently, there is not any room to insert new imports and I checked all 3 of the tables that Kayaker mentioned.

I suppose this means adding some empty space at the end of the current import table. Before I try this though, I just want to confirm that its necessary and that I'm not overlooking the obvious...

Clandestiny

OK, now I'm flummoxed. I finally rebuilt a logical PE file out of this s***, and suddenly I get the Congratulations message (but only if I don't set certain breakpoints, some are OK, some aren't). My hat's off to you Code_Inside, you turned this PE file inside out, chewed it up, and spat out... something.

I started by trying to answer Clandestiny's question about IIDKing. The *reason* it can't insert another section in the PE Header is because there's not enough empty bytes after the Section header, either because of the original code, or because of the advert crap PEditor 1.7 puts in there if you used it. If you made a raw image dump, then the real code begins at 1000h, so you can fill that whole section from the end of the Section header around 1B8h to 1000h with 0's. IIDKing will now be able to insert a new section.

I found a problem with this anyway because the image file extends to 4F1000, and IIDKing wipes out most of it because I guess it doesn't really recognize the still screwed up PE header. Well, I could see that all of the code was between 1000h and 1430h, and I was getting fed up with this F1000h file size (964KB), so I decided to create a "proper" PE file.

I deleted everything from 2000h onwards, this left me with just a .text section from 1000h to 2000h. Then I rebuilt my own .idata section of the 3 API's at 2000h. I used the existing one as a template, and just changed the IMAGE_IMPORT_DESCRIPTOR pointers and the IAT pointers. While messing with getting the file to run, I finally realized what that 3rd section, the one I called .wtf, really is! This is the one in the original file that has a Raw and Virtual Offset of 0000000. Very peculiar this. Turns out this is actually the PE header, beginning at the ImageBase Virtual Address of 400000. This section seems necessary to map the PE header into memory so part of it can be overwritten at:

:00401107 BE20114000 mov esi, 00401120
:0040110C BF00004000 mov edi, 00400000
:00401111 F3 repz
:00401112 A4 movsb

and elsewhere. If the 400000 address is not mapped properly, the repz/movsb code crashes. Anyway, that was interesting, I kept wondering why I couldn't delete that .wtf section. (Which is why I called it .wtf

To continue, I realized that the original Import Table, at F0000, is **required** to be mapped there, because the SMC code at 4011A0 at one point calls GetTickCount, and it's looking for it in this memory range. But, I didn't want a raw file this big, so I discarded my rebuilt IT and copied the original Import table, including the IAT, (i.e. from F0000h to F0090h in the dumped file, or 200h to 290h in the original file) and inserted it in a new .idata section at 2000h. Then I set the Virtual Offset to be F0000 so it would be mapped where it was expected to be.

So my final Section header looks like:

.text VSize=2000, VOff=1000, RSize=1000, ROff=1000, Char=E0000020
.idata VSize=1000, VOff=F0000, RSize=1000, ROff=2000, Char=C0000040
.wtf VSize=400, VOff=0000, RSize=400, ROff=0000, Char=C0000040

SizeOfImage=F1000
OEP=401100

*note- raw size of .text can be 1000h (minimum 430h), but virtual size *must* be 2000 (or somewhere in there) because this memory, even though it only contains 0's, is read/written to at some point and must be mapped to prevent a crash.

Not sure where the checks are, but this rebuilt file seems to call the Goodboy message box. IIDKing also seems to be able to insert API's properly now. I inserted 10 new API's:

CreateFileA, ReadFile, WriteFile if I wanted to read JimmyClif's encrypted file into memory to decrypt it.

CreateFileA, CreateFileMapping, MapViewOfFile, UnmapViewOfFile, CloseHandle if I wanted to map it into memory.

LoadLibraryA, GetProcAddress, FreeLibraryA if I wanted to call my own dll to do the dirty work.

Kayaker