Didier Stevens

Tuesday 31 July 2018

Update: python-per-line.py Version 0.0.5

Filed under: My Software,Update — Didier Stevens @ 0:00

This new version of python-per-line.py adds new options: –grep, –grepoptions, –begingrep, –begingrepoptions, –endgrep and –endgrepoptions

With –grep and –grepoptions, you can select the lines to be processed by python-per-line.py.

If you want to skip lines at the beginning of the file, use option –begingrep to grep for the first line where processing should start.

And if you want to skip lines at the end of the file, use option –endgrep to grep for the last line to be processes.

python-per-line_V0_0_5.zip (https)
MD5: 1CED1F84FD44E64BF448558BA02E0978
SHA256: 8E6845006BD3463135CE7AA0AA05FA596AC10E6E2ACC4B45C5909B624A20D6A5

Monday 30 July 2018

Update: numbers-to-string.py Version 0.0.4

Filed under: My Software,Update — Didier Stevens @ 0:00

This new version of numbers-to-string.py adds new options: –grep, –grepoptions, –begin and –end.

With –grep and –grepoptions, you can select the lines to be processed by numbers-to-string.py.

And if you don’t want the tool to take a whole line into account when processing numbers, but only part of the line, you can use option –begin to specify where in the line processing should start.

Likewise, with –end you can specify where processing should end.

numbers-to-string_v0_0_4.zip (https)
MD5: DFBA2CE60D59A5DF25D7BE415D55B0FF
SHA256: DA75A6BEB7DCD0F71C008EFE43EE3D3831B545BC916AA5176F4E2004FE97A250

Sunday 29 July 2018

Update: re-search.py Version 0.0.12

Filed under: My Software,Update — Didier Stevens @ 0:00

This new version of re-search adds 3 regular expressions to the library: str-e matches quoted strings like str but including the empty string too. str-u matches strings like str, but strips the double quotes. str-eu matches like str-e and also strips double quotes.

re-search_V0_0_12.zip (https)
MD5: 8CA8D767BDB126B097E41F0D4B1F197B
SHA256: 69752CF9862FC4EC29DD96289A21D1C8C82FB4C3C3083BE622C169BA658F0A40

Wednesday 25 July 2018

Extracting DotNetToJScript’s PE Files

Filed under: Forensics,Malware — Didier Stevens @ 0:00

I added a new option (-I, –ignorehex) to base64dump.py to make the extraction of the PE file inside a JScript script generated with DotNetToJScript a bit easier.

DotNetToJScript is James Forshaw‘s “tool to generate a JScript which bootstraps an arbitrary .NET Assembly and class”.

Here is an example of a script generated by James’ tool:

The serialized .NET object is embedded as a string concatenation of BASE64 strings, assigned to variable serialized_obj.

With re-search.py, I extract all strings from the script (e.g. strings delimited by double quotes):

The first 3 strings are not part of the BASE64 encoded object, hence I get rid of them (there are no unwanted strings at the end):

And now I have BASE64 characters, I just have to get rid of the doubles quotes and the newlines (base64dump searches for continuous strings of BASE64 characters). With base64dump‘s -w option I can get rid of whitespace (including newlines), and with option -i I can get rid of the double-quote character. Unfortunately, escaping of this character (\”) works on Windows, but then cmd.exe gets confused for the next pipe (it expects a closing double-quote). That’s why I introduced option -I, to specify characters with their hexadecimal value. Double-quote is 0x22, thus I use option -I 22:

This is the serialized object, and it contains the .NET assembly I want to analyze. .NET assemblies are .DLLs, e.g. PE files. With my YARA rule to detect PE files, I can find it inside the serialized data:

A PE file was found, and it starts at position 0x04C7. I can cut this data out with option -c:

Another method to find the start of the PE file, is to use a cut expression that searches for ‘MZ’, like this:

If there is more than one instance of string MZ, different cut-expressions must be tried to find the real start of the PE file. For example, this is the cut-expression to select data starting with the second instance of string MZ: -c “[‘MZ’]2:”

It’s best to pipe the cut-out data into pecheck, to validate that it is indeed a PE file:

pecheck also helps with finding the length of the PE file (with the given cut-expression, I select all data until the end of the serialized data).

Remark that there is an overlay (bytes appended to the end of the PE file), and that it starts at position 0x1400. Since I don’t expect an overlay in this .NET assembly, the overlay is not part of the PE file, but it is part of the serialization meta data.

Hence I can cut out the PE file precisely like this:

This PE file can be saved to disk now for reverse-engineering.

I have not read the .NET serialization format specification, but I can make an educated guess. Right before the PE file, there is the following data:

Remark the first 4 bytes (5 bytes before the beginning of the PE file): 00 14 00 00. That’s 0x1400 as a little-endian 32-bit integer, exactly the length of the PE file, 5120 bytes:

So that’s most likely another method to determine the length of the PE file.

 

Tuesday 24 July 2018

Update: base64dump.py Version 0.0.11

Filed under: My Software,Update — Didier Stevens @ 0:00

This new version of base64dump adds option -I (ignorehex). Like -i, -I can be used to specify characters to be ignore by base64dump. Option -I takes the characters to be ignored as hexadecimal values, like this:

base64dump.py -I 2209

This will ignore the double-quote character (0x22) and the TAB character (0x09).

base64dump_V0_0_11.zip (https)
MD5: BF9D9EB3E6D574633D7F85345213E3E8
SHA256: 2741F9C3FD7B0897A04F60C741D7125568C8355A82FCF0FD4BB80877EE7FB935

Saturday 21 July 2018

Update: sets.py Version 0.0.2

Filed under: My Software,Update — Didier Stevens @ 0:00

sets.py is a small & simple tool for operations on sets, like the intersection of 2 sets.

2 new operations were added to this version: sample and join.

sets_V0_0_2.zip (https)
MD5: F744A900D3EBF7A0D0927F5244FA65F9
SHA256: B205B766D0FB4D12DD334BD6CD20748E14EF1136D545F7EFBB5CEAC6B3F0D942

Tuesday 17 July 2018

!exploitable Crash Analyzer – Statically Linked CRT

Filed under: Reverse Engineering — Didier Stevens @ 0:00

Regularly when I use Microsoft MSEC’s !exploitable WinDbg extension, it doesn’t load because the correct VC runtime is not installed (vcredist 2012) on the machine I’m debugging on.

Since it’s open-source, I decided to recompile it with a statically linked C runtime, making it independent of the installed runtime(s). I used Visual Studio 2017 and let it do the default upgrade of the Visual Studio 2012 solution (default implies Windows XP is no longer supported). The only change I made was option /MT to link the runtime into the DLL.

To load the extension, type command “.load” with the full path to the DLL.
Or you can copy the DLL into a folder of the “extension dll search path”. You can view this search path with command “.chain” or “.extpath”:


Then you can just type “.load msec” to load the extension. If you use folders like x86\winext and x64\winext, you can copy the respective x86 and x64 versions without having to rename the DLL.

You can also load the extension and execute the command with one line (!msec.exploitable), like this:

One downside of statically linking the C runtime, is that I will have to recompile the DLLs if the C runtime gets patched to fix a vulnerability.

You can download the recompiled plugins here:
MSECWinDbgExtensions.zip (https)
MD5: 090D9E4BE43B7272AA54673C366695E3
SHA256: 39AB11FDF9F80608235CE26833F57A850DD2C36C513EB92C97E28714BA0076FA

Wednesday 11 July 2018

New Tool: file-magic.py

Filed under: Announcement,My Software — Didier Stevens @ 0:00

I find the *nix tool file very useful. There’s no equivalent on Windows, that’s why I use a Windows port of this tool.

But it has some limitations, the most annoying to me being the lack of support for stdin. This prevents me from using it in a chain of commands.

That’s the main reason I developed file-magic.py, a Python tool that is essentially a wrapper for the Python magic module.

On Windows and OSX, install module python-magic-bin with pip (this will install binaries too), while on Linux install module python-magic.

Here is an example showing how output from base64dump is piped into file-magic:

And here is an example with jsonoutput I mentioned before:

You can also add your own definitions to file file-magic.def.

For example, I added a definition for VBE/JSE files (encoded .vbs/.js scripts).

file-magic_V0_0_2.zip (https)
MD5: EAE684E74731FF493D5EC5D243EB16B6
SHA256: 9B0E7B47CAED8F5627DEFCE19B737554BBF998EF380187D6DE4FC1C9572EC9ED

Tuesday 10 July 2018

Quickpost: Compiling DLLs with MinGW on Kali

Filed under: Quickpost — Didier Stevens @ 0:00

To compile the DLLs from this quickpost with MinGW on Kali, you first have to install MinGW.

Issue this command: apt install mingw-w64

Compile for 64-bit: x86_64-w64-mingw32-gcc -shared -o DemoDll.dll DemoDll.cpp

Compile for 32-bit: i686-w64-mingw32-gcc -shared -o DemoDll-x86.dll DemoDll.cpp

Option -shared is required to produce a DLL in stead of an EXE.

Quickpost info

 

Monday 9 July 2018

–jsonoutput

Filed under: My Software — Didier Stevens @ 0:00

My oledump.py and zipdump.py tools have a new option: –jsonoutput. With this option, my tools will output JSON data to stdout. For oledump, the JSON data will contain the content of all the streams found inside the analyzed OLE file, and for zipdump respectively, the JSON data will contain the content of all the files found inside the analyzed ZIP file.

This is meant to be piped into a new tool I will release soon.

Let’s take a small ZIP files with 2 small files as example (a binary file and a text file). Here is the content displayed with zipdump:

With zipdump’s option –jsonoutput, we output JSON data with the content of these 2 files encoded in BASE64:

Here is the same data pretty-printed:

This can now be piped into other tools that support this JSON data format.

 

Next Page »

Blog at WordPress.com.