Friday, March 18, 2011

RusCryptoCTF T4 Task


Lets show you decision of T4 RusCrypto task from Ufologists.

We were given an access to the box on which key container was running. It was uploaded not long ago by third party developer. Container search ended with BSOD with help of antirootkit and antiviruse. Analyze the dump and find the key in root of OS.
P.S.We know for sure that flag contains only latin symbols. download file

First of all unzip it.And get memory dump. Put it in to WinDbg.

Let's start
kd>!analise -v
WARNING: Stack unwind information not available. Following frames may be wrong.
989e9c58 8a267f44 badb0d00 00000000 00000801 nt!Kei386EoiHelper+0x291c
989e9ce4 81a2aa31 00000004 00000d54 00000000 klif+0xdf44
989e9d54 81a2b2ff 00000000 00000000 8d41f348 nt!IoSetIoCompletion+0x3bd
989e9d74 819f1a2d 8d41f348 00000000 00000001 nt!IoSetIoCompletion+0xc8b
989e9dc0 8184aa3e 905f5973 83d2e8a0 00000000 nt!RtlDestroyAtomTable+0x50f
00000000 00000000 00000000 00000000 00000000 nt!RtlSubAuthorityCountSid+0x3c4
Something crazy and Unknown. Lets Google driver name klif.
It's Antivirus. Remember that Memdump was made with Antivirus and antirootkit.
Ok. Let's see all drivers in system.

kd> lm oft
(It's last drivers)
905de000 905e1d00   Dbgv     \??\C:\Windows\system32\Drivers\Dbgv.sys Sat May 17 19:18:56 2008 (482EF760)

905e2000 905f0000   atapi32  \??\C:\Windows\System32\drivers\atapi32.sys Wed Mar 09 23:33:41 2011 (4D77E425)
905f0000 905f8700   Normandy \SystemRoot\System32\Drivers\Normandy.SYS Fri Apr 30 08:00:34 2010 (4BDA55E2)
93c10000 93e11000   win32k   \SystemRoot\System32\win32k.sys Sat Jan 19 08:36:46 2008 (47918C6E)
93e20000 93e37000   dxg      \SystemRoot\System32\drivers\dxg.sys Sat Jan 19 08:36:11 2008 (47918C4B)
93e50000 93e59000   TSDDD    \SystemRoot\System32\TSDDD.dll Sat Jan 19 09:01:09 2008 (47919225)
93ea0000 93ec8a80   vmx_fb   \SystemRoot\System32\vmx_fb.dll Fri Oct 03 22:41:58 2008 (48E66776)
One of them was developed in 2011.And one in 2010. All another drivers there are in Vista.
Google Normandy.sys -> It's RkU. (antirootkit)

Let's analyze driver.
kd> !dh 905e2000
Debug Directories(1)
Type       Size     Address  Pointer
cv           70        acb8     98b8 Format: RSDS, guid, 1, d:\develop\my_project\ruscryptotask\driver\ruscrypto\objfre_win7_x86\i386\Ruscrypto.pdb
Sure it's some task for RusCrypto.
Get file from memory.
kd> .writemem d:\dumpnt.exe 0x905e2000 L?E000

OK. Add it to IDA. Base program on 905e2000.

Remember that driver unloads init section. So DriverEntry we can't find.
Find a peaces of code.


IDA colored code. Push 'P' to make function.
Let's analyze imported functions. IDA knows about .idata section. So all imported functions are red.


Imported function are

.idata:905E4000                 extrn unk_905E4000      ; CODE XREF: sub_905E4422+712 p
.idata:905E4000                                         ; DATA XREF: sub_905E4422+712 r
.idata:905E4004                 extrn unk_905E4004      ; CODE XREF: sub_905E4422+70B p
.idata:905E4004                                         ; DATA XREF: sub_905E4422+70B r
.idata:905E4008                 extrn unk_905E4008      ; CODE XREF: sub_905E4422+6FC p
.idata:905E4008                                         ; DATA XREF: sub_905E4422+6FC r
.idata:905E400C                 extrn unk_905E400C      ; CODE XREF: sub_905E4422+22 p
.idata:905E400C                                         ; DATA XREF: sub_905E4422+22 r
.idata:905E4010
.idata:905E4014                 extrn unk_905E4014      ; CODE XREF: .rdata:905E4BAA p
.idata:905E4014                                         ; DATA XREF: .rdata:905E4BAA r
.idata:905E4018                 extrn unk_905E4018      ; DATA XREF: sub_905E4BB6 r
Analyze all funcrions with Windbg.

kd>u poi(905E4000) and rename in IDA.


Now Import looks like:


More comfortable. And. Driver allocates pool and didn't Free it.
Another interesting things is MmProtectMdlSystemAddress function.

NTSTATUS MmProtectMdlSystemAddress(
  __in  PMDLX MemoryDescriptorList,
  __in  ULONG NewProtect );
Push add symbolic constant and find READ_EXECUTE. Now peace of code is


Driver make Mdl from memory [ebp-80h] + 0x236, then Protect in as EXECUTE. And Call it later.
Interesting pool. How we can find it. Lets see another function for memory.

PVOID ExAllocatePoolWithTag(
  __in  POOL_TYPE PoolType,
  __in  SIZE_T NumberOfBytes,
  __in  ULONG Tag
);



Now we sure, that driver allocate this pool and put pointer to [ebp-80h].
We need to find this pool in memory, but pointer was in stack and driver lose it...
System don't lose it and we can find pool by TAG.

Params of ExAllocatePoolWithTag is

PoolType [in]
Specifies the type of pool memory to allocate. For a description of the available pool memory types, see POOL_TYPE.

NumberOfBytes [in]
Specifies the number of bytes to allocate.

Tag [in]
Specifies the pool tag for the allocated memory. Specify the pool tag as a character literal of up to four characters delimited by single quotation marks (for example, 'Tag1'). The string is usually specified in reverse order (for example, '1gaT'). The ASCII value of each character in the tag must be between 0 and 127. Each allocation code path should use a unique pool tag to help debuggers and verifiers identify the code path.

Reverse string order. So 0x4D646Ch  is 'Mdl', reverse it 'ldM'.Windbg again.
kd>!poolfind ldM

Nothing. Let's see all pools.
kd>!poolused

If you get error add c:\symserver;SRV*c:\symserver*http://msdl.microsoft.com/download/symbols to symbol path.
Sure ldM is exist.
ldM.        1      576         0        0 UNKNOWN pooltag ' ldM', please update pooltag.txt
Size 576 is 240 in hex. We allocate 0x238. 8 bytes it's header.
Another way to get pool is kd>!poolfind 0x004D646C
Again fail. Lets
kd>!poolfind 0x004D646C 0

8d4a9a60 size:  240 previous size:   30  (Allocated) ldM.

Ok. We find a pool. Dump it.
kd> .writemem d:\dumpnt2.exe 0x8d4a9a60 L?240

First 8 bytes is header. All another is code. Put it in IDA.


Inline Function without any import and with some data on stack. Execute it with IDA and Bochs.


Here is answer.

P.S. Encryption in binary was DES. Encryptoin in pool was xtea. 

No comments:

Post a Comment