Results 1 to 4 of 4

Thread: From simple to complex

  1. #1
    Imported blog (Hex-Rays)
    Join Date
    Nov 2007
    Posts
    105

    From simple to complex

    The last week Elias ran a sample malware in the Bochs emulator and I was curious to see what it exactly does. So I took the unpacked version of the malware and fed it into the decompiler. It turned out to be a pretty short downloadler (different AV vendors give it different names: Lighty after the compression method, or FraudLoad, or FakeAlert, etc). Such simple code is very easy to decompile. I renamed some functions and added some comments to it. The final text looks like this:
    Code:
      download_winivstr();  // Download a program from the internet
                            // It will be launched later
                            // Create a thread to scare the user
      icon_thread = CreateThread(0, 0, icon_thread_entry, 0, 0, &Data);
      Sleep(1000u);         // 1 second
      while ( 1 )
      {
        if ( check_security_guards() == GUARD_EXISTS )
          SendMessageA(main_hwnd, WM_DESTROY, 0, 0);
        else
          scare_user();    // Tell the user that his computer is infected
        Sleep(180000u);    // 3 minutes
      }
    The original listing is 118KB and the decompilation result is 23KB. the difference is 5 times, which is a good ratio for such a simple program. The assember listing and the decompilation output can be downloaded here:

    http://www.hex-rays.com/decompilation/files/lighty_fraudload.zip

    The next time I'll try to find something more complicated to show you more advanced features of the decompiler. Something really difficult to understand even for seasoned reverse engineers. For example, can you make sense out the following code? How much time does it take for you?

    Code:
                    push    ebp
                    mov     ebp, esp
                    sub     esp, 8
                    mov     edx, [ebp+arg_C]
                    mov     eax, [ebp+arg_8]
                    push    edx
                    push    eax
                    fild    [esp+10h+var_10]
                    add     esp, 8
                    test    edx, edx
                    js      short loc_2A23
                    fstp    [ebp+var_8]
                    fld     [ebp+var_8]
                    fld     [ebp+arg_0]
                    leave
                    fucompp
                    fnstsw  ax
                    sahf
                    setnz   al
                    setp    dl
                    or      al, dl
                    movzx   eax, al
                    retn
    
    loc_2A23:                               
                    fadd    ds:flt_AEEC
                    fstp    [ebp+var_8]
                    fld     [ebp+var_8]
                    fld     [ebp+arg_0]
                    leave
                    fucompp
                    fnstsw  ax
                    sahf
                    setnz   al
                    setp    dl
                    or      al, dl
                    movzx   eax, al
                    retn
    This mess was originally a one-line statement:
    Code:
    bool cmpeq_double_longlong(double a, unsigned __int64 b){  return a == b;}
    (you knew that it would be that simple, didn't you?
    As you see, we are playing with the floating point arithmetic now. Who knows, maybe the decompiler will handle it in the nearest future. Do not hold your breath yet: there is a long way ahead and many problems to solve. The above listing is from our sample test file. The test file has ~750 trivial functions and we compile it with 3 different compilers in optimized and non-optimized modes. So we 'just' need to make sure that all 750*3*2=4500 functions decompile correctly and we will have the first decompilation step over. Then we will need to make sure that all possible combinations of integer and floating point arithmetic decompile well, type conversions do not spoil the result, and the output is generated correctly. For integer arithmetic, a similar test file took more than one month, I bet that floating point will take longer... But we will eventually be there, with a good result (it must be portable too, since we do not plan to stay forever with x86). Stay tuned!

    http://hexblog.com/2008/10/from_simple_to_complex.html

  2. #2

    bug in Hex-rays

    i have wrote in c++ like this (VC++ 6.0 MFC)

    //some code 1
    if(false)
    {
    // some code here 2
    }

    and when i used Hex-Rays i got this :
    some code 1
    without the "if" and the code in it ..

  3. #3
    Master Of Nebulah Frost Polaris's Avatar
    Join Date
    Jun 2002
    Location
    Invincible Cyclones Of FrostWinds
    Posts
    221
    There is no bug in what you are describing. You have created an unreachable statement, that has been pruned either by the compiler itself (depending on the aggressiveness of optimizations) or by HexRays' dead code elimination algorithm...
    Stand In The Fog With So Cold A Heart... Watching The Death Of The Sun...

  4. #4
    Yea but what i have done is that i inject a __asm code so i jump manually to this address of the scope of the "if(false)" ...
    this means that Hex-Rays is not useful analyzer for a malware that will use this technique .

Similar Threads

  1. bit of a simple one here
    By GES1234 in forum The Newbie Forum
    Replies: 2
    Last Post: September 2nd, 2008, 05:59
  2. ptrace detection in complex apps
    By Giaour in forum Linux RCE
    Replies: 9
    Last Post: May 23rd, 2007, 08:29
  3. simple rsa
    By Donan in forum RCE Cryptographics
    Replies: 4
    Last Post: February 12th, 2004, 18:37
  4. What is going on with this simple cmp ?
    By __DuDu__ in forum Advanced Reversing and Programming
    Replies: 2
    Last Post: June 3rd, 2001, 23:05

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
  •