Typedef struct _IMAGE_FILE_HEADER (WORD Machine; WORD NumberOfSections; DWORD TimeDateStamp; DWORD PointerToSymbolTable; DWORD NumberOfSymbols; WORD SizeOfOptionalHeader; WORD-kenmerken;) IMAGE_FILE_HEADER, * PIMEADAGE_FI;
Ik zal deze velden gewoon droog beschrijven, tk. de namen zijn intuïtief en vertegenwoordigen directe betekenissen, niet VA, RVA, RAW en andere enge intrigerende dingen waar we tot nu toe alleen over 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 wel raw pointers of bestandsoffset genoemd). Dat wil zeggen, als we een RAW-adres hebben, betekent dit dat we van het begin van het bestand naar de RAW-posities moeten gaan ( ptrFile+ RAUW). Dan kunt u beginnen met het lezen van de waarden. Een sprekend voorbeeld van dit type is: e_lfnieuw- die we hierboven in de Dos-kop hebben behandeld.
*Machine: WORD is een getal (2 bytes) dat de processorarchitectuur aangeeft waarop deze applicatie kan draaien.
AantalSecties: DWORD - het aantal secties in het bestand. Secties (hierna de sectietabel genoemd) volgen direct na de kop (PE-Header). Volgens de documentatie is het aantal secties beperkt tot 96.
TijdDatumStempel: WORD - een nummer dat de datum en tijd opslaat waarop het bestand is gemaakt.
PointerToSymboolTabel: DWORD is de offset (RAW) naar de symbooltabel en SizeOfOptionalHeader is de grootte van deze tabel. Deze tafel is bedoeld om als opberger te dienen debug informatie, maar het detachement merkte het verlies van een soldaat niet vanaf het begin van de dienst. Meestal wordt dit veld gewist met nullen.
SIzeOfOptionHeader: WORD - de grootte van de optionele header (die onmiddellijk volgt op de huidige) De documentatie stelt dat deze voor een objectbestand is ingesteld op 0 ...
*Kenmerken: WORD - bestandskenmerken.
* - velden die worden gedefinieerd door een reeks waarden. Tabellen met mogelijke waarden worden gepresenteerd in de beschrijving van de structuur op kantoor. site en wordt hier niet gegeven, tk. ze bevatten niets dat bijzonder belangrijk is om het formaat te begrijpen.
Laten we dit eiland verlaten! We moeten verder. Het herkenningspunt is een land genaamd Optional-Header.
'- Waar is de kaart, Billy? Ik heb een kaart nodig."
(Schateiland)
Optionele koptekst (IMAGE_OPTIONAL_HEADER)
De titel van deze titel op het vasteland is niet erg toepasselijk. Deze header is vereist en heeft 2 formaten PE32 en PE32+ (respectievelijk IMAGE_OPTIONAL_HEADER32 en IMAGE_OPTIONAL_HEADER64). Het formaat wordt opgeslagen in het veld Magie: WOORD. De kop bevat Nodige informatie om het bestand te downloaden. Zoals gewoonlijk :
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 BaseOfCode; DWORD BaseOfData; DWORD Section ImageBase MinorImageVersion, WORD MajorSubsystemVersion, WORD MinorSubsystemVersion, DWORD Win32VersionValue, DWORD SizeOfImage, DWORD SizeOfHeaders, DWORD CheckSum, WORD subsysteem, WORD DllCharacteristics, DWORD SizeOfStackReserve, DWORD SizeOfStackCommit, DWORD SizeOfHeapReserve, DWORD SizeOfHeapCommit, DWORD LoaderFlags, DWORD NumberOfRvaAndSizes, IMAGE_DATA_DIRECTORY DataDirectory;) IMAGE_OPTIONAL_HEADE R , * PIMAGE_OPTIONAL_HEADER;
* Zoals altijd zullen we alleen de basisvelden onderzoeken die de grootste impact hebben op het begrijpen van downloads en hoe u verder door het bestand kunt gaan. Laten we het erover eens zijn - de velden van deze structuur bevatten waarden met VA (virtueel adres) en RVA (relatief virtueel adres) adressen. Deze adressen zijn niet hetzelfde als RAW, en je moet ze kunnen lezen (of liever tellen). We zullen zeker leren hoe we dit moeten doen, maar om te beginnen zullen we de structuren die elkaar opvolgen uit elkaar halen om niet in de war te raken. Voor nu, onthoud gewoon - dit zijn adressen die, na berekeningen, verwijzen naar een specifieke locatie in het bestand. Er komt ook een nieuw concept - uitlijning. We zullen het beschouwen in combinatie met RVA-adressen, aangezien: deze zijn vrij nauw verwant.
AddressOfEntryPoint: DWORD - RVA-adres van het ingangspunt. Kan overal in de adresruimte wijzen. Voor .exe-bestanden komt het ingangspunt overeen met het adres van waaruit het programma begint te lopen en kan niet nul zijn!
BaseOfCode: DWORD - RVA van het begin van de programmacode (codesectie).
BaseOfData: DWORD - RVA van het begin van de programmacode (gegevenssectie).
ImageBase: DWORD - voorkeur basisadres: het programma downloaden. Moet een veelvoud van 64kb zijn. In de meeste gevallen is dit 0x00400000.
Sectie Uitlijning: DWORD - uitlijningsgrootte (bytes) van de sectie bij het lossen in virtueel geheugen.
Bestandsuitlijning: DWORD - uitlijningsgrootte (bytes) van de sectie in het bestand.
GrootteVanAfbeelding: DWORD is de grootte van het bestand (in bytes) in het geheugen, inclusief alle headers. Moet een veelvoud zijn van SectionAligment.
GrootteVanHeaders: DWORD - grootte van alle headers (DOS, DOS-Stub, PE, Section) uitgelijnd op FileAligment.
AantalRvaAndMaten: DWORD - het aantal mappen in de directorytabel (onder de tabel zelf). Op de dit moment dit veld is altijd gelijk aan de symbolische constante IMAGE_NUMBEROF_DIRECTORY_ENTRIES, die 16 is.
Gegevensmap: IMAGE_DATA_DIRECTORY - gegevensmap. Simpel gezegd, het is een array (16 in grootte), waarvan elk element een structuur van 2 DWORD-waarden bevat.
Laten we eens kijken hoe de IMAGE_DATA_DIRECTORY structuur eruit ziet:
Typedef struct _IMAGE_DATA_DIRECTORY (DWORD VirtualAddress; DWORD-grootte;) IMAGE_DATA_DIRECTORY, * PIMAGE_DATA_DIRECTORY;
Wat we hebben? We hebben een array van 16 elementen, waarvan elk element een adres en grootte bevat (wat? Hoe? Waarom? Alles in een minuut). De vraag rijst wat deze kenmerken precies zijn. Hiervoor heeft Microsoft speciale constanten voor matching. Ze zijn te zien aan het einde van de structuurbeschrijving. Tot dan:
// Directory-ingangen #define IMAGE_DIRECTORY_ENTRY_EXPORT 0 // Directory exporteren #define IMAGE_DIRECTORY_ENTRY_IMPORT 1 // Directory importeren #define IMAGE_DIRECTORY_ENTRY_RESOURCE 2 // Resourcemap #define IM_DIRECTORY_ENTRY_ENTRY_EXCEPENTIRinedectory gebruik) #define IMAGE_DIRECTORY_ENTRY_ARCHITECTURE 7 // Architectuurspecifieke gegevens #define IMAGE_DIRECTORY_ENTRY_GLOBALPTR 8 // RVA van GP #define IMAGE_DIRECTORY_ENTRY_TLS 9 // TLS Directory #define IMAGE_DIRECTORY_ENTRY_LOAD_ IMAGE_DIRECTORY_ENTRY_IAT 12 // Adrestabel importeren #define IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT 13 // Vertraging laden Importdescriptors #define IMA GE_DIRECTORY_ENTRY_COM_DESCRIPTOR 14 // COM Runtime-descriptor
Aha! We zien dat elk element van de array verantwoordelijk is voor de tabel die eraan is gekoppeld. Maar helaas en ah, terwijl deze kusten voor ons onbereikbaar zijn, tk. we weten niet hoe we met VA- en RVA-adressen moeten werken. En om te leren, moeten we bestuderen wat secties zijn. Zij vertellen over hun structuur en werk, waarna duidelijk wordt waar VA, RVA en afstemmingen voor zijn. Voor de toepassing van dit artikel zullen we het alleen hebben over export en import. Het doel van de overige velden vindt u op kantoor. documentatie of in boeken. Dus dat is het. De eigenlijke velden:
Virtueel adres: DWORD - RVA naar de tabel waarmee het array-element overeenkomt.
Maat: DWORD - tabelgrootte in bytes.
Dus! Om bij zulke exotische kusten te komen, zoals tabellen met invoer, uitvoer, hulpbronnen en andere, moeten we een zoektocht met secties doorlopen. Nou, jongen, laten we eens kijken naar de algemene kaart, bepalen waar we nu zijn en verder gaan:
En we bevinden ons direct voor de grote open ruimtes van de secties. We moeten er in ieder geval achter komen wat ze verhullen en uiteindelijk een ander soort adressering aanpakken. We willen echt avontuur! We willen zo snel mogelijk naar republieken als de import- en exporttabellen. Oude piraten zeggen dat niet iedereen bij hen kon komen, en degene die daar kwam keerde terug met goud en vrouwen met heilige kennis van de oceaan. Ga op weg en blijf bij de sectiekop.
'- Je bent afgezet, Silver! Ga van de ton af!"
(Schateiland)
Sectiekoptekst (IMAGE_SECTION_HEADER)
Direct achter de array Gegevensmap Secties volgen elkaar op. De sectietabel is een soevereine staat, die is onderverdeeld in: AantalSecties steden. Elke stad heeft zijn eigen ambacht, zijn eigen rechten en een grootte van 0x28 bytes. Het aantal secties wordt aangegeven in het veld AantalSecties die is opgeslagen in File-header. Laten we dus eens kijken naar de structuur:
Typedef struct _IMAGE_SECTION_HEADER (BYTE-naam; union (DWORD PhysicalAddress; DWORD VirtualSize;) Diversen; DWORD VirtualAddress; DWORD SizeOfRawData; DWORD PointerToRawData; DWORD PointerToRelocations; DWORD PointerToLinenlocations; DWORD PointerWORDLinenlocations;
Naam: BYTE - sectienaam. Het is momenteel 8 tekens lang.
Virtuele Grootte: DWORD - sectiegrootte in virtueel geheugen.
GrootteVanRawData: DWORD - de grootte van de sectie in het bestand.
Virtueel adres: DWORD - RVA-sectieadres.
GrootteVanRawData: DWORD - de grootte van de sectie in het bestand. Moet een veelvoud zijn van Bestandsuitlijning.
PointerToRawData: DWORD - RAW-offset naar het begin van de sectie. Moet ook een veelvoud zijn van Bestandsuitlijning…
Kenmerken: DWORD - toegangsattributen tot de sectie en regels om deze in Wirth te laden. geheugen. Bijvoorbeeld een attribuut om de inhoud van een sectie te definiëren (initiële gegevens, geen initiële gegevens, code). Of toegang tot attributen - lezen, schrijven, uitvoeren. Dit is niet hun hele spectrum. Kenmerken worden ingesteld door constanten van dezelfde WINNT.h, die beginnen met IMAGE_SCN_. U kunt meer te weten komen over de sectiekenmerken. Kenmerken in de boeken van Chris Kaspersky zijn ook goed beschreven - de lijst met referenties aan het einde van het artikel.
Onthoud het volgende over de naam - de sectie met bronnen moet altijd de naam.rsrc hebben. Anders worden de bronnen niet geladen. Wat de rest van de secties betreft, de naam kan van alles zijn. Meestal zijn er betekenisvolle namen, bijvoorbeeld .data, .src, enz ... Maar het gebeurt ook als volgt:
Secties zijn een gebied dat wordt uitgewisseld in het virtuele geheugen en al het werk wordt rechtstreeks met deze gegevens gedaan. Het adres in het virtuele geheugen, zonder enige offset, wordt het virtuele adres genoemd, of kortweg VA. Voorkeursadres voor het downloaden van de applicatie, ingesteld in het veld ImageBase... Het is als het punt waarop een toepassingsgebied begint in het virtuele geheugen. En de offsets RVA (Relatief virtueel adres) worden gemeten ten opzichte van dit punt. Dat wil zeggen, VA = ImageBase+ RVA; ImageBase we weten het altijd en als we een VA of RVA tot onze beschikking hebben, kunnen we het een via het ander uitdrukken.
Hier lijken ze eraan gewend te zijn geraakt. Maar dit is virtueel geheugen! En dan zijn we in het fysieke. Virtueel geheugen is voor ons nu als een reis naar andere sterrenstelsels, die we ons tot nu toe alleen kunnen voorstellen. We kunnen dus momenteel niet in het virtuele geheugen komen, maar we kunnen wel uitzoeken wat er zal zijn, omdat het uit ons bestand is gehaald.
Uitlijning
Om het lossen in Wir. geheugen, moet je omgaan met een mechanisme als uitlijning. Laten we eerst eens kijken naar een diagram van hoe secties in het geheugen worden uitgewisseld.
Zoals u kunt zien, wordt de sectie niet door zijn grootte in het geheugen geladen. Hier worden uitlijningen gebruikt. Dit is de waarde die een veelvoud moet zijn van de sectiegrootte in het geheugen. Als we naar het diagram kijken, zullen we zien dat de grootte van de sectie 0x28 is en dat deze wordt gelost met de grootte van 0x50. Dit komt door de grootte van de uitlijning. 0x28 "bereikt niet" 0x50 en als gevolg daarvan wordt de sectie leeggemaakt en wordt de rest van de ruimte in de grootte van 0x50-0x28 op nul gezet. En als de sectiegrootte groter was dan de uitlijningsgrootte, wat dan? bijvoorbeeld sectieGrootte= 0x78, en sectieUitlijning= 0x50, d.w.z. bleef onveranderd. In dit geval zou de sectie 0xA0 (0xA0 = 0x28 * 0x04) bytes in het geheugen innemen. Dat wil zeggen, een waarde die een veelvoud is van sectieUitlijning en volledig dekt sectieGrootte... Houd er rekening mee dat de secties in het bestand op dezelfde manier zijn uitgelijnd, alleen op grootte Bestandsuitlijning... Zodra we de basis hebben die we nodig hebben, kunnen we uitzoeken hoe we van RVA naar RAW kunnen converteren.
"Hier ben je geen vlakte, hier is het klimaat anders."
(V.S. Vysotsky)
Een kleine les in rekenen
Voordat de uitvoering wordt gestart, moet een deel van het programma naar de adresruimte van de processor worden verzonden. Adresruimte is de hoeveelheid fysiek geadresseerd door de processor werkgeheugen... Het "stuk" in de adresruimte waar het programma wordt gelost heet op een virtuele manier(virtueel beeld). Het beeld wordt gekenmerkt door het adres van de basisbelasting (Image base) en grootte (Image size). Dus VA (virtueel adres) is het adres ten opzichte van het begin van virtueel geheugen en RVA (relatief virtueel adres) is relatief ten opzichte van de plaats waar het programma is verwijderd. Hoe vind ik het basisdownloadadres van de applicatie? Hiervoor is er een apart veld in de optionele header genaamd ImageBase... Het was een kleine opfrissing vooraf. Laten we nu eens kijken naar een schematische weergave van de verschillende adresseringen:
Dus hoe kun je nog steeds informatie uit een bestand lezen zonder het in het virtuele geheugen te laden? Om dit te doen, moet u de adressen converteren naar het RAW-formaat. Dan kunnen we in het bestand stappen naar het gebied dat we nodig hebben en de benodigde gegevens lezen. Aangezien RVA een adres in het virtuele geheugen is, waarvan de gegevens uit een bestand zijn geprojecteerd, kunnen we het omgekeerde proces uitvoeren. Hiervoor hebben we de sleutel negen bij zestien eenvoudige rekenkunde nodig. Hier zijn enkele formules:
VA = ImageBase + RVA; RAW = RVA - sectieRVA + rawSection; // rawSection - offset naar de sectie vanaf het begin van het bestand // sectionRVA - RVA-sectie (dit veld is opgeslagen in de sectie)
Zoals u kunt zien, moeten we voor het berekenen van de RAW bepalen tot welk onderdeel 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 de volgende lijst:
Typedef uint32_t DWORD; typedef uint16_t WORD; typedef uint8_t BYTE; #define ALIGN_DOWN (x, uitlijnen) (x & ~ (uitlijnen-1)) #define ALIGN_UP (x, uitlijnen) ((x & (uitlijnen-1))? ALIGN_DOWN (x, uitlijnen) + uitlijnen: 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 >= begin && 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 de typedeclaratie en de initialisatie van de array niet in de code opgenomen, maar heb alleen functies gegeven die helpen bij het berekenen van de adressen. Zoals je kunt zien, is de code niet erg ingewikkeld. Is dat een beetje verwarrend. Het verdwijnt... als je wat meer tijd besteedt aan het verzamelen van in.exe via de disassembler.
HOERA! Begrepen. Nu kunnen we naar de randen van bronnen gaan, bibliotheken importeren en exporteren, en in het algemeen waar de ziel maar wil. We hebben net leren werken met een nieuw soort adressering. Laten we op de weg gaan!
"-Niet slecht niet slecht! Toch kregen ze hun rantsoen voor vandaag!”
(Schateiland)
Tabel exporteren
In het allereerste element van de array Gegevensmap RVA wordt opgeslagen in de exporttabel, die wordt weergegeven door de structuur IMAGE_EXPORT_DIRECTORY. Deze tabel is specifiek voor Dynamic Link Library-bestanden (.dll). De belangrijkste taak van de tabel is om de geëxporteerde functies te koppelen aan hun RVA. De beschrijving wordt gepresenteerd in het kantoor. specificaties:
Typedef struct _IMAGE_EXPORT_DIRECTORY (DWORD-kenmerken; DWORD TimeDateStamp; WORD MajorVersion; WORD MinorVersion; DWORD Name; DWORD Base; DWORD NumberOfFunctions; DWORD NumberOfNames; DWORD AddressOfFunctions; DWORD AddressOfNames; DWORD AddressOfNameOrdAGE
Deze structuur bevat drie verwijzingen naar drie verschillende tafels... Dit is een tabel met namen (functies) ( Adres Van Namen), rangtelwoorden ( AdresVanNamenOrdinalen), adressen ( Adres Van Functies). In het veld Naam wordt de RVA van de naam van de dynamische bibliotheek opgeslagen. De ordinaal is als een intermediair tussen de naamtabel en de adrestabel, en is een array van indices (de grootte van de index is 2 bytes). Bekijk voor de duidelijkheid het diagram:
Laten we naar een voorbeeld kijken. Stel dat het i-de element van de reeks namen de naam van de functie aangeeft. Vervolgens kan het adres van deze functie worden verkregen door te verwijzen naar het i-de element in de reeks adressen. Die. ik is een ordinaal.
Aandacht! Als u bijvoorbeeld het 2e element in de tabel met rangtelwoorden hebt genomen, betekent dit niet 2 - het is een ordinaal voor tabellen met namen en adressen. De index is de waarde die is opgeslagen in het tweede element van de rangtelwoordenreeks.
Het aantal waarden in de naamtabellen ( Aantal Namen) en rangtelwoorden zijn gelijk en vallen niet altijd samen met het aantal elementen in de adrestabel ( Aantal Functies).
“Ze kwamen voor mij. Dank u voor uw aandacht. Nu moeten ze moorden!”
(Schateiland)
Tabel importeren
De importtabel is een essentieel onderdeel van elke toepassing die dynamische bibliotheken gebruikt. Deze tabel helpt bij het toewijzen van de dynamische bibliotheekfunctieaanroepen aan de corresponderende adressen. Importeren kan in drie verschillende modi: standaard, gebonden import en uitgestelde import. Omdat het onderwerp van import is behoorlijk veelzijdig en is gebaseerd op een apart artikel, ik zal alleen het standaardmechanisme beschrijven en de rest zal ik alleen als een "skelet" beschrijven.
Standaard import- v Gegevensmap onder de index IMAGE_DIRECTORY_ENTRY_IMPORT (= 1) wordt de importtabel opgeslagen. 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 loader het effectieve adres van deze functie moet schrijven. Dit mechanisme is niet erg efficiënt omdat: eerlijk gezegd komt het allemaal neer op het herhalen van de hele exporttabel voor elke vereiste functie.
Gebonden import- met dit werkschema in de velden (in het eerste element standaard tafel import) TimeDateStamp en ForwardChain zijn ingesteld op -1 en de bindingsinformatie wordt opgeslagen in de cel Gegevensmap met index IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT (= 11). Dat wil zeggen, dit is een soort vlag voor de lader om gebonden import te gebruiken. Ook voor de "importgebonden keten" verschijnen hun structuren. Het werkalgoritme is als volgt - het virtuele geheugen van de applicatie is leeggemaakt vereiste bibliotheek en alle benodigde adressen zijn "gebonden" in de compilatiefase. Van de tekortkomingen kan worden opgemerkt dat wanneer u dll opnieuw compileert, u de toepassing zelf opnieuw moet compileren, omdat functieadressen worden gewijzigd.
Importeren vertragen- deze methode gaat ervan uit dat het .dll-bestand is gekoppeld aan het uitvoerbare bestand, maar het wordt niet onmiddellijk in het geheugen verwijderd (zoals in de vorige twee methoden), maar alleen bij de eerste aanroep van de toepassing naar het symbool (dit is de naam van de niet-geladen elementen uit dynamische bibliotheken). Dat wil zeggen, het programma wordt in het geheugen uitgevoerd en zodra het proces de functieaanroep van de dynamische bibliotheek bereikt, wordt een speciale handler aangeroepen die de dll laadt en de effectieve adressen van zijn functies distribueert. De lader roept de DataDirectory (item 15) op voor uitgestelde importen.
Nadat we de importmethoden een beetje hebben gemarkeerd, gaan we direct naar de importtabel.
'-Dit is een zeeman! Zijn kleren waren nautisch. - Ja? Heb je eraan gedacht hier een bisschop te vinden?"
(Treasure Island - John Silver)
Import-descriptor (IMAGE_IMPORT_DESCRIPTOR)
Om de coördinaten van de importtabel te achterhalen, moeten we verwijzen naar de array Gegevensmap... Namelijk naar het element IMAGE_DIRECTORY_ENTRY_IMPORT (= 1). En lees het RVA-adres van de tabel. Hier is een algemene schets van de te volgen weg:
Dan halen we RAW van RVA, volgens bovenstaande formules, en "stappen" dan door het bestand. Nu bevinden we ons direct naast een reeks structuren genaamd IMAGE_IMPORT_DESCRIPTOR. Het einde van de array wordt aangegeven door de "null"-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_IMPORT_IMSCRIPTOR, * PIMAGE_IMPORT_IMPORT_IMSCRIPTOR, *
Ik kon geen link ophalen naar de structuurbeschrijving op msdn, maar je kunt het zien in het WINNT.h-bestand. Laten we beginnen het uit te zoeken.
OrigineelFirstThunk: DWORD - RVA-importnaamtabel (INT).
TijdDatumStempel: DWORD - datum en tijd.
ForwarderChain: DWORD - index van het eerste doorgestuurde karakter.
Naam: DWORD - RVA-tekenreeksen met de naam van de bibliotheek.
EersteThunk: DWORD - RVA-importadrestabel (IAT).
Alles lijkt hier een beetje op exporteren. Ook een namentabel (INT) en ook vodden erop (IAT). Ook RVA genoemd naar de bibliotheek. Alleen INT en IAT verwijzen naar een reeks IMAGE_THUNK_DATA-structuren. Het wordt gepresenteerd in twee vormen - voor 64 - en voor 32 systemen en verschilt alleen in de grootte van de velden. Laten we eens kijken naar x86 als voorbeeld:
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 daar antwoord op te geven: volgende stappen afhankelijk van het meest significante deel van de structuur. Indien ingesteld, zijn de resterende bits het nummer van het symbool dat wordt geïmporteerd (importeren op nummer). Anders (meest significante bit 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 aanwijzer 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 het allemaal voor? Al deze arrays, structuren ... Beschouw, voor de duidelijkheid, een prachtig diagram met:
Lezing 3. Bestandsstructuur
Literatuur
o Moderne besturingssystemen, E. Tanenbaum, 2002, St. Petersburg, Peter, 1040 pagina's, (in djvu 10.1MB) meer >>
o Netwerkbesturingssystemen N.A. Oliver, V.G. Oliver (zip-archief 1,1 MB)
o Netwerkbesturingssystemen N.A. Oliver, V.G. Oliver, 2001, St. Petersburg, Peter, 544 pagina's, (in djvu 6.3MB) meer >>
Bestanden
Vereisten voor informatieopslag:
o de mogelijkheid om grote hoeveelheden gegevens op te slaan
o informatie moet worden bewaard na beëindiging van het proces
o meerdere processen moeten gelijktijdig toegang hebben tot informatie
2.1.1 Bestandsnaamgeving
De lengte van de bestandsnaam is afhankelijk van het besturingssysteem en kan van 8 (MS-DOS) tot 255 (Windows, LINUX) tekens zijn.
Het besturingssysteem kan onderscheid maken tussen hoofdletters en kleine letters. WINDOWS en windows zijn bijvoorbeeld hetzelfde voor MS-DOS, maar het zijn verschillende bestanden voor UNIX.
Op veel besturingssystemen bestaat de bestandsnaam uit twee delen gescheiden door een punt, zoals windows.exe. Het gedeelte na de punt heet bestandsextensie... Het systeem gebruikt het om het bestandstype te onderscheiden.
MS-DOS heeft een extensie van 3 tekens. Volgens dit maakt het systeem onderscheid tussen het type bestand en kan het ook worden uitgevoerd of niet.
In UNIX is de extensie beperkt tot de grootte van de bestandsnaam van 255 tekens, en UNIX kan ook meerdere extensies hebben, maar de extensies worden meer gebruikt toepassingsprogramma's, niet het besturingssysteem. Bij uitbreiding kan UNIX niet bepalen of dit bestand uitvoerbaar is of niet.
2.1.2 Bestandsstructuur
Er zijn drie hoofdbestandsstructuren:
1. Opeenvolging van bytes- 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 flexibiliteit in gebruik. Gebruikt op Windows en UNIX.
2. Volgorde van invoer- records met een vaste lengte (bijvoorbeeld een ponskaart), opeenvolgend gelezen. Nu niet gebruikt.
3. Record boom- elk record heeft een sleutel, records worden per sleutel gelezen. Het grote voordeel van een dergelijk systeem is de zoeksnelheid. Nog steeds in gebruik op mainframes.
Drie soorten bestandsstructuren.
2.1.3 Bestandstypen
Belangrijkste bestandstypen:
O Normaal- gebruikersinformatie bevatten. Gebruikt op Windows en UNIX.
O Catalogi - systeembestanden ondersteunende structuur bestandssysteem... Gebruikt op Windows en UNIX.
O Karakter- om input-output te simuleren. Alleen gebruikt op UNIX.
O blokkerig- om schijven te simuleren. Alleen gebruikt op UNIX.
De belangrijkste soorten reguliere bestanden zijn:
O ASCII-bestanden- bestaan uit tekstreeksen... Elke regel wordt afgesloten met een regelterugloop (Windows), een regelinvoer (UNIX) en beide (MS-DOS). Daarom, als u een tekstbestand opent dat is geschreven in UNIX op 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). De belangrijkste voordelen van ASCII-bestanden:
- kan op het scherm worden weergegeven en zonder transformaties naar de printer worden uitgevoerd
- kan door bijna elke editor worden bewerkt
O Binaire bestanden- andere bestanden (geen ASCII). In de regel hebben ze een interne structuur.
De belangrijkste soorten binaire bestanden zijn:
O Uitvoerbaar- programma's, ze kunnen worden verwerkt door het besturingssysteem zelf, hoewel ze worden geschreven als een reeks bytes.
O Niet-uitvoerbaar- ander.
Voorbeelden van uitvoerbare en niet-uitvoerbare bestanden
"Magisch nummer"- het identificeren van het bestand als uitvoerend.
2.1.4 Bestandstoegang
De belangrijkste soorten bestandstoegang:
O Consequent- bytes worden in volgorde gelezen. Gebruikt toen er magneetbanden waren.
2.1.5 Bestandskenmerken
Belangrijkste bestandskenmerken:
o Bescherming - wie en hoe kan toegang krijgen tot het bestand (gebruikers, groepen, lezen / schrijven). Gebruikt op Windows en UNIX.
o Wachtwoord - wachtwoord voor het bestand
o Maker - wie heeft het bestand gemaakt
o Eigenaar - de huidige eigenaar van het bestand
o Alleen-lezen vlag - 0 - lezen / schrijven, 1 - alleen-lezen. Gebruikt in Windows.
o De "verborgen" vlag - 0 - zichtbaar, 1 - onzichtbaar in de lijst met catalogusbestanden (standaard). Gebruikt in Windows.
o De vlag "systeem" - 0 - normaal, 1 - systeem. Gebruikt in Windows.
o Markeer "archief" - klaar of niet voor archivering (niet te verwarren met compressie). Gebruikt in Windows.
o Vlag "gecomprimeerd" - het bestand is gecomprimeerd (vergelijkbaar met zip-archieven). Gebruikt in Windows.
o Vlag "versleuteld" - het versleutelingsalgoritme wordt gebruikt. Als iemand een bestand probeert te lezen dat niet geautoriseerd is om dit te doen, zal hij of zij het niet kunnen lezen. Gebruikt in Windows.
o ASCII / binaire vlag - 0 - ASCII, 1 - binair
o Willekeurige toegangsvlag - 0 - alleen sequentieel, 1 - willekeurige toegang
o Markeer "tijdelijk" - 0 - normaal, 1 - om het bestand aan het einde van het proces te verwijderen
o Blokkeer vlag - blokkeer de toegang tot het bestand. Als hij bezig is met bewerken.
o Aanmaaktijd - datum en tijd van aanmaak. UNIX gebruikt.
o Laatste toegangstijd - datum en tijd van de laatste toegang
o Tijd 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 Bestandsbewerkingen
Basissysteem vereist het werken met bestanden:
o Maken - maak een bestand zonder gegevens.
o Verwijderen - verwijder een bestand.
o Openen - open een bestand.
o Sluiten - sluit het bestand.
o Lezen - lezen uit een bestand, vanaf de huidige positie van het bestand.
o Schrijven - schrijven naar een bestand, op de huidige positie van het bestand.
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 Stel attributen in - stel bestandsattributen in.
o Hernoemen - hernoem een bestand.
geheugen door de lader van het besturingssysteem en vervolgens uitgevoerd. In de operatiekamer Windows-systeem uitvoerbare bestanden hebben meestal de extensies ".exe" en ".dll". De extensies ".exe" hebben programma's die direct door de gebruiker kunnen worden gestart. De extensie ".dll" heeft zogenaamde dynamische linkbibliotheken. Deze bibliotheken exporteren functies die door andere programma's worden gebruikt.Om ervoor te zorgen dat de lader van het besturingssysteem correct wordt geladen uitvoerbaar bestand in het geheugen, moet de inhoud van dit bestand overeenkomen met de indeling van uitvoerbare bestanden die in dit besturingssysteem worden geaccepteerd. In verschillende besturingssystemen, op verschillende tijden, waren en zijn er nog steeds veel verschillende formaten... In dit hoofdstuk zullen we het Portable Executable (PE) formaat bekijken. Het PE-formaat is het belangrijkste formaat voor het opslaan van uitvoerbare bestanden in het Windows-besturingssysteem. Samenstellingen. NET worden ook in dit formaat opgeslagen.
Bovendien kan het PE-formaat worden gebruikt om objectbestanden... Objectbestanden worden gebruikt om een afzonderlijke compilatie van het programma te organiseren. De betekenis van afzonderlijke compilatie is dat de delen van het programma (modules) onafhankelijk worden gecompileerd tot objectbestanden, die vervolgens door de linker worden gekoppeld tot één uitvoerbaar bestand.
En nu - een beetje geschiedenis. Het PE-formaat is gemaakt door de ontwikkelaars van Windows NT. Daarvoor gebruikte het Windows-besturingssysteem de formaten New Executable (NE) en Linear Executable (LE) om uitvoerbare bestanden weer te geven en om objectbestanden gebruikte Object Module Format (OMF). Het NE-formaat was bedoeld voor 16-bits Windows-applicaties, terwijl het LE-formaat, oorspronkelijk ontwikkeld voor OS/2, al 32-bits was. De vraag rijst: waarom? Windows-ontwikkelaars NT besloot te stoppen bestaande formaten? Het antwoord wordt duidelijk als je bedenkt dat het grootste deel van het team achter Windows NT voorheen bij Digital Equipment Corporation werkte. Ze waren bij DEC bezig met het ontwikkelen van tooling voor het VAX / VMS-besturingssysteem, en ze hadden al de vaardigheden en klaar code voor het werken met uitvoerbare bestanden die worden gepresenteerd in de Common Object File Format (COFF). Dienovereenkomstig werd het COFF-formaat in een enigszins gewijzigde vorm geport naar Windows NT en PE genoemd.
De .NET Framework-woordenlijst zegt dat PE een implementatie is Microsoft-formaat KOFF. Tegelijkertijd stelt het dat PE het formaat is van uitvoerbare bestanden en COFF het formaat is objectbestanden... Over het algemeen kunnen we in de Microsoft-documentatie verwarring waarnemen over de naam van het formaat. Op sommige plaatsen noemen ze het COFF en op andere plaatsen PE. Toegegeven, je ziet dat in de nieuwe teksten de naam COFF steeds minder wordt gebruikt. Bovendien evolueert het PE-formaat voortdurend. Een paar jaar geleden stopte Microsoft bijvoorbeeld met het opslaan van foutopsporingsinformatie in een uitvoerbaar bestand, en daarom worden nu veel velden in COFF-structuren gewoon niet gebruikt. Bovendien is het COFF-formaat 32-bits en laatste revisie PE-formaat (genaamd PE32+) kan worden gebruikt op 64-bits hardwareplatforms. Het gaat er dus blijkbaar om dat de naam COFF helemaal niet meer wordt gebruikt.
Het is interessant om op te merken dat oudere NE- en LE-binaire bestanden vandaag de dag nog steeds door Windows worden ondersteund. Uitvoerbare bestanden in NE-indeling kunnen worden uitgevoerd onder NTVDM (NT Virtual DOS Machine), terwijl LE-indeling wordt gebruikt voor virtuele apparaatstuurprogramma's (
Het bestand begrijpen Linux-systemen, directorystructuur, configuratielocatie, uitvoerbare en tijdelijke bestanden zullen u helpen uw systeem beter te begrijpen en een succesvolle systeembeheerder te worden. Het Linux-bestandssysteem zal ongebruikelijk zijn voor een nieuweling die net is overgestapt van Windows, omdat alles hier compleet anders is. In tegenstelling tot Windows bevindt het programma zich niet in één map, maar wordt het in de regel verdeeld over het rootbestandssysteem. Deze verdeling leent zich voor bepaalde regels. Heb je je ooit afgevraagd waarom sommige programma's in de map / bin, of / sbin, / usr / sbin, / usr / local / bin staan, wat is het verschil tussen deze mappen?
Het minder programma staat bijvoorbeeld in /usr /bin, maar waarom niet /sbin of /usr/sbin. En programma's zoals ifconfig of fdisk staan in de /sbin directory en nergens anders.
Dit artikel gaat volledig in op de structuur van het Linux-bestandssysteem. Na het te hebben gelezen, zou u de betekenis moeten begrijpen van het gebruik van de meeste mappen in de Linux-hoofdmap.
/ - wortel
Dit is de hoofdmap op een Linux-systeem. In wezen is dit het Linux-bestandssysteem. Er zijn hier geen schijven of iets dergelijks. In plaats daarvan beginnen alle bestandsadressen bij de root, en extra secties, flashdrives of optische schijven zijn verbonden met de mappen van de hoofdmap.
Merk op dat root een homedirectory van / root heeft, maar niet / zelf.
/ bin - (binaire bestanden) binaire bestanden van gebruikers
Deze map bevat uitvoerbare bestanden. Dit zijn de programma's die u kunt gebruiken in de modus voor één gebruiker of in de herstelmodus. Kortom, de hulpprogramma's die kunnen worden gebruikt, zijn nog niet verbonden met de / usr / directory. Zij zijn algemene commando's zoals kat, ls, staart, ps, enz.
/ sbin - (systeem binaire bestanden) systeem binaire bestanden
Net als / bin, bevat het binaire bestanden die vroeg in de opstartfase beschikbaar zijn wanneer / usr niet is aangekoppeld. Maar hier zijn programma's die alleen kunnen worden uitgevoerd met superuser-rechten. Dit zijn verschillende hulpprogramma's voor systeemonderhoud. Bijvoorbeeld iptables, reboot, fdisk, ifconfig, swapon, etc.
/ etc - (etcetera) configuratiebestanden
Deze map bevat configuratiebestanden voor alle programma's die op het systeem zijn geïnstalleerd.
Naast de configuratiebestanden bevat het initialisatiesysteem Init Scripts scripts voor het starten en beëindigen van systeemdaemons, het aankoppelen van bestandssystemen en het starten van programma's. De linux-directorystructuur in deze map kan een beetje verwarrend zijn, maar ze zijn allemaal ingesteld en geconfigureerd.
/ dev - (apparaten) apparaatbestanden
In Linux, alles, inclusief externe apparaten zijn bestanden. Dus alle aangesloten flashdrives, toetsenborden, microfoons, camera's zijn gewoon bestanden in de / dev / directory. Deze map bevat een ongebruikelijk bestandssysteem. De structuur van het Linux-bestandssysteem en de bestanden in de map / dev worden tijdens het opstarten geïnitialiseerd door de udev-service. Alle aangesloten apparaten worden voor hen gescand en aangemaakt. speciale bestanden... Dit zijn apparaten zoals: / dev / sda, / dev / sr0, / dev / tty1, / dev / usbmon0, etc.
/ proc - (proces)informatie over processen
Dit is ook een ongebruikelijk bestandssysteem, maar een subsysteem dat dynamisch door de kernel wordt gecreëerd. Alle informatie over lopende processen live. Kortom, het is een pseudo-bestandssysteem met: gedetailleerde informatie over elk proces, zijn Pid, de naam van het uitvoerbare bestand, opstartparameters, toegang tot RAM, enzovoort. Ook vindt u hier informatie over het gebruik van systeembronnen bijv. / proc / cpuinfo, / proc / meminfo, of / proc / uptime. Naast de bestanden heeft deze map een grote structuur linux-mappen, waaruit u veel informatie over het systeem kunt leren.
/ var (variabele) - Variabele bestanden
De directorynaam / var spreekt voor zich, het zou bestanden moeten bevatten die regelmatig veranderen. De grootte van deze bestanden groeit voortdurend. Dit bevat de bestanden systeemlogboeken, verschillende caches, databases enzovoort. Overweeg vervolgens de afspraak Linux-mappen in de / var / map.
/ var / log - Logbestanden
/ var / lib - databases
een ander type veranderlijke bestanden zijn databasebestanden, pakketten opgeslagen pakket manager enzovoort.
/ var / mail - mail
In deze map mail server telt alle ontvangen of verzonden e-mails, zijn logs en configuratiebestanden ook hier te vinden.
/ var / spool - printer
Aanvankelijk was deze map verantwoordelijk voor de afdrukwachtrijen op de printer en het werk van de CPU-suite met programma's.
/ var / lock - bestanden vergrendelen
De lock-bestanden bevinden zich hier. Deze bestanden betekenen dat: een bepaalde hulpbron, het bestand of apparaat is bezet en kan niet door een ander proces worden gebruikt. Apt-get vergrendelt bijvoorbeeld zijn database zodat andere programma's deze niet kunnen gebruiken terwijl het programma ermee werkt.
/ var / run - PID van processen
Bevat bestanden met PID's van processen die kunnen worden gebruikt voor communicatie tussen programma's. In tegenstelling tot de map / run blijven de gegevens behouden tijdens het opnieuw opstarten.
/ tmp (temp) - Tijdelijke bestanden
Deze map bevat tijdelijke bestanden die zijn gemaakt door het systeem, programma's of gebruikers. Alle gebruikers hebben schrijftoegang tot deze directory.
Bij elke herstart worden bestanden verwijderd. De map Windows \ Temp is analoog aan Windows; hier worden ook alle tijdelijke bestanden opgeslagen.
/ usr - (gebruikerstoepassingen) Gebruikersprogramma's
Dit is de grootste map met grote hoeveelheid functies. Dit is de grootste Linux-directorystructuur. Het bevat uitvoerbare bestanden, broncodes, verschillende applicatiebronnen, afbeeldingen, muziek en documentatie.
/ usr / bin / - Uitvoerbare bestanden
Bevat uitvoerbare bestanden verschillende programma's die niet nodig zijn in de eerste fasen van het opstarten van het systeem, bijvoorbeeld muziekspelers, grafische editor, browsers enzovoort.
/ usr / sbin /
bevat binaire bestanden systeembeheerprogramma's die moeten worden uitgevoerd met superuser-rechten. Bijvoorbeeld, zoals Gparted, sshd, useradd, userdel, etc.
/ usr / lib / - Bibliotheken
Bevat bibliotheken voor programma's van / usr / bin of / usr / sbin.
/ usr / local - Gebruikersbestanden
Bevat bestanden van programma's, bibliotheken en instellingen die door de gebruiker zijn gemaakt. Programma's die zijn gecompileerd en geïnstalleerd op basis van bronnen en met de hand geschreven scripts kunnen hier bijvoorbeeld worden opgeslagen.
/ home - Thuismap
Deze map bevat de homedirectories van alle gebruikers. Daarin kunnen ze hun persoonlijke bestanden, programma-instellingen, enz. Bijvoorbeeld / home / sergiy, enz. In vergelijking met Windows is dit uw gebruikersmap op de C-schijf, maar in tegenstelling tot Windows bevindt home zich meestal op een aparte partitie, dus wanneer u het systeem opnieuw installeert, al uw gegevens en programma-instellingen worden opgeslagen.
/ boot - Opstartbestanden
Bevat alle bestanden met betrekking tot de systeem-bootloader. Dit is de vmlinuz-kernel, de initrd-afbeelding en de bootloader-bestanden die te vinden zijn in de map / boot / grub.
/ lib (bibliotheek) - Systeembibliotheken
Bevat bestanden systeembibliotheken die worden gebruikt door de uitvoerbare bestanden in de mappen / bin en / sbin.
Bibliotheken hebben bestandsnamen met de extensie * .so en beginnen met het prefix lib *. Bijvoorbeeld libncurses.so.5.7. Map / lib64 op 64 bitsystemen bevat 64-bits versies van bibliotheken van / lib. Deze map is te vergelijken met WIndows\system32, alle bibliotheken van het systeem worden daar ook gedownload, alleen daar worden ze gemengd met uitvoerbare bestanden, en hier is alles gescheiden.
/ opt (Optionele toepassingen) - Extra programma's
In deze map worden eigen programma's, games of stuurprogramma's geïnstalleerd. Dit zijn programma's die door de fabrikanten zelf als afzonderlijke uitvoerbare bestanden zijn gemaakt. Dergelijke programma's worden geïnstalleerd in / opt / subdirectories, ze lijken erg op Windows-programma's, alle uitvoerbare bestanden, bibliotheken en configuratiebestanden bevinden zich in één map.
/ mnt (montage) - Montage
Naar deze map systeembeheerders kan externe of aanvullende bestandssystemen aankoppelen.
/ media - Verwisselbare media
In deze map koppelt het systeem alle aangesloten externe schijven- USB-flashstations, optische schijven en andere opslagmedia.
/ srv (server) - Server
Deze directory bevat server- en servicebestanden. De apache-webserverbestanden kunnen bijvoorbeeld ingesloten zijn.
/ uitvoeren - processen
Een andere map met PID-bestanden van processen, vergelijkbaar met / var / run, maar anders dan deze, bevindt deze zich in TMPFS en daarom gaan alle bestanden verloren na een herstart.
/ sys (systeem) - Systeeminformatie
Het doel van de Linux-directory's uit deze map is om systeeminformatie rechtstreeks uit de kernel te halen. Dit is een ander bestandssysteem dat door de kernel is georganiseerd en waarmee je veel parameters van het systeem kunt bekijken en wijzigen, bijvoorbeeld hoe swap werkt, ventilatoren aansturen en nog veel meer.
2.1 Bestanden
Vereisten voor informatieopslag:
de mogelijkheid om grote hoeveelheden gegevens op te slaan
informatie moet worden bewaard na beëindiging van het proces
meerdere processen moeten gelijktijdig toegang hebben tot informatie
2.1.1 Bestandsnaamgeving
De lengte van de bestandsnaam is afhankelijk van het besturingssysteem en kan van 8 (MS-DOS) tot 255 (Windows, LINUX) tekens zijn.
Het besturingssysteem kan onderscheid maken tussen hoofdletters en kleine letters. WINDOWS en windows zijn bijvoorbeeld hetzelfde voor MS-DOS, maar het zijn verschillende bestanden voor UNIX.
Op veel besturingssystemen bestaat de bestandsnaam uit twee delen gescheiden door een punt, zoals windows.exe. Het gedeelte na de punt heet bestandsextensie... Het systeem gebruikt het om het bestandstype te onderscheiden.
MS-DOS heeft een extensie van 3 tekens. Volgens dit maakt het systeem onderscheid tussen het type bestand en kan het ook worden uitgevoerd of niet.
In UNIX is de extensie beperkt tot een bestandsnaam van 255 tekens, en UNIX kan ook meerdere extensies hebben, maar de extensies worden meer gebruikt door toepassingsprogramma's dan door het besturingssysteem. Bij uitbreiding kan UNIX niet bepalen of dit bestand uitvoerbaar is of niet.
2.1.2 Bestandsstructuur
Er zijn drie hoofdbestandsstructuren:
Opeenvolging van bytes- 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 flexibiliteit in gebruik. Gebruikt op Windows en UNIX.
Volgorde van invoer- records met een vaste lengte (bijvoorbeeld een ponskaart), opeenvolgend gelezen. Nu niet gebruikt.
Record boom- elk record heeft een sleutel, records worden per sleutel gelezen. Het grote voordeel van een dergelijk systeem is de zoeksnelheid. Nog steeds in gebruik op mainframes.
Drie soorten bestandsstructuren.
2.1.3 Bestand types
Belangrijkste bestandstypen:
Normaal- gebruikersinformatie bevatten. Gebruikt op Windows en UNIX.
Catalogi- systeembestanden, die de structuur van het bestandssysteem ondersteunen. Gebruikt op Windows en UNIX.
Karakter- om input-output te simuleren. Alleen gebruikt op UNIX.
blokkerig- om schijven te simuleren. Alleen gebruikt op UNIX.
De belangrijkste soorten reguliere bestanden zijn:
ASCII-bestanden- bestaan uit tekstregels. Elke regel wordt afgesloten met een regelterugloop (Windows), een regelinvoer (UNIX) en beide (MS-DOS). Daarom, als u een tekstbestand opent dat is geschreven in UNIX op 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). De belangrijkste voordelen van ASCII-bestanden:
- kan op het scherm worden weergegeven en zonder transformaties naar de printer worden uitgevoerd
- kan door bijna elke editor worden bewerkt
Binaire bestanden- andere bestanden (geen ASCII). In de regel hebben ze een interne structuur.
De belangrijkste soorten binaire bestanden zijn:
Uitvoerbaar- programma's, ze kunnen worden verwerkt door het besturingssysteem zelf, hoewel ze worden geschreven als een reeks bytes.
Niet-uitvoerbaar- ander.
Voorbeelden van uitvoerbare en niet-uitvoerbare bestanden
"Magisch nummer"- het identificeren van het bestand als uitvoerend.
2.1.4 Toegang tot bestanden
De belangrijkste soorten bestandstoegang:
Consequent- bytes worden in volgorde gelezen. Gebruikt toen er magneetbanden waren.
2.1.5 Bestandskenmerken
Belangrijkste bestandskenmerken:
Beveiliging - wie en hoe heeft toegang tot het bestand (gebruikers, groepen, lezen / schrijven). Gebruikt op Windows en UNIX.
Wachtwoord - het wachtwoord voor het bestand
Maker - wie heeft het bestand gemaakt
Eigenaar - de huidige eigenaar van het bestand
Alleen-lezen vlag - 0 - lezen / schrijven, 1 - alleen-lezen. Gebruikt in Windows.
De "verborgen" vlag - 0 - zichtbaar, 1 - niet zichtbaar in de lijst met catalogusbestanden (standaard). Gebruikt in Windows.
De vlag "systeem" is 0 - normaal, 1 - systeem. Gebruikt in Windows.
Archiefvlag - klaar of niet voor archivering (niet te verwarren met compressie). Gebruikt in Windows.
Vlag "Gecomprimeerd" - het bestand is gecomprimeerd (vergelijkbaar met zip-archieven). Gebruikt in Windows.
Vlag "Versleuteld" - coderingsalgoritme wordt gebruikt. Als iemand een bestand probeert te lezen dat niet geautoriseerd is om dit te doen, zal hij of zij het niet kunnen lezen. Gebruikt in Windows.
ASCII / binaire vlag - 0 - ASCII, 1 - binair
Willekeurige toegangsvlag - 0 - alleen sequentieel, 1 - willekeurige toegang
De "tijdelijke" vlag - 0 - normaal, 1 - om het bestand aan het einde van het proces te verwijderen
De blokkeervlag blokkeert de toegang tot het bestand. Als hij bezig is met bewerken.
Aanmaaktijd - datum en tijd van aanmaak. UNIX gebruikt.
Laatste toegangstijd - datum en tijd van de laatste toegang
Laatst gewijzigde tijd - datum en tijd van de laatste wijziging. Gebruikt op Windows en UNIX.
De huidige grootte is de grootte van het bestand. Gebruikt op Windows en UNIX.
2.1.6 Bestandsbewerkingen
Basissysteem vereist het werken met bestanden:
Maken - maak een bestand zonder gegevens.
Verwijderen - verwijder een bestand.
Openen - een bestand openen.
Sluiten - sluit het bestand.
Lezen - lezen uit een bestand, vanaf de huidige positie van het bestand.
Schrijven - schrijven naar een bestand, op de huidige positie van het bestand.
Toevoegen - toevoegen aan het einde van het bestand.
Zoeken - stelt de bestandsaanwijzer in op een specifieke positie in het bestand.
Attributen ophalen - de attributen van een bestand ophalen.
Stel attributen in - stel bestandsattributen in.
Hernoemen - hernoem een bestand.
2.1.7 Bestanden toegewezen aan geheugenadresruimte
Soms is het handig om het bestand in het geheugen weer te geven (u hoeft geen I / O-systeemaanroepen te gebruiken om met het bestand te werken), en met geheugen te werken en vervolgens het gewijzigde bestand naar schijf te schrijven.
Gebruik makend van pagina-organisatie geheugen, wordt niet het hele bestand geladen, maar worden alleen de benodigde pagina's geladen.
Bij gebruik van een gesegmenteerde geheugenorganisatie wordt het bestand in een apart segment geladen.
Een voorbeeld van het kopiëren van een bestand via geheugentoewijzing.
Algoritme:
Segment is gemaakt voor bestand 1
Het bestand wordt weergegeven in het geheugen
Segment is gemaakt voor bestand 2
Segment 1 wordt gekopieerd naar segment 2
Segment 2 wordt op schijf opgeslagen
Nadelen van deze methode:
Moeilijk om de lengte van het uitvoerbestand te bepalen
Als een proces een bestand in het geheugen heeft toegewezen en gewijzigd, maar het bestand is nog niet opgeslagen, zal het tweede proces hetzelfde bestand openen en met het verouderde bestand werken.
Het bestand kan groot zijn, groter dan een segment of virtuele ruimte.
2.2 Directory's
2.2.1 Directorysystemen op één niveau
Op dit systeem bevinden alle bestanden zich in één map.
Systeem met één map met vier bestanden, bestanden A twee, maar verschillende eigenaren
Systeem voordelen:
Eenvoud
De mogelijkheid om snel een bestand te vinden, u hoeft niet door mappen te bladeren
Nadelen van het systeem:
Verschillende gebruikers kunnen bestanden maken met dezelfde naam.
2.2.2 Tweeledige directorysystemen
Voor elke gebruiker wordt zijn eigen directory aangemaakt.
Directorysysteem met twee niveaus
De gebruiker komt bij het betreden van het systeem in zijn directory en werkt er alleen mee. Dit maakt het gebruik van systeembestanden problematisch.
Dit probleem kan worden opgelost door het creëren van systeemmap, met algemene toegang.
Als een gebruiker veel bestanden heeft, heeft hij mogelijk ook bestanden met dezelfde naam nodig.
2.2.3 Hiërarchische directorysystemen
Elke gebruiker kan zoveel mappen aanmaken als hij nodig heeft.
Hiërarchisch directorysysteem
Bijna alle moderne algemene besturingssystemen zijn op deze manier georganiseerd. Dit is misschien niet nodig voor een gespecialiseerd besturingssysteem.
2.2.4 Padnaam
Het organiseren van een directorystructuur vereist een manier om het bestand te specificeren.
Er zijn twee hoofdmethoden voor het specificeren van een bestand:
absolute padnaam- geeft het pad van de hoofdmap aan, bijvoorbeeld:
- voor Windows \ usr \ ast \ mailbox
- voor UNIX / usr / ast / mailbox
- voor MULTICS> usr> ast> mailbox
relatieve padnaam- het pad wordt gespecificeerd vanuit de huidige directory (werkdirectory), bijvoorbeeld:
- als de huidige map / usr / is, dan absoluut pad/ usr / ast / mailbox wordt herschreven naar ast / mailbox
- als de huidige map / usr / ast / is, wordt het absolute pad / usr / ast / mailbox overschreven in mailbox
- als de huidige directory / var / log / is, dan wordt het absolute pad / usr / ast / mailbox overschreven in ../../usr / ast / mailbox
./ - betekent de huidige map
../ - betekent bovenliggende map
2.2.5 Bewerkingen met mappen
Basissysteem vereist het werken met directory's:
Aanmaken - maak een map aan
Verwijderen - verwijder een map
OpenDir - map sluiten
CloseDir - sluit de map
Hernoemen - hernoem een map
