Page 1 of 4 1234 LastLast
Results 1 to 15 of 52

Thread: A New Project?

  1. #1

    A New Project?

    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:

    Have Fun.


    I promise that I have read the FAQ and tried to use the Search to answer my question.

  2. #2
    Hi Everyone,

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

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


    I promise that I have read the FAQ and tried to use the Search to answer my question.

  3. #3
    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...


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

  5. #5
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Blog Entries
    WTF ??? ^_^

  6. #6
    Hi Guys,


    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)


    I promise that I have read the FAQ and tried to use the Search to answer my question.

  7. #7
    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.


  8. #8

    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 :-)


  9. #9
    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 [XX],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


  10. #10
    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.


  11. #11
    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

    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

    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 [xx],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*


  12. #12
    Hi Again Jimmy,

    Thought you might be interested in comparing notes...

    This is bizarre. After unzipping the, 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

    Virtual Size

    Virtual Offset

    Raw Size

    Raw Offset


    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:

    Virtual Size

    Virtual Offset

    Relative Size

    Relative Offset


    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 ?


  13. #13
    Hi Clandestiny & JimmyCliff,


    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" ???


    I promise that I have read the FAQ and tried to use the Search to answer my question.

  14. #14
    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.

    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???

  15. #15
    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


    I promise that I have read the FAQ and tried to use the Search to answer my question.

Similar Threads

  1. Project RainbowCrack
    By klier in forum RCE Cryptographics
    Replies: 6
    Last Post: October 28th, 2005, 07:26
  2. RSA Mini Project
    By Bengaly in forum Mini Project Area
    Replies: 11
    Last Post: October 10th, 2002, 08:12
  3. Ideas For A New Project ???
    By Clandestiny in forum Mini Project Area
    Replies: 15
    Last Post: February 8th, 2001, 15:36
  4. Great Project
    By Mustapha in forum Mini Project Area
    Replies: 2
    Last Post: January 5th, 2001, 02:30
  5. Project # 3
    By Kayaker in forum Mini Project Area
    Replies: 8
    Last Post: December 2nd, 2000, 21:04


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts