Page 2 of 2 FirstFirst 12
Results 16 to 19 of 19

Thread: Code running before entry point

  1. #16
    Registered User
    Join Date
    Apr 2011
    Posts
    78
    Blog Entries
    1
    Thanks. You're right about the byte. Its at 409b10 or something and its compared with 0. If equal jumps to goodboy else badboy. That much I got. The problem though was that it would never become 0 at all irrespective of what I did.

    These protections I could bypass:
    --- IDA Temp files
    --- Running debugger Process detection
    --- Patching to avoid GetLastError problems

    But all this still resulted in encrypted junk. Then I looked at the solution.

    Solution had:
    --- Check for IsDebuggerPresent
    --- IDA Temp files
    --- Running debugger Process detection
    --- Patching to avoid GetLastError problems

    That was the extra thing I was missing. To solve this; I did the following:
    --- Ctrl+F2
    --- Right click on EBX - Follow in dump
    --- Change 00 00 01 to 00 00 00
    --- IDA Temp files
    --- Running debugger Process detection
    --- Patching to avoid GetLastError problems

    After doing this the 409xxx byte automatically became 0 and I jumped to goodboy without the routine you are mentioning. Hope it is clearer now.

    Thanks
    Arvind
    Reversing articles, primarily from a newbie perspective - http://ardsec.blogspot.com

    Latest article written - http://resources.infosecinstitute.com/author/arvind

  2. #17
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,486
    Blog Entries
    15
    Code:
    004045D4   MOV     EAX, DWORD PTR FS:[18]
    004045DB   MOV     EAX, DWORD PTR DS:[EAX+30]
    004045DE   MOVZX   EAX, BYTE PTR DS:[EAX+2]
    004045E2   CMP     EAX, 1
    004045E5   JNZ     SHORT eset_rev.004045ED
    004045E7   MOV     EAX, 80
    004045EC   RETN
    004045ED   MOV     EAX, 1
    004045F2   RETN
    Code:
    00408326     E8 A9C2FFFF                            CALL    eset_rev.004045D4
    0040832B     0005 AC904000                          ADD     BYTE PTR DS:[4090AC], AL
    the byte at 4090ac will be 0x03 to start with and after successfully passing all detection methods will be 0x0a

    this byte is passed as an argument to the xorring routine

    Code:
    00408487   ADD     BYTE PTR DS:[4090AC], 4
    0040848E   MOV     AL, BYTE PTR DS:[4090AC]
    00408493   PUSH    EAX                                             ; /Arg2 = 00901240
    00408494   PUSH    eset_rev.004090AD                               ; |Arg1 = 004090AD
    00408499   CALL    eset_rev.0040453C                               ; \eset_rev.0040453C
    and this byte is used in the xorring routine here
    Code:
    0040456F   |MOV     CL, BYTE PTR SS:[EBP+C]
    this is how your analysis should be
    i dont know why you need to restart (ctrl+f2) i think after restarting ebx holds a pointer to !peb if so then you are patching !peb->IsbeingDebugged (this is fine but this is not the way to do analysis it simply means you use some cheat to pass hurdles and do not understand the underlying mechanism) and many plugins will do this automatically for you

    restart from start and re analyze the program and understand the mechanisms so that next time you dont have to look for cheats when one of the cheats stops working
    you can create your own cheats everytime


    edit
    i reran to check your comment about 409b10 it is not a byte it is a dword
    a byte is only 8 bits
    a word is only 16bits
    a dword is 32 bits
    2 bytes = 1 word
    2word / 4 bytes = 1 dword
    when i said byte i meant byte not a dword
    and the dword at 409b10 is a checksum of the decrypted string it should be equal to 21b6 (that is another hint you could have worked backwards from)
    like ineed 21b6
    so to have 21b6 from the preceding algo what should i do
    also it checks for h at start
    to get h what should i do

    you know itis a xor and xor is reversible so to get h as start you should know what cl must be
    so for cl to be the required byte what must be the preceding requirement etc

    reversing is a methodical approach
    Last edited by blabberer; December 30th, 2011 at 15:17.

  3. #18
    Registered User
    Join Date
    Apr 2011
    Posts
    78
    Blog Entries
    1
    Yes Thanks. I got it now. I redid the part where I was patching EBX after reading your post. It much more logical that way and I don't have to "guess" what protection there is and change the PEB value without understanding. In fact the IsDebuggerPresent function also is not called; if it was that would also be a clue. Since it isn't I guess this is the best way.

    I have a question though...At what point would 1 realise that the byte at 4090ac is deciding a lot of things? Its when I step through and finally reach the XOR routine at the end..rt? And then i put a hardware breakpoint on 4090AC to break on Access... then restart the program and see where all it is being accessed and why and work from there..trying to identify the various antidebug measures. So for e.g
    Code:
    00408487   ADD     BYTE PTR DS:[4090AC], 4
    0040848E   MOV     AL, BYTE PTR DS:[4090AC]
    00408493   PUSH    EAX                                             ; /Arg2 = 00901240
    00408494   PUSH    eset_rev.004090AD                               ; |Arg1 = 004090AD
    00408499   CALL    eset_rev.0040453C                               ; \eset_rev.0040453C
    I would have to arrive at 40848E to even understand that 4090AC is important. Otherwise it would be difficult to understand anything. Am I correct?

    Then following that logic it's now clear that 4090AC starts with 03.
    --- It is incremented by 1 at 40832B (For IsDebuggerPresent)
    --- It is incremented by 2 more at 408431 (For IDA Temp files and Running process checks)
    --- Then I patch the 5 GetLastError's
    --- Finally it is incremented by 4 at 408487
    --- The sum comes out to 03+01+02+04=0A !! ---> Just like you said

    This is also passed as an argument to 40453C and an XOR happens with the garbage text at 901240 etc etc resulting in the final URL.

    Just 1 thing I will slightly disagree on is that it's not a straight XOR with 0A. Its some minor addition and shifting before the XOR happens. So for e.g 0A becomes 1B before XOR of the 1st byte. So the algo ..instead of : Encrypted Byte 1 XOR 0A becomes Encrypted Byte 1 XOR MinorChanges(0A) instead. But yes.. its quite trivial and understandable easily.

    The only thing is that I'm not great at math so try and make the program do the math for me wherever it is instead of trying to understand the algo in depth..that's a problem I hope to overcome slowly by reversing more.

    But this makes so much sense now... thanks for your help

    ---------------
    Edit:
    I looked at 4090b1 as well and found how to work with that as well. The initial value is set to 21B6 as you said. The XOR routine if it calculates correctly returns 21B6 in EAX. Value of EAX is subtracted and it becomes 0 and then a CMP 4090b1,0 goes to goodboy.

    Also checked that 4090b1 is not used anywhere else but only at the end by Right Click - Search For - All constants - 4090B1 ..only 2 references right at the end pop up . Lots of nice tricks and learning lots..thnx
    Last edited by live_dont_exist; December 31st, 2011 at 01:42.
    Reversing articles, primarily from a newbie perspective - http://ardsec.blogspot.com

    Latest article written - http://resources.infosecinstitute.com/author/arvind

  4. #19
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,486
    Blog Entries
    15
    I have a question though...At what point would 1 realise that the byte at 4090ac is deciding a lot of things
    you can realize that byte may play a role immediately on returning from the isDebuggerPresent Routine

    Code:
    00408326   CALL    <eset_rev.IsDebuggerPresent>
    0040832B   ADD     BYTE PTR DS:[4090AC], AL

    Code:
    004045D4 <>MOV     EAX, DWORD PTR FS:[18]       ;  nt_teb -> self ptr
    004045DB   MOV     EAX, DWORD PTR DS:[EAX+30]   ;  PEB
    004045DE   MOVZX   EAX, BYTE PTR DS:[EAX+2]     ;  nt!_teb ProcessEnvironmentBlock->BeingDebugged
    004045E2   CMP     EAX, 1
    004045E5   JNZ     SHORT eset_rev.004045ED
    004045E7   MOV     EAX, 80                      ;  if debugged retn 0x80
    004045EC   RETN
    004045ED   MOV     EAX, 1                       ;  if not debugged retn 1
    004045F2   RETN
    and you can find references to that byte immediately and set bp immediately
    Code:
    References in eset_rev: to 004090AC
    Address     Disassembly                                                   Comment
    00404BCF    MOV     EAX, eset_rev.004090AC                                004090AC=eset_rev.004090AC
    0040832B    ADD     BYTE PTR DS:[4090AC], AL                              (Initial CPU selection)
    00408414    ADD     BYTE PTR DS:[4090AC], 20                              DS:[004090AC]=03
    00408431    ADD     BYTE PTR DS:[4090AC], AL
    00408487    ADD     BYTE PTR DS:[4090AC], 4                               DS:[004090AC]=03
    0040848E    MOV     AL, BYTE PTR DS:[4090AC]                              [004090AC]=03

Similar Threads

  1. Thread entry point
    By diplot in forum OllyDbg Support Forums
    Replies: 3
    Last Post: May 9th, 2005, 05:23
  2. How to locate child process entry point ?
    By GIJoe in forum OllyDbg Support Forums
    Replies: 9
    Last Post: May 11th, 2004, 01:59
  3. How to find entry point for SPARC ELF binary?
    By SuperCali in forum Malware Analysis and Unpacking Forum
    Replies: 1
    Last Post: May 12th, 2002, 08:14
  4. Replies: 0
    Last Post: June 4th, 2001, 11:31
  5. Finding the entry-point......
    By SpeKKeL in forum Advanced Reversing and Programming
    Replies: 0
    Last Post: February 28th, 2001, 18:46

Tags for this Thread

Bookmarks

Posting Permissions

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