Recent Blogs Posts

Dataflow-0.2.0 is now available

After month of development new features are available:
1. Module’s functions recovering from binary code without any additional information;
2. Binary program test SDK creation;
3. Test loading to target binary program’s address space. Test executing. An analyzed binary continues executing in same mode as before test loading.

Thus, Dataflow-0.2.0 version can be used for in memory fuzzing performing.

You can download utility, watch screenshots and release history from MaiWay project home page. Dataflow is MaiWay project part. The Dataflow tutorial is also available. Enhanced features are described in The Dataflow tutorial. Part 2. Please, feel free send bug reports, suggestions etc. to authors.

In short.

You can generate functions prototypes from binary module that looks like:

Code:

int ( __cdecl *functionstest2_sub_1120__)( void )
    = ( int ( __cdecl * ) ( void) ) 0x401120;

inline int __cdecl functionstest2_sub_1120( int a )
{
   __asm{
      mov EBX, a
   }
   return functionstest2_sub_1120__( );
}

After that you can develope some tests ( may be fuzzing actions ):

Code:

#include "functionstest.h"
void StartTest( void )
{
   functionstest_sub_10C0( 88, 77, 66, 55 );
   functionstest_sub_1080( 33, 44, 55, 66 );
}

BOOL APIENTRY DllMain( HMODULE hModule,
                                 DWORD  ul_reason_for_call,
                                 LPVOID lpReserved
)

void StartTest( void )
{
   switch (ul_reason_for_call)
   {
      case DLL_PROCESS_ATTACH:
         StartTest();

      case DLL_THREAD_ATTACH:
      case DLL_THREAD_DETACH:
      case DLL_PROCESS_DETACH:
      break;
  }
  return TRUE;
}

Buid it and execute in analyzed program address space with one click ( 3 clicks in deed ).



Test executed, module's internal functions are fuzzed. After that program countinues its normal execution.

Thanks for attention

It is not a mistery that Hex-Rays is preparing for the IDA 6.0 beta program. In this post I'll write a bit about my personal, behind the scenes, experience with the project.

It took me 7 months to port/rewrite the old VCL GUI of IDA Pro. The new GUI, as it had been already anticipated months ago on the official blog, is Qt based.

The main difficulties I have faced were mostly not of technical nature, although it was a complex task, but psychological ones. It took a lot of patience and it was very difficult every morning to go to work and to have to see an unfinished product with the old GUI reminding myself how much was still to do.

What follows is a rough roadmap of my work, I'll mention only the milestones and not the hundreds of smaller parts. It has to be noted that at least for what concerns the docking I wrote most of it before joining Hex-Rays to accelerate the development of the actual GUI once in the company. While Qt has a docking system, it is not as advanced as the one used by the VCL GUI, which is a commercial control. So, I wrote a docking system myself in order to offer all the advanced features the old GUI had.

January: first impact with the code. Took me a week to grasp the initial concepts to start. Basically at the end of the month I could display disassembly and graph mode of a file. Also, hints, graph overview and disassembly arrows were implemented.

February: implemented chooser and forms (which I actually completely changed internally, that's why I had to improve them again later on to obtain better backwards compatibility).

March: marathon month. Implemented every day one or more dialogs/views such as: hex view, cpu regs view, enum view, struct view, options, navigation band, colors, etc. etc. More than 30, some very easy, some advanced controls such as the hex view or the cpu regs view.

April: two weeks to finish the docking and smaller things.

May: two weeks to implement the desktop part (the ability to save/restore layouts and options) and smaller things.

June: fixes, help system and improved the forms implementation.

July: Hundreds of fixes for the beta.

While there will be still bugs to fix, I consider the project as completed and I wrote this post to close a chapter for myself.

So I've been integrating Boomerang into Sin32 and I am releasing all future code under BSD and GPL licenses references therein.

In doing this I dont want to use the GC stuff or the wierd LOG class provided to do the logging of all this important information that is gleaned out of this project, so a reimplementation of that is needed( all 367 or so calls that I commented out) as well as the reimplementation of the GUI..removing QT was fun.. But reworking the controller GUI to also view output of server..is primary goal. But as seen with my post in rekindled hope(maybe) I'm trying to probe for remote console allocation for output as well as input commands.

For the Most Part I am done with getting it to compile correctly, now I have to make the code not examine 'Binary Files' and examine 'mapped Binary portions' which isnt anything 'really different' from what it does anyways, my method is just runtime based ...

But I know the 'some' benefits from the inclusion of the marvelous little tool, but there is so much to be done..But I will give you the source and the first 'complete compiling project'.. This update is only running what has been released in the past for the 'LPC Server portion of this maybe with minor updates' expect a BIG update on that regard soon.

heres a download link for sources
http://www.filefactory.com/file/b2ca04f/n/SIN32.zip

Hi,

In this little blog post I'm going to reverse kdbgctrl.exe an handy tool delivered with Windows Debugging Tools kit (windbg package). This tool has the handy functionality to allow Kernel Triage Dumps building, also from a non /DEBUG bootted machine.

As written before, from nynaeve, Triage Dump writing make able the kernel to create small dump files which contains the basical and usual informations of a Dump, like processes with associated threads and relative stacks.

There is not many documentation about the usage of kdbgctrl, we have only a basical:
kdbgctrl -td pid file

Let's now see how internally works kdbgctrl.exe; why this?..curiosity and the potentiality to know which functions are used and became able to rewrite it, and also (as asked by some people) to show a subset of considerations that make you able to fastly and effectively reverse the functionality of an application.

What we have is an application that takes two arguments, one of them is a filename, so after disassembling it we can immediately search for File Management Operations, like CreateFile and WriteFile, at this point we can trace back to the origins, locating the requestor and consecutively identify the functions that provide data dumped into file.

Code:

.text:0100340F loc_100340F:                            ; CODE XREF: sub_1003310+BF j
.text:0100340F                 push    0               ; hTemplateFile
.text:01003411                 push    80h             ; dwFlagsAndAttributes
.text:01003416                 push    2               ; dwCreationDisposition
.text:01003418                 push    0               ; lpSecurityAttributes
.text:0100341A                 push    0               ; dwShareMode
.text:0100341C                 push    40000000h       ; dwDesiredAccess
.text:01003421                 mov     ecx, [ebp+lpFileName]
.text:01003424                 push    ecx             ; lpFileName
.text:01003425                 call    ds:CreateFileA

the first line denotes a Cross Reference, so let's follow it:

Code:

.text:010033AE loc_10033AE:                            ; CODE XREF: sub_1003310+84 j
.text:010033AE                 lea     eax, [ebp+nNumberOfBytesToWrite]
.text:010033B1                 push    eax
.text:010033B2                 mov     ecx, [ebp+dwSize]
.text:010033B5                 push    ecx
.text:010033B6                 mov     edx, [ebp+lpAddress]
.text:010033B9                 push    edx
.text:010033BA                 push    24h
.text:010033BC                 lea     eax, [ebp+var_44]
.text:010033BF                 push    eax
.text:010033C0                 push    1Dh
.text:010033C2                 call    ds:NtSystemDebugControl

This is the heart of kdbgctrl algorithm, the Triage Dump is obtained by calling NtSystemDebugControl, we have now to uncover its parameters to be able to reproduce the code.

Code:

NtSystemDebugControl(
IN SYSDBG_COMMAND Command,
IN PVOID InputBuffer OPTIONAL,
IN ULONG InputBufferLength,
OUT PVOID OutputBuffer OPTIONAL,
IN ULONG OutputBufferLength,
OUT PULONG ReturnLength OPTIONAL );

In our case SYSDBG_COMMAND has the value 1D, with a little research we can discover that this value belongs to SysDbgGetTriageDump, and immediately after the involved struct

Code:

typedef struct _SYSDBG_TRIAGE_DUMP
{
    ULONG Flags;
    ULONG BugCheckCode;
    ULONG_PTR BugCheckParam1;
    ULONG_PTR BugCheckParam2;
    ULONG_PTR BugCheckParam3;
    ULONG_PTR BugCheckParam4;
    ULONG ProcessHandles;
    ULONG ThreadHandles;
    PHANDLE Handles;
} SYSDBG_TRIAGE_DUMP, *PSYSDBG_TRIAGE_DUMP;

Immediately before NtSystemDebugControl we meet:

Code:

.text:0100336C                 mov     [ebp+var_40], 69696969h
.text:01003373                 mov     [ebp+dwSize], 400000h
.text:0100337A                 push    4               ; flProtect
.text:0100337C                 push    1000h           ; flAllocationType
.text:01003381                 mov     edx, [ebp+dwSize]
.text:01003384                 push    edx             ; dwSize
.text:01003385                 push    0               ; lpAddress
.text:01003387                 call    ds:VirtualAlloc

69696969 belongs to the tipical BugCheck of Triage Dumps. A bit upper we have

Code:

.text:0100335D                 push    ecx
.text:0100335E                 call    sub_1002EB0
.text:01003363                 test    eax, eax
.text:01003365                 jz      short loc_100336C ;Prosecute with Dumping Process
.text:01003367                 jmp     loc_100357C    ;Jump Out

Let's see what happens inside call sub_1002EB0

Code:

 ..
.text:01002EE3                 push    offset aDbgeng_dll ; "dbgeng.dll"
.text:01002EE8                 call    ds:LoadLibraryA
..
.text:01002F45                 push    offset aDebugcreate ; "DebugCreate"
.text:01002F4A                 mov     edx, [ebp+arg_8]
.text:01002F4D                 mov     eax, [edx]
.text:01002F4F                 push    eax             ; hModule
.text:01002F50                 call    ds:GetProcAddress

The DebugCreate function creates a new client object and returns an interface pointer to it, the parameters passed to DebugCreate are the same as those passed to IUnknown::QueryInterface, and they are treated the same way.

Code:

.text:0100307A                 call    sub_1004D90
.text:0100307F                 push    eax
.text:01003080                 push    offset aAttachprocessF ; "AttachProcess failed, %s\n"
.text:01003085                 call    ds:printf

kdbgctrl attempts to a Debug Attach by using the pid inserted by user.

Code:

.text:010030BA                 call    sub_1004D90
.text:010030BF                 push    eax
.text:010030C0                 push    offset aWaitforeventFa ; "WaitForEvent failed, %s\n"
.text:010030C5                 call    ds:printf

and waits for events.

Code:

.text:010030FA                 call    sub_1004D90
.text:010030FF                 push    eax
.text:01003100                 push    offset aGetnumberthrea ; "GetNumberThreads failed, %s\n"
.text:01003105                 call    ds:printf

Retrieve the number of Threads, this value is necessary to define the limits of a cycle that will perform a per thread scan.

Code:

.text:010031AB                 call    sub_1004D90
.text:010031B0                 push    eax
.text:010031B1                 push    offset aGetthreadidsby ; "GetThreadIdsByIndex failed, %s\n"
.text:010031B6                 call    ds:printf
.text:010031BC                 add     esp, 8
.text:010031BF                 jmp     loc_1003252

GetThreadIdsByIndex belongs (Like GetNumberThreads) to the interface IDebugSystemObjects, the GetThreadIdsByIndex method returns the engine and system thread IDs for the specified threads in the current process.

Code:

.text:010031E8                 call    sub_1004D90
.text:010031ED                 push    eax
.text:010031EE                 push    offset aSetcurrentthre ; "SetCurrentThreadId failed, %s\n"
.text:010031F3                 call    ds:printf
.text:010031F9                 add     esp, 8
.text:010031FC                 jmp     short loc_1003252

The currently indexed thread, became the Current Thread, at this point we can know the thread handle, by calling GetCurrentThreadHandle.

This enumeration routine provides all informations that will be stored into the Triage Dump.

Should be now clear how is builded a Triage Dump, just an hint if you want to uncover other kdbgctrl functionalities, as you have seen the core function is NtSystemDebugControl, so easly list all xRefs of this function.

See you to the next post..
Giuseppe 'Evilcry' Bonfa

Though I usually not writing blogs here at woodman,
I decided to write one (who knows, maybe more), especially on what is going on today in the disassembly world.

We all know the usual tools new/old reversers/engineers/developers use today, they are mainly IDA & OllyDbg. There are however more tools of course (Such as mine, beedisasm, windbg, softice (?) and many more...) that aids in the job for code understanding, analyzing and sometimes breaking.

However, the latest efforts by major companies today leaves me (and maybe us) in a very puzzled state about the future of our tools. Google for example is pushing more and more their cloud operating system (Chrome OS) and the their underlying infrastructure: Android, into the wild.

This brings me to think, will operating systems today be forced to move to cloud computing?! Will Windows (I very much doubt about *nix/linux), mac and others will give-in to consumer demand and will be forced to move in to the virtual world - where everything is Internet based? Tools such as Google Docs, Microsoft Docs..etc

Sure, the internet is a nice idea to stream data, "secure" data, store data, retrieve data, but.. where does it leaves the RCE community ? The day that 90% of the "slaves" out there will use cloud OS is very near, and the death of PC as we knew might be near as well.

Comparing latest years since we started tinkering with RCE (late +- 1997 (HCU Days) - present day) where PC pretty much dominated (against mac - though doesn't really matter) and the very few years (3-5) it took big companies to push Cloud OS into a full working model, I pretty much think RCE is going to have to adjust & mutate their tools!

If mutation is needed, than I am pleased to tell that PVDasm is also going to battle this change !. PVDasm's engine has now been ported to native code (x86/x64) and can be loaded straight from a web-browser (Chrome build), where the user will be able to disassemble files/data from far away @ some cafe/airplane/mobile device. Just access to the web (where servers will hold the native package) and you're done.

Watch a demo here: http://tinypic.com/r/ziul1h/6

This is an early build, that shows dynamic disassembling of data straight from the browser, where execution is done using native plugins loaded at run-time by chrome.

My guess is that regular OS of course will stay, however, Cloud OS will take over!

- HTML5
- JS engines (ie: V8)
- Video/Audio (WebM / OGG/AAC)
- Vector / Flash / Surface

Those are all just a small drop in the ocean of what's coming next (or already came) and we can't deny that the future is here. So, Mutate you tools and adjust, because you never know what the future holds (or do we?)

- Ben

After various articles on malware analysis I decided to talk about a little different topic, due to the fact that I'm involved into Kernel Mode Coding the Windows Internals Research become a truly important aspect of my Research. As the title suggests, this time I'm going to Study and Reverse a particular component used by the Windows Debugging System, more precisely a Device Driver involved into Local Kernel Debugging.

Not many people is aware that is possible to perform Local Kernel Debugging, one of the most used Debugging Configurations is the Remote Debugging. Local Kernel Debugging can offer many important vantages, like valuable informations on the Status of the Kernel and Inspect Kmode Components. LKD (Local Kernel Debugging) can be acheived by booting in Debug Mode, both kd and windbg fully supports LKD.

The essential question now is, How the Debugging Engine, let's consider for example Windbg, is able to obtain informations about the kernel by running from usermode?

The reply to this question not only will uncover the problem itself but also will open new interesting questions and possibilities, such as:

#1 - "It's possible to develop an application that can use the same
technology ?"

#2 - "How to access the involved components and what are parameter to
have access?"

To begin the study of this problem, we have in first instance to reproduce the environement necessary to start a Local Debugging Session.

I've used for these tests Windows 7 32-Bits Ultimate Edition and Windbg.

First step is to enable debug mode by running:

bcdedit -debug on then reboot.

At this point we have literally to debug our debugger to be able to reveal the mechanism and component involved in communication between the Debug Engine and Kernel.

In the past Windows Editions, the function used was NtSystemDebugControl, but from Windows Vista to Higher Versions this function is not immediately available.

To trace windbg activities I've used a great tool for professional API Tracing, called Blade API Monitor.

The hypothesis was, if windbg runs at usermode and accesses a kernel component it's obvious that will be used a Device Driver, by assuming true this statement, every application that deals directly with Device Drivers will use:

* CreateFile -> For Driver Opening
* ReadFile / WriteFile -> Device Driver Communication
* DeviceIoControl -> Data exchange between Driver and umode application
* NtSystemDebugControl


After setting the proper filter for these functions, let's run a Local Kernel Debugging Session and watch the results from API Monitor.

When debugger is loaded, we can launch some command, like:

!drvobj
!irpfind
!isr

From API Log emerges an important result, we have two threads:

#- First Thread

DeviceIoControl(...)
DeviceIoControl(...)
CreateFileW(wchar_t* lpFileName = C:\Windows\Fonts\staticcache.dat,...)

#- Second Thread

CreateFileW( wchar_t* lpFileName = C:\Windows\system32\kldbgdrv.sys )
return value -> void* return = 0x00000128

WriteFile(void* hFile = 0x00000128, .., unsigned long nNumberOfBytesToWrite = 0x000031F0 )

CreateFileW(wchar_t* lpFileName = \\.\kldbgdrv)
return value -> void* return = 0x00000170

DeviceIoControl(void* hDevice = 0x00000170)
IOCTL -> unsigned long dwIoControlCode = 0x0022C007
As you can see, from the second thread we obtain a valuable amount of informations.

WinDbg creates a driver called kldbgdrv.sys placed in %\system32\ this file is 0x31F0 long.

Successively this driver is openened and windbg starts to send IOCTL to this driver.

The IO Control Code used is 0x0022C007.

When debugging session finishes, kldbgdrv.sys it's deleted.

To reverse this driver we have obviously to dump it, so the first operation is to locate where is placed and successively carve out this.

The most probable location where can be located are the resources of windbg or kd executables, so let's explore their PE.

Between resources of windbg.exe we can see that the last one called "17476" which contains another subdir called "30583" by opening also this last directory finally appears our wldbgdrv.sys (can be easly detected by watching between strings)

From the starting address of this resource if we add the len of bytes ( nNumberOfBytesToWrite = 0x000031F0) we can easly into a new file kldbgdrv.sys

Now let's reverse this driver.

INIT:00010D1F push offset aKdsystemdebugc ; "KdSystemDebugControl"
INIT:00010D24 lea eax, [ebp+DestinationString]
INIT:00010D27 push eax ; DestinationString
INIT:00010D28 call ds:RtlInitUnicodeString
INIT:00010D2E lea ecx, [ebp+DestinationString]
INIT:00010D31 push ecx ; SystemRoutineName
INIT:00010D32 call ds:MmGetSystemRoutineAddress
INIT:00010D38 mov [ebp+var_1C], eax
INIT:00010D3B cmp [ebp+var_1C], 0
INIT:00010D3F jnz short loc_10D4B
INIT:00010D41 mov eax, STATUS_PROCEDURE_NOT_FOUND
INIT:00010D46 jmp loc_10DF5

this is a really interesting piece of code, here the driver attempts to obtain the Routine Address of the function KdSystemDebugControl()

INIT:00010D4B mov edx, [ebp+DriverObject]
INIT:00010D4E mov dword ptr [edx+34h], offset sub_10A10 ;DriverUnload
INIT:00010D55 mov eax, [ebp+DriverObject]
INIT:00010D58 mov dword ptr [eax+38h], offset sub_10A50 ;DriverObject->MajorFunction[0] = (PDRIVER_DISPATCH)sub_10A50
INIT:00010D5F mov ecx, [ebp+DriverObject]
INIT:00010D62 mov dword ptr [ecx+40h], offset sub_10A50 ;DriverObject->MajorFunction[0] = (PDRIVER_DISPATCH)sub_10A50
INIT:00010D69 mov edx, [ebp+DriverObject]
INIT:00010D6C mov dword ptr [edx+70h], offset sub_10A80 ;DriverObject->MajorFunction[14] = (PDRIVER_DISPATCH)sub_10A80
INIT:00010D73 push offset aDeviceKldbgdrv ; "\\Device\\kldbgdrv"
INIT:00010D78 lea eax, [ebp+DeviceName]
INIT:00010D7B push eax ; DestinationString
INIT:00010D7C call ds:RtlInitUnicodeString
..
INIT:00010D96 call ds:IoCreateDevice

Here the device it's created \\Device\\kldbgdrv and

There are also four MajorFunctions associations:

DriverObject->DriverUnload = (PDRIVER_UNLOAD)sub_10A10;
DriverObject->MajorFunction[0] = (PDRIVER_DISPATCH)sub_10A50; // IofCompleteRequest(Irp, 0)
DriverObject->MajorFunction[2] = (PDRIVER_DISPATCH)sub_10A50; // IofCompleteRequest(Irp, 0)
DriverObject->MajorFunction[14] = (PDRIVER_DISPATCH)sub_10A80; // Suddenly Reversed
Let's check the latest Dispatch Routine:

PAGE:00010AEE push edx
PAGE:00010AEF push eax ; PrivilegeValue
PAGE:00010AF0 call ds:SeSinglePrivilegeCheck
PAGE:00010AF6 movzx ecx, al
PAGE:00010AF9 test ecx, ecx
PAGE:00010AFB jnz short loc_10B09
PAGE:00010AFD mov [ebp+var_3C], STATUS_ACCESS_DENIED
PAGE:00010B04 jmp loc_10C5B
PAGE:00010B09 mov [ebp+var_4], 0
PAGE:00010B10 mov edx, [ebp+var_30]
PAGE:00010B13 mov [ebp+var_48], edx
PAGE:00010B16 cmp [ebp+var_48], 22C007h ; IOCTL = 22C007h
PAGE:00010B1D jz short loc_10B24
PAGE:00010B1F jmp loc_10C2B


When the IOCTL = 22C007h it's sent the first operation is to check if the action has the proper privileges "SeSinglePrivilegeCheck", successively this dispatch routine validates and sanitizes parameters sent with the IOCTL, by using MmUserProbeAddress and ProbeForWrite.

Finally we can say that kldbgdrv.sys works as wrapper for KdSystemDebugControl.

This function belongs to NtSystemDebugControl but can be accessed only at kernel mode.

Here it's prototipe:

NTSTATUS
NTAPI
KdSystemDebugControl(
SYSDBG_COMMAND Command,
PVOID InputBuffer,
ULONG InputBufferLength,
PVOID OutputBuffer,
ULONG OutputBufferLength,
PULONG ReturnLength,
KPROCESSOR_MODE PreviousMode
);
_SYSDBG_COMMAND it's an enum, let's suppose we want SysDbgReadVirtual we have the corresponding struct:

typedef struct _SYSDBG_VIRTUAL
{
PVOID Address;
PVOID Buffer;
ULONG Request;
} SYSDBG_VIRTUAL, *PSYSDBG_VIRTUAL;
At this point we have all elements to use with success kldbgdrv.sys, that means the possibility to have access to the kernel ...

once upon a time, i saw a request for filemaker target. so, i took my time to familiar myself with it (as normal user), as it was the first time i ever heard about it.

one thing that appeal to me that time, was, it's capability to produce a so called runtime application, or in their term, a filemaker solution, by means of developer tool menu at filemaker pro.

so, like a noob, i tried to break at msgbox error, to see where things go. but after sometime, i failed to got one, and i dropped it. it took a while since i didn't really have much free time, to get back into it. and this time, i start with none but with winhex (no debugging at all), collecting any information i can get about this filemaker.

i was thinking as a real noob. so, this is a database application. see, let say i made a table and put a 'name' field as text, and type some text in, to see where it goes in the file. alas, i can't find that text i typed in, in the file that just created. so, i assume there is somekind of encryption involved.

there is a bit pre-assumption i made. this is a database, so, it will hold a massive size of data. so since it'll involve a huge data read/write, as a programmer, i'd use something fast. block cipher speed is fairly good, but i didn't see any reason why it should be used for entire table fields.

so, i made 2 file, with palindrom texts to test it, i.e. text in file1 : "abcd", text in file2 : "dcba". scan the diff with winhex, and found that there were actually some strange bytes forming palindrom sequence. it is actually a bit long to notice that. but it was that time, i found that Examdiff ease my job excelently. so, right now, when i need to compare things, i use it. winhex compare routine is dumb.

at first, i thought it was a subtitution cipher. but as i revisit my preassumption, it can't be true. subtitution can really take a long delay, so it won't be suitable. a simple xor maybe? and then i test it, IT IS!! (i was a bit glad).

so, now i know how the texts 'encoded' in the file, what next?
let see how things managed inside the binary file. i opened it up with winhex, and letting my eyes stared at it, again and again. to ease seeing things, i set 2 window in winhex, one opened it normally, and one opened it and xored (so i can see texts clearly).

the first one i noticed, was, the file content somehow managed for every 1000h bytes (later i found it called a 'page' in filemaker term). and it was interest me that in the beginning of each page, there are some bytes showed some small number. i took a note for every pages in the file, and made an assume, that it was a linked list struct numbers. so, i take my time to observe some another filemaker file, and i thought, it's true.

i also took advantage of recover menu from filemaker pro, to recover a dummy file, just to see the recover log. there are some usefull information i got there. well, i learned 'page' term from there

so what else?

well, at the time i found that it was a linked list, i was thrilled enough to continue exploring the binary further... so, i don't really want to spoil anything here, but i'd rather let the reader to do their homework

I worked on cracking some older PC games I had, and have successfully cracked them to accept any serial and proceed with installation. They range from like the mid 90's to early 00's, but I am still excited that I was able to do it .

Interestingly enough, I was surprised that this company (don't know if I can say who, despite the games being old, I don't know if I am aloud to mention it) had so many games with like 0% protection on the CDs and the installers (didn't even do any checks on the file sizes).

I only had to use HDasm (to find the error string), Ollydbg (to debug it, and then to patch), and Imgburn (to create an ISO for debugging, then to recreate the ISO with my patch).

I feel awesome now , can't wait to work on more complicated programs.

They won't know what hit them.

I have been unable to RCE at all lately. Personal life has been taking up my time. But I have a free weekend, and I am going to go for cracking the ASProtect program that has been staring me in the face for the past month .

Can't wait ...

It is not a technical post, but I think I should put it here, because after all I read the Hex-Rays hiring announcement on the blogs of this forum.

At the beginning of September I started looking for a job. I actually wanted a job to work from remote. Despite the fact that I got several offers, all of them required relocation. So in the end I saw the Hex-Rays hiring announcement on Woodmann and sent out my résumé. From all the relocations, Belgium was the nearest and best connected one and of course it's a very good job.

The first month at Hex-Rays has been tough on all fronts. Mainly because of the relocation and getting used to work in an office. Now work is proceeding well, but the rest is still difficult. Having one day of sun here in Belgium would help, by the way.

Musil wrote in his life's work that modern man is spending his life always increasing his level of expertise, remaining with a millimeter of specialistic knowledge which only few people in the world could really understand. The others, talking about his millimeter would only say stupid things and he himself can't move from his own millimeter without running into the same problem.
I think I found my millimeter in the IT world. However, I can't stand still on it. I always keep moving with exasperated restlessness.

I have written in the last 2 years at least 5 programs of bigger size which are almost complete, but as I'm now working at Hex-Rays they will have to wait. When I was writing mostly software on my own I did it almost entirely to be active in something. Now that I'm working on IDA every day I feel that my need of being active is fulfilled and I don't feel the need to write more code when I'm at home. Instead, I feel the need of art.

Why haven't I tried producing art instead of programming already? Because I have always been capable of judging my own work objectively and I know when the time is not right.

What's the difference between programming and art? Both need experience. The difference is that one can build one's technical experience alone in one's room, without the help of events, social interaction, etc. In a technical field it is possible to make the time needed for experience advance faster. Viceversa, in one's reflections about life one has to actually follow the time of his own life.

I feel that something is changing about that.

I finally reversed the application I was stuck on, turns out I had just skipped a simple CMP command, I feel stupid about that but I am still glad I got it done. Currently working on a couple of new apps, and they are certainly a challenge, mostly because they are packed and my current unpackers don't seem to unpack them, but I will continue to work on them. I guess my real next challenge is reversing an app that is packed and/or contains a serial which has 3 or more values instead of 1. Anyways, I feel like I have finally entered the realm of RCE . That's all for now...

I am feeling great! I have already successfully reversed one application, and I am almost done with my second! Need to brush up on some tutorials, but I'm finding this easier and easier as I go. Only a matter of time till I'm finished and I already have another for my next project. RCEing is one of the funnest things I have done in a while. I have one thing to say though, I love PeID ! It's so helpful. That's all for now.

As I enter this strange world of reverse engineering, I feel as though I have traveled back to when I first started playing video games. I was beginner then and I am a beginner now. The only difference is that RCEer's are more intelligent then gamers. Atleast I hope so . Anyways here is to the new world of RCE .

Today I'm going to expose how to perform the preliminar analysis of a Rootkit Application both via the classical Reverse Engineering approach and Crytpanalysis one.

We will inspect a recent threat commonly detected as Rootkit Agent.adah, this rootkit is delivered in the usual form of executable (.exe) via Compromised or Malicious Websites.

Usually the main executable is delivered in packed/compressed form and presents other executables embedded as resources, in other cases we can have blocks of encrypted data that will be decrypted on fly by the main executable.


In the first step we are going to see how is structured the executable. CFF reveals us that the application is packed with UPX v3.0;

Due to the nature of UPX, that is essentially a compressor, we will see a pattern almost constant, stabilized at high levels of entropy. Here a graph plot



As should be evident, the internal structure and presence of embedded data is protected cause the constancy of the Entropy along the executable. In other words in this case the contribution from knowledge of entropy does not help us to have additional information. We have to perform more specific inspections, this time by using Floating Frequency Analysis.


Let's spend some word about what mean Floating Frequency..

The floating frequency of a document is a characteristic of its local information content at individual points in the document. The floating frequency specifies how many different characters are to be found in any given 64-character long segment of the document. The function considers sequences of text in the active window that are 64 characters long and counts how many different characters are to be found in this "window". The "window" is then shifted one character to the right and the calculation is repeated. This procedure results in a summary of the document in which it is possible to identify the places with high and low information density. A document of length n > 64 bytes has n-63 such index numbers in its characteristics.

This is how work, implicitly should be clear enough how to interpret a Floating Frequency Graph,
high values which deviate markedly from the background in an executable suggest that encrypted data or even cryptographic keys will be found in those places.

Let's inspect the first graph:



As you can see, with floating frequency we are now able to distinguish the PE Header that presents a low Differences Ratio, suddenly after the PE Header we can see UPX at work, plot is constant and uniform, near the end happens an interesting thing, a marked decrease of frequency that remains stable and uniform for a certain offset range, at the end of this isolated behaviour we register another abrupt decrease, this is the end of PE and obviously of the file.

The isolated behaviour is truly interesting, the offset of this 'object' is placed in .rsrc section and presents a strong entropy due the evident density of Floating Freq. plot. A good compression algo introduces a significative increase of entropy, but if the block has already an high entropy this increase obviously cannot happen.We may think that the resource is compressed/encrypted. For example we could have another packed exectable.

After this preliminary inspection we unpack the main malicious executable and inspect in the same way the unpacked one.

Here the Entropy Plot of unpacked sample:



As you can the, now the situation is different, emerges the evidence of PE Header, after a normal ammount of entropy, globally lower that the previous graph, a central drop caused by Zero Padding for PE Alignment, sucessively an increase long a defined amount of bytes (a block) and suddenly after an evident increase of entropy that reaches the RED Level. This mean that our previous observations on floating frequency plot was correct, here the 'object' that certainly is packed/compressed. Finally we have a classical slow down caused by the intrinsic structure of PE Format.

Again let's perform the Floating Frequency inspection of the unpacked executable, here how changes the graph:



Again Floating Frequency reveals us more details, or better (in this case) highlights better the structure of the whole executable plus the conformations of the two objects. If you pay attention to the first one, you can see that this corpse is truly similar to the global look of the unpacked executable, in other words we can state that the first object is effectively another merged executable!
The second one is certainly a compressed object, the reason is clear just lookup the previous explaintions.

Now let's see practically the whole body of our unpacked executable, from a classical Reverse Engineering point of view. We said that the two objects are placed into .rsrc section, let's look with Great CFF (I love this Tool ) if this is true.

Bang! correct, the two merged resources are definitely two executables!
The first one is a clean .sys, this is clear due to the presence of INIT in the PE Header.
Also the second resource corresponds to our predictions, we have an UPX packed executable.

Now should be trivial to carve these two executables, just locate the starting offset and by delimiting with Block Start/End function of CFF we obtain the executable size that added to the starting offset give us the final offset where to cut.

The Block End corresponds obviously with the end of first/second resource.

The .sys is the core file of our rootkit, I'll reverse it in a future post, the second executable, when unpacked become clear that is a DLL, if we take a look to some function name for exampe this:

_NF_STATUS __cdecl nf_addRule(struct _NF_RULE *)

became clear that this DLL acts as Network Filter by using NetFilterSDK ( http://netfiltersdk.com/ )

But this is matter of future blog post.

Hope you enjoyed this little paper

Giuseppe 'Evilcry' Bonfa'

Hi there,

In this period I'm heavy working on Signature Generation for big malware families, this mean that there is a large amount of binaries to be checked for Static Patterns recurrences, you should understand that this work can't be done by hand on families of 400+k number of samples, and hashing would not help, this because Hash Algorithms respects the Avalanche Effect via its most famous generalization the SAC ( Strict Avalanche Criterion ), this mean that, this property it is satisfied if, whenever a single input bit is complemented, each of the output bits changes with a probability of one half.

In other words a minimum little change will deeply change the hash result and we can't come back to similarities, so we need a technology that does not respect the SAC, also in this case the wonderful cryptography help us

We have the CTPH that mean Context Triggered Piecewise Hashes, called also Fuzzy Hashes, this will help us to match inputs that have homologies like sequences of identical bytes in the same order.

Here an interesting paper about CTPH Identifying almost identical files using context triggered piecewise hashing

http://dfrws.org/2006/proceedings/12-Kornblum.pdf

and here an open source implementation of fuzzyhashing called DeepToad

http://code.google.com/p/deeptoad/

Regards,
Giuseppe 'Evilcry' Bonfa