How to Generate DarunGrim DGF files from Command Line

Using DarunGrim doesn’t mean that you always need to use DarunGrim GUI to generate and analyze files. Everything can be scriptable from generating DGF files and initiating diffing process to consuming diffing data. Most of the data is saved in SQLite format and the schema of the tables used are pretty simple to understand and use.

So, first of all, today I’ll go through basic process of generating DGF files from IDB files. The DarunGrim plugin (DarunGrimPlugin.plw) exposes some useful functions to IDC scripts and it will enable you to do some custom operations.

First, write a IDC script like following. You can replace log file name used in SetLogFile function and the output filename used in SaveAnalysisData function to whatever of your choice. The 2nd and 3rd argument for SaveAnalysisData function is start and end EA (effective address). Just passing 0s for them will generate DGF file for whole code sections in the file.






After saving this file, you can simply run following command from the console. In this case, I assume that you saved the file as “DarunGrim.idc” file.


“C:\Program Files (x86)\IDA 6.5\idaq.exe” -A -L”IDALog.txt” -S”DarunGrim.idc” sample.idb


The IDALog.txt file will have the same log messages displayed on the log pane of the IDA GUI program. The DarunGrimLog.txt file will contain DarunGrim specific logs in it.

Depending on the IDB file size, it will take some time to generate output.dgf file.

Big file diffing with DarunGrim


One of the challenges with patch analysis is diffing big files. The definition of big files can vary, but usually we are talking about files that are bigger than a few mega-bytes. Usually Windows system32 files are relatively small. (Figure 1)


Figure 1 Usual Windows dll files


One of the main issues with big file diffing is the memory usage, DarunGrim uses a lot of internal data structure on the memory during whole process. Sometimes when the memory usage goes over what the process can handle, you might see DarunGrim crashes with memory error.


Figure 2 Memory and address space limits (source:

Figure 2 shows the memory limits depending on process type (64bit, 32bit) and Windows type. You can see that using IMAGE_FILE_LARGE_ADDRESS_AWARE compilation option, you can increase the memory limit for 32 bit processes and also if you use 64 bit processes, you can have up to 128TB of memory to be used by a process on some Windows flavors. So with this pre-alpha release, we included IMAGE_FILE_LARGE_ADDRESS_AWARE option to all binaries and added DarunGrim command line tool with 64 bit support. You can download new distribution from following link.


So basically just using new binaries, you can have benefit of large memory (up to 4GB on 64 bit Windows). But, some binaries are so huge, you still need more memory and it can be achieved by using 64 bit version of DarunGrimC.exe. The main GUI program (DarunGrim.exe) has some dependencies on 3rd party binaries without 64bit support. That is one of the reasons why we separated main logic into DarunGrimC.exe and built 64 bit version of core command line tool.



This process has been used with my blog. First the binaries for unpatched and patched binaries are like Figure 3. The binary sizes are more than 18MB which is huge compared to other normal files. We all know that Office binaries are usually huge.


Figure 3 Diffing target files

When you follow instructions from my previous DarunGrim blog, you will have two DGF files generated. (Figure 4)


Figure 4 DGF files

Now, instead of running DarunGrim.exe, you can use DarunGrimC.exe command line tool. From the folder where two DGF files exist, run command line like following. After –f option, you can put unpatched and patched DGF file names and after that you can put the output diff file.


“C:\Program Files (x86)\DarunGrim4\x64\DarunGrimC.exe” -f “wwlib-14.0.7113.5001.dgf” “wwlib-14.0.7121.5004.dgf” “wwlib-14.0.7113.5001-14.0.7121.5004-diff.dgf”


It will take some time to finish whole analysis and if all process went well, you will get a diff file like Figure 5.


Figure 5 Diff file


I tested on a machine with following spec (2.30GHz) with 16GB physical memory and it took about 1 hour forty minutes to finish the analysis. (Figure 7)

Figure 6 Tested system




Figure 7 Test result


You can double click the diff file and GUI program (DarunGrim.exe) will display results. Everything else is same except diffing process. I might come up with 64 bit GUI (DarunGrim.exe) sometime later when all the dependency issues are figured out. And also the memory footage issue will be worked on in the future, but for now using command line 64 bit DarunGrimC.exe is the best option to perform binary diff analysis on big binary files.

DarunGrim 4 Pre-Alpha Testing

Recently I have been working on new DarunGrim and I was just cleaning up the old code. The objective of this new version 4 is faster, lighter and simpler DarunGrim. For a week, I cleaned up a lot of code and fixed a lot of issues with many code refactorings. It is still far from the complete, but I thought that I can share the binary from time to time so that I can get some feedback from the users.


I just uploaded a developmental snapshot here:



The following shows the basic steps to follow to test this test release.


Generating DGF files

After installation, you need to confirm that DarunGrim plugin is installed under IDA program folder. Then, first open an unpatched and patched binaries and run DarunGrim plugin. (Figure 1)



Figure 1 Select DarunGrim Plugin from IDA


A dialog box will pop up and it will ask you where to save the analysis file with .dgf extension. (Figure 2) The analysis file is basically in SQLite format and we just use our own extension so that it can register DarunGrim program handler upon .dgf extension.




Figure 2 Choose output DGF filename


You also do same thing upon patched file with different name, kernel-post.dgf in this case. (Figure 3)

Figure 3 Choose output DGF filename for the patched binary

Perform Binary Diffing

After saving two unpatched and patched dgf files, open them from DarunGrim main program. Run DarunGrim.exe from the Start menu and choose File -> New Diffing menu item. Select source and target dgf files we created already and set output file to save diffing analysis results. (Figure 4)

Figure 4 File Selections Dialog

 When you press OK button, the analysis will start. (Figure 5)

Figure 5 Start analysis

 It takes some time to complete analysis, the actual timing depends on the binary sizes to analyze. When it is complete, you will see the results will show up on the Functions list. (Figure 6)


Figure 6 Analysis complete

 When you double click each function, the Blocks list will be activated and will show the list of blocks inside the function. (Figure 7)

Figure 7 Blocks list


Synchronized IDA view

So, now you can now go through functions and check what functions are patched or something. But it might be beneficial to synchronize DarunGrim program with IDA and DarunGrim already supports it.

First choose View -> Connect to IDA menu. (Figure 8)

Figure 8 Connect to IDA

 From the dialog, press “Accept Connection” button from “Source File” line. It will show “Listening…” message. DarunGrim uses TCP port 1216 for the connection between DarunGrim and IDA. This will make DarunGrim to listen on TCP port 1216.

Figure 9 Accept connections


At this point, open up original binary and run DarunGrim plugin. (Figure 10) It will first try to connect to port 1216 on localhost first. If it can connect to that port, it will be running in IDA synchronization mode.



Figure 10 Run DarunGrim plugin

 When the connection is successful, the dialog box “Listening…” message will turn into a file path from the original filename. (Figure 11)

Figure 11 IDA Plugin connected successfully

 Perform same operations with patched binary. (Figure 12)

Figure 12 Connecting patched binary IDA

 Now if everything worked fine, you will see that IDA will display the position where you click from Blocks list view.

Figure 13 Full synchronized view

Now you can enjoy full power of IDA with DarunGrim.


This release is pre-alpha and it might have a lot of issues that are not taken care of yet. I refactored a lot of code and there might be some issues I never tested. If you find any issues or if you have any suggestions form DarunGrim 4, just shoot me a mail at or send me a tweet at


Java Deployment Toolkit Insufficient Validation of Parameters Vulnerability Patch Analysis

I spent some time to figure out what Oracle did to fix the @taviso’s 0-day. I digged into javasw.exe and java.exe and javaw.exe for the patched parts in vain. The binaries are all identical except the version numbers. And finally I got that they were in the deploytk and deployJava1 files. They changed the file name of COM control for the CLSID “{CAFEEFAC-DEC7-0000-0000-ABCDEFFEDCBA}”. Originally it was deploytk and it became deployJava1. That’s why I didn’t try to diff them at first.

So here’s what I got after I crack diffed two files.

You see, the left side is the unpatched function and right side is patched one. Unpatched one has whole a lot of red and yellow blocks. Red block means it has no match in the other side. Yellow block means the block has been changed. In short, the whole function’s basic blocks have been changed or removed. The function is responsible for querying registry key for JNLPFile Shell Open key and launching it using CreateProcessA API. And they removed it to fix @taviso’s 0-day. Simple! No further analysis needed. But I’m not so sure how this will impact their normal deploy process.

Anyway that’s it for now and thanks for reading.

Setting breakpoint on entry point with Windbg

You might wonder how to breakpoint on entry point in windbg. I didn’t know neither because I never tried it. I usually do kernel mode debugging so I didn’t need to bp on entry point. Here’s a little bit complicated method. But if you find any simpler way, just let me know.

First, start the application from windbg using File -> Open Executable(or ^E).
On the first breakpoint, execute the following commands.

0:000> !peb

PEB at 7ffd8000

InheritedAddressSpace: No

ReadImageFileExecOptions: No

BeingDebugged: Yes

ImageBaseAddress: 01000000

Ldr 001a1ea0

Ldr.Initialized: Yes

Ldr.InInitializationOrderModuleList: 001a1f58 . 001a2920

Ldr.InLoadOrderModuleList: 001a1ee0 . 001a2910

Ldr.InMemoryOrderModuleList: 001a1ee8 . 001a2918

Base TimeStamp Module

1000000 48025287 Apr 13 11:35:51 2008 c:\windows\notepad.exe

7c900000 4802a12c Apr 13 17:11:24 2008 C:\WINDOWS\system32\ntdll.dll

7c800000 4802a12c Apr 13 17:11:24 2008 C:\WINDOWS\system32\kernel32.dll

763b0000 4802a0c9 Apr 13 17:09:45 2008 C:\WINDOWS\system32\comdlg32.dll

77dd0000 4802a0b2 Apr 13 17:09:22 2008 C:\WINDOWS\system32\ADVAPI32.dll

77e70000 4802a106 Apr 13 17:10:46 2008 C:\WINDOWS\system32\RPCRT4.dll

77fe0000 4802a11b Apr 13 17:11:07 2008 C:\WINDOWS\system32\Secur32.dll

773d0000 4802a094 Apr 13 17:08:52 2008 C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\COMCTL32.dll

77c10000 4802a188 Apr 13 17:12:56 2008 C:\WINDOWS\system32\msvcrt.dll

77f10000 49006fbe Oct 23 05:36:14 2008 C:\WINDOWS\system32\GDI32.dll

7e410000 4802a11b Apr 13 17:11:07 2008 C:\WINDOWS\system32\USER32.dll

77f60000 45091361 Sep 14 01:31:29 2006 C:\WINDOWS\system32\SHLWAPI.dll

7c9c0000 48580a39 Jun 17 12:02:17 2008 C:\WINDOWS\system32\SHELL32.dll

73000000 4802a127 Apr 13 17:11:19 2008 C:\WINDOWS\system32\WINSPOOL.DRV

SubSystemData: 00000000

ProcessHeap: 000a0000

ProcessParameters: 00020000

WindowTitle: 'c:\windows\notepad.exe'

ImageFile: 'c:\windows\notepad.exe'

CommandLine: 'c:\windows\notepad.exe'


WINDBG_DIR=C:\Program Files\Debugging Tools for Windows (x86)



0:000> !dh 01000000



14C machine (i386)

3 number of sections

48025287 time date stamp Sun Apr 13 11:35:51 2008

0 file pointer to symbol table

0 number of symbols

E0 size of optional header

10F characteristics

Relocations stripped


Line numbers stripped

Symbols stripped

32 bit word machine


10B magic #

7.10 linker version

7800 size of code

A600 size of initialized data

0 size of uninitialized data

739D address of entry point

1000 base of code

----- new -----

01000000 image base

1000 section alignment

200 file alignment

2 subsystem (Windows GUI)

5.01 operating system version

5.01 image version

4.00 subsystem version

14000 size of image

400 size of headers

18700 checksum

00040000 size of stack reserve

00011000 size of stack commit

00100000 size of heap reserve

00001000 size of heap commit

0 [ 0] address [size] of Export Directory

7604 [ C8] address [size] of Import Directory

B000 [ 8948] address [size] of Resource Directory

0 [ 0] address [size] of Exception Directory

0 [ 0] address [size] of Security Directory

0 [ 0] address [size] of Base Relocation Directory

1350 [ 1C] address [size] of Debug Directory

0 [ 0] address [size] of Description Directory

0 [ 0] address [size] of Special Directory

0 [ 0] address [size] of Thread Storage Directory

18A8 [ 40] address [size] of Load Configuration Directory

250 [ D0] address [size] of Bound Import Directory

1000 [ 348] address [size] of Import Address Table Directory

0 [ 0] address [size] of Delay Import Directory

0 [ 0] address [size] of COR20 Header Directory

0 [ 0] address [size] of Reserved Directory


.text name

7748 virtual size

1000 virtual address

7800 size of raw data

400 file pointer to raw data

0 file pointer to relocation table

0 file pointer to line numbers

0 number of relocations

0 number of line numbers

60000020 flags


(no align specified)

Execute Read

Debug Directories(1)

Type Size Address Pointer

cv 24 18f0 cf0 Format: RSDS, guid, 1, notepad.pdb


.data name

1BA8 virtual size

9000 virtual address

800 size of raw data

7C00 file pointer to raw data

0 file pointer to relocation table

0 file pointer to line numbers

0 number of relocations

0 number of line numbers

C0000040 flags

Initialized Data

(no align specified)

Read Write


.rsrc name

8948 virtual size

B000 virtual address

8A00 size of raw data

8400 file pointer to raw data

0 file pointer to relocation table

0 file pointer to line numbers

0 number of relocations

0 number of line numbers

40000040 flags

Initialized Data

(no align specified)

Read Only

0:000> u 01000000+739D


0100739d 6a70 push 70h

0100739f 6898180001 push offset notepad!`string'+0x8 (01001898)

010073a4 e8bf010000 call notepad!_SEH_prolog (01007568)

010073a9 33db xor ebx,ebx

010073ab 53 push ebx

010073ac 8b3dcc100001 mov edi,dword ptr [notepad!_imp__GetModuleHandleA (010010cc)]

010073b2 ffd7 call edi

010073b4 6681384d5a cmp word ptr [eax],5A4Dh

0:000> bp 01000000+739D

0:000> g

ModLoad: 5cb70000 5cb96000 C:\WINDOWS\system32\ShimEng.dll

ModLoad: 6f880000 6fa4a000 C:\WINDOWS\AppPatch\AcGenral.DLL

ModLoad: 76b40000 76b6d000 C:\WINDOWS\system32\WINMM.dll

ModLoad: 774e0000 7761d000 C:\WINDOWS\system32\ole32.dll

ModLoad: 77120000 771ab000 C:\WINDOWS\system32\OLEAUT32.dll

ModLoad: 77be0000 77bf5000 C:\WINDOWS\system32\MSACM32.dll

ModLoad: 77c00000 77c08000 C:\WINDOWS\system32\VERSION.dll

ModLoad: 769c0000 76a74000 C:\WINDOWS\system32\USERENV.dll

ModLoad: 5ad70000 5ada8000 C:\WINDOWS\system32\UxTheme.dll

ModLoad: 76390000 763ad000 C:\WINDOWS\system32\IMM32.DLL

ModLoad: 629c0000 629c9000 C:\WINDOWS\system32\LPK.DLL

ModLoad: 74d90000 74dfb000 C:\WINDOWS\system32\USP10.dll

ModLoad: 48000000 48022000 C:\PROGRA~1\Google\GOOGLE~3\GOEC62~1.DLL

ModLoad: 71ab0000 71ac7000 C:\WINDOWS\system32\WS2_32.dll

ModLoad: 71aa0000 71aa8000 C:\WINDOWS\system32\WS2HELP.dll

Breakpoint 0 hit

eax=00000000 ebx=7ffd8000 ecx=0007ffb0 edx=7c90e4f4 esi=08f2f55c edi=7c911440

eip=0100739d esp=0007ffc4 ebp=0007fff0 iopl=0 nv up ei pl zr na pe nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246


0100739d 6a70 push 70h

Exporting IDA function for IDC Script Usage

Sometimes you want to specify additional options or to call internal function of IDA plugin that you wrote. You can use “set_idc_func” API to achive this. Here’s a sample skeleton code that is showing how to make a custom function that idc script can call.
char *OutputFilename;
static const char SendDiassemblyInfoArgs[]={VT_STR,0 };
static error_t idaapi SendDiassemblyInfo(value_t *argv,value_t *res)
msg("%s is called with arg0=%s\n",argv[0].str);
return eOk;

int idaapi init(void)
if ( inf.filetype == f_ELF ) return PLUGIN_SKIP;


void idaapi term(void)
From idc script, you can call the defined function as if it’s a built-in API like following.
static main()

Dumping NT_TIB

When a thread is crashed without any clue at all(eg. all registers are set to invalid value or something), you might try to get stack trace by manually pointing esp/ebp to some probable value inside stack. In that case, you need to get valid stack range. It can be achieved with following windbg command. Check out StackBase,StackLimit field from NT_TIB structure.

0:005> dt -r ntdll!_NT_TIB poi(fs:18h)

+0x000 ExceptionList : 0x01c3ac88 _EXCEPTION_REGISTRATION_RECORD



+0x004 Handler : 0x7e44048f _EXCEPTION_DISPOSITION user32!_except_handler3+0

+0x004 Handler : 0x7e44048f _EXCEPTION_DISPOSITION user32!_except_handler3+0

+0x004 StackBase : 0x01c40000

+0x008 StackLimit : 0x01c2c000

+0x00c SubSystemTib : (null)

+0x010 FiberData : 0x00001e00

+0x010 Version : 0x1e00

+0x014 ArbitraryUserPointer : (null)

+0x018 Self : 0x7ffd9000 _NT_TIB

+0x000 ExceptionList : 0x01c3ac88 _EXCEPTION_REGISTRATION_RECORD


+0x004 Handler : 0x7e44048f _EXCEPTION_DISPOSITION user32!_except_handler3+0

+0x004 StackBase : 0x01c40000

+0x008 StackLimit : 0x01c2c000

+0x00c SubSystemTib : (null)

+0x010 FiberData : 0x00001e00

+0x010 Version : 0x1e00

+0x014 ArbitraryUserPointer : (null)

+0x018 Self : 0x7ffd9000 _NT_TIB

+0x000 ExceptionList : 0x01c3ac88 _EXCEPTION_REGISTRATION_RECORD

+0x004 StackBase : 0x01c40000

+0x008 StackLimit : 0x01c2c000

+0x00c SubSystemTib : (null)

+0x010 FiberData : 0x00001e00

+0x010 Version : 0x1e00

+0x014 ArbitraryUserPointer : (null)

+0x018 Self : 0x7ffd9000 _NT_TIB