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: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#memory_limits)

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.

DarunGrim4Setup.exe

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.

 

Example

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.

Advertisements

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:

DarunGrim4Setup.exe

 

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)

 

fig

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.

 

fig

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 oh.jeongwook@gmail.com or send me a tweet at http://twitter.com/ohjeongwook.

Thanks!

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.