RCE Messageboard's Regroupment - Blogs

POP SS and Debuggers

Arcane — Thu, 21 Aug 2008 20:14:28 GMT

This little trick is very interesting, my first encounter with it was in a commercial protection, it left me wondering why a Push / Pop SS would implicit execute the next instruction without the Debugger knowing of it, i.e. raising a single-step exception, so I�ve decided to look into it and try to figure out why, and I believe I have found the explanation , but first let me show you how this technique can be used to detect debuggers relying on the Single Step flag for tracing.

If a debugger executes something like this:

PUSHFD -> push Efflags to Stack .

debuggers such as Olly is kind enough to �shadow� itself, And clean the result produced by this instruction and removing the trap flag from the EFflags pushed to stack.

But if it�s done like this:

Push ss
pop ss
pushfd

Olly will not remove the trap flag, which is very interesting and leaves it very vulnerable to trace detection. The Explanation seems to be pretty straight forward if you check out the Intel manuals and look up pop , you will find a passage similar to this :

A POP SS instruction inhibits all interrupts, including the NMI interrupt, until after
Execution of the next instruction. This action allows sequential execution of POP SS
And MOV ESP, EBP instructions without the danger of having an invalid stack during
An interrupt1. However, use of the LSS instruction is the preferred method of loading
the SS and ESP registers.

Well most of this can be boiled down to , if POP SS is executed , the CPU will prevent triggering of interrupts , as to avoid corruption of the stack. So why on earth is this affecting us when we are tracing using the single-step flag, well simply because when the Single-step flag is set , it triggers and interrupt in the CPU , but when a POP SS is executed it won�t trigger interrupts before it has executed the next instruction after it , and thus olly will never get a single-step exception for the PUSHFD and won�t know it has been executed , and thus wont clean out the trap-flag and leave us vulnerable to detection.

Circumventing this trick , is tricky since simply patching it out is easy , but if implementet correctly it can prevent tracing of your code very effectively and be a pain in the ass.

Comments and suggestions , are always welcome

Fighting Oreans' VM (code virtualizer flavour)

_g_ — Tue, 19 Aug 2008 14:41:15 GMT

If you don't know what code virtualizer is, or how it works, you should read this first:
http://rapidshare.com/files/16968098/Inside_Code_Virtualizer.rar
(Inside Code Virtualizer by scherzo)

Now, as you probably already know from paper by scherzo ;), one possible way recover virtualized code is to identify each mutated handler (find corresponding non-mutated version). After this done, we can trace virtual opcodes and "decompile" them to VM instructions. Having "clean" decompiled output, we can translate it to x86 assembly. I consider the last step, to be simple "find and replace" job with flex/yacc.

The problem is, oreans' vm obfuscation engine can be a bitch. Consider this piece of code:

Code:

	push ebx 
	mov ebx 0F06h
	inc ebx 
	shr ebx 15h
	push ecx 
	mov ecx 6156h
	xor ebx ecx
	pop ecx 
	add ebx 4114h
	shl ebx 7
	push ecx 
	mov ecx 51351Ch
	xor ebx ecx
	pop ecx 
	add ebx edi
	mov eax [ebx]
	pop ebx 
	push 67E0h 
	mov [esp] edx
	mov edx 1
	and eax edx
	mov edx [esp]
	push edx 
	mov edx esp
	add edx 4
	add edx 4
	xchg edx [esp]
	pop esp 
	or eax eax
	push eax 
	mov eax 3B02h
	not eax 
	push ecx 
	mov ecx 0FFFFC3FFh
	sub eax ecx
	pop ecx 
	and [edi+1Ch] eax
	mov eax [esp]
	add esp 4
	push 3328h 
	mov [esp] ebx
	mov ebx [esp]
	push ecx 
	mov ecx esp
	add ecx 4
	add ecx 4
	xchg ecx [esp]
	pop esp

It's one of VM's handlers. Can you tell what it does? Me neither, so let's try to deobfuscate this crap.

It turns out that simple strategies like contant folding (http://en.wikipedia.org/wiki/Constant_folding), dead code elimination (http://en.wikipedia.org/wiki/Dead_code), peephole optimisation (find and replace :P) plus some stack cleaning ;), suffice to recover obfuscated code:

Code:

NEW = 47, OLD = 0, -47 lines removed
################################ NEXT ROUND ###########################
################################ original
push ebx 
mov ebx 00000f06 
inc ebx 
shr ebx 00000015 
push ecx 
mov ecx 00006156 
xor ebx ecx 
pop ecx 
add ebx 00004114 
shl ebx 00000007 
push ecx 
mov ecx 0051351c 
xor ebx ecx 
pop ecx 
add ebx edi 
mov eax [ebx ] 
pop ebx 
push 000067e0 
mov [esp ] edx 
mov edx 00000001 
and eax edx 
mov edx [esp ] 
push edx 
mov edx esp 
add edx 00000004 
add edx 00000004 
xchg edx [esp ] 
pop esp 
or eax eax 
push eax 
mov eax 00003b02 
not eax 
push ecx 
mov ecx ffffc3ff 
sub eax ecx 
pop ecx 
and [edi 0000001c ] eax 
mov eax [esp ] 
add esp 00000004 
push 00003328 
mov [esp ] ebx 
mov ebx [esp ] 
push ecx 
mov ecx esp 
add ecx 00000004 
add ecx 00000004 
xchg ecx [esp ] 
pop esp 
################################ after constant propagation and folding
push ebx 
mov ebx 00000000 
push ecx 
mov ecx 00006156 
xor ebx 00006156 
pop ecx 
add ebx 00004114 
shl ebx 00000007 
push ecx 
mov ecx 0051351c 
xor ebx 0051351c 
pop ecx 
add ebx edi 
mov eax [ebx ] 
pop ebx 
push 000067e0 
mov [esp ] edx 
mov edx 00000001 
and eax 00000001 
mov edx [esp ] 
push edx 
mov edx esp 
add edx 00000004 
add edx 00000004 
xchg edx [esp ] 
pop esp 
or eax eax 
push eax 
mov eax ffffc4fd 
push ecx 
mov ecx ffffc3ff 
sub eax ffffc3ff 
pop ecx 
and [edi 0000001c ] eax 
mov eax [esp ] 
add esp 00000004 
push 00003328 
mov [esp ] ebx 
mov ebx [esp ] 
push ecx 
mov ecx esp 
add ecx 00000004 
add ecx 00000004 
xchg ecx [esp ] 
pop esp 
################################ after dead code elimination
push ebx 
mov ebx 00000000 
push ecx 
xor ebx 00006156 
pop ecx 
add ebx 00004114 
shl ebx 00000007 
push ecx 
xor ebx 0051351c 
pop ecx 
add ebx edi 
mov eax [ebx ] 
pop ebx 
push 000067e0 
mov [esp ] edx 
and eax 00000001 
mov edx [esp ] 
push edx 
mov edx esp 
add edx 00000004 
add edx 00000004 
xchg edx [esp ] 
pop esp 
or eax eax 
push eax 
mov eax ffffc4fd 
push ecx 
sub eax ffffc3ff 
pop ecx 
and [edi 0000001c ] eax 
mov eax [esp ] 
add esp 00000004 
push 00003328 
mov [esp ] ebx 
mov ebx [esp ] 
push ecx 
mov ecx esp 
add ecx 00000004 
add ecx 00000004 
xchg ecx [esp ] 
pop esp 
################################ after peephole optimisation
push ebx 
mov ebx 00000000 
push ecx 
xor ebx 00006156 
pop ecx 
add ebx 00004114 
shl ebx 00000007 
push ecx 
xor ebx 0051351c 
pop ecx 
add ebx edi 
mov eax [ebx ] 
pop ebx 
push edx 
and eax 00000001 
pop edx 
or eax eax 
push eax 
mov eax ffffc4fd 
push ecx 
sub eax ffffc3ff 
pop ecx 
and [edi 0000001c ] eax 
pop eax 
push ebx 
pop ebx 
################################ after stack cleaning
mov ebx 00000000 
xor ebx 00006156 
add ebx 00004114 
shl ebx 00000007 
xor ebx 0051351c 
add ebx edi 
mov eax [ebx ] 
and eax 00000001 
or eax eax 
mov eax ffffc4fd 
sub eax ffffc3ff 
and [edi 0000001c ] eax 
NEW = 11, OLD = 47, 36 lines removed
################################ NEXT ROUND ###########################
################################ original
mov ebx 00000000 
xor ebx 00006156 
add ebx 00004114 
shl ebx 00000007 
xor ebx 0051351c 
add ebx edi 
mov eax [ebx ] 
and eax 00000001 
or eax eax 
mov eax ffffc4fd 
sub eax ffffc3ff 
and [edi 0000001c ] eax 
################################ after constant propagation and folding
mov ebx 0000001c 
add ebx edi 
mov eax [ebx ] 
and eax 00000001 
or eax eax 
mov eax 000000fe 
and [edi 0000001c ] 000000fe 
################################ after dead code elimination
mov ebx 0000001c 
add ebx edi 
mov eax [ebx ] 
and eax 00000001 
or eax eax 
and [edi 0000001c ] 000000fe 
################################ after peephole optimisation
mov ebx 0000001c 
add ebx edi 
mov eax [ebx ] 
and eax 00000001 
or eax eax 
and [edi 0000001c ] 000000fe 
################################ after stack cleaning
mov ebx 0000001c 
add ebx edi 
mov eax [ebx ] 
and eax 00000001 
or eax eax 
and [edi 0000001c ] 000000fe 
NEW = 5, OLD = 11, 6 lines removed
################################ NEXT ROUND ###########################
################################ original
mov ebx 0000001c 
add ebx edi 
mov eax [ebx ] 
and eax 00000001 
or eax eax 
and [edi 0000001c ] 000000fe 
################################ after constant propagation and folding
mov ebx 0000001c 
add ebx edi 
mov eax [ebx ] 
and eax 00000001 
or eax eax 
and [edi 0000001c ] 000000fe 
################################ after dead code elimination
mov ebx 0000001c 
add ebx edi 
mov eax [ebx ] 
and eax 00000001 
or eax eax 
and [edi 0000001c ] 000000fe 
################################ after peephole optimisation
mov ebx 0000001c 
add ebx edi 
mov eax [ebx ] 
and eax 00000001 
or eax eax 
and [edi 0000001c ] 000000fe 
################################ after stack cleaning
mov ebx 0000001c 
add ebx edi 
mov eax [ebx ] 
and eax 00000001 
or eax eax 
and [edi 0000001c ] 000000fe

Well almost ;). Above trash is the verbose output of my little "cleaner" tool. Cleaner is usable, it'll give nice results for most of included code samples. In handlers.clean folder (see link at bottom) there are nonmutated versions of CV handlers. After deobfuscation, few heuristics can be applied to match deobfuscated and clean versions: edit distance / rare instruction matching (for example rol, ror, rcr are rare and show up only in one handler).

The problem is, I got bored with all of this, so if anyone would like to help, I will be more than happy :)

Here is the code:
http://www.orange-bat.com/oreans.rar

compile with make, will work without problems under cygwin. it should work under linux. to use rip_handlers.py you will need idapython.

There are some bugs in my code, beware :p.

PEiD imports parsing DoS

_g_ — Tue, 19 Aug 2008 13:41:02 GMT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- - Orange Bat advisory -

Name : PEiD v0.94 exe File Parsing DoS
Class : DoS
Published : 2008-08-18
Credit : g_ (g_ # orange-bat # com)

- - Details -

When parsing .exe files, PEiD will allocate memory to hold the
file content. Size of this memory chunk will be divisible by
0x1000 (4KB). If the file size is a multiple of 4KB and if
the import table is located at the end of the file, import parsing
procedure could try to read data off the heap -- to check if
there are more valid import descriptors, memory pointer is advanced
without bounds checking and this leads to access violation:

.text:0043958B loc_43958B:
.text:0043958B mov eax, [esi+10h] ;Oooops!
.text:0043958E add esi, 14h
.text:00439591 cmp eax, ebx
.text:00439593 mov [esp+60h+var_4C], esi
.text:00439597 jnz loc_4393FE

Exe file can still run normally after modifing the IAT btw, see POC.

- - Proof of concept -

http://www.orange-bat.com/adv/2008/poc.08.18.peid.rar

- - PGP -

All advisories from Orange Bat are signed. You can find our public
key here: http://www.orange-bat.com/g_.asc

- - Disclaimer -

This document and all the information it contains is provided "as is",
without any warranty. Orange Bat is not responsible for the
misuse of the information provided in this advisory. The advisory is
provided for educational purposes only.

Permission is hereby granted to redistribute this advisory, providing
that no changes are made and that the copyright notices and
disclaimers remain intact.

(c) 2008 www.orange-bat.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32) - GPGshell v3.70

iEYEARECAAYFAkiokJkACgkQIUHRVUfOLgUCcgCgxI1B4xeCqOV8prG6CisbRcTV
ZZ8An1HSq/W4+Gx6gI9UeNCPqgwmo6jU
=Ddln
-----END PGP SIGNATURE-----

Nucleus Framework

OHPen — Sun, 17 Aug 2008 17:09:21 GMT

I just released the initial release of nucleus framework. You have to decide if you like it :)

OHPen

Attached Files

nucleus_v1.0.0012.0846.rar (153.6 KB, 233 views)

SoftICE and KDExtensions

deroko — Thu, 14 Aug 2008 03:31:20 GMT

Well I was writing one extension for softice, and I faced one serious problem which in turn might not be that big problem if softice authors decided to write softice code properly at some points. SoftICE manual doesn't provide us with concept how to write KDExtensions, but in turn it gives us tools which we might use to convert existing windbg extensions into softice extension. One of rules is that we may not use Exception Handling in KDExtension (taken from SoftICE manual), and silently it refuses usage of many exports from ntoskrnl.exe...

KD2SYS.exe works simply by adding extra code to your dll, and changing it's entrypoint to code which looks like this:

Code:

.1000147F: B800000000                     mov         eax,0
.10001484: C20800                         retn        8
.10001487: 0010                           add         [eax],dl
.10001489: 0000                           add         [eax],al

when extension is loaded, it MUST have Debug symbols so softice will know that it should check EntryPoint for mov eax, 0/retn 8 using INT 2D (during driver loading ntoskrnl.exe will call -> DbgLoadImageSymbols which in turns will call int 2D, hooked by SoftICE which will examine entrypoint of driver and substitute mov eax, 0 with jmp __softice_code which will in turn call DllEntryPoint.

Code:

PAGE:004D7D27                 push    dword ptr [edi] ; ImageBase
PAGE:004D7D29                 call    _CacheImageSymbols@4 ; CacheImageSymbols(x)   
PAGE:004D7D2E                 test    eax, eax
PAGE:004D7D30                 jz      __no_debug_symbols

Upper code shows part of ntos which checks if Debug directory is used, and after that it will call DbgLoadImageSymbols.

If you take a look at upper Disassm code, you may see that right after retn 08 is stored : 1000h which is RVA of DllEntryPoint... You may examine a little bit hook of int2D and you will see how loading of KD takes place in SoftICE, not a nuclear physics as you may trace Int2D hook in SoftICE without a problem, as it will be running at PASSIVE_LEVEL (level at which drivers are being loaded).

Next step is to create such driver that will have similar if not the same code which will be handld by SoftICE. My walkaround was to define DriverEntry in asm code like this:

Code:

extern                  DllEntryPoint@12:dword 
public  C               DriverEntry@8

DriverEntry@8:          mov     eax, 0
                        ret     8
                        dd      0FFFFFFFFh
                        dd      offset DllEntryPoint@12

Also make sure that TARGETTYPE=MINIPORT to link directly with DriverEntry@8 as your entrypoint, as DRIVER type will link using GsDriverEntry:

Code:

INIT:00011185                 public GsDriverEntry
INIT:00011185 GsDriverEntry   proc near
INIT:00011185                 mov     edi, edi
INIT:00011187                 push    ebp
INIT:00011188                 mov     ebp, esp
INIT:0001118A                 mov     eax, __security_cookie
INIT:0001118F                 test    eax, eax
...
INIT:000111B8                 mov     __security_cookie_complement, eax
INIT:000111BD                 pop     ebp
INIT:000111BE                 jmp     DriverEntry

Which is not what I want...

Next step is to write convert.c/asm code which will:

1. open your file
2. locate entry point
3. calculate relative offset of DllEntryPoint
4. store it in placess of 0FFFFFFFF
5. update checksum
6. save changes :)

Now you may have neet extension (at least that's how I write them). Kayaker probably has better solution :p

Now comes funn part which I figgured after making dump of whole memory in VMWare, as minidump wasn't enough for me.

I tried to call some procedures which require dropping of IRQL like ExAllocatePool, which will eventually endup in ExAcquireQueuedSpinLock, which will drop IRQL to DISPATCH_LEVEL. I've started receiving numerous BSODs, and I tought that IRQL was an issue... and those BSODs occured only, and only when I was breaking in softice from ring3 applications, so I figured something had to be wrong, but in my wildest dreams I wouldn't suspect that solution was that stupid...

Let's have a look at code responsible for calling KDExtension in softice:

Code:

.text:A7AB9D3A si_callExtension proc near             
.text:A7AB9D3A
.text:A7AB9D3A ExtensionApi    = dword ptr  8
.text:A7AB9D3A hCurrentProcess = dword ptr  0Ch
.text:A7AB9D3A hCurrentThread  = dword ptr  10h
.text:A7AB9D3A dwCurrentPc     = dword ptr  14h
.text:A7AB9D3A dwProcessor     = dword ptr  18h
.text:A7AB9D3A args            = dword ptr  1Ch
.text:A7AB9D3A
.text:A7AB9D3A                 push    ebp
.text:A7AB9D3B                 mov     ebp, esp
.text:A7AB9D3D                 push    ds
.text:A7AB9D3E                 push    es
.text:A7AB9D3F                 push    fs
.text:A7AB9D41                 push    gs
.text:A7AB9D43                 pusha
.text:A7AB9D44                 pushf
.text:A7AB9D45                 mov     edi, kd_extension_esp_start
.text:A7AB9D4B                 mov     ecx, kd_extension_stack_size
.text:A7AB9D51                 shr     ecx, 2
.text:A7AB9D54                 xor     eax, eax
.text:A7AB9D56                 cld
.text:A7AB9D57                 rep stosd
.text:A7AB9D59                 cli
.text:A7AB9D5A                 mov     save_sice_esp, esp
.text:A7AB9D60                 mov     save_sice_ebp, ebp
.text:A7AB9D66                 mov     ErrorString_to_display, 0
.text:A7AB9D70                 mov     si_extension_aborted_pagefault, 0
.text:A7AB9D77                 mov     b_extension_executing, 1
.text:A7AB9D7E                 mov     dl, 1
.text:A7AB9D80                 call    Install_Reinsall_DivideOverflowHandler
.text:A7AB9D85                 mov     esp, kd_extension_esp
.text:A7AB9D8B                 sti
.text:A7AB9D8C                 mov     fs, word ptr kd_extension_fs 
.text:A7AB9D92                 call    sub_A7AB9C86    
.text:A7AB9D97                 push    [ebp+args]
.text:A7AB9D9A                 push    [ebp+dwProcessor]
.text:A7AB9D9D                 push    [ebp+dwCurrentPc]
.text:A7AB9DA0                 push    [ebp+hCurrentThread]
.text:A7AB9DA3                 push    [ebp+hCurrentProcess]
.text:A7AB9DA6                 call    [ebp+ExtensionApi]
.text:A7AB9DA9 loc_A7AB9DA9:                           
.text:A7AB9DA9                 cli
.text:A7AB9DAA                 mov     esp, save_sice_esp
.text:A7AB9DB0                 mov     ebp, save_sice_ebp
.text:A7AB9DB6                 mov     b_extension_executing, 0
.text:A7AB9DBD                 call    restore_SEH
.text:A7AB9DC2                 xor     dl, dl
.text:A7AB9DC4                 call    Install_Reinsall_DivideOverflowHandler
.text:A7AB9DC9                 sti
.text:A7AB9DCA                 mov     edi, kd_extension_esp_start
.text:A7AB9DD0                 mov     ecx, kd_extension_stack_size
.text:A7AB9DD6                 shr     ecx, 2
.text:A7AB9DD9                 xor     eax, eax
.text:A7AB9DDB                 cld
.text:A7AB9DDC                 repe scasd
.text:A7AB9DDE                 mov     eax, ecx
.text:A7AB9DE0                 inc     eax
.text:A7AB9DE1                 shl     eax, 2
.text:A7AB9DE4                 popf
.text:A7AB9DE5                 popa
.text:A7AB9DE6                 pop     gs
.text:A7AB9DE8                 pop     fs
.text:A7AB9DEA                 pop     es
.text:A7AB9DEB                 pop     ds
.text:A7AB9DEC                 pop     ebp
.text:A7AB9DED                 retn    18h
.text:A7AB9DED si_callExtension endp

Now comes funny part, really funny part!!!!

Code:

.text:A7AB9D8C                 mov     fs, word ptr kd_extension_fs

This is not kd_extension_fs, this is FS of interupted TASK!!!!!!!!!! So if you are debugging ring3 code, KDExtension will be called with FS = 0x3B which points to TEB instead of KPCR, what most exports from ntoskrnl.exe will expect it to be!!! Of course, this is not the problem when you interupt TASK which is running in ring0, but I want my extension to work the same way no matter if interupted task is in ring0 or ring3.

That's the reason why KeSetEvent, ExAllocatePool, KeInsertQueueDpc and many, many others will fail, as those at some point expect FS to point to KPCR instead of TEB!

My solution was to create 2 functions, and call them, one at the beginning of exported function, and one at the end:

Code:

ULONG   old_fs;
void    set_fs()
{
        __asm{
                xor     eax, eax
                mov     ax, fs
                mov     old_fs, eax
                mov     eax, 30h
                mov     fs, ax
        }
}

void    restore_fs()
{
        __asm{
                mov     eax, old_fs
                mov     fs, ax
        }
}

Although those seem like not safe functions, remember that softice uses NMI to suspend all other CPUs while it works, so this code is absolutely safe, as all other CPUs are stoped while SoftICE code is executing (at least it seems so), and current CPU is executing at HIGH_IRQL so no synchronization is required with global varaibla, as softice ensurs that only one thread can touch it :)

Does anyone remember this exception in SoftICE window when dumping memory from ring3 process using IceExt?

Code:

A page fault at CS:EIP 0008:12345678 occurred when address 12345678 was referenced SS:EBP 0010:12345678

Well here is the answer why it occurs :sneaky: FS is wrongly set by SoftICE :sneaky:

Inside DeleteFiber() as Anti Debug Trick

evilcry — Thu, 31 Jul 2008 12:41:21 GMT

Hi,

Malware is often really boring to reverse because in high percentage they implements basical well known mechanisms of infection and self protection.
But sometimes there are really intersting malware that implements innovative techniques, this is the case of a trojan borned into 2006 that implemented DeleteFiber() as Anti�Debug Trick in a really easy and smart way.

To understand how it works, let's see whar DeleteFiber is, directly from MSDN:

Deletes an existing fiber.

Syntax

Code:

VOID WINAPI DeleteFiber(
  __in  LPVOID lpFiber
);

lpFiber is the address of the fiber to be deleted.

Important to say that the DeleteFiber function deletes all data associated with the fiber. This data includes the stack, a subset of the registers, and the fiber data.

Now let's see a basical use of DeleteFiber():

Code:

#define _WIN32_WINNT 0x0400
#include 

int main(void)
{
	char fiber[1024] = {0};		
	DeleteFiber(fiber);	
	return EXIT_SUCCESS;
}

After showing the basical use of DeleteFiber let's see how can be implemented as Anti-Debug Trick, I insert here direcly the code:

Code:

#define _WIN32_WINNT 0x0400
#include 
#include 

int main(void)
{
      char fib[1024] = {0};	
	DeleteFiber(fib);

	if(GetLastError() == 0x00000057)
		MessageBoxA(NULL,"This process is NOT debugged","Info",MB_OK);
	else
		MessageBoxA(NULL,"This process IS debugged","Info",MB_OK);
	
	
	return EXIT_SUCCESS;
}

As you can understant we can resume this trick into two cases:

If the process is NOT debugged DeleteFiber give us an Error Code of 0x00000057 that corresponds to ERROR_INVALID_PARAMETER
If the process IS debugged the error code is differs from 0x00000057

What to say it's really easy to implement and really effective for all kind of debuggers, with a bit of junk code that confuses ideas the conditional check could be placed really distant from the DeleteFiber() itself.

Inside DeleteFiber()

Now we will see how DeleteFiber internally works to understand why this should be used as Anti-Debug trick.

This is the Dead List:

Code:

00401000  PUSH DF.00403370
00401005  CALL DWORD PTR DS:[<&KERNEL32.DeleteFiber>;  kernel32.DeleteFiber

inside DeleteFiber()

7C825A9F >   MOV EDI,EDI          ; DF.00403778
7C825AA1     PUSH EBP
7C825AA2     MOV EBP,ESP
7C825AA4     PUSH ECX
7C825AA5     PUSH ESI
7C825AA6     MOV EAX,DWORD PTR FS:[18]     ;_TEB Struct
7C825AAC     MOV ECX,DWORD PTR DS:[EAX+10] ;pointer to _TIB.FiberData field
7C825AAF     MOV ESI,DWORD PTR SS:[EBP+8]  ;lpFiber
7C825AB2     CMP ECX,ESI
7C825AB4     JE kernel32.7C826596          ;ExitThread if( FiberData == lpfiber)
7C825ABA     AND DWORD PTR SS:[EBP-4],0    ;Clears this Stack location
7C825ABE     PUSH 8000                     ;MEM_RELEASE
7C825AC3     LEA EAX,DWORD PTR SS:[EBP-4]  
7C825AC6     PUSH EAX
7C825AC7     LEA EAX,DWORD PTR DS:[ESI+10]
7C825ACA     PUSH EAX
7C825ACB     PUSH -1
7C825ACD     CALL DWORD PTR DS:[<&ntdll.NtFreeVirtual>  ntdll.ZwFreeVirtualMemory
7C825AD3     MOV EAX,DWORD PTR FS:[18]        ;_TEB Struct
7C825AD9     MOV EAX,DWORD PTR DS:[EAX+30]    ;points to _PEB Struct
7C825ADC     PUSH ESI                         ;lpFiber
7C825ADD     PUSH 0                           ;0x00000000
7C825ADF     PUSH DWORD PTR DS:[EAX+18]       ;PEB.ProcessHeap
7C825AE2     CALL DWORD PTR DS:[<&ntdll.RtlFreeHeap>] ; ntdll.RtlFreeHeap
7C825AE8     POP ESI
7C825AE9     LEAVE
7C825AEA     RETN 4

In the first part of DeleteFiber is retrived the _TEB structure and specifically a member of _TIB structure located at 10h

0:003> dt nt!_TEB -b
ntdll!_TEB
+0x000 NtTib : _NT_TIB
+0x000 ExceptionList : Ptr32
...
+0x00c SubSystemTib : Ptr32
+0x010 FiberData : Ptr32

and next if FiberData is equal to our Fiber's Address it means that Fiber is suicinding itself and system calls ExitThread(), next we can notice a NtFreeVirtualMemory call with the following parameters:

Code:

NtFreeVirtualMemory(NtCurrentProcess(), &pStackAllocBase,&nSize,MEM_RELEASE);

The system deallocates the used stack and finally calls RtlFreeHeap in this manner:

Code:

RtlFreeHeap(GetProcessHeap(), 0, lpFiber);

This last call clarifies totally the presence of ERROR_INVALID_PARAMETER because has we have seen DeleteFiber is directly correlated with Heap, and Heap Memory presents a set of Flags that characterize the Heap itself.
These Flags differs in case the process IS debugged or NOT, so we can suppose that these flags are created when the exe itself is executed, in other words at Process Creation Time. Under Windows NT processes are created through PspUserThreadStartup and inside it we can found LdrInitializeThunk, that as Russinovich sais The LdrInitializeThunk routine initializes the loader, heap manager, NLS tables, thread-local storage (TLS) array, and critical section structures. By going more deep we can see that there is a specific function that fill the PEB Struct of the new process MmCreatePeb(), PEB is important because between his various fields are stored Heap Flags of our process. I'm talking about NtGlobalFlag, for a debugged process these flags are:

#define FLG_HEAP_ENABLE_TAIL_CHECK 0x00000010
#define FLG_HEAP_ENABLE_FREE_CHECK 0x00000020
#define FLG_HEAP_VALIDATE_PARAMETERS 0x00000040

Now if a process has these flags enabled ( HeapDebug ) RtlFreeHeap will fail the Heap freeing and this error will be propagated to DeleteFiber() that will exit with an ERROR_INVALID_PARAMETER.

Anti Anti-Debug

Due to the fact that the Heap Validation is accomplished at Processs Creation Time, one countermeasure against Anti-Debug will be to attach the debugger after that the process is created.
If you are using WinDbg could be used the HeapDebug option ( -hd )
Between the function involved in process creation we have also LdrQueryImageFileExecutionOptions that mantains trace of IFEO ( Image File Execution Options structure) this struct is located into Registry under the path [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\]
The various possible values are:
Debugger
DisableHeapLookaside
ShutdownFlags
MinimumStackCommitInBytes
ExecuteOptions
GlobalFlag
DebugProcessHeapOnly
ApplicationGoo
RpcThreadPoolThrottle
GlobalFlag can be used to modify NtGlobalFlag, so if you set this key entry to NULL, Heap of the debugged program will looks as an undebugged one, read this as an Anti-Anti Debug Trick :).

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Target.exe]
"GlobalFlag"=""

Regards,
Giuseppe 'Evilcry' Bonfa'

Inside SetUnhandledExceptionFilter

evilcry — Sat, 26 Jul 2008 07:44:14 GMT

Hi,

SetUnhandledExceptionFilter() is frequently used as Anti Debug Trick, especially in Malware Applications. Around here there are various plugins for Olly that allows the Reverser to trasparently debug this kind of protection, so there is not a real necessity add other words about the mere practical part of trick overcoming.

Due to the fact that today, too many young reversers uses a ton of plugins anti - anti - xxx without knowing how internally they works, I decided to expose here a little summary of SetUnhandledExceptionFilter Internal characteristics.

First of all, what SetUnhandledExceptionFilter is? according to MSDN documentation:

Enables an application to supersede the top-level exception handler of each thread of a process.

After calling this function, if an exception occurs in a process that is not being debugged, and the exception makes it to the unhandled exception filter, that filter will call the exception filter function specified by the lpTopLevelExceptionFilter parameter.

And this is the Syntax:

Code:

LPTOP_LEVEL_EXCEPTION_FILTER WINAPI SetUnhandledExceptionFilter(
__in  LPTOP_LEVEL_EXCEPTION_FILTER lpTopLevelExceptionFilter
);

lpTopLevelExceptionFilter is a pointer to top-level exception filter function that will be called whenever the UnhandledExceptionFilter function gets control, and the process is not being debugged. A value of NULL for this parameter specifies default handling within UnhandledExceptionFilter.

Usually, in absence of an UnhandledExceptionFilter the topmost handler called when an uncatched exception occours, is the default one provided by Windows Itself, the classical MessageBox that advices the user that an Unhandled Exception has occured.

But Windows allow programs to use custom Handlers for UnhandledException. The core of the trick is here, if the application is NOT debugged, the application is able to call the Custom Handler, but if the application IS debugged the Custom Handler will be never called.

The possibility of cognitive differentiation make obviously able the target application to apply a series of countemeasures against debugging, from detection to code hidding.

Just remember that due to the architecture of Windows Exception Handling, in every case is called UnhlandledExceptionFilter() function, and this will our point of attack (for anti - anti dbg trick).

This is the general inner meccanism of SetUnhandledExceptionFilter(), going more deep we observe the call stack of the first thread of any Win32 application, we can see that execution in every case is reported to BaseProcess, here the pseudo definition:

Code:

VOID BaseProcessStart( PPROCESS_START_ROUTINE pfnStartAddr )
{
    __try
    {
        ExitThread( (pfnStartAddr)() );
    }
    __except( UnhandledExceptionFilter( GetExceptionInformation()) )
    {
        ExitProcess( GetExceptionCode() );
    }
}

The same thing happens for threads, by referencing to BaseThreadStart:

Code:

VOID BaseThreadStart( PTHREAD_START_ROUTINE pfnStartAddr, PVOID pParam )
{
    __try
    {
        ExitThread( (pfnStartAddr)(pParam) );
    }
    __except( UnhandledExceptionFilter(GetExceptionInformation()) )
    {
        ExitProcess( GetExceptionCode() );
    }
}

All that happens inside BaseProcessStart() and BaseThreadStart() for what previously said, will be passed to the UnhandledExceptionFilter().

It�s now time to see what really is UnhandledExceptionFilter(), according to MSDN:

An application-defined function that passes unhandled exceptions to the debugger, if the process is being debugged. Otherwise, it optionally displays an Application Error message box and causes the exception handler to be executed. This function can be called only from within the filter expression of an exception handler.

Syntax:

Code:

LONG WINAPI UnhandledExceptionFilter(
  __in  struct _EXCEPTION_POINTERS *ExceptionInfo
);

Became clear that UnhandledExceptionFilter represents the last choise for processing unhandled exceptions, so the Check Debugger Presence surely is located inside this function, let�s see a simplified version of this function:

Code:

LONG UnhandledExceptionFilter( EXCEPTION_POINTERS* pep )
{
    DWORD rv;

    EXCEPTION_RECORD* per = pep->ExceptionRecord;

    if( ( per->ExceptionCode == EXCEPTION_ACCESS_VIOLATION ) &&
         ( per->ExceptionInformation[0] != 0 ) )
    {
        rv = BasepCheckForReadOnlyResource( per->ExceptionInformation[1] );

        if( rv == EXCEPTION_CONTINUE_EXECUTION )
            return EXCEPTION_CONTINUE_EXECUTION;
    }

    DWORD DebugPort = 0;

    rv = NtQueryInformationProcess( GetCurrentProcess(), ProcessDebugPort,
                                    &DebugPort, sizeof( DebugPort ), 0 );

    if( ( rv >= 0 ) && ( DebugPort != 0 ) )
    {
        // Yes, it is -> Pass exception to the debugger
        return EXCEPTION_CONTINUE_SEARCH;
    }

    // Is custom filter for unhandled exceptions registered ?

    if( BasepCurrentTopLevelFilter != 0 )
    {
        // Yes, it is -> Call the custom filter

        rv = (BasepCurrentTopLevelFilter)(pep);

        if( rv == EXCEPTION_EXECUTE_HANDLER )
            return EXCEPTION_EXECUTE_HANDLER;

        if( rv == EXCEPTION_CONTINUE_EXECUTION )
            return EXCEPTION_CONTINUE_EXECUTION;
    }   

}

As you can see, inside UnhandledExceptionFilter() is called NtQueryInformationProcess() that has as first parameter our process and next DebugPort, this is done to know if the process is debugged.

All that we have to do to obtain an apparently undebugged process is to modify the first parameter (last pushed at debugging time), in other words we have to change the retur value of GetCurrentProcess() from 0xFFFFFFFF to 0�00000000.

So remember, when you have to overcome a SetUnhandledExceptionFilter() just put a Breakpoint for UnhandledExceptionFilter() and go inside this function to modify the previously exposed parameter :)

Thanks to Oleg Starodumov for pseudocodes :)

See you to the next blog post.. :)

Small Devices & RCE

Daniel Pistelli — Fri, 25 Jul 2008 13:47:18 GMT

Didn't want to go off-topic in the other thread, that's why I'm opening a new one. I wanted to add some thoughts about the IDA-on-IPhone news.

Quote:

Good news for real iPhone fans: we ported IDA to iPhone! It can handle any application and provides the same analysis as on other platforms. It is funny to see IDA on a such small device:

http://hexblog.com/2008/07/ida_on_iphone.html

Ilfak Guilfanov

I think it's awesome.

It's also funny, because in theory the new CFF Explorer will be compilable for mac os (being written in Qt), thus also IPhone. The only problem is the small display of such devices and I'm not sure if there's a possibility to reduce the needed space, but I'm quite optimistic.

I mention this because the new CFF Explorer will support elf and other formats (lib, object, symbian etc), making it useful also for other systems and it might become part of a new generation of cross platform/device tools. It would be encouraging to know that in the future it will be possible to do reversing stuff on such a small device. The new CFF will also have zoom in/out features for the hex editor, making it very useful on devices with a small (or big) display.

I hope that other programmers will follow the same lead.

The main problem is writing cross platform applications and reorganizing GUIs for small displays.

I want to share something I read on wikipedia some time ago:

Quote:

Microsoft software is also presented as a "safe" choice for IT managers purchasing software systems. In an internal memo for senior management Microsoft's head of C++ development, Aaron Contorer, stated:[7]

�The Windows API is so broad, so deep, and so functional that most Independent Software Vendors would be crazy not to use it. And it is so deeply embedded in the source code of many Windows apps that there is a huge switching cost to using a different operating system instead... It is this switching cost that has given the customers the patience to stick with Windows through all our mistakes, our buggy drivers, our high TCO (total cost of ownership), our lack of a sexy vision at times, and many other difficulties [...] Customers constantly evaluate other desktop platforms, [but] it would be so much work to move over that they hope we just improve Windows rather than force them to move. In short, without this exclusive franchise called the Windows API, we would have been dead a long time ago.

Companies such as Apple and Microsoft are very conscious of the strategic importance of hard binding applications to their propretary API. That's why Apple pushes cocoa and Microsoft .NET. They don't want cross platform development environments (oh and don't tell me that .NET is cross-platform, before doing so, show me a .NET GUI with more than a button in it on a system which isn't Windows), because it would make possible for users to switch to another system without losing his tools.

However, "the times they are a changin'". Nowadays, developers are more conscious about this problem and prefer not to bind their application to only one platform. You can notice this if you pay attention to the names of newer applications. Ten years ago there were lots of windows applications which contained the word "win" in them. Winhex, WinDvd, Winzip, WinRar, WinAce, Winamp etc. etc. etc. Have you noticed that this trend has stopped? It's interesting, right now a struggle between developers and OS producers is taking place. OS producers want to ever more bind (even more than before) developers to their platform. Why do I say more than before? Well, consider that .NET implements its own languages, you can't simply share real C++ code with the managed one (yes, you can rely on pinvoke, but not for everything). Well, it's a bit more complicate than that, I know, but unsafe code is not encouraged in the .NET environment. Meanwhile, Apple pushes Obj-C. I want to know how this ends. Speaking for myself, I refuse to take a side and will stick with my beloved C++ (the real one).

I hope this post won't generate a big controversy like the one about Windows Vista.

SymbolFinder

deroko — Sat, 19 Jul 2008 16:16:20 GMT

Dunno if this is just me or this is for real, but if someone tries to google for some kind of example of symbol lister it will endup in dead-end (maybe I should work on my google skils :devil:), anyway, I spent last 2 days playing and figuring these symbols (great MS simply points in MSDN to PDB documentation... where is that thing!??!!?), to write this enum, struct, symbol lister and decided to share my source so there can be at least one refference on how to list and parse symbols...

http://deroko.phearless.org/SymbolFinder.rar

Hope someone will find it usefull :)

Sun VirtualBox Disassembler Explantation

OHPen — Tue, 15 Jul 2008 19:55:19 GMT

Hey,

because i needed a good disassembler for my projects i check different distributions in the internet. most of them are homebrew and the support, or lets better talk about MAINTAINANCE is in most cases not the best.

I really hate it if use a component and realize that there is a bug and the releaser of the component is not able to fix it or sometimes has no real interest in fixing it. That sucks.

Thats why i focused on a disassembler which is well maintained and last but not least a good one.

During my search i stumbled over VirtualBox, which is an similar SUN implementation of VMWARES Workstation. The difference is that VirtualBox comes with source, or at least you can download the source ( http://www.sun.com/software/products/virtualbox/get.jsp ).

I thought that the pretty sure have to have an working disassembler inside there virtual machine and bingo....they have.
The problem was that the disassembler was not contained in form of a library, it was simple integrated in the source.

It took me about 2 hours to explant the needed source parts out of virtualbox and built a project for a library for it.

I now use it for my projects and it is very usefull for me.

There is only one problem you will discover when you try the example. I looking forward for your solutions for the problem :)

Regards,

OHPen aka PAPiLLiON

Attached Files

VirtualBoxDisassembler.rar (392.5 KB, 182 views)

CartellaUnicaTasse.exe Italian Malware RCE Analysis

evilcry — Tue, 15 Jul 2008 14:25:33 GMT

Hi,
I've just released a paper into my website about the RCE Analysis of an italian Downloader :)

Paper can be reached here:

http://evilcry.altervista.org/tuts/Mw/CartellaUnicaTasse.pdf

if this link does not works, just reach it from the home of my website.

Regards,
Evilcry

Why is secure development so important?

TiGa — Thu, 10 Jul 2008 00:31:11 GMT

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...

pde/pte softice plugin

deroko — Tue, 08 Jul 2008 17:30:36 GMT

Today I needed to verify some bits in PDE/PTE from SoftICE (well while I'm debugging) so I wrote one plugin for softice which will give me all needed information about pde/pte for a given address. Note that this is for PAE systems as I'm using PAE mainly... maybe I'll update it for non pae systems someday. Anyway, source is included :)

http://deroko.phearless.org/pdepte.rar

Funny coded malware

ZaiRoN — Thu, 03 Jul 2008 17:58:54 GMT

Some days ago I had the opportunity to check one of the last msn malware. I think there�s often something interesting inside a malware, no matter what it does and this is a perfect example!

The malware is able to infect only right handed people! I�m not kidding...
Among all the windows settings there�s one made for left handed people. The option I�m referring to is located under the Mouse control panel, labelled �Switch primary and secondary buttons�. It lets you exchange the functions performed by the right and left mouse button. Don�t know if this setting is usefull or not, most of the left handed friends I have are still using the mouse like a right handed. Maybe they don�t even know the existence of such an option. Anyway, look at this code:

It�s a simple query on a registry key named SwapMouseButtons.
result_value is sent back to the caller, and the caller checks the value. If the value is equal to 0�30 (right handed) the malware goes on running the rest of the code, but if the value is 0�31 (left handed) the malware ends immediately. All the nasty things performed by the malware are executed after this check, it means that a left handed won�t get infected!

I�ve seen some malwares using SwapMouseButton function in the past, but never something like that. I bet the author is left handed and he wrote the check just to be sure to avoid a possible infection� I can�t think of anything else. Quite funny!!!

The malware is not really interesting per se, but it has something I�ve never noticed before. It�s not a cool and dangerous new technique, but a coding behaviour. Look at the graph overview:

The image represents the content of a malware procedure. Nothing strange per se, except the fact that it contains 657 instructions in it, too many for a simple malware. It�s a big routine and I was surprised at first because you can do a lot of things with so many instructions. I started analysing the code, nothing is passed to the routine and nothing is returned back to the original caller. I tought it should be an important part of the malware, but I was disappointed by the real content of the routine. After few seconds I realized what�s really going on: 657 lines of code for doing something that normally would require around 50 lines�
The function contains a block of 17 instructions repeated 38 times. When I�m facing things like that I always have a little discussion with my brain. The questions are:
- why do you need to repeat each block 38 times?
- can�t you just use a while statement?
- is this a sort of anti-disassembling trick?
- can you produce such a procedure setting up some specific compiler�s options?

The repeated block contains the instruction below:

Code:

00402175    push 9                       ; Length of the string to decrypt
00402177    push offset ntdll_dll        ; String to decrypt
0040217C    push offset aM4l0x123456789  ; key: "M4L0X123456789"
00402181    call sub_401050              ; decrypt "ntdll.dll"
00402186    add  esp, 0Ch
00402189    mov  edi, eax
0040218B    mov  edx, offset ntdll_dll
00402190    or   ecx, 0FFFFFFFFh
00402193    xor  eax, eax
00402195    repne scasb
00402197    not  ecx
00402199    sub  edi, ecx
0040219B    mov  esi, edi
0040219D    mov  eax, ecx
0040219F    mov  edi, edx
004021A1    shr  ecx, 2
004021A4    rep movsd
004021A6    mov  ecx, eax
004021A8    and  ecx, 3
004021AB    rep movsb

It�s only a decryption routine, nothing more. The string is decrypted by the �call 401050″, the rest of the code simply moves the string in the right buffer.
Ok, let�s try answering the initial questions.

According to some PE scanners the exe file was produced by Microsoft Visual C++ 6.0 SPx.
It�s possible to code the big procedure just using a loop (while, for, do-while) containing the snippet above. I don�t think the author used one of these statements because as far as I know it�s not possible to tell the compiler to explode a cycle into a sequence of blocks. At this point I have to options:
- he wrote the same block for 38 times
- he defined a macro with the block�s instructions repeating the macro for 38 times
I won�t code something like that, but the macro option seems to be the most probable choice.
Is it an anti-disassembling trick? My answer is no because it�s really easy to read such a code. You don�t have to deal with variables used inside a for/while; to understand what�s going on you only have to compare three or four blocks.
I don�t have a valid answer to the doubt I had at first�.

Trying to find out some more info I studied the rest of the code. I was quite surprised to see another funny diagram.

This time the image represents the content of the procedure used to retrieve the address of the API functions. Again, no while/for/do-while statement. The rectangle on the upper part of the image it�s a sequence of calls to GetProcAddress, and the code below it�s just a sequence of checks on the addresses obtained by GetProcAddress.
It�s a series of:

address = GetProcAddress(hDLL, "function_name");

followed by a series of:

if (!address) goto _error;

Apart the non-use of a loop there�s something more this time, something that I think reveals an unusual coding style; tha author checks errors at the end of the procedure. I always prefer to check return values as soon as I can, it�s not a rule but it�s something that help you to avoid oversight and potential errors� The procedure has a little bug/oversight at the end, the author forgot to close an opened handle. Just a coincidence?
Anyway, two procedures without a single loop. Seems like the author didn�t use any kind of loop for choice. In case you still have some doubts here�s another cool pictures for you:

The routine inside the picture contains the code used to check if the API(s) are patched or not. The check is done comparing the first byte with 0xE8 and 0xE9 (call and jump). If the functions are not patched the malware goes on, otherwise it ends. As you can see no loops are used.

In summary: it�s not jungle code, it�s not an anti-disasm code and it�s not a specific compiler setting. I think it�s only a personal choice, but I would really like to know why the author used this particular style.
Do you have any suggestions?

Beyond the coding style, the malware has some more strange things. As pointed out by *asaperlo*, the code contains a bugged RC4 implementation.
It also has a virtual machine check. The idea is pretty simple, the malware checks the nick of the current user. If the nick is �sandbox� or �vmware� you are under a virtual machine�
This malware spawns another one (it�s encrypted inside the file), it might be material for another post.

That�s a funny coded malware for sure!

antisptd

smoke — Tue, 01 Jul 2008 20:21:56 GMT

antisptd is a driver that makes it possible for softice to load when sptd.sys is present. It uses the method described by Kayaker and that is, by removing the notifyroutine sptd sets to prevent ntice.sys to load. After ntice.sys gets loaded, it restores the notifyroutine and the keyboard hooks in i8042prt.sys that have been screwed by the sptd.sys.

Usage:
Just put the startsi.exe in a directory with antisptd.sys and execute startsi.exe.

Compatibility:
The driver should work on XP SP2/SP3 with the latest softice installed. I have no idea if it'll work on XP SP1 (cause I have used hardcoded values to locate the patch locations in i8042prt.sys). If it doesnt work, feel free to modify the sources and recompile the driver yourself. ;)

Attached Files

antisptd.rar (10.4 KB, 164 views)