You are browsing the archive for Silly.

Batch decompilation with IDA / Hex-Rays Decompiler

July 4, 2019 in IDA/Hex-Rays, Random ideas, Reversing, Silly, Tips & Tricks, Trivia

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.

Re-usigned binaries: NVFBC Screen & Video Capture library

June 7, 2019 in Living off the land, LOLBins, Malware Analysis, Reusigned Binaries, Silly

Traditional screen grabbing malware uses a bunch of GDI APIs: CreateDC, CreateCompatibleDC, CreateCompatibleBitmap, BitBlt. It may also use GDI+ to save screenshots as JPEG, GIF, PNG, etc. There are plenty of code examples online that demonstrate how to do it. Now, it turns out that the very same functionality can be programmed via existing and pretty convenient wrapper libraries that are offered by some of the GFX card vendors.

While poking around NVIDIA files I came across a very intriguing document NVIDIA Capture SDK Programming Guide [PDF Warning]. It describes a set of functions that help to capture screen/video snapshots using a NVIDIA helper library called NVFBC (or NVFBC64 on 64-bit systems). There is also an accompanying document called NVIDIA Capture Sdk Sample Descriptions [PDF Warning] that introduces samples that utilize NVIDIA SDK to do some screen/video capture work.

For instance, NvFBCToSys demonstrates how to use the NvFBCToSys interface to copy the desktop into a system memory buffer and save it as a file. The DX9/DX10/DX11/GL IFR SimpleSample targets DirectX 9, 10, 11, and OpenGL to capture and render target to a file. The DX9IFRSimpleHWEncode
captures a renders target, compresses it, and write it to a video file. Googling around it’s easy to find more samples with a similar code.

So, again, by introducing a signed proxy library one can deliver a desired functionality and potentially evade some of the security tools. Imagine reading and writing files via Java library, taking screenshots via NVFBC library, and utilizing other legitimate libraries for other purposes. You end up with a Frankenstein’s monster, but one that may be harder and harder to distinguish from a legitimate software.