Category Archives: Malware Analysis

The not so boring land of Borland executables, part 1

Posted on by

“Borland”, “Inprise”, “Code Gear”, “Embarcadero”, “Delphi”, “C++ Builder”, as well as “Boolean”, “False”, “True”, “System”, “AnsiChar” are keywords that are very familiar to anyone who reverse engineers executables on regular basis. Seeing them is a good indicator that the samples we look at were most likely produced by compilers coming either directly, or through its descendants and spinoffs from Borland.

I want to talk about them, because Borland executables can be a goldmine for forensic investigators.

The part 1 will focus on the infamous number 0x2A425E19 (708992537) a.k.a 1992-06-19 22:22:17 (Friday).

This is a compilation timestamp of many Delphi files and let’s face it – it is just simply annoying.

Lots of people complained about it in the past; it is actually a very well-known bug, have not been addressed for many years, and only (as per the note in the link provided): “In Delphi 7 this structure was filled properly, but in 2006 not.” i.e. Delphi 4 – Delphi 2006 do not set this timestamp correctly.

Now, this is actually an interesting forensic artifact as it tells you the file was compiled most likely with Delphi 4 – Delphi 2006.

There is more to it.

If the compilation stamp is wrong you can still manage to win the game. If the Delphi executable has a resource directory you may retrieve its compilation timestamp. It is stored in an old-school DOS time format (note that non-Delphi files store it as an EPOCH timestamp, as per PE documentation; yes, Delphi executables are weird 🙂 ). And lo and behold, it may be actually a compilation timestamp that indicates when the whole thing was compiled, or at least give you a better estimate!

In any case, it’s better than nothing.

Example for the same file:

PE Comp.:    1992-06-19 22:22:17 2A425E19, 708992537
.rsrc comp.: 2010-12-09 14:25:36 3D897332, 1032418098

PE Compilation timestamp is the buggy 1992-06-19 22:22:17, but the .rsrc directory timestamp is a very reasonable timestamp 2010-12-09 14:25:36.

And yes, there is a script that you can use to do a dirty work for ya (use it for Delphi executables only).

perl pect.pl <filename>

Download pect.pl here.

Beyond good ol’ Run key, Part 19

Posted on by

In my last post I mentioned Sysinternals. While combining the info for that post I came across a few things that gave me enough material to write a #19 in the series.

And it’s based on bugs in Sysinternals’ tools. Bugs that can be spotted easily. Today I’ll explain how you can utilize these bugs to create new persistent mechanisms.

Say, you like Process Explorer.

Nowadays 64-bit systems are very popular so running procexp.exe on a 64-bit system ends up with a procexp.exe dropping its 64-bit version into a %TEMP% folder and launching it.

procexp

Now, what you can do is f.ex. copy your notepad.exe to %TEMP% and name it procexp64.exe. Then you need to set up 2 access rights for everyone:

  • One that forbids deleting %temp%\procexp64.exe (on the file itself)
  • One that forbids deleting subfolders and files inside %TEMP% (on the %TEMP% folder); this is btw. one of the WTFs of NTFS system where prohibiting deletion of the files needs to be extended to its parent folder; there must be some reasons for that, but it is not something you can learn about from a cryptic Security Properties tab

From now on, launching procexp.exe on a 64-bit system will always launch notepad.exe. A nice man-in-the-middle attack especially if the malicious notepad.exe actually does spawn the legitimate procexp64.exe and hides its presence somehow from the Process Explorer GUI.

Of course blocking %TEMP% from deletion is a silly idea, but:

  • it is an example only
  • it actually works
  • there are many other ways to prevent deletion of the procexp64.exe by procexp.exe (on exit), or at least ensure the malicious procexp64.exe is restored after it is being deleted

Another bug I spotted was the way vmmap.exe craves for dbghelp.dll.

VMMAP is not a very popular program and I bet not too many people use it daily, but the way it works requires a special attention; it’s an example of a difference between programming for your own use vs. programming for ‘public’. As a non-professional programmer who writes buggy programs every day I am actually quite surprised by it. Yes, it’s that buggy.

Let me elaborate.

VMMAP has a very peculiar way for searching for dbghelp.dll:

First, it searches for the entry in the Registry:

  • HKCU\Software\Sysinternals\VMMap\DbgHelpPath32 = <path to dbghelp.dll>
  • #persistence #1
    • By modifying HKCU\Software\Sysinternals\VMMap\DbgHelpPath32 to point to a malicious DLL we can ensure that DLL is loaded every time VMMAP is launched

If it is not found, VMMAP goes ballistic (#persistence #2..N).

It calls a LoadLibraryW with a NULL which is a (sort of) result of retrieving data from a non-existing HKCU\Software\Sysinternals\VMMap\DbgHelpPath32 value.

This is when things get crazy. The craving goes totally addictive.

NULL is a Pandora’s box (Or’ Pandor’s since the author is a male) open for LoadLibraryW.

It means it will walk through every directory listed in the PATH environment variable and will attempt to load a library called ‘.dll’ from every single directory on that list.

Yes, ‘.dll’ is a valid library name i.e. a NULL with a ‘.dll’ extension.

So, you can place a DLL called “.dll” in any location that is covered by a PATH environment variable and you will have it launched by VMMAP anytime it starts.

You probably want to hear that this is the end of the story.

Not quite so.

There are still a few places to look at:

  • C:\Program Files\Debugging Tools for Windows (x86)\dbghelp.dll
  • C:\Program Files\Debugging Tools for Windows\dbghelp.dll
  • C:\Debuggers\dbghelp.dll

Dropping a dbghelp.dll in the …

yawnz…

you know the drill 🙂