You are browsing the archive for Reversing.

The Archaeologologogology #3 – Downloading stuff with cmdln32

April 30, 2017 in Archaeology, Reversing

One of the less-known tools residing in Windows system32 directory is cmdln32.exe. It is being used by CMAK (Connection Manager Administration Kit) to set up Connection Manager service profiles. The profile is typically packaged into an .exe that can be deployed to the user system. The package installs the profile that can be used to launch a Dial-up/VPN connection.

On older versions of Windows f.ex. XP you could fool cmdln32.exe to act as a simple downloader.

You can create 3 files:

  • A profile file
    [Profile Format]
    
    Version=4
    
    [Connection Manager]
    
    CMSFile=<settings file name - described next>
  • A settings file
    [Connection Manager]
    
    TunnelFile=<tunnel file name - described next>
  • A tunnel file
    [Settings]
    
    UpdateUrl=URL pointing to the file

The file that UpdateUrl points to needs to start with a [VPN Servers] Profile Section, followed by the actual data  f.ex.:

[VPN Servers]
This could be anything...

All you have to do now is to launch cmdl32.exe passing to it a full path to the profile file and providing a VPN argument f.ex.:

cmdln32 c:\test\profile /vpn

The program will read the profile file, then read the file name of the settings file; then read the settings file and extract the file name of the VPN tunnel file, and finally from the VPN file it will retrieve the URL for the update. Once downloaded, the file that the UpdateUrl location point to will replace the tunnel file (overwrite).

If it sounds complicated, it definitely is :), but it works and such download could potentially fly under radar of security products.

The request sent by the tool looks as follows:

GET / HTTP/1.1
User-Agent: Microsoft(R) Connection Manager Vpn File Update
Host: <domain>

So it’s easy to look for it in the logs. The version of the tool that is used on newer versions of Windows is a bit more careful. It checks if the RAS connection provided in the settings file is present (note, in my example the RAS connection is not listed inside the settings file) and only if it does, the tool continues. The alternative to the VPN download is the PhoneBook download, but this also requires the presence of the RAS connection. You can read about Connection Manager Tools and Settings on the Microsoft web page from 2003.

If you have a spare XP box you can test this functionality by downloading this package, placing its content inside c:\test and launching the cmdl32.exe via the following command:

cmdln32 c:\test\cmdl32_xp.cmp /vpn

Will this still work on newer versions?

I don’t know, but here are two ideas:

  • As long as _some_ program can be smuggled in to the victim’s system (f.ex. from the malicious attachment) it could launch cmdln32.exe under control of custom debugger and patch the RAS Enumeration check during run-time
  • Perhaps it’s possible to find a configuration where the RAS Enumeration check will work and knowing the RAS connection’s name one could set up a profile that would allow the download

In terms of forensics, you may find the following file inside the %TEMP% folder (XP-only):

  • %Temp%\VPN<random>.tmp

In any case, it’s just a trivia – it cannot really become a replacement for BITS…

IDA, hotpatched functions and signatures that don’t work…

April 7, 2017 in Malware Analysis, Reversing

In my recent post, I described issues related to signatures of functions prefixed with 0xCC (int 3).

It turns out that there is one more issue that causes sigs to fail, including both the built-in ones and also these I build myself. I was recently seeing more and more files where sigs failed and eventually decided to investigate the reason.

The problem is caused by the hotpatch prefix for the functions. For 32-bit it is the instruction mov edi,edi (8B FF). If your signatures were built from standard libraries that were compiled with a hotpatch prefix, the sigs will include the prefix as well.

What happens now when you see a piece of software that is using the very same version of the static library, but that uses the functions without the hotpatch? You end up with signature mismatch, and functions will not be recognized!

Let’s look at the example:

8BFF558BEC837D0800742D8B511483FA0872048B01EB028BC1394508721A83FA
1E 2DB8 003E :0000 ?_Inside@?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@QAE_NPB_W@Z

This is a pattern generated from the libcpmt.lib included in SDK 10.0.

Now, consider the code that looks like this:

fun1:
                push    ebp
                mov     ebp, esp
                cmp     DWORD PTR [ebp+8], 0
                jz      short loc_10001297
                mov     edx, [ecx+14h]
                cmp     edx, 8
                jb      short loc_10001276
                mov     eax, [ecx]
                jmp     short loc_10001278
loc_10001276:
                mov     eax, ecx
loc_10001278:
                cmp     [ebp+8], eax
                jb      short loc_10001297
                cmp     edx, 8
                jb      short loc_10001286
                mov     eax, [ecx]
                jmp     short loc_10001288
loc_10001286:
                mov     eax, ecx
loc_10001288:
                mov     ecx, [ecx+10h]
                lea     eax, [eax+ecx*2]
                cmp     eax, [ebp+8]
                jbe     short loc_10001297
                mov     al, 1
                jmp     short loc_10001299
loc_10001297:
                xor     al, al
loc_10001299:
                pop     ebp
                retn    4

fun2:
                mov     edi,edi
                push    ebp
                mov     ebp, esp
                cmp     DWORD PTR [ebp+8], 0
                jz      short loc_2_10001297
                mov     edx, [ecx+14h]
                cmp     edx, 8
                jb      short loc_2_10001276
                mov     eax, [ecx]
                jmp     short loc_2_10001278
loc_2_10001276:
                mov     eax, ecx
loc_2_10001278:
                cmp     [ebp+8], eax
                jb      short loc_2_10001297
                cmp     edx, 8
                jb      short loc_2_10001286
                mov     eax, [ecx]
                jmp     short loc_2_10001288
loc_2_10001286:
                mov     eax, ecx
loc_2_10001288:
                mov     ecx, [ecx+10h]
                lea     eax, [eax+ecx*2]
                cmp     eax, [ebp+8]
                jbe     short loc_2_10001297
                mov     al, 1
                jmp     short loc_2_10001299
loc_2_10001297:
                xor     al, al
loc_2_10001299:
                pop     ebp
                retn    4

Start:
  call fun1
  call fun2
  invoke ExitProcess,0

If you now apply the signature built using the pattern above, you will get the following result:

The function with the hotpatch prefix (fun2) is recognized, and the one without (fun1) – is not!

After discovering this bit I contacted the Hexrays guys and they fixed it with a simple, yet clever patch (Thx Igor&Ramiro). I can’t talk about the details, but I hope this will find its way into the new release of IDA.