Ongeacht of de computer aanstaat of niet, alle gegevens en programma's worden in de vorm van bestanden opgeslagen in het langetermijn (externe) geheugen van de computer - van waaruit ze worden geladen tijdens de uitvoering of verwerking.

Bestand is een bepaalde reeks codes die een bepaalde hoeveelheid informatie weergeven die verband houdt met een type of doel, waaraan een unieke naam is toegewezen en die is opgeslagen in het langetermijngeheugen.

De bronteksten van programma's, kant-en-klare programma's, documenten, grafische afbeeldingen en andere gegevens kunnen in de vorm van bestanden worden opgeslagen. Op basis van het type organisatie en inhoud worden bestanden onderverdeeld in twee categorieën: tekst en binair (binair). Tekstbestanden in overeenstemming met hun doel slaan ze tekenreeksen op die als tekst worden geïnterpreteerd. Uitvoerbare bestanden bestaan ​​uit programmacodes van programma's die gereed zijn voor uitvoering.

Unieke namen bieden een manier om bestanden te ordenen en toegankelijk te maken voor besturingssystemen en andere programma's. De bestandsnaam bestaat uit twee delen, gescheiden door een punt: Eigenlijk Naam bestand en verlenging , waarbij het type wordt gedefinieerd (programma, gegevens, enz.). De bestandsnaam wordt toegewezen door de gebruiker (soms standaard door het systeem). Het bestandstype wordt doorgaans automatisch ingesteld door het programma wanneer het wordt gemaakt, waardoor u in de meeste gevallen het starten van programma's kunt automatiseren. Bijvoorbeeld, .com, .exe– uitvoerbare bestanden (programma's), .txt, .rtf . doc– tekstbestanden, .pas– de brontekst van een programma geschreven in de taal Pascal .

Om de plaatsing van bestanden op schijven te organiseren, worden hun namen geregistreerd in speciale bestanden– mappen (in moderne besturingssystemen worden deze bestanden genoemd mappen) . Catalogus Dit is een tabelbestand (opgeslagen op dezelfde schijf als de bestanden) waarin bestandsnamen, informatie over hun grootte, het tijdstip van de laatste update, bestandskenmerken (eigenschappen), enz. worden opgeslagen. Als een map de naam van een bestand opslaat, wordt vaak gezegd dat het bestand zich in die map bevindt. In werkelijkheid bevindt het bestand zich (opgeslagen) in een bepaald geheugengebied op de computerschijf, vaak in de vorm van verschillende delen, fragmenten op verschillende tracks en schijven van het pakket (op vrije delen van de media). Relevante informatie vindt u in de catalogus.

Elke schijf kan veel mappen bevatten - hun aantal wordt bepaald door de geschiktheid en wordt alleen beperkt door de schijfcapaciteit. Dit geldt ook voor het aantal bestanden in de directory. Alle moderne schijfbesturingssystemen bieden de creatie van een bestandssysteem dat is ontworpen om gegevensopslag te organiseren en er toegang toe te bieden. Het principe van het organiseren van het bestandssysteem is in tabelvorm. Het oppervlak van een harde schijf wordt beschouwd als een driedimensionale matrix, waarvan de afmetingen de oppervlakte-, cilinder- en sectornummers zijn. Onder een cilinder wordt verstaan ​​een verzameling van alle sporen die tot verschillende oppervlakken behoren en zich op gelijke afstand van de rotatie-as bevinden. Gegevens over waar op de schijf een bepaald bestand is opgenomen, worden opgeslagen in het systeemgebied van de schijf in speciale bestandstoewijzingstabellen (FAT-tabellen).

De volgorde waarin bestanden op schijf worden opgeslagen, wordt bepaald door de organisatie bestandssysteem(organisatie van mappen en de methode voor het beschrijven van de plaatsing en attributen van bestanden daarin).

Honderdduizenden bestanden zijn op schijven opgeslagen, dus voor het gemak van zoeken zijn de bestanden georganiseerd in de vorm van een bestandssysteem met meerdere niveaus, dat de structuur heeft die in de afbeelding wordt weergegeven.

De initiële hoofdmap bevat submappen van het eerste niveau, in elk daarvan zijn er submappen van het tweede niveau, enz. Elke map heeft een naam (zonder extensie) en deze kan in een andere worden geregistreerd, ouderlijk catalogus. Opgemerkt moet worden dat mappen op alle niveaus niet alleen mappen, maar ook bestanden kunnen opslaan.

Hoewel bestandslocatiegegevens feitelijk in tabelvorm worden opgeslagen, worden deze voor het gemak van de gebruiker gepresenteerd als hiërarchische boom structuren, en alle noodzakelijke verbindingen worden verzorgd door het besturingssysteem.

Onderhoudsfuncties voor bestandssystemen omvatten de volgende bewerkingen die worden uitgevoerd onder controle van het besturingssysteem:

bestanden maken en benoemen;

mappen aanmaken en benoemen;

het hernoemen van bestanden en mappen;

het kopiëren en verplaatsen van bestanden tussen computerstations en tussen mappen op dezelfde schijf;

bestanden en mappen verwijderen;

navigatie door de bestandsstructuur om toegang te krijgen tot een bepaald bestand of map;

beheer van bestandskenmerken.

Typedef struct _IMAGE_FILE_HEADER ( WORD Machine; WORD NumberOfSections; DWORD TimeDateStamp; DWORD PointerToSymbolTable; DWORD NumberOfSymbols; WORD SizeOfOptionalHeader; WORD-kenmerken; ) IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;
Ik zal deze velden slechts droog beschrijven, omdat... de namen zijn intuïtief en vertegenwoordigen directe betekenissen, en niet VA, RVA, RAW en andere enge, intrigerende dingen waar we tot nu toe alleen van hebben gehoord van oude piraten. Hoewel we RAW al zijn tegengekomen, zijn dit slechts offsets ten opzichte van het begin van het bestand (ze worden ook raw pointers of file offset genoemd). Dat wil zeggen, als we een RAW-adres hebben, betekent dit dat we van het begin van het bestand naar RAW-posities moeten stappen ( ptrBestand+ RAW). Vervolgens kunt u beginnen met het lezen van de waarden. Een sprekend voorbeeld van dit type is e_lfnieuw- die we hierboven onder de Dos-kop hebben besproken.

*Machine: WORD - dit nummer (2 bytes) specificeert de processorarchitectuur waarop deze applicatie kan worden uitgevoerd.
AantalSecties: DWORD - aantal secties in het bestand. Secties (hierna noemen we ze een tabel met secties) volgen onmiddellijk na de header (PE-Header). Volgens de documentatie is het aantal secties beperkt tot 96.
Tijddatumstempel: WORD - een getal dat de datum en tijd opslaat waarop het bestand is gemaakt.
PointerToSymbolTable: DWORD is de offset (RAW) van de symbooltabel, en SizeOfOptionalHeader is de grootte van deze tabel. Deze tafel ontworpen om als opslag te dienen foutopsporingsinformatie, maar het detachement merkte vanaf het allereerste begin van de dienst het verlies van een jager niet op. Meestal wordt dit veld gewist met nullen.
SIzeOfOptionHeader: WORD - de grootte van de optionele header (die onmiddellijk volgt op de huidige) In de documentatie staat dat deze voor een objectbestand is ingesteld op 0...
*Kenmerken: WORD - bestandskenmerken.

* - velden die worden gedefinieerd door een bereik van waarden. Tabellen met mogelijke waarden staan ​​in de structuurbeschrijving op kantoor. website en wordt hier niet vermeld, omdat Ze bevatten niets dat bijzonder belangrijk is om het formaat te begrijpen.

Laten we dit eiland verlaten! We moeten verder gaan. Het referentiepunt is een land met de naam Optioneel-Header.

'Waar is de kaart, Billy? Ik heb een kaart nodig.’
(Schateiland)

Optionele koptekst (IMAGE_OPTIONAL_HEADER)

De titel van dit continent is niet erg goed. Deze header is vereist en heeft 2 formaten PE32 en PE32+ (respectievelijk IMAGE_OPTIONAL_HEADER32 en IMAGE_OPTIONAL_HEADER64). Het formaat wordt in het veld opgeslagen Magie: WOORD. Kop bevat noodzakelijke informatie om het bestand te downloaden. Zoals altijd:

IMAGE_OPTIONAL_HEADER

typedef struct _IMAGE_OPTIONAL_HEADER (WORD Magic; BYTE MajorLinkerVersion; BYTE MinorLinkerVersion; DWORD SizeOfCode; DWORD SizeOfInitializedData; DWORD SizeOfUninitializedData; DWORD AddressOfEntryPoint; DWORD BaseOfCode; DWORD BaseOfData; DWORD ImageBase; DWORD SectionAlignment; WORD MajorOperatingSystemVersion Minor; ImageVersion; WORD MinorSubsystemValue; DWORD SizeOfHeaders; DWORD SizeOfHeapCommit; DWORD NumberOfRvaAndSizes;

*Zoals altijd onderzoeken we alleen de belangrijkste velden die de grootste impact hebben op het begrijpen van de download en hoe verder te gaan met het bestand. Laten we het erover eens zijn: de velden van deze structuur bevatten waarden met VA-adressen (virtueel adres) en RVA-adressen (relatief virtueel adres). Dit zijn geen RAW-adressen en je moet ze kunnen lezen (of beter gezegd tellen). We zullen zeker leren hoe we dit moeten doen, maar eerst zullen we de structuren analyseren die elkaar volgen om niet in de war te raken. Onthoud voorlopig: dit zijn adressen die, na berekeningen, naar een specifieke locatie in het bestand verwijzen. Je zult ook een nieuw concept tegenkomen: uitlijning. We zullen het overwegen in combinatie met RVA-adressen, omdat deze zijn vrij nauw verwant.

AdresVanEntryPoint: DWORD - RVA-adres van het toegangspunt. Kan naar elk punt in de adresruimte verwijzen. Voor .exe-bestanden komt het toegangspunt overeen met het adres vanwaar de uitvoering van het programma begint en kan niet gelijk zijn aan nul!
BasisVanCode: DWORD - RVA van het begin van de programmacode (codesectie).
BasisVanGegevens: DWORD - RVA van het begin van de programmacode (datasecties).
ImageBase: DWORD - voorkeur basis adres download het programma. Moet een veelvoud van 64 kb zijn. In de meeste gevallen is dit gelijk aan 0x00400000.
SectieUitlijning: DWORD - uitlijningsgrootte (bytes) van de sectie bij het uploaden naar virtueel geheugen.
Bestandsuitlijning: DWORD - uitlijningsgrootte (bytes) van de sectie in het bestand.
Grootte van afbeelding: DWORD - de grootte van het bestand (in bytes) in het geheugen, inclusief alle headers. Moet een veelvoud zijn van SectionAligment.
GrootteVanHeaders: DWORD - de grootte van alle headers (DOS, DOS-Stub, PE, Section) uitgelijnd met FileAligment.
AantalRvaAndSizes: DWORD - het aantal mappen in de mappentabel (de tabel zelf staat hieronder). Op op dit moment dit veld is altijd gelijk aan de symbolische constante IMAGE_NUMBEROF_DIRECTORY_ENTRIES, die gelijk is aan 16.
GegevensDirectory: IMAGE_DATA_DIRECTORY - gegevensmap. Simpel gezegd is dit een array (grootte 16), waarvan elk element een structuur van 2 DWORD-waarden bevat.

Laten we eens kijken naar wat de IMAGE_DATA_DIRECTORY-structuur is:

Typedef struct _IMAGE_DATA_DIRECTORY ( DWORD VirtualAddress; DWORD-grootte; ) IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;
Wat hebben we? We hebben een array van 16 elementen, waarvan elk element een adres en grootte bevat (wat? hoe? waarom? allemaal in een minuut). De vraag rijst wat deze kenmerken precies zijn. Hiervoor heeft Microsoft speciale constanten voor matching. Ze zijn te zien helemaal aan het einde van de structuurbeschrijving. In de tussentijd:

// Directorygegevens #define IMAGE_DIRECTORY_ENTRY_EXPORT 0 // Exportmap #define IMAGE_DIRECTORY_ENTRY_IMPORT 1 // Importmap #define IMAGE_DIRECTORY_ENTRY_RESOURCE 2 // Bronmap #define IMAGE_DIRECTORY_ENTRY_EXCEPTION 3 // Uitzonderingsmap #define IMAGE_DIRECTORY_ENTRY _SECURITY 4 // Beveiligingsmap # definieer IMAGE_DIRECTORY_ENTRY_BASERELOC 5 / / Basisverplaatsingstabel #define IMAGE_DIRECTORY_ENTRY_DEBUG 6 // Debug Directory // IMAGE_DIRECTORY_ENTRY_COPYRIGHT 7 // (X86-gebruik) #define IMAGE_DIRECTORY_ENTRY_ARCHITECTURE 7 // Architectuurspecifieke gegevens #define IMAGE_DIRECTORY_ENTRY_GLOBALPTR 8 // RVA van GP #define IMAGE_D TLS 9 // TLS-directory # definieer IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG 10 // Laad configuratiemap #define IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT 11 // Gebonden importmap in headers #define IMAGE_DIRECTORY_ENTRY_IAT 12 // Importeer adrestabel #define IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT 13 // Vertraag importdescriptors laden #define IMAGE_DIRECTOR Y_ENTRY_ COM_DESCRIPTOR 14 // COM Runtime-descriptor
Ja! We zien dat elk element van de array verantwoordelijk is voor de tabel die eraan is gekoppeld. Maar helaas en ach, deze kusten zijn nog steeds ontoegankelijk voor ons, omdat... wij weten niet hoe we met VA- en RVA-adressen moeten werken. En om te leren, moeten we bestuderen wat secties zijn. Zij zijn degenen die vertellen over hun structuur en werk, waarna duidelijk wordt waarom VA, RVA en afstemmingen nodig zijn. In dit artikel zullen we alleen ingaan op de export en import. De bestemming van de overige velden vindt u op kantoor. documentatie of in boeken. Dus hier is het. De daadwerkelijke velden:

Virtueel Adres: DWORD - RVA voor de tabel waarmee het array-element correspondeert.
Maat: DWORD - tabelgrootte in bytes.

Dus! Om zulke exotische kusten te bereiken als tabellen met import, export, hulpbronnen en andere, moeten we een zoektocht met secties voltooien. Welnu, scheepsjongen, laten we eens naar de algemene kaart kijken, bepalen waar we nu zijn en verder gaan:

En we bevinden ons direct voor de grote open ruimtes van de secties. We moeten zeker weten wat ze verbergen en uiteindelijk een ander soort adressering bedenken. Wij willen echte avonturen! We willen snel naar republieken gaan als import- en exporttabellen. Oude piraten zeggen dat niet iedereen hen kon bereiken, maar degenen die dat wel deden, keerden terug met goud en vrouwen met heilige kennis over de oceaan. We gaan op pad en gaan richting Section Header.

'Je bent afgezet, Zilver! Ga van het vat af!”
(Schateiland)

Sectiekop (IMAGE_SECTION_HEADER)

Direct achter de array GegevensDirectory secties volgen elkaar op. De sectietabel vertegenwoordigt een soevereine staat, die is onderverdeeld in AantalSecties steden. Elke stad heeft zijn eigen ambacht, zijn eigen rechten en ook een grootte van 0x28 bytes. Het aantal secties wordt aangegeven in het veld AantalSecties, die is opgeslagen in Bestandskop. Laten we dus naar de structuur kijken:

Typedef struct _IMAGE_SECTION_HEADER ( BYTE Naam; union ( DWORD PhysicalAddress; DWORD VirtualSize; ) Diversen; DWORD VirtualAddress; DWORD SizeOfRawData; DWORD PointerToRawData; DWORD PointerToRelocations; DWORD PointerToLinenumbers; WORD NumberOfRelocations; WORD NumberOfLinenumbers; DWORD-kenmerken; ) HEADER, *PIMAGE_SECTION_HEADER;
Naam: BYTE - sectienaam. Momenteel is het 8 tekens lang.
Virtueel formaat: DWORD - sectiegrootte in virtueel geheugen.
GrootteVanRawData: DWORD - sectiegrootte in het bestand.
Virtueel Adres: DWORD - RVA-sectieadres.
GrootteVanRawData: DWORD - sectiegrootte in het bestand. Moet een veelvoud zijn Bestandsuitlijning.
PointerToRawData: DWORD - RAW-verschuiving naar het begin van de sectie. Moet ook een veelvoud zijn Bestandsuitlijning…
Kenmerken: DWORD - toegang tot attributen van de sectie en regels voor het laden ervan in virtueel. geheugen. Bijvoorbeeld een attribuut voor het definiëren van de inhoud van een sectie (initiële gegevens, niet-initiële gegevens, code). Of krijg toegang tot attributen - lezen, schrijven, uitvoeren. Dit is niet hun hele assortiment. De kenmerken worden bepaald door constanten uit dezelfde WINNT.h, die beginnen met IMAGE_SCN_. U kunt meer in detail kennis maken met de kenmerken van secties. De kenmerken in de boeken van Chris Kaspersky worden ook goed beschreven - de lijst met referenties staat aan het einde van het artikel.

Wat de naam betreft, moet u het volgende onthouden: de sectie met bronnen moet altijd de naam.rsrc hebben. Anders worden bronnen niet geladen. Wat de overige secties betreft, de naam kan van alles zijn. Meestal zijn er betekenisvolle namen, bijvoorbeeld .data, .src, enz... Maar het gebeurt ook:

Secties zijn een gebied dat in het virtuele geheugen wordt geladen en al het werk gebeurt rechtstreeks met deze gegevens. Het adres in het virtuele geheugen, zonder enige offset, wordt Virtueel adres genoemd, afgekort VA. Voorkeursadres voor het downloaden van de applicatie, ingesteld in het veld ImageBase. Dit is hetzelfde als het punt waarop het toepassingsgebied in het virtuele geheugen begint. En RVA-offsets (Relative Virtual Address) worden relatief ten opzichte van dit punt gemeten. Dat wil zeggen, VA = ImageBase+ RVA; ImageBase we weten het altijd en omdat we VA of RVA tot onze beschikking hebben, kunnen we het een via het ander uitdrukken.

Hier lijken ze gewend te zijn geraakt. Maar dit is virtueel geheugen! En we bevinden ons in het fysieke. Virtueel geheugen is voor ons nu als een reis naar andere sterrenstelsels die we ons alleen maar kunnen voorstellen. We kunnen op dit moment dus niet in het virtuele geheugen komen, maar we kunnen wel uitzoeken wat daar zal zijn, omdat het uit ons bestand is gehaald.

Uitlijning

Om het uploaden naar virtueel correct weer te geven. geheugen, is het noodzakelijk om een ​​dergelijk mechanisme als uitlijning te begrijpen. Laten we eerst eens kijken naar een diagram van hoe secties in het geheugen worden opgeslagen.

Zoals u kunt zien, wordt de sectie niet in het geheugen geladen op basis van de grootte ervan. Hier worden uitlijningen gebruikt. Dit is een waarde die een veelvoud moet zijn van de grootte van de sectie in het geheugen. Als we naar het diagram kijken, zien we dat de sectiegrootte 0x28 is en de grootte van de sectie 0x50. Dit komt door de uitlijningsgrootte. 0x28 "bereikt" 0x50 niet en als gevolg daarvan wordt de sectie gelost en wordt de resterende ruimte in de grootte 0x50-0x28 op nul gezet. En als de sectiegrootte groter was dan de uitlijningsgrootte, wat dan? Bijvoorbeeld sectieGrootte= 0x78, een sectieUitlijning= 0x50, d.w.z. bleef onveranderd. In dit geval zou de sectie 0xA0 (0xA0 = 0x28 * 0x04) bytes in het geheugen in beslag nemen. Dat wil zeggen, een waarde die een veelvoud is van sectieUitlijning en volledig bedekt sectieGrootte. Opgemerkt moet worden dat secties in het bestand op een vergelijkbare manier zijn uitgelijnd, alleen op grootte Bestandsuitlijning. Nadat we de benodigde basis hebben ontvangen, kunnen we uitzoeken hoe we van RVA naar RAW kunnen converteren.

“Dit is geen vlakte, het klimaat hier is anders.”
(VS Vysotsky)

Een klein rekenlesje

Voordat de uitvoering kan beginnen, moet een deel van het programma naar de adresruimte van de processor worden gestuurd. Adresruimte is de hoeveelheid gegevens die fysiek door de processor worden geadresseerd. RAM. Het “stuk” in de adresruimte waar het programma wordt verwijderd, wordt aangeroepen vrijwel(virtueel beeld). De afbeelding wordt gekenmerkt door het basisdownloadadres (Image base) en de grootte (Image size). VA (virtueel adres) is dus het adres ten opzichte van het begin van het virtuele geheugen, en RVA (relatief virtueel adres) is relatief ten opzichte van de plaats waar het programma is verwijderd. Hoe kan ik het basisdownloadadres van een applicatie achterhalen? Hiervoor is er een apart veld in de optionele header genaamd ImageBase. Dit was een kleine opmaat om je geheugen op te frissen. Laten we nu eens kijken naar een schematische weergave van verschillende adresseringen:

Dus hoe kun je nog steeds informatie uit een bestand lezen zonder deze in het virtuele geheugen te dumpen? Om dit te doen, moet u adressen converteren naar RAW-formaat. Vervolgens kunnen we in het bestand naar het gebied gaan dat we nodig hebben en de benodigde gegevens lezen. Omdat RVA het virtuele geheugenadres is waarnaar de gegevens uit het bestand zijn geprojecteerd, kunnen we het omgekeerde proces uitvoeren. Om dit te doen hebben we een eenvoudige rekenkunde van negen bij zestien nodig. Hier zijn enkele formules:

VA = ImageBase + RVA; RAW = RVA - sectieRVA + rawSectie; // rawSection - offset naar de sectie vanaf het begin van het bestand // sectionRVA - RVA van de sectie (dit veld wordt opgeslagen in de sectie)
Zoals u kunt zien, moeten we, om RAW te berekenen, bepalen tot welke sectie de RVA behoort. Om dit te doen, moet u alle secties doorlopen en de volgende voorwaarden controleren:

RVA >= sectieVitualAddress && RVA< ALIGN_UP(sectionVirtualSize, sectionAligment) // sectionAligment - выравнивание для секции. Значение можно узнать в Optional-header. // sectionVitualAddress - RVA секции - хранится непосредственно в секции // ALIGN_UP() - функция, определяющая сколько занимает секция в памяти, учитывая выравнивание
Als we alle puzzels samenvoegen, krijgen we deze lijst:

Typedef uint32_t DWORD; typedef uint16_t WORD; typedef uint8_t BYTE; #define ALIGN_DOWN(x, uitlijnen) (x & ~(align-1)) #define ALIGN_UP(x, uitlijnen) ((x & (align-1))?ALIGN_DOWN(x,align)+align:x) // IMAGE_SECTION_HEADER secties; // init array-secties int defSection(DWORD rva) ( for (int i = 0; i< numberOfSection; ++i) { DWORD start = sections[i].VirtualAddress; DWORD end = start + ALIGN_UP(sections[i].VirtualSize, sectionAligment); if(rva >= start && rva< end) return i; } return -1; } DWORD rvaToOff(DWORD rva) { int indexSection = defSection(rva); if(indexSection != -1) return rva - sections.VirtualAddress + sections.PointerToRawData; else return 0; }
*Ik heb geen typedeclaratie of array-initialisatie in de code opgenomen, maar heb alleen functies aangeleverd die helpen bij het berekenen van adressen. Zoals je kunt zien, was de code niet erg ingewikkeld. Gewoon een beetje verwarrend. Dit gaat weg... als je wat meer tijd besteedt aan het sleutelen aan het .exe-bestand via de disassembler.

HOERA! Wij zijn er achter gekomen. Nu kunnen we naar de landen van hulpbronnen gaan, bibliotheken importeren en exporteren, en in het algemeen waar ons hartje maar begeert. We hebben zojuist geleerd hoe we met een nieuw type adressering moeten werken. Laten we gaan!

“Niet slecht, niet slecht! Toch hebben ze hun rantsoenen voor vandaag gekregen!”
(Schateiland)

Tabel exporteren

In het allereerste element van de array GegevensDirectory RVA wordt opgeslagen in de exporttabel, die wordt weergegeven door de IMAGE_EXPORT_DIRECTORY-structuur. Deze tabel is gebruikelijk voor dynamische bibliotheekbestanden (.dll). Het belangrijkste doel van de tabel is om geëxporteerde functies te relateren aan hun RVA. De beschrijving wordt op kantoor gepresenteerd. Specificaties:

Typedef struct _IMAGE_EXPORT_DIRECTORY (DWORD-kenmerken; DWORD TimeDateStamp; WORD MajorVersion; WORD MinorVersion; DWORD-naam; DWORD Base; DWORD NumberOfFunctions; DWORD NumberOfNames; DWORD AddressOfNames; DWORD AddressOfNameOrdinals ; ) _DIRECTORY;
Deze structuur bevat drie verwijzingen naar drie verschillende tabellen. Dit is een tabel met namen (functies) ( AdresVanNamen), rangtelwoorden( AdresVanNamenOrdinalen), adressen( AdresVanFuncties). In het veld Naam wordt de RVA van de naam opgeslagen dynamische bibliotheek. Ordinal is als een tussenpersoon tussen de tabel met namen en de tabel met adressen, en is een array van indexen (indexgrootte is 2 bytes). Voor meer duidelijkheid, bekijk het diagram:

Laten we eens kijken naar een voorbeeld. Laten we zeggen dat het i-de element van de namenarray de naam van de functie aangeeft. Vervolgens kan het adres van deze functie worden verkregen door toegang te krijgen tot het i-de element in de adresarray. Die. ik ben een ordinaal.

Aandacht! Als u bijvoorbeeld het tweede element in een tabel met rangtelwoorden neemt, betekent dit niet 2; het is een rangtelwoord voor tabellen met namen en adressen. De index is de waarde die is opgeslagen in het tweede element van de reeks rangtelwoorden.

Aantal waarden in naamtabellen ( AantalNamen) en rangtelwoorden zijn gelijk en vallen niet altijd samen met het aantal elementen in de adrestabel ( AantalFuncties).

“Ze kwamen voor mij. Bedankt voor uw aandacht. Nu moeten ze aan het moorden zijn!”
(Schateiland)

Tabel importeren

De importtabel is een integraal onderdeel van elke toepassing die dynamische bibliotheken gebruikt. Deze tabel helpt bij het correleren van oproepen naar dynamische bibliotheekfuncties met de overeenkomstige adressen. Importeren kan in drieën plaatsvinden verschillende modi: standaard, gebonden import en vertraagde import. Omdat Het onderwerp import is behoorlijk veelzijdig en verdient een apart artikel. Ik zal alleen het standaardmechanisme beschrijven, en de rest zal ik alleen beschrijven als een “skelet”.

Standaard import- V GegevensDirectory De importtabel wordt opgeslagen onder de index IMAGE_DIRECTORY_ENTRY_IMPORT(=1). Het is een array van elementen van het type IMAGE_IMPORT_DESCRIPTOR. De importtabel slaat (in een array) de namen van functies/rangtelwoorden op en waar de lader het effectieve adres van deze functie moet schrijven. Dit mechanisme is niet erg effectief, omdat Eerlijk gezegd komt het allemaal neer op het doorzoeken van de hele exporttabel voor elke vereiste functie.

Gebonden import- met dit werkschema op het terrein (in het eerste element standaard tafel import) TimeDateStamp en ForwardChain zijn ingesteld op -1 en de bindingsinformatie wordt in de cel opgeslagen GegevensDirectory met index IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT(=11). Dat wil zeggen, dit is een soort vlag voor de lader die u nodig hebt om gebonden import te gebruiken. Ook kent de ‘gebonden importketen’ zijn eigen structuren. Het werkingsalgoritme is als volgt: het virtuele geheugen van de applicatie wordt leeggemaakt benodigde bibliotheek en alle benodigde adressen zijn “gebonden” in de compilatiefase. Een van de nadelen is dat u bij het opnieuw compileren van de dll de applicatie zelf opnieuw moet compileren, omdat functieadressen worden gewijzigd.

Import uitstellen- bij deze methode Er wordt aangenomen dat het .dll-bestand aan het uitvoerbare bestand is gekoppeld, maar het wordt niet onmiddellijk in het geheugen geladen (zoals bij de vorige twee methoden), maar alleen wanneer de toepassing voor het eerst toegang krijgt tot het symbool (dit is wat elementen uit dynamische bibliotheken verwijdert worden genoemd). Dat wil zeggen dat het programma in het geheugen wordt uitgevoerd en zodra het proces het punt heeft bereikt waarop een functie uit een dynamische bibliotheek wordt aangeroepen, wordt een speciale handler aangeroepen die de dll laadt en de effectieve adressen van zijn functies distribueert. Voor uitgestelde import neemt de lader contact op met de DataDirectory (itemnummer 15).

Nadat we de importmethoden een beetje hebben besproken, gaan we direct naar de importtabel.

'Dit is een matroos! Zijn kleding was nautisch. - Ja, nou? Dacht je dat je hier een bisschop zou vinden?’
(Schateiland - John Silver)

Importdescriptor (IMAGE_IMPORT_DESCRIPTOR)

Om de coördinaten van de importtabel te achterhalen, hebben we toegang tot de array nodig GegevensDirectory. Namelijk naar het IMAGE_DIRECTORY_ENTRY_IMPORT element (=1). En lees het RVA-adres van de tafel. Hier is een algemeen diagram van het pad dat moet worden gevolgd:

Vervolgens halen we RAW van RVA, in overeenstemming met de hierboven gegeven formules, en “stappen” dan door het bestand. Nu staan ​​we recht voor een reeks structuren genaamd IMAGE_IMPORT_DESCRIPTOR. Het einde van de array wordt aangegeven door de "nul"-structuur.

Typedef struct _IMAGE_IMPORT_DESCRIPTOR ( union ( DWORD-kenmerken; DWORD OriginalFirstThunk; ) DUMMYUNIONNAME; DWORD TimeDateStamp; DWORD ForwarderChain; DWORD-naam; DWORD FirstThunk; ) IMAGE_IMPORT_DESCRIPTOR,*PIMAGE_IMPORT_DESCRIPTOR;
Ik kon geen link naar de structuurbeschrijving op msdn vinden, maar je kunt deze zien in het bestand WINNT.h. Laten we het beginnen uit te zoeken.

OrigineelEersteThunk: DWORD - RVA van de importnamentabel (INT).
Tijddatumstempel: DWORD - datum en tijd.
ForwarderChain: DWORD - index van het eerste doorgestuurde teken.
Naam: DWORD - RVA-tekenreeks met de bibliotheeknaam.
EersteThunk: DWORD - RVA van de importadrestabel (IAT).

Alles lijkt hier enigszins op export. Ook een tabel met namen (INT) en ook een vodje adressen erop (IAT). Ook RVA van de bibliotheeknaam. Alleen INT en IAT verwijzen naar een array van IMAGE_THUNK_DATA-structuren. Het wordt in twee vormen gepresenteerd: voor 64 en 32 systemen en verschilt alleen in de grootte van de velden. Laten we x86 als voorbeeld bekijken:

Typedef struct _IMAGE_THUNK_DATA32 ( union ( DWORD ForwarderString; DWORD-functie; DWORD ordinaal; DWORD AddressOfData; ) u1; ) IMAGE_THUNK_DATA32,*PIMAGE_THUNK_DATA32;
Het is belangrijk om daarop te antwoorden verdere acties afhankelijk van het belangrijkste deel van de structuur. Als dit is ingesteld, vertegenwoordigen de resterende bits het nummer van het teken dat wordt geïmporteerd (importeren op nummer). Anders (het meest significante bit wordt gewist) specificeren de resterende bits de RVA van het symbool dat wordt geïmporteerd (importeren op naam). Als we een import op naam hebben, slaat de pointer het adres op in de volgende structuur:

Typedef struct _IMAGE_IMPORT_BY_NAME ( WORD Hint; BYTE Naam; ) IMAGE_IMPORT_BY_NAME, *PIMAGE_IMPORT_BY_NAME;
Hier Tip is het functienummer, en Naam- Naam.

Waar is dit allemaal voor? Al deze arrays, structuren... Laten we voor de duidelijkheid een prachtig diagram bekijken

Lezing 3. Bestandsstructuur

Literatuur

o Moderne besturingssystemen, E. Tanenbaum, 2002, St. Petersburg, St. Petersburg, 1040 pagina's, (in djvu 10,1 MB) meer>>

o Netwerkbesturingssystemen N.A. Olifer, V.G. Olifer (zip-archief 1,1 MB)

o Netwerkbesturingssystemen N. A. Olifer, V.G. Olifer, 2001, St. Petersburg, Peter, 544 pp., (in djvu 6,3 MB) meer details>>

Bestanden

Vereisten voor informatieopslag:

o mogelijkheid om grote hoeveelheden gegevens op te slaan

o informatie moet worden bewaard nadat het proces is beëindigd

o meerdere processen moeten hebben gelijktijdige toegang naar informatie

2.1.1Bestanden een naam geven

De lengte van de bestandsnaam is afhankelijk van het besturingssysteem; deze kan 8 (MS-DOS) tot 255 (Windows, LINUX) tekens bevatten.

OS kan onderscheid maken tussen hoofdletters en kleine letters. WINDOWS en Windows voor MS-DOS zijn bijvoorbeeld hetzelfde, maar voor UNIX zijn het verschillende bestanden.

Op veel besturingssystemen bestaat de bestandsnaam uit twee delen, gescheiden door een punt, bijvoorbeeld windows.exe. Het gedeelte na de punt wordt aangeroepen bestandsextensie. Het systeem gebruikt het om het bestandstype te onderscheiden.

Voor MS-DOS is de extensie 3 tekens. Hiermee onderscheidt het systeem het type bestand en of het kan worden uitgevoerd of niet.

In UNIX is de extensie beperkt tot een bestandsnaamgrootte van 255 tekens, en UNIX kan verschillende extensies hebben, maar extensies worden vaker gebruikt door toepassingsprogramma's, niet door het besturingssysteem. UNIX kan op basis van de extensie niet bepalen of een bestand uitvoerbaar is of niet.

2.1.2 Bestandsstructuur

Drie belangrijke bestandsstructuren:

1. Bytereeks- Het besturingssysteem is niet geïnteresseerd in de inhoud van het bestand, het ziet alleen bytes. Het belangrijkste voordeel van een dergelijk systeem is de gebruiksflexibiliteit. Gebruikt op Windows en UNIX.

2. Volgorde van records- records met een vaste lengte (bijvoorbeeld een ponskaart) worden opeenvolgend gelezen. Nu niet gebruikt.

3. Ingangsboom- elk record heeft een sleutel, records worden met behulp van de sleutel gelezen. Het belangrijkste voordeel van een dergelijk systeem is de zoeksnelheid. Wordt nog steeds gebruikt op mainframes.

Drie soorten bestandsstructuren.

2.1.3 Bestandstypen

Belangrijkste bestandstypen:

O Normaal- bevatten gebruikersinformatie. Gebruikt op Windows en UNIX.

O Catalogi - systeembestanden, dat ondersteuning biedt voor de bestandssysteemstructuur. Gebruikt op Windows en UNIX.

O Karakter- voor input-outputmodellering. Alleen gebruikt op UNIX.

O Blok- voor het modelleren van schijven. Alleen gebruikt op UNIX.

Belangrijkste typen reguliere bestanden:

O ASCII-bestanden- bestaan ​​uit tekstreeksen. Elke regel eindigt met een regelterugloop (Windows), een regelinvoer (UNIX) en beide (MS-DOS). Daarom, als je opengaat tekstbestand geschreven in UNIX, in Windows, dan zullen alle regels samenvloeien tot één grote regel, maar onder MS-DOS zullen ze niet samenvoegen ( dit is een vrij veel voorkomende situatie). Belangrijkste voordelen van ASCII-bestanden:
- kan zonder conversie op het scherm worden weergegeven en naar de printer worden uitgevoerd
- kan door vrijwel elke editor worden bewerkt

O Binaire bestanden- andere bestanden (niet-ASCII). In de regel hebben ze een interne structuur.

Belangrijkste soorten binaire bestanden:

O Uitvoerbaar- programma's, ze kunnen door het besturingssysteem zelf worden verwerkt, hoewel ze zijn geschreven als een reeks bytes.

O Niet-uitvoerbaar- alle anderen.

Voorbeelden van uitvoerbare en niet-uitvoerbare bestanden

"Magisch nummer"- het bestand identificeren als uitvoerbaar bestand.

2.1.4 Bestandstoegang

Belangrijkste soorten bestandstoegang:

O Consistent- bytes worden op volgorde gelezen. Gebruikt toen er nog magneetbanden bestonden.

2.1.5 Bestandsattributen

Belangrijkste bestandskenmerken:

o Beveiliging - wie heeft toegang tot het bestand en hoe (gebruikers, groepen, lezen/schrijven). Gebruikt op Windows en UNIX.

o Wachtwoord - wachtwoord voor het bestand

o Maker - wie het bestand heeft gemaakt

o Eigenaar - huidige eigenaar van het bestand

o Alleen-lezen vlag - 0 - lezen/schrijven, 1 - alleen-lezen. Gebruikt op Windows.

o De vlag "verborgen" - 0 - zichtbaar, 1 - onzichtbaar in de lijst met directorybestanden (standaard). Gebruikt op Windows.

o Vlag "systeem" - 0 - normaal, 1 - systeem. Gebruikt op Windows.

o Markeer "archief" - klaar of niet voor archivering (niet te verwarren met compressie). Gebruikt op Windows.

o Markeer "gecomprimeerd" - het bestand is gecomprimeerd (vergelijkbaar met zip-archieven). Gebruikt op Windows.

o Markeer "versleuteld" - het versleutelingsalgoritme wordt gebruikt. Als iemand een bestand probeert te lezen dat daarvoor geen toestemming heeft, kan hij/zij het niet lezen. Gebruikt op Windows.

o ASCII/binaire vlag - 0 - ASCII, 1 - binair

o Vlag voor willekeurige toegang - 0 - alleen sequentieel, 1 - willekeurige toegang

o Markeer "tijdelijk" - 0 - normaal, 1 - om het bestand aan het einde van het proces te verwijderen

o Blokkeervlag - blokkeert de toegang tot het bestand. Als hij bezig is met bewerken.

o Aanmaaktijd - datum en tijd van creatie. UNIX wordt gebruikt.

o Laatste toegangstijd - datum en tijd van de laatste toegang

o Tijdstip van laatste wijziging - datum en tijd van de laatste wijziging. Gebruikt op Windows en UNIX.

o Huidige grootte - bestandsgrootte. Gebruikt op Windows en UNIX.

2.1.6 Bewerkingen met bestanden

Basis systeemoproepen werken met bestanden:

o Maken - een bestand maken zonder gegevens.

o Verwijderen - verwijder een bestand.

o Openen - open een bestand.

o Sluiten - het bestand sluiten.

o Lezen - lezen uit een bestand, vanaf de huidige bestandspositie.

o Schrijven - schrijf naar een bestand, naar de huidige bestandspositie.

o Toevoegen - toevoegen aan het einde van het bestand.

o Zoeken - stelt de bestandsaanwijzer in op een specifieke positie in het bestand.

o Attributen ophalen - bestandsattributen ophalen.

o Kenmerken instellen - bestandskenmerken instellen.

o Hernoemen - hernoem het bestand.

geheugen door de besturingssysteemlader en vervolgens uitgevoerd. In de operatiekamer Windows-systeem Uitvoerbare bestanden hebben meestal de extensies ".exe" en ".dll". De extensie ".exe" verwijst naar programma's die rechtstreeks door de gebruiker kunnen worden gestart. De extensie ".dll" heeft de zogenaamde dynamisch gekoppelde bibliotheken ( dynamische koppeling bibliotheken). Deze bibliotheken exporteren functies die door andere programma's worden gebruikt.

Om ervoor te zorgen dat de opstartlader van het besturingssysteem correct wordt geladen uitvoerbaar bestand in het geheugen wordt opgeslagen, moet de inhoud van dit bestand overeenkomen met het uitvoerbare bestandsformaat dat door dit besturingssysteem wordt geaccepteerd. In verschillende besturingssystemen op verschillende tijdstippen waren en bestaan ​​er nog steeds veel verschillende formaten. In dit hoofdstuk bekijken we het Portable Executable (PE)-formaat. Het PE-formaat is het primaire formaat voor het opslaan van uitvoerbare bestanden in het Windows-besturingssysteem. Assemblages. NET-bestanden worden ook in dit formaat opgeslagen.

Bovendien kan het PE-formaat worden gebruikt om weer te geven objectbestanden. Objectbestanden worden gebruikt om een ​​afzonderlijke compilatie van een programma te organiseren. Het punt van afzonderlijke compilatie is dat delen van het programma (modules) onafhankelijk worden gecompileerd tot objectbestanden, die vervolgens door de linker worden gekoppeld tot één bestand. uitvoerbaar bestand.

En nu - een beetje geschiedenis. Het PE-formaat is gemaakt door de ontwikkelaars van Windows NT. Voorheen gebruikte het Windows-besturingssysteem de formaten New Executable (NE) en Linear Executable (LE) om uitvoerbare bestanden weer te geven en om bestanden op te slaan. objectbestanden Er werd gebruik gemaakt van Object Module Format (OMF). Het NE-formaat was bedoeld voor 16-bit Windows-applicaties, en het LE-formaat, oorspronkelijk ontwikkeld voor OS/2, was al 32-bits. De vraag rijst: waarom? Windows-ontwikkelaars NT besloot op te geven bestaande formaten? Het antwoord wordt duidelijk als je let op het feit dat het grootste deel van het team eraan heeft gewerkt creatie van Windows NT, werkte voorheen bij Digital Equipment Corporation. Bij DEC waren ze tools aan het ontwikkelen voor het VAX/VMS-besturingssysteem, en ze beschikten al over de vaardigheden en vaardigheden gereed code voor het werken met uitvoerbare bestanden gepresenteerd in het formaat Gemeenschappelijk voorwerp Bestandsformaat (COFF). Dienovereenkomstig werd het COFF-formaat, in een enigszins gewijzigde vorm, overgebracht naar Windows NT en kreeg het de naam PE.

De ".NET Framework Glossary" zegt dat PE een implementatie is Microsoft-formaat KOFF. Tegelijkertijd wordt vermeld dat PE een uitvoerbaar bestandsformaat is, en COFF een formaat objectbestanden. Over het algemeen kunnen we verwarring waarnemen in Microsoft-documentatie over de naam van het formaat. Op sommige plaatsen noemen ze het COFF en op andere plaatsen noemen ze het PE. Toegegeven, het valt op dat in nieuwe teksten de naam COFF steeds minder wordt gebruikt. Bovendien evolueert het PE-formaat voortdurend. Een aantal jaren geleden is Microsoft bijvoorbeeld gestopt met het opslaan van foutopsporingsinformatie in het uitvoerbare bestand, en daarom worden nu veel velden in COFF-formaatstructuren eenvoudigweg niet gebruikt. Bovendien is het COFF-formaat 32-bits en nieuwste editie PE-formaat (PE32+ genoemd) kan worden gebruikt op 64-bits hardwareplatforms. Daarom evolueren de zaken blijkbaar richting het punt dat de naam COFF helemaal niet meer zal worden gebruikt.

Het is interessant om op te merken dat uitvoerbare bestanden in de oudere NE- en LE-formaten nog steeds door Windows worden ondersteund. Uitvoerbare bestanden in het NE-formaat kunnen worden uitgevoerd onder NTVDM (NT Virtual DOS Machine), en het LE-formaat wordt gebruikt voor virtuele apparaatstuurprogramma's (

Veel gebruikers computersystemen U bent waarschijnlijk wel eens het concept van een uitvoerbaar programmabestand tegengekomen. Uitvoerbare bestanden hebben niet altijd, maar vrij vaak de EXE-extensie, wat gebruikelijk is voor besturingssystemen Windows-familie. Om enig licht te werpen op de kwestie van extensies, zullen we kijken naar algemene informatie over deze objecten, en overweeg ook enkele soorten basisuitbreidingen.

Hoe uitvoerbare bestanden verschillen van andere objecten

Voordat we beweren dat een uitvoerbaar bestand van een programma slechts één specifiek type extensie kan hebben, is het noodzakelijk om te begrijpen hoe je een dergelijk object van andere kunt onderscheiden. De belangrijkste verschillen tussen uitvoerbare bestanden en andere informatiegegevens omvatten de volgende factoren: de extensie zelf, die de inhoud van machinecode of bytecode in het bestand aangeeft virtuele machine,handtekening,attributen in het bestandssysteem. Maar zelfs als de gebruiker weet dat uitvoerbare bestanden een naamextensie van het type EXE hebben, zal het niet mogelijk zijn om de inhoud met gewone middelen te bekijken, aangezien dergelijke objecten inhoud hebben gecompileerd, die wordt weergegeven als deze wordt bekeken als een betekenisloze reeks tekens. . Over het algemeen zal de gebruiker een Disassembler-tool of iets dergelijks moeten gebruiken waarmee decompilatie mogelijk is. Maar dat is niet waar we het over hebben.

Uitvoerbare bestanden: structuur

Wat de constructie van uitvoerbare bestanden betreft, deze moeten headers (de beoogde uitvoering van instructies, parameters en codeformaten) en de instructies zelf (bron-, machine- of bytecodes) bevatten. In sommige gevallen kan de structuur foutopsporingsgegevens, beschrijvingen van de omgeving, besturingssysteemvereisten, lijsten met relevante bibliotheken, geluid, afbeeldingen, afbeeldingen, snelkoppelingspictogrammen en dergelijke omvatten. Velen van jullie hebben waarschijnlijk gemerkt dat elk dergelijk bestand in het besturingssysteem aanvankelijk een pictogram heeft.

Werkingsprincipe

Hoewel uitvoerbare bestanden mogelijk de extensie verschillende soorten, ze werken volgens hetzelfde principe. Wanneer het wordt gestart, wordt het uitvoerbare bestand in het geheugen van de computer geladen. Tegelijkertijd wordt de omgeving opgezet en geïnitialiseerd, en wordt de extra bibliotheken, als het gebruik ervan door het programma wordt voorzien. Ook op in dit stadium enkele aanvullende bewerkingen worden geconfigureerd en de instructies zelf worden uitgevoerd met behulp van de methoden die rechtstreeks in het bestand zijn geschreven.

Uitvoerbare programmabestanden: welke extensie hebben ze?

Laten we nu verder gaan met het probleem met betrekking tot extensies. Het zal natuurlijk niet mogelijk zijn om absoluut alle typen te overwegen; het zal veel tijd kosten. We zullen alleen de meest voorkomende en populaire opties benadrukken. De extensie wordt dus ingesteld afhankelijk van het inhoudstype. Bijvoorbeeld in het besturingssysteem Windows-type de meest voorkomende uitvoerbare bestanden hebben EXE-extensie. Dit geldt voor alle programma's die zijn ontworpen om te werken in de omgeving van deze besturingssystemen. Dergelijke objecten bevatten machinecodes. BIN-bestanden lijken erg op elkaar. Batchbestanden zoals CMD, BAT en COM zijn een ander type uitvoerbaar bestand. De eerste typt in in dit geval is batchbestand Ramen. Bestanden van het tweede en derde type behoren tot besturingssystemen van de DOS-familie. Velen van jullie zijn waarschijnlijk al MSI- en MSU-bestanden tegengekomen. Dit kan een installatieprogramma voor een systeemupdate zijn, of een systeemeigen installatieprogramma voor het Windows-besturingssysteem. Een aparte categorie bestanden bestaat uit macro's en scripts. Dit zijn bestanden met de extensies JSE, JS, SCR, VBE, VBS, VB. Vaak zijn er ook JAD- en JAR-bestanden, die bedoeld zijn om applicaties op mobiele apparaten te installeren of te gebruiken JAVA-omgeving. Dergelijke objecten bevatten inhoudelijk geen machinecodes meer, maar virtuele machinecodes.

Welke extensie hebben uitvoerbare bestanden op verschillende besturingssystemen?

Als je goed kijkt, zul je merken dat sommige besturingssystemen vrij specifieke componenten hebben. Het Windows-besturingssysteem heeft bijvoorbeeld een speciale categorie uitvoerbare bestanden. Over het algemeen kunt u in elk besturingssysteem zowel standaard- als speciale componenten. Er zijn echter ook enkele veelgebruikte formaten, zoals HTA, uitvoerbaar HTML-document. Ze werken vrijwel overal, ongeacht het type besturingssysteem dat wordt gebruikt. Net als bij andere soorten systemen, bijvoorbeeld op Macs, hebben uitvoerbare bestanden de extensie APP voor programma's en PKG voor distributies. Bij besturingssystemen Linux-familie dingen zijn een beetje anders. Het probleem is dat er in dergelijke besturingssystemen helemaal geen concept van uitbreiding bestaat. U kunt een uitvoerbaar bestand herkennen aan de kenmerken ervan, zoals systeem, verborgen, alleen-lezen, enz. Als gevolg hiervan verdwijnt het probleem van het wijzigen van de extensie om het vereiste bestand te starten of te lezen. Echter, in elk besturingssysteem, zelfs op mobiele apparaten je kunt een groot aantal objecten vinden van dit type. Je hoeft niet ver te gaan. In hetzelfde besturingssysteem van de Android-familie heeft het uitvoerbare installatiebestand APK-extensie. Op Apple-apparaten hebben uitvoerbare bestanden de IPA-extensie.

Conclusie

Laten we onze samenvatten kleine recensie over de extensie van uitvoerbare bestanden. De nadruk lag in dit geval vooral op objecten die aanwezig zijn in besturingssystemen van de Windows-familie. Andere besturingssystemen werden slechts terloops ter sprake gebracht algemene ontwikkeling. Zoals al duidelijk is geworden, is de verscheidenheid aan uitvoerbare bestanden erg groot. Het is onmogelijk om iets te geven draaitabel geeft absoluut alle soorten extensies aan. Daarom hebben we ons in dit artikel beperkt tot alleen de meest voorkomende formaten.