When you stare at the code of OS binaries for a long time, you will eventually collect a list of curiosities that serve as an anecdotal proof that software, same as security, is… a state.
Some of these curiosities is just a legacy code that still makes it to the latest OS releases.
Some are legacy code that was there for a long time, but was eventually removed in newer OS versions. For example notepad.exe retrieving the ancient system metrics SM_PENWINDOWS (expected to return an address of a DLL!), and then resolves its function RegisterPenApp and… call it.
Some are just obvious copypasted code blocks. Despite the existence of libraries that can share code, it’s obvious that some of the projects were literally build upon the same source code that was eventually compiled into many final binaries. And funnily enough, it’s not uncommon to find binaries where one has the symbols available, or richer, or where symbols are named slightly different way than the other. Presence of the same code can be often leveraged to enrich the listings of binaries where the symbols are not available.
Some are hidden exports in drivers.
Some are Unicode characters outside of 16-bit set.
Some are references to project names and neologisms e.g. ProjectCentennialDogfood, or daVincisGarageLLC.LarryBooBoo (you will find these inside Windows 10’s explorer.exe).
And… some seem to be just silly typos that probably escaped the code / localization QA process. In fairness, the typos are actually pretty rare, so anytime I come across one I jot them down. And I am not sure if they are real typos, or perhaps some sort of way to watermark the binaries? Who knows… This is a list I came across so far:
- ole32.dll
- registers strangely named messages:
- OM_POST_WM_COMMAND
- OLE_MESSAHE
- why not ON_POST_WM_COMMAND and OLE_MESSAGE?
- registers strangely named messages:
- riched20.dll
- registers MSH_WHEELSUPPORT_MSG; why not MSG_WHEELSUPPORT_MSG
- TPSvc.dll
- registers TOOLBAR_RESETKEYBAORD message – an obvious typo
