TiGa

  1. Why is secure development so important?

    Here's a conversation I had recently with somebody:
    A: Why do you check the length of your strings so often and do that much validation of inputs?
    Me: It's more secure that way.
    A: Why do you need to make you program secure?
    Me: Better secure than sorry.
    A: It's a useless loss of time.
    Me: Bah, it's surprising sometimes the unforeseen problems that it can save.

    Here's a good example of an unforeseen problem that might happen, somebody managed to exploit a buffer overflow in OllyDbg and ImpREC.
    http://forums.accessroot.com/index.php?showtopic=7278
    http://www.milw0rm.com/exploits/6031
    It happens when an export from a dll has a name longer than the buffer.

    CHimpREC does not get fooled by this trick:

    http://img234.imageshack.us/my.php?image=antidebugdn6.png

    Better secure than sorry...
    Categories
    Uncategorized
  2. My "Unofficial" ReCon Video

    My "Unofficial" video is now available from the ReCon website along with my pdf slides.

    The official videos recorded live are not out yet.
    I recorded this one after the conference so it is available before all the others.
    The live version is funnier though.

    Also, I messed-up a bit my live Armadillo demo.
    But it happens...

    So this video is a little less than 60 minutes with voice and a TOC.
    And the Armadillo demo works.

    http://www.recon.cx/2008/speakers.html#i64bitunpacking

    Don't forget to watch ALL the official ones too when they come out.
    Every speaker out there was really great.

    And yes dELTA, I mentioned the CRCETL.
    Categories
    Uncategorized
  3. Weird export forwarding thanks to Vista x64 SP1

    After installing the SP1 for Vista x64, I noticed that ImpREC stopped working properly on some files using DefWindowProcA and DefWindowProcW from user32.dll.
    These 2 APIs are forwarded as usual respectively to NtdllDefWindowProc_A and NtdllDefWindowProc_W from ntdll.dll but cannot be "unforwarded" back to user32.dll using the traditional method.

    I'll explain how the loader usually resolves forwarded exports, the unforwarding method used by ImpREC and why it fails on those 2 particular cases.

    Using the information provided by the Import Directory of the executable, the loader looks for a matching name or ordinal in the specified dll.
    After a match is found, the corresponding entry from the AddressOfFunctions array is retrieved from the Export Directory and augmented by the ImageBase of the dll.
    That value is then written to the IAT.

    Sometimes, for compatibility reasons, an import can be forwarded to another one from a different module.
    In that case, the AddressOfFunctions entry does not lead to code but to an ASCII string composed of the module name and the import name or ordinal.
    Code:
    .text:7DCA751E ; LRESULT __stdcall DefWindowProcA(HWND hWnd,UINT Msg,WPARAM wParam,LPARAM lParam)
    .text:7DCA751E DefWindowProcA  db 'NTDLL.NtdllDefWindowProc_A',0
    .text:7DCA7539 ; Exported entry 151. DefWindowProcW
    .text:7DCA7539                 public DefWindowProcW
    .text:7DCA7539 ; LRESULT __stdcall DefWindowProcW(HWND hWnd,UINT Msg,WPARAM wParam,LPARAM lParam)
    .text:7DCA7539 DefWindowProcW  db 'NTDLL.NtdllDefWindowProc_W',0
    The loader then restarts the whole process from the beginning, using the info from the forwarding string rather than the original info from the Import Directory of the executable.
    The Entry Point of the newly-found function is written to the IAT instead.

    ImpREC finds the IAT and goes through it to identify all the imports that it contains.
    Some entries belong to ntdll.dll and need to be "unforwarded" to their original location.
    DefWindowProcA should be unforwarded from NtdllDefWindowProc_A.


    http://img510.imageshack.us/my.php?image=presp1zr0.png

    If everything goes well, the original import is found by "bruteforcing" the Entry Point of every function until a forwarding string is found: NTDLL.DefWindowProc_A at the Entry Point of DefWindowProcA in user32.dll and then comes in some guesswork.

    Because an import could have been forwarded from another module, doesn't mean that it really was, there are some false-positives.
    The guesswork is based on a very crude probability analysis based on the module name of the previous import and the module name of the next import.
    EndDialog from user32.dll is almost never forwarded from shlwapi32.dll.

    Something changed with Vista x64 SP1 through some modifications of wow64.dll since the content of the \SysWOW64 directory should be the same as the standard Vista 32-bit SP1.
    Some hotfix is applied only during run-time by WoW64.


    http://img177.imageshack.us/my.php?image=postsp11vz2.png


    http://img177.imageshack.us/my.php?image=postsp12vf6.png

    During execution, the AddressOfFunctions entries of DefWindowProcA and DefWindowProcW from user32.dll are modified.
    The RVA based at the ImageBase becomes greater than the SizeOfImage and leads into the memory area of ntdll.dll rather than the usual forwarding string.
    Instead of 0x0001751E, the AddressOfFunctions becomes 0x015C3D42 or 0x01793D42 or 0x01B83D42 for DefWindowProcA.

    The same result is achieved but this method prevents the unforwarding of some imports through the traditional method since there is no forwarding string anymore.
    It leads into code now:
    Code:
    ntdll.dll:77C43D42 ntdll_NtdllDefWindowProc_A:
    ntdll.dll:77C43D42 jmp     ds:off_77CB6020
    ...
    ntdll.dll:77CB6020 off_77CB6020 dd offset loc_7669C0E7     ; DATA XREF: ntdll.dll:ntdll_NtdllDefWindowProc_Ar
    And jumps back to user32.dll:
    Code:
    user32.dll:7669C0E7 loc_7669C0E7:                           ; DATA XREF: ntdll.dll:off_77CB6020o
    user32.dll:7669C0E7 push    10h
    user32.dll:7669C0E9 push    offset unk_7669C158
    user32.dll:7669C0EE call    near ptr unk_766BC240
    user32.dll:7669C0F3 call    near ptr unk_766980D7
    ...
    Unforwarding is still possible anyway since a side-effect could be identified: the Entry Point of both imports become identical.
    GetProcAddress(DefWindowProcA) == GetProcAddress(NtdllDefWindowProc_A)
    GetProcAddress(DefWindowProcW) == GetProcAddress(NtdllDefWindowProc_W)

    To sum everything up:
    It doesn't really matter, the average user of Vista x64 SP1 would never notice the difference.
    Unpacking in a 32-bit VM instead is still more reliable than under WoW64.

    This will be a part of my proposed upcoming ReCon talk.
    Categories
    Uncategorized
  4. New face and new concept for the Reverse Code Engineering Video Portal

    As promised, the site has been improved greatly.
    http://video.reverse-engineering.net

    We are now using a multi-lingual Video Gallery interface with many useful features.

    Everybody can now publish their own RCE-related videos (not porn!) in their personal gallery by manual upload or direct URL download by the server.
    So many good videos disappear every day from RapidShare-like hosting.

    The most interesting ones will be moved to the main sections for more visibility.

    For those who don't like watching videos online or downloading many separate files, it is possible to create your own custom downloadable ZIP package (batch-download) by adding videos to your Favorites folder.

    We added more than 100 videos to the local database, including:

    40 videos from the Lena series
    43 conference videos from Recon 05 and 06 (including Woodmann, Fravia and Zero)
    7 buffer overflow videos, some using olly
    3 video solutions from crackmes.de
    and many more, all in one place.

    As if that wasn't enough, 3 new videos in my IDA series:

    6. TLS-CallBacks and preventing debugger detection with IDA
    7. Unwrapping a Flash Video Executable (exe2swf)
    8. Stop fishing and start keygenning.

    The last one is an analysis of a crackme using anti-debugging techniques with IDA.

    I hope we will receive some contributions soon.
    Categories
    Uncategorized
  5. Video #5 is up.

    New addition to the Reverse Code Engineering Community Forum video tutorial website:
    http://video.reverse-engineering.net

    Video #5: x64 Disassembling and Fixing obfuscated APIs with IDA

    In this one I compare two programs compiled in x86 PE format and x64 PE32+ format with GoAsm from the same source.

    Also previous download packages have been updated (some files were missing) and I added a warning about a bug when tracing with IDA 5.1 in video #3.

    Comments/Questions/Suggestions are always welcome.
    Categories
    Uncategorized
  6. New Video Tutorials website

    New addition to the Reverse Code Engineering Community Forum:
    http://community.reverse-engineering.net
    (in the useful places box below)

    We now have a new website for video tutorials.
    http://video.reverse-engineering.net

    3 video tutorials about IDA are already online.
    #4 has just been finished, it should be added soon.

    They are mostly aimed at beginner to intermediate reversers, made in the Lena151 style.

    1. Introduction to Visual Debugging with IDA's Graphical View
    2. Remote Debugging a Linux (DVL) program from Windows / IDA for Linux
    3. Debugging a buggy program through Watching variables and Instruction tracing.
    4. How to solve crackmes for newbies / "Making of" of the keygen

    New videos will be added as time goes by.

    The site will be improved soon, the first goal was to have it online.
    Categories
    Uncategorized