Category Archives: Reversing

Quick & Dirty Sysmon Replacement aka Process Hacker logging

Posted on by

Sysmon is great, no doubt. However… very often an overkill.

Yes, you’ve read this right. I say: who cares about registry writes, process access, driver or module loads, etc. ? What if we just want to log running processes?

Process Hacker comes to our rescue.

The recent versions of this tool include a very handy logging capability that is available not only from a GUI level (CTRL+L keyboard shortcut), but also helps to write stuff that is ‘happening’ directly to a log file – yes, as it happens.

I find it very useful as it helps to monitor unusual activity of the system w/o engaging the full-blown capabilities of Sysmon (performance!). And yes, I do know how weird it sounds… Sysmon cures everything…

How do we set our Process Hacker instance to deliver all this goodness?

We first run Process Hacker with our Admin creds. Then we open Hacker \ Options menu item:

Then choose one of the ‘Notification’ options and either leave it as it is (log everything) or we write down our own rules that can either include or exclude certain paths….

In the below example we include all the process names:

and then we exclude notepad*.exe:

We can include/exclude both processes and services. This is awesome. It’s simple, it’s working.

And if you are curious where the information about these is stored, look for a `ProcessHacker.exe.settings.xml`file that lists the following:

  <setting name="ProcessHacker.ExtendedNotifications.LogFileName">LOGFILEPATH</setting>
  <setting name="ProcessHacker.ExtendedNotifications.ProcessList">PROCESSLIST</setting>
  <setting name="ProcessHacker.ExtendedNotifications.ServiceList">SERVICELIST</setting>

where PROCESSLIST/SERVICELIST has a form of:

  • \e<pattern for exclusion
  • \i<pattern for exclusion

That’s it really… Nothing ground breaking, but a very handy tool for quick & dirty investigations. I find it most useful to detect ‘funny’ Windows 10 services that start ‘out of nowhere’. I then… usually kill them. One by one, you may eventually kill’em all…

Oh yeah.. it may help with malware analysis too 😉 but somehow.. the analysis techniques and priorities changed a lot over last few years…

Batch decompilation with IDA / Hex-Rays Decompiler

Posted on by

if you are very used to 32-bit IDA you may sometimes find yourself in a blind alley when you try to port your working solution to IDA 64-bit. This was the case with my old batch decompilation script.

The way it works is very simple – for every <file> in a folder, run IDA in its automation/batch mode mode, decompile the <file>, and finally save it in a <file>.c file – more or less like the below (I am omitting the loop):

c:\Ida\idaw.exe -A -Ohexrays:-new:%%k.c:ALL “%%k”

Nothing could be simpler.

Until you run it with the 64-bit idaw64.exe:

c:\Ida\idaw64.exe -A -Ohexrays:-new:%%k.c:ALL “%%k”

It doesn’t work. It loads idaw64 and just stays there.

The gotcha is in a plug-in name. The 64-bit decompiler’s plugin name is not hexrays, it’s not hexrays64 either. It is actually hexx64.dll.

So, you have to run this instead:

c:\Ida\idaw64.exe -A -Ohexx64:-new:%%k.c:ALL “%%k”

It’s ridiculously trivial, but it’s always the little things.

Also, interestingly, when you google hexx64.dll or hexx64.p64 you only get a few hits. As if not too many ppl ever came across the issue.

Another gotcha is that if you run it with too many files, your system’s performance will deteriorate quickly. I don’t know if it is memory fragmentation/leaks, or something else, but after running the script on a number of samples I observed my VM dying on me and requiring a restart due to low memory (despite no other process running on a 2G RAM guest). If you know what causes it I would be grateful if you could let me know.

The third gotcha is to rely on the text version of IDA for this task – it is faster than the GUI version. At least in my experience.

Finally, the last gotcha is to remove all the other plugins from the IDA’s Plugins directory, other than the one you are using e.g. hexrays. Why? This may look like nothing, but IDA enumerates and loads all of them _each_ time it starts.