Wat binaire Windows-bestanden verraden
Wat binaire Windows-bestanden allemaal verraden
Uitvoerbare Windows-bestanden (.exe, .dll, .sys …) verraden veel meer over hun herkomst, de gebruikte tools en zelfs over de programmeerstijl dan je zo zou denken. Ook kun je daarmee te weten komen hoe modern softwareconcerns zelf eigenlijk te werk gaan als ze ons de hele tijd met updates lastigvallen.
Programma's onder Windows hebben in de regel een bestandsformaat dat Microsoft gespecificeerd heeft als Portable Executable (PE). In de headers daarvan zit vaak ook gedetailleerde informatie over de exacte versies van de gebruikte compiler, assembler, linker en import- en exportbibliotheken. Daarmee is te herkennen of het programma met C, C++ of met andere compilers of zelfs in assembler gemaakt werd en op welk updateniveau het zit.
Er zijn veel verschillende PE-bestanden, en niet alleen met de extensie .exe, .dll en .sys. Op Windows-computers staan meestal vijftig en meer verschillende typen met het PE-bestandsformaat – of ze nu .ocx,. scr, .efi, .bin, .tlb, .cat, .mui of nog wat anders heten.
Veel daarvan, zoals bestanden die eindigen op .api, zijn in feite niet meer dan hernoemde DLL's. Ze zijn niet direct uitvoerbaar, maar bevatten wel uitvoerbare segmenten. Andere zijn überhaupt niet uitvoerbaar, waaronder pure databestanden met extensies als .tlb, .rsc, .dll en dergelijke. Dat zijn vaak zogeheten resources, met name taalpakketten, die vaak de extensie .mui (Multi User Interface) hebben.
Bestanden met de extensies .com, .edi, .scr en .sfx zijn normaal gesproken uitvoerbaar. Omdat de naam van de extensie echter willekeurig is, is dat alleen zeker te bepalen aan de hand van de entry's in de PE-header. Bestanden met .scr (zoals C:\windows\system32\bubble.scr) zijn bedoeld voor screensavers. Die extensie wordt door malware vaak misbruikt omdat die daar redelijk onopvallend mee gestart kan worden. Bestanden met .efi zijn wel uitvoerbaar, maar niet onder Windows, alleen onder UEFI. In de PE-header staat namelijk ook onder welke besturingssystemen een programma wil draaien en bij welk subsysteem het hoort (Windows-console, Windows-GUI, OS/2, CE, EFI-applicatie, EFI-driver, Xbox …). Hier en daar heb je nog bestanden met de extensie .com, bijvoorbeeld mode.com, format.com en tree.com in Windows\system32. De namen stammen nog uit het goede oude DOS-tijdperk en zijn ook gewoon te hernoemen naar .exe. Dat Microsoft zijn Visual Studio traditioneel via devenv.com laat starten, is meer een grapje van de programmeurs.
Een belangrijk item in de PE-header is de linker-versie. Dat is de tool die het PE-
bestand gemaakt heeft. Daar kun je al aan herkennen of vermoedelijk een Microsoftlinker gebruikt werd (met gangbare waarden tussen 5.0 en 14.0) of Borland (meestal tussen 2 en 3) of wellicht helemaal geen linker, maar een 'wrapper' voor DotNet. Die zet daar al een paar jaar de versie van het gebruikte DotNet-framework in als 35 of 40 of meer. Ook aan de 'DOS-stub', een stukje code dat onder DOS draait en aangeeft dat het programma niet geschikt is voor DOS, kun je al een en ander herkennen.
De standaardcode van Microsoft bevat de string "This program cannot be run in DOS mode", terwijl Borlands Tlink32 daar "This program must be run under Win32" aangeeft.
De Rich-header
Wat Microsoft echter niet gedocumenteerd heeft – en er bij andere linkers als die van Borland ook helemaal niet is – is een kleine structuur achter die DOS-stub (normaal vanaf offset $80). Begin deze eeuw zorgde die voor veel ophef. Complotdenkers kenden daar onheilspellende kenmerken aan toe, maar het duurde niet lang voordat anderen erachter kwamen waar het om ging. In die structuur zit informatie over de bij de build gebruikte tools, maar dan beveiligd met een eenvoudige XOR-versleuteling. Een voorwaarde is dat die tools in de gemaakte objectbestanden (.obj) en bibliotheken (.lib) hun ID's in de variabele @comp.id hebben gezet en dat een Microsoft-linker vanaf versie 5.0 wordt gebruikt, die verantwoordelijk is voor het maken van de PE-bestanden.
Door het kenmerk 'Rich' aan het eind van die structuur heet die sindsdien de Rich Header of Rich-structuur. De 32-bit key voor het ontsleutelen staat daar meteen achter. Die wordt uit de bytes in de PE-header voor de Rich-structuur en de entry's gemaakt. Als je die key XOR't met de rest van de structuur, krijg je als eerste het kenmerk 'DanS', dan driemaal de key en dan de lijst van versie-entry's. De kenmerken Rich en DanS verwijzen vermoedelijk naar de namen van de programmeurs: DanS is dan Dan Ruder, Microsofts linker-expert.
Maar ook als je die structuur ontsleuteld hebt, blijft het probleem de gevonden entry's toe te schrijven aan de talrijke tools, versies, builds, updates et cetera. Door gebrek aan documentatie is dat een blinde vlek. Twee projecten op GitHub houden zich daar mee bezig: Detect It Easy – dat bovendien een grote database heeft voor het herkennen van allerlei mogelijke bestandsformaten en ook overweg kan met de gebruikelijke packers – en het project Richprinter, dat zich alleen beperkt tot het weergeven en interpreteren van de Rich Header van PE-bestanden. Alle genoemde tools en documenten staan overigens bij de link aan het eind van dit artikel.
Richprint heeft in de loop der tijd een heleboel informatie verzameld om preciezer te kunnen zijn over de linker, compiler, assembler, resource-compiler en import- en exportbibliotheken. Richprint wordt nog steeds bijgewerkt, de nieuwste items hebben te maken met de verschillende versies van Visual Studio 15.
Sinds Microsoft openbare bètaprogramma's voor Visual Studio heeft, is er een inflatie aan versiekenmerken. Inmiddels zijn er naast community-previews, RC's (release candidates), RTM's (Ready To Market) nog Updates 1, 2, 3, 4, 5 … en zo verder. Voor VS2015 (linker-generatie 14.0) kwamen we al meer dan 30 verschillende ID's tegen. Daarvan is minstens een zestal in commerciële software terecht gekomen. De huidige database van Richprint heeft zes pakket-entry's – ten dele met geïnterpoleerde ID's voor de afzonderlijke tools. De Rich-kenmerken van een tool bestaan uit de 16-bit pakket-ID (het buildnummer van het bijbehorende Visual Studio-pakket), gevolgd door de eveneens 16-bit tool-ID. Die tool-ID was tot en met Visual Studio 2013 slechts 8-bit, inmiddels wordt ook het negende bit gebruikt. Daarna komt nog een teller die het aantal ermee gemaakte modules aangeeft. Met '24215' wordt bijvoorbeeld Visual Studio 2015 Update 3.1 Build 24215 aangegeven. De tool-ID 261 (hexadecimaal $105) staat voor de C++-compiler uit die suite.
Het laatste item in de Rich-structuur stamt van de tool die het PE-bestand gemaakt heeft. Normaal is dat de Microsoftlinker. Daarvoor staat meestal de compiler van het hoofdprogramma met het programma-entry-point. Als beide ID's op nul staan ('0-0'), dan gaat het om een andere compi-
ler zonder @comp.id die wel de Microsoftlinker gebruikt, bijvoorbeeld Composer van Intel.
Tegenwoordig is de laatste tool die wat met de code doet vaak een programma voor de digitale ondertekening. Die heeft geen pakket-ID, maar daar gebruikt de linker in ieder geval een tool-ID voor, meestal 151 ($97), dus '0-151'. Een bijzonderheid zijn de modules uit de kernel-bibliotheek, die met '0-1' worden aangegeven.
Bij de uitvoerbare bestanden horen de zogeheten 'wrappers'. DotNet-programma's hebben zoals eerder gezegd geen linker. Je kunt ze echter als .exe in een PE-bestandsformaat pakken en rechtstreeks starten. Bij Python-programma's werkt dat hetzelfde. Bestanden met de extensie .pyc en .pyo zijn gecompileerde bytecode – die verder gewoon sequentieel geïnterpreteerd wordt, dus niet noemenswaardig sneller is dan broncode. Op Windows-pc's staan normaal gesproken Python-dll's die je kunt herkennen aan .pyd. Ze worden via python.dll aangeroepen.
Dergelijke python-dll's worden bijvoorbeeld door OpenOffice en het opensource beeldbewerkingsprogramma GIMP gebruikt. Ook het hardeschijfanalyseprogramma Autopsy en de Intel Composer werken met dergelijke ingepakte Python-scripts.
Programma's of programmaketens worden bovendien vaak ingepakt. De opensource packer UPX (Ultimate Packer for eXecutables) is populair. Die staat inmiddels op GitHub in versie 3.93. Met UPX ingepakte programma's kun je makkelijk herkennen aan hun segmentnamen UPX0, UPX1 … Voor de set-up, de (de)installer en packer kom je nog redelijk vaak de oeroude Inno Setup-module 5.3.10 tegen – in Delphi 2.0. De Inno Setup 5.57 is wat nieuwer met Delphi 2009. Daar wordt bijvoorbeeld de huidige SiSoft Sandra mee geïnstalleerd. Microsoft gebruikt zijn eigen inpakprogramma's.
Doorscannen
We hebben een aantal computers met Windows 10 hier op de redactie eens doorgelicht. De vroegste bestanden met Rich-entry's stammen uit 1998 – afgezien van wat verkeerd ingestelde datums door Microsofts Phone-SDK 8.1. Toen was Visual Studio 93 SP3 (codenaam Boston) de actuele versie, eerst met de linker ML 6.12.7146, later met ML 6.13.7299. Als eerste Rich-kenmerk staat daar 7303-02.
Een van de oudste tools die van Rich voorzien is, komt van de InstallShield Software Corporation. Die veteraan heet _isdel. exe versie 5.54 en staat bij een 64-bit Windows in C:\Windows\SysWOW64\InstallShield\.
Microsoft heeft DotNet met C# uitgevonden en geprobeerd om programmeurs over te halen naar DotNet over te stappen, maar bij eigen applicaties zoals Office wordt DotNet in verhouding weinig gebruikt. Hier en daar een keer een kleine tool als spreadsheet-compare.exe, maar alle belangrijke programma's zoals Excel, Word, PowerPoint, Acces en Outlook zijn met C/C++ gemaakt. Daarbij liepen de Office-ontwikkelaars lange tijd altijd twee of drie generaties achter op de actuele eigen versies van Visual Studio. De build van juni vorig jaar van Office 15 heeft bijvoorbeeld het pakket/link-kenmerk 30716-186. Dat hoort bij Visual Studio 2010 met linker 10.10. Microsoft gebruikt overigens intern graag interimversies die 'buiten' helemaal niet beschikbaar zijn. Pas bij Office 2016 uit december 2016 lukte het Microsoft naar een enigszins actuele Visual Studio 2015 23919 over te stappen. Ook die versie komt in het wild niet voor, zodat je niet precies weet op welk updatelevel hij zit. De dichtstbijzijnde Update 2 van de community-versie heeft in ieder geval kenmerk 23720.
Oude runtime-omgevingen worden door Microsoft altijd nog onderhouden. MSVCP60.dll voor VC6 werd voor het laatst in juni 2016 nog bijgewerkt – VC6 wordt immers nog veel gebruikt. Adobe heeft bij zijn producten voor lange tijd aan VC6 vastgehouden. PhotoShop-versie CS2 is daar in 2002 mee gemaakt, en die is nog altijd erg populair, te meer omdat Adobe die voor algemeen gebruik heeft vrijgegeven. Bij Acrobat Reader is Adobe op een gegeven moment overgestapt op Visual Studio. Bij de huidige versie gebruiken de Adobe-programmeurs de al wat oudere Visual Studio 2014-40629. Daar is Adobe altijd nog actueler mee dan Oracle, waarvan Java 8.1 nog op de oude Visual Studio 2010-40219 gebaseerd is. Terwijl Oracle toch zo graag updates wil uitvoeren.
De nieuwste versie PhotoShop CC is ook wat betreft de gebruikte compiler helemaal
bij de tijd. Daar wordt de Intel Composer 2016 met MKL, OpenMK en Fortran-Core bij gebruikt.
Verder kom je weinig software tegen die met de erg efficiënte Intel-compiler is gemaakt, met uitzondering van High Performance Computing. Cinebench R15 heeft veel met '0-0' gemarkeerde modules – en zoals je aan de libs ook kunt zien, wordt daar de Intel-compiler bij gebruikt.
Mozilla is met Firefox op basis van Visual Studio 2015-24213 redelijk bij de tijd, maar Thunderbird hinkt daar met Visual Studio 2013-30723 weer wat achteraan.
MinGW wordt met zijn eigen linker overigens vaker gebruikt dan de Intel-compiler, bijvoorbeeld bij GIMP 2.8.20. Versie 1.01 van Detect It Easy herkent ook de MinGW-versies. Samen met het project Richprint krijg je dan een redelijk beeld van de binaire bestanden op een Windows-computer. We hebben het door Richprint gebruikte bestand compid.txt (zie de link hieronder) nog flink uitgebreid met de entry's die we onderweg tegenkwamen. (nkr)