You are browsing the archive for Archaeology.

The risk of falling for a system32 blasé

October 10, 2019 in Archaeology, Undocumented Windows Internals

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


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?


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.


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…

I’M SO excited, Part 2

October 5, 2019 in Archaeology, Uncategorized, Undocumented Windows Internals

In my last post I touched on some basic mso.dll findings. Today we will continue with the same theme, but instead of exported functions, we will focus on low hanging fruits which are… yup, strings. And I don’t mean your usual dump of all strings from a binary (imagine what value you can get from strings ran over a 26MB DLL), but more focused and API-centric strings.

What is the value?

Knowing unique strings used by APIs can help us to narrow down some interesting functionality/features that may be undocumented, or otherwise useful. In my experience, many of these are good starting points for deeper research that culminates in new posts on this blog, or my better understanding of windows internals.

Let’s take Windows Properties for starters. Some of them can be used to code-inject. This offensive train of thought led me to ask a question: does MS Office offer any window properties that allow pointer overwrites? If it does, it is definitely interesting.

I have identified the following Windows Properties set by MSO.DLL:

  • AirSpace::LayerHost
  • AirSpace::FlipModel
  • AirSpace::IsOverlayWindow
  • NUINativeHWNDHost

I know there are more, but they need to be identified either via sandboxing, or better static analysis. I also didn’t identify any that allow pointer overwrites yet, but at least we have our foot in the doors.

There is also a list of atoms mso.dll creates:

  • VertLine
  • HorizSlider
  • ListColumnLabel
  • ColorAreaImage
  • ColorSwatchButtonContainer
  • GroupHeaderContainer
  • ColorSwatchElement
  • ScrollViewer
  • PanViewerScrollButton
  • ButtonDropArrow
  • TreeViewContentImage
  • TreeViewContentLabel
  • TreeViewContents
  • ListViewViewer

At the moment I don’t see any use for these, but again, the more strings you recognize, the less time you need to spend on them in a future & can also use them in exclusions of any sort (e.g. yara strings or code markups).

Another bit that is easy to spot are RichEdit Classes. I used to think I know them all, but mso.dll surprises us again. Here is a list of Window classes mso.dll recognizes:

  • RichEdit20A
  • RichEdit20W
  • RichEdit20WPT
  • RichEdit50W
  • RichEdit60W

Another interesting bits I found are some of the environment variables expected by mso.dll; among these common ones that everyone recognizes we can also see these two weird ones:

  • LORI_099F5E083DF84BC98E90139DFB45C0B9
  • msooaopt

Again, I have no idea what they represent at the moment, but it’s yet another research bit we should pursue.

Okay, now that we had a quick glance over exported functions that are directly mapped to Windows APIs, and unique strings that are easy to include/exclude, we should go a step further.

What about file names or anything that uses a file-extension-like strings e.g. MIME types or Object names?

A quick regexp reveals the following strings of interest:

  • Access.Application
  • AccessAddin.DC
  • AssetLibrary.ico
  • blog_request.xml
  • blog_response.xml
  • client_LocationBasedDefaults.html
  • communicator.ex
  • CompositorFrames.csv
  • ContactPicture.jpg
  • CorelPhotoHouse.Document
  • CsiVersionSupportsSecureHttpRedirection
  • customStreamsXsn.xml
  • DataContext.Label
  • DataSource.Anchor
  • DataSource.CanGrow
  • DataSource.Categories
  • DataSource.Commands
  • DataSource.EventingItem
  • DataSource.FilterIndex
  • DataSource.FilterItems
  • DataSource.HelpId
  • DataSource.HighlightedItem
  • DataSource.HighlightedValue
  • DataSource.ImageSource
  • DataSource.InRibbonItemsHeight
  • DataSource.InRibbonItemsWidth
  • DataSource.IsAnchorEnabled
  • DataSource.IsAnchorPressed
  • DataSource.IsAutoCompleteEnabled
  • DataSource.IsBitFiltering
  • DataSource.IsDropFullWidthEnabled
  • DataSource.IsDropped
  • DataSource.IsFilterVisible
  • DataSource.IsScrollToSelectedEnabled
  • DataSource.IsSelectionRequired
  • DataSource.Items
  • DataSource.ItemsHeight
  • DataSource.ItemsWidth
  • DataSource.Label
  • DataSource.Layout
  • DataSource.ResizeType
  • DataSource.SelectedItem
  • DataSource.SelectedString
  • DataSource.SelectedValue
  • DataSource.StatusText
  • DataSource.SuperTip
  • DataSource.Tooltip
  • DocumentRepository.ico
  • EasyPhoto.Photograph
  • editdata.mso
  • Excel.Application
  • ExcelPlugInShell.PowerMapConnect
  • exp_pdf_server.dll
  • FaxImage.tif
  • GetFeatureDS.cs
  • HiJaak.Image
  • Imaging.Document
  • InfoPath.Application
  • infref.chm
  • InternalTailDS.HighlightedItem
  • InternalTailDS.ListHeight
  • InternalTailDS.SelectedItem
  • InternalTailDS.TailContext
  • IPM.Appointment
  • IPM.DistList
  • kernelBase.dll
  • meetings.asmx
  • mergedoc.rcd
  • METTrace.log
  • mscreate.dir
  • msodatalast.dat
  • msohdinh.tmp
  • msosqmcached.dat
  • MySharePoints.ico
  • Node.StyleTree
  • Normal.dotm
  • NormalEmail.dotm
  • ODC.TableCollection
  • office-AppPrivilege.OPEP
  • OscAddin.SharePointProvider
  • Outlook.Application
  • Outlook.FileAttach
  • Paint.Picture
  • PersonaMenus.ribbonpp
  • pg_custom.xml
  • Photohse.Document
  • PhotoSuite.Image
  • PowerPoint.Application
  • PowerPoint.Slide
  • proppanel.xsn
  • prottpln.doc
  • RenderFrames.csv
  • sampledata.xml
  • SharePointPortalSite.ico
  • SharePointTeamSite.ico
  • skydocsservice.svc
  • SocialConnector.dll
  • typeSchema.xsd
  • UIAutomationCore.DLL
  • verifier.dll
  • WangImage.Document
  • Word.Application
  • Word.Document
  • xlimpconv.dll

As I go through functions that reference these strings I gain more insight into logging, debugging functions that are built-in into MS Office. In fact, the Office persistence mechanisms I discovered in the past are a direct result of digging in some of these artifacts…

And now it’s time to introduce a MsoFWzEqual and MsoFSzEqual functions that mso.dll relies on to compare many strings. I cannot list all the strings that these 2 functions operate on, but many of them are good pointers for further analysis as well. The comparisons include file extensions, MIME types, data block headers, etc. Yup, they are used during data parsing so highly possible there will be some vulns possible…

Not much, but at the same too much. You be the judge…