Category Archives: Archaeology

Re-sauce, Part 1

Posted on by

PE Resources are like an unwanted child of malware analysis and reverse engineering. Almost no one talks about them and… this post is going to… make it worse ;).

Let’s take a large number of ‘bad’ samples, export their resource information, and do some data crunching… we now have some stats.

What are the most popular resources?

These are:

4720830   RT_ICON (3) -
4703093   RT_GROUP_ICON (14) -
3445748   RT_VERSION (16) -
2574034   RT_MANIFEST (24) -
2291058   RT_DIALOG (5) -
2022739   RT_STRING (6) -
1564623   RT_RCDATA (10) -
1193659   RT_BITMAP (2) -
1159726    'DVCLAL' -
1050941    'PACKAGEINFO' -
 931572    'MAINICON' -
 903265   RT_CURSOR (1) -
 884868   RT_GROUP_CURSOR (12) -
 557473    'BBABORT' -
 551898    'BBALL' -
 551836    'BBOK' -
 551785    'BBNO' -
 551023    'BBRETRY' -
 542886    'BBIGNORE' -
 542836    'BBHELP' -
 542834    'BBCLOSE' -
 542593    'BBYES' -
 541708    'BBCANCEL' -
 498816    'PREVIEWGLYPH' -
 497272    'DLGTEMPLATE' -
 358081   RT_MENU (4) -
 199615    'TFORM1' -
 174781   RT_ACCELERATOR (9) -

These with a RT_prefix are standard resource types defined by Microsoft, and the ones in apostrophes are strings that ‘tag’ (or ‘name’) the resources according to developer’s wishes…

Given a number of these ‘named’ ones used repeatedly (as shown by the list above) you can guess that they are somehow ‘known’, or a part of some ‘standard’ — and yup, these are primarily from Borland/Delphi/Embarcadero family of executables that include standard GUI elements from this platform. All ‘BB*’ and ‘T*’ come from this environment. Additionally ‘PACKAGEINFO’ is a resource I covered a little bit in the past – it lists all the packages the executable uses (a good IOC except no one writes malware in Delphi anymore).

Surprisingly, modern PE Viewers and Editors do not parse PE resources very well. They only show the most popular resource types, because the others are often … undocumented. I really don’t like to look at resources in hex view. We can do better.

Let’s start with these that are ‘kinda documented’.

For instance, Resource Hacker can handle some Delphi resources (e.g. forms) pretty well:

A popular ‘Typelib’ resource:

can be viewed with OleView:

The ‘Registry’ is typically an embedded ‘.reg’ file.

A ‘FOMB’ is a binary MOF that was described in this post by FireEye and can be decoded using bmfdec.

What about the others?

And this is where it gets really difficult…

Looking at resources embedded in Windows 10 exe, dll, ocx files one can very quickly build a list of more or less enigmatically-looking resource names:

  • ACCELERATOR
  • ANICURSOR
  • AVI
  • BINARY
  • BITMAP
  • BITMAP4
  • BRANDING_METADATA_RES
  • BRANDING_REQUIRED_RESOURCEID_MAP
  • CERT
  • CODEPAGES
  • CODEPAGESEXT
  • CURSOR
  • DATA_FILE
  • DATAFILERESOURCE
  • DGML
  • DIALOG
  • DUI
  • EDPAUTOPROTECTIONALLOWEDAPPINFOID
  • EDPENLIGHTENEDAPPINFOID
  • EDPPERMISSIVEAPPINFOID
  • EMBEDDEDDATA
  • FILES
  • FLEX_TABLE
  • FLEXDL
  • FONT
  • FONTDIR
  • FONTFALLBACK
  • GIF
  • GROUP_CURSOR
  • GROUP_ICON
  • HTML
  • HWB
  • HWXLANGID
  • IBC
  • ICON
  • IMAGE
  • JPEG
  • JS
  • JSON
  • JSON_RESPONSE
  • MANIFEST
  • MENU
  • MESSAGETABLE
  • MOFDATA
  • MSTESTROOT
  • MUI
  • PNG
  • PNGFILE
  • PRELOAD
  • PRXFILE
  • RCDATA
  • REGINST
  • REGISTRY
  • RGSLIST
  • SCHEMA
  • SIAMDB
  • SKDFILE
  • SRGRAMMAR
  • STYLE_XML
  • TESTROOT
  • TEXT
  • TEXTINCLUDE
  • TUNINGSPACE
  • TYPELIB
  • UIFILE
  • VR_ETW_MANIFEST
  • VR_ETW_RESOURCE
  • VSGEXP
  • WAVE
  • WEVT_TEMPLATE
  • XML
  • XML_FILE
  • XML_SCHEMA
  • XMLFILE
  • XSD
  • XSDFILE
  • XSLFILE

Yup. Some are easy to handle (just by looking at their name e.g. AVI, BITMAP, XML), but… this is just Windows 10.

Time will tell if we will ever see a PE editor/viewer that can handle all of, or at least most of these well.

In the meantime…

Resources is something you may want to look at more closely. Starting today.

Why?

Because of this guy:

I got it from resources of Norton SecureWorks circa 2002-2003. Do you even remember this software existed?

One of cool side-effects of poking around in many resources is coming across weird, unusual strings, texts, images, movies, you name it. You will find developer pictures that were not meant for general public, ‘tagging’ images with names of developers of project managers, jokes, and whatever else. Yes, there is cheezy, there is porn, there are obscenities, there are also Easter Eggs.

If you want to start building your own collection, it couldn’t be easier…

You can simply use:

  • 7z l <filename> .rsrc
    • to list all the resources of a <filename>
  • 7z x <filename> .rsrc’
    • to extract them.

And then start data crunching:

  • Icons are interesting, especially if re-used for malicious purposes (e.g. Adobe, Microsoft) –> there are existing yara sigs for these!
  • Manifest may include references to other executables/DLLs loaded
  • Manifest may also include references to rights required for running the executable (e.g. look for level=”requireAdministrator”)
  • Language information may be helpful with attribution (beware of false flags)
  • Version Information lists lots of interesting information that can be co-related with the information extracted from certificates / signatures, if present
  • Delphi resources are fairly well documented and can be extracted, especially the aforementioned package names — can help to at least cluster samples as per the modules used (may sometimes highlight similar families, plus good for yara sigs)
  • Everything else should be extracted and checked against typical file types/magic:
    • BMP
    • PNG
    • GIF
    • JPG
    • AVI
    • Wav
    • Rtf
    • Ico
    • Cur
    • PE files
    • LE files (older version of MZ executables)
    • MZ files (yup, plain DOS)
    • UTF8/Unicode BOMs
    • Office files
    • etc.

Resources are a very important metadata source for analysts. If you are lucky you may not only get the visuals, but also timestamps (e.g. in Delphi executables).

Be err… resourceful.

The risk of falling for a system32 blasé

Posted on by

Yeah, system32… who cares… so old, so over-explored… nothing to see here…

RIGHT?

Welcome to a post that will ask some questions that will possibly make you ask even more questions.

Have you ever… and I mean.. like… ever… tried to compare the following directories:

  • System32 on a 32- and a 64-bit system (same OS version)
  • System32 on a 64-bit system vs. SysWOW64 on a very same 64-bit system?

No?

Welcome… to a system32 blasé effect.

We take system32 for granted. It’s there, it has its own vulns. it has its own features, and we (most of us really) assume that it’s a monolith structure that is just there and never changes, except for the major OS releases.

However…

Putting patches aside, the system32 folder has multiple versions. I alluded to it in my earlier question, but it is a matter-of-fact that you will find different versions of system32 folder not only on different versions of Windows OS, but also… the very same versions as well. This is because they differ not only by a version number, but also by their architectural ‘geoposition’…

Let me explain…

When you compare a list of exports from a kernel32.dll that is taken from a 64-bit OS against a 32-bit version of OS (e.g. from Windows 10, same version) you will quickly notice that the 64-bit version exports more APIs. However. the 32-bit version exports a number of APIs that are not exported by 64-bit version either. So… We are talking two different metadata sets… and one is not a subset of another.

The 32-bit version has the following additional APIs not present in a kernel32.dll compiled for 64-bit:

  • CreateSocketHandle
  • GetHandleContext
  • InterlockedCompareExchange
  • InterlockedCompareExchange64
  • InterlockedDecrement
  • InterlockedExchange
  • InterlockedExchangeAdd
  • InterlockedIncrement
  • SetHandleContext

And the 32-bit kernel32.bit is missing the following APIs that are present inside a 64-bit kernel32.dll:

  • __C_specific_handler
  • __chkstk
  • CreateUmsCompletionList
  • CreateUmsThreadContext
  • DeleteUmsCompletionList
  • DeleteUmsThreadContext
  • DequeueUmsCompletionListItems
  • EnterUmsSchedulingMode
  • ExecuteUmsThread
  • GetCurrentUmsThread
  • GetNextUmsListItem
  • GetUmsCompletionListEvent
  • GetUmsSystemThreadInformation
  • _local_unwind
  • __misaligned_access
  • QueryUmsThreadInformation
  • RtlAddFunctionTable
  • RtlCompareMemory
  • RtlCopyMemory
  • RtlDeleteFunctionTable
  • RtlInstallFunctionTableCallback
  • RtlLookupFunctionEntry
  • RtlRaiseException
  • RtlRestoreContext
  • RtlUnwindEx
  • RtlVirtualUnwind
  • SetUmsThreadInformation
  • uaw_lstrcmpiW
  • uaw_lstrcmpW
  • uaw_lstrlenW
  • uaw_wcschr
  • uaw_wcscpy
  • uaw_wcsicmp
  • uaw_wcslen
  • uaw_wcsrchr
  • UmsThreadYield

You may think that it’s okay, nothing to see here. It’s obvious that different architectures will ask for different exported APIs, different handling of some system events, etc.

But again… however…

You need to look at all these files: DLLs, EXEs, etc. as completely different binary compositions. They follow a different logic, they obey different rules, and can be vulnerable to completely different set of attacks. Yes. There is a code inside a 32-bit kernel32.dll that you won’t find in its 64-bit equivalent, and vice versa. Repeat after me: These. Are. 2. Different. Dlls. Cousins, but not twins. Apply the very same logic to every single common OS DLL name you know.

And to be more specific… when you compare the allegedly same code base between 32- and 64-bits you will find lots of differences. The WOW64 layer, and associated with it Registry Entries that are very expected to be there are one thing, but there is definitely more. Decompiling both binaries and looking at their string references shows that many of 32-bit references are simply gone inside a 64-bit version. The 64-bit version is obviously stricter, and less concerned about compatibility-down, hence the code is defo simplified…