You are browsing the archive for Archaeology.

advpack.dll ! DelNodeRunDLL32 and its flags

November 24, 2018 in Archaeology, Living off the land, LOLBins

It’s one of these “I was looking at something else, and as usual, came across something else” cases. In this particular instance it was the good ol’ DelNodeRunDLL32 function exported by the advpack.dll.

A quick search followed, and I soon discovered that @bohops twitted about it a while ago, so there was not that much to add…

However…

Looking closer at the DelNodeRunDLL32W function I noticed that it tries to take two arguments, not one, as originally assumed. If the second argument is not present, it is assumed to be 0.

Why not checking what the second argument is all about though? And here we are…

A few more Google searches later we can (re-)discover that DelNodeRunDLL32 function can delete both individual files, and whole directories + change its behavior if we ask it too.

How?

Via its flags. Ones that we can choose to pass via a command line argument (the second one, as you guessed by now).

Again, googling around I came across this header file that lists all the flags that are documented:

// FLAGS:
#define ADN_DEL_IF_EMPTY 0x00000001 // delete the directory only if it's empty
#define ADN_DONT_DEL_SUBDIRS 0x00000002 // don't delete any sub-dirs; delete only the files
#define ADN_DONT_DEL_DIR 0x00000004 // don't delete the dir itself
#define ADN_DEL_UNC_PATHS 0x00000008 // delete UNC paths

Running

  • rundll32.exe advpack.dll,DelNodeRunDLL32 “c:\test” – will wipe out the whole ‘test’ directory
  • rundll32.exe advpack.dll,DelNodeRunDLL32 “c:\test\file” – will delete the ‘file’ only
  • rundll32.exe advpack.dll,DelNodeRunDLL32 “c:\test”,4 – will wipe out the whole ‘test’ directory except the ‘test’ directory itself
  • rundll32.exe advpack.dll,DelNodeRunDLL32 “c:\test”,1 – will wipe out the whole ‘test’ directory only if it is empty

Little trivia, but always…

logman & API Trace & lame anti-tracing trick :)

July 13, 2018 in Archaeology, Malware Analysis, Undocumented Windows Internals

As I explained in my older post I was playing around with an obscure logman functionality that could be used for API Tracing.

Using these two commands:

logman create api foo -f bincirc 
-exe c:\windows\notepad.exe
-o c:\test\notepad.etl
logman start foo

one can start tracing API calls inside the Notepad. The resulting .etl file can be then parsed with ETL Parser – a really cool tool from @HECFBlog‘s @nicoleibrahim.

When I came across it I thought API Tracing supported natively by OS is a cool and promising feature. So I thought at first… then I started digging deeper. In particular, I was curious how the functionality was implemented and why it didn’t work on Windows 10. After some poking around I think I found the answers.

The functionality is implemented via Application patching using these SDB databases:

  • c:\WINDOWS\AppPatch\sysmain.sdb – 32-bit Win7
  • c:\WINDOWS\AppPatch\AppPatch64\sysmain.sdb – 64-bit Win 7, at least in theory

When used (the actual mechanism of loading the patch is not known to me at the moment), the system loads the following files into a traced application’s process:

  • c:\WINDOWS\AppPatch\apihex86.dll (win7 32)
  • c:\WINDOWS\AppPatch\AppPatch64\apihex64.dll (win7 64), at least in theory

Example from Windows 7 32-bit:

You will find a couple of other libs loaded inside the process as well.

  • amxread.dll – API Tracing Manifest Read Library – possibly mapping APIs to their description (?) – have not spent too much time on it
  • apilogen.dll – API Tracing Log Engine – it is responsible for the actual trace writes; anyone who has too much time on their hand could try to reverse it and improve the API Trace parser, but it’s probably not worth it

With Windows 64-bit I couldn’t make it work despite ensuring all the commands were run from 64-bit processes; so… the ‘at least in theory’ bits are referring to this problem. In any case, it’s probably an obscure mechanism that is no longer supported; this leads us to…

Question #2

Windows 10 doesn’t seem to support it. I couldn’t make it work either + I don’t see the aforementioned DLLs in any of the Windows subfolders. Well, there you go. A cool functionality that never stood a chance…  oh well…

Last, but not least – here’s your promised anti-* trick:

  • check if your program is loading any of these listed DLLs and abort if any is found. I have added these to the list of naughty libraries even I know the usefulness is close to nil. Still, what’s documented is better understood.

And one more bit:

When the command to create API trace is called, the system adds this Reghitry key:

  • HKLM\SOFTWARE\Microsoft\Windows NT\
    CurrentVersion\Schedule\TaskCache\Tree\
    Microsoft\Windows\PLA\foo

and

  • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\
    Schedule\TaskCache\
    Plain\{F95FD9E0-54DB-464C-B379-FF720B10726A}

 

  • HKLM\SOFTWARE\Microsoft\Windows NT\
    CurrentVersion\Schedule\TaskCache\
    Tasks\{F95FD9E0-54DB-464C-B379-FF720B10726A}

It survives the reboot, but the trace needs to be restarted.