Didier Stevens

Saturday 30 April 2022

Quickpost: Machine Code Infinite Loop

Filed under: Reverse Engineering — Didier Stevens @ 8:04

Someone asked me what the byte sequence is for an infinite loop in x86 machine code (it’s something you could use while debugging, for example).

That byte sequence is just 2 bytes long: EB FE.

It’s something you can check with nasm, for example.

File jump-infinite-loop.asm:

BITS 32

loop1:
    jmp loop1
loop2:
    jmp short loop2
    jmp $
    jmp short $
    jmp short -2

nasm jump-infinite-loop.asm -l jump-infinite-loop.lst

File jump-infinite-loop.lst:

     1                                  BITS 32
     2                                  
     3                                  loop1:
     4 00000000 EBFE                        jmp loop1
     5                                  loop2:
     6 00000002 EBFE                        jmp short loop2
     7 00000004 EBFE                        jmp $
     8 00000006 EBFE                        jmp short $
     9 00000008 EB(FE)                      jmp short -2

Quickpost info

Friday 22 October 2021

New Tool: cs-decrypt-metadata.py

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

cs-decrypt-metadata.py is a new tool, developed to decrypt the metadata of a Cobalt Strike beacon.

An active beacon regularly checks in with its team server, transmitting medata (like the AES key, the username & machine name, …) that is encrypted with the team server’s private key.

This tool can decrypt this data, provided:

  1. you give it the file containing the private (and public) key, .cobaltstrike.beacon_keys (option -f)
  2. you give it the private key in hexadecimal format (option -p)
  3. the private key is one of the 6 keys in its repository (default behavior)

I will publish blog posts explaining how to use this tool.

Here is a quick example:

cs-decrypt-metadata_V0_0_1.zip (https)
MD5: 31F94659163A6E044A011B0D82623413
SHA256: 50ED1820DC63009B579D7D894D4DD3C5F181CFC000CA83B2134100EE92EEDD9F

Saturday 7 November 2020

1768 K

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

According to Wikipedia, 1768 Kelvin is the melting point of the metal cobalt.

This tool decodes and dumps the configuration of Cobalt Strike beacons.

You can find a sample beacon here.

1768_v0_0_3.zip (https)
MD5: 73DB2E96EE5B6427AF6CCE2672F91CB2
SHA256: C06850A132B89F5E8C127E43FD5CC42051706CDF058EB2D688BC8BD3043E6E02

Saturday 10 October 2020

Quickpost: 4 Bytes To Crash Excel

Filed under: Hacking,Quickpost,Reverse Engineering — Didier Stevens @ 0:00

A couple of years ago, while experimenting with SYLK files, I created a .slk file that caused Excel to crash.

When you create a text file with content “ID;;”, save it with extension .slk, then open it with Excel, Excel will crash.

Microsoft Security Response Center looked at my DoS PoC last year: the issue will not be fixed. It is a “Safe Crash”, Excel detects the invalid input and calls MsoForceAppExitIf to terminate the Excel process.

If you have Excel crashing with .slk files, then look at the first line. If you see something like “ID;;…”, know that the absence of characters between the semi-colons causes the crash. Add a letter, or remove a semi-colon, and that should fix the issue.


Quickpost info


Saturday 27 April 2019

Update: format-bytes.py Version 0.0.8

Filed under: My Software,Reverse Engineering,Update — Didier Stevens @ 9:42

This new version of format-bytes.py (a tool to decompose structured binary data with format strings) brings a couple of new features.

Format strings can now be stored in libraries: you can store often used format strings (option -f) in text files and refer to them for using with format-bytes.py. A library file has the name of the program (format-bytes) and extension .library. Library files can be placed in the same directory as the program, and/or the current directory.
A library file is a text file. Each format string has a name and takes one line: name=formatstring.

Example:
eqn=<HIHIIIIIBBBBBBBBBB40sIIBB*:XXXXXXXXXXXXXXXXXXsXXXX

This defines format string eqn. It can be retrieved with option -f name=eqn.
This format string can be followed by annotations (use a space character to separate the format string and the annotations):

Example:
eqn=<HIHIIIIIBBBBBBBBBB40sIIBB*:XXXXXXXXXXXXXXXXXXsXXXX 1: size of EQNOLEFILEHDR 9: Start MTEF header 14: Full size record 15: Line record 16: Font record 19: Shellcode (fontname)

A line in a library file that starts with # is a comment and is ignored.

Format strings inside a library can be used with option -f. For example, to use format string eqn1, you use option -f name=eqn1. You prefix the format string name with “name=”, like in this example:

Option -s can also take value r now, to select the remainder: -s r. Like this:

The FILETIME format has been added. To use it explicitly, use representation format T.

And finally, with option -F (Find), you can search for values inside a binary file. For the moment, only integers can be searched. Start the option value with #i# followed by the decimal number to search for.

Example:

format-bytes_V0_0_8.zip (https)
MD5: 22F216C2304434A302B0904A9D4AF1FE
SHA256: A38D9B57DDB23543E2D462CD0AF51A4DCEDA1814CF9EAD315716D471EAACEF19

Saturday 20 April 2019

Extracting “Stack Strings” from Shellcode

Filed under: Malware,My Software,Reverse Engineering — Didier Stevens @ 0:00

A couple of years ago, I wrote a Python script to enhance Radare2 listings: the script extract strings from stack frame instructions.

Recently, I combined my tools to achieve the same without a 32-bit disassembler: I extract the strings directly from the binary shellcode.

What I’m looking for is sequences of instructions like this: mov dword [ebp – 0x10], 0x61626364. In 32-bit code, that’s C7 45 followed by one byte (offset operand) and 4 bytes (value operand).

Or: C7 45 10 64 63 62 61. I can write a regular expression for this instruction, and use my tool re-search.py to extract it from the binary shellcode. I want at least 2 consecutive mov … instructions: {2,}.

I’m using option -f because I want to process a binary file (re-search.py expects text files by default).

And I’m using option -x to produce hexadecimal output (to simplify further processing).

I want to get rid of the bytes for the instruction and the offset operand. I do this with sed:

I could convert this back to text with my tool hex-to-bin.py:

But that’s not ideal, because now all characters are merged into a single line.

My tool python-per-line.py gives a better result by processing this hexadecimal input line per line:

Remark that I also use function repr to escape unprintable characters like 00.

This output provides a good overview of all API functions called by this shellcode.

If you take a close look, you’ll notice that the last strings are incomplete: that’s because they are missing one or two characters, and these are put on the stack with another mov instruction for single or double bytes. I can accommodate my regular expression to take these instructions into account:

This is the complete command:

re-search.py -x -f "(?:\xC7\x45.....){2,}(?:(?:\xC6\x45..)|(?:\x66\xC7\x45...))?" shellcode.bin.vir | sed "s/66c745..//g" | sed "s/c[67]45..//g" | python-per-line.py -e "import binascii" "repr(binascii.a2b_hex(line))"

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

Monday 28 May 2018

Quickpost: Windows Debugger as Post Mortem Debugger – 32-bit & 64-bit

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

I was following Microsoft’s advice to install WinDbg as a post mortem debugger, but didn’t get the expected results.

It turns out that WinDbg x64 version will register itself as the post mortem debugger for 64-bit and 32-bit processes, and not just for 64-bit processes:

Of course, WinDbg x86 version will register itself only for 32-bit processes:

So to make sure that WinDbg x64 version will debug only 64-bit processes and WinDbg x86 version will debug 32-bit processes, run the post mortem registration commands in this order:

"c:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe" -I
"c:\Program Files (x86)\Windows Kits\10\Debuggers\x86\windbg.exe" -I

And of course, run the commands from an elevated command prompt, as you’ll need to write to the HKLM hive. Otherwise you’ll get a reminder:

 


Quickpost info


Tuesday 23 May 2017

WannaCry Simple File Analysis

Filed under: Malware,My Software,Reverse Engineering — Didier Stevens @ 7:32

In this video, I show how to get started with my tools and a WannaCry sample.

Tools: pecheck.py, zipdump.py, strings.py

Sample: 84c82835a5d21bbcf75a61706d8ab549

Monday 30 January 2017

Quickpost: Dropbox & Alternate Data Streams

Filed under: Forensics,Quickpost,Reverse Engineering — Didier Stevens @ 0:00

When I got this popup while moving a file from a Dropbox folder, I immediately thought Alternate Data Stream:

20170124-221042

I ran my filescanner on the file, and found an ADS with name com.dropbox.attributes:

20170128-094319

From the Magic HEX value, we can see that the content of the stream (frozen-sea-foam.mp4:com.dropbox.attributes) starts with 0x78 (and the streamsize is 83 bytes). 0x78 hints at zlib deflated data.

If you are not that familiar with magic values, you can use my file-magic tool:

20170128-224649

Trying to decompress the ADS with translate.py gives us JSON data {“dropbox_fileid_local”: {“machineid_attr”: {“data”: “aa4xliox7z5n0qewxOlT3Q==”}}}:

20170128-102645

The data field looks like BASE64, so let’s try to decode it with base64dump.py:

20170128-104110

It decodes with BASE64 to data that looks random. From the names in the JSON data, we can deduce that this is probably a machine ID.

Remark 1: as it could well be my unique machine ID, I altered the value of the ID.

Remark 2: my file-magic.py tool is beta.

Remark 3: if you wonder what the video frozen-sea-foam is, I have it on Instragram.

 


Quickpost info


Next Page »

Blog at WordPress.com.