PE-tiedostorakenne

PE-tiedoston yleinen kuvaus

Monien ohjelmointitehtävien ratkaiseminen edellyttää suoritettavien tiedostojen sisäisen rakenteen tuntemista ja ymmärrystä niiden lataamisesta muistiin.

Kaikissa Windows-käyttöjärjestelmän 32-bittisissä haaroissa objekti- (.OBJ), kirjasto- (.LIB) ja suoritettavat tiedostot (.EXE ja .DLL) on tallennettu yhteen COFF-muotoon (Common Object File Format), jota jotkut käyttävät järjestelmät Unix-perhe ja VMS-käyttöjärjestelmä.

PE (Portable Executable) -muoto on COFF-erikoistuminen suoritettavien moduulien tallentamiseen. Tool Interface Standard Committee (Microsoft, Intel, IBM, Borland, Watcom jne.) standardoi sen vuonna 1993, ja sen jälkeen päivitettiin asteittain (viimeinen päivitys, jonka tiedän, oli helmikuussa 1999, mutta se ei sisällä metatietojen tukea .NET, lisätty vuonna 2000). Nimi Portable Executable johtuu siitä, että tämä muoto ei riipu sen prosessorin arkkitehtuurista, jota varten suoritettava tiedosto on rakennettu.

Nykyään on olemassa kaksi PE-tiedostomuotoa: PE32 ja PE32+. Molemmat rajoittavat ohjelman osoiteavaruuden 4 Gt:iin (0xFFFFFFFF), mutta PE32 käyttää 32-bittisiä osoitteita (Win32-arkkitehtuuri) ja PE32+ käyttää 64-bittisiä osoitteita (Win64-arkkitehtuuri).

Useimmat alla kuvatuista rakenteista ja vakioista sisältyvät tavalliseen Windowsin otsikkotiedostoon WINNT.H.

Mikä tahansa PE-tiedosto koostuu useista otsikoista ja useista (1 - 96) osioista. Otsikoissa on palvelutietoja, jotka kuvaavat suoritettavan tiedoston erilaisia ​​ominaisuuksia ja sen rakennetta. Osat sisältävät tietoja, jotka on varattu prosessin osoiteavaruuteen, kun suoritettava tiedosto ladataan muistiin.

PE-tiedostot ovat suhteellisia lataustiedostoja, ts. voidaan teoriassa sijoittaa osoiteavaruuteen 0x00000000 - 0xFFFFFFFF mistä tahansa osoitteesta, jota kutsutaan perusosoitteeksi. Koska perusosoitetta ei tiedetä etukäteen, PE-tiedostojen rakenne perustuu RVA-konseptiin (relative virtual address). RVA on siirtymä suoritettavan tiedoston perusosoitteesta tiettyyn osoitteeseen. Toisin sanoen, saadaksesi lineaarisen osoitteen prosessin virtuaalimuistissa, sinun on lisättävä RVA perusosoitteeseen.

Erityisesti on korostettava, että RVA:lla ei ole mitään tekemistä tiedoston alkuun verrattuna. Tiedoston latausprosessin aikana jokainen sen osa sijoitetaan muistiin omalla RVA:lla ja tarvittaessa täytetään nollia määritettyyn kokoon. Tässä tapauksessa RVA-osio ja sen koko muistissa ei yleisesti ottaen liity mitenkään sen sijaintiin ja kokoon lähdetiedostossa.

PE-tiedoston yleinen rakenne on esitetty taulukossa 2.1:

Taulukko 2.1 - Tiedoston rakenne

Jokainen näistä rakenteista kuvataan yksityiskohtaisesti alla.

DOS-otsikon ja tynkän yleinen kuvaus

Koska sekä DOS-sovellukset että Windows-sovellukset on laajennus .EXE, kaikki suoritettavat Windows-tiedostoja käytä kaavaa kaksoiskäynnistys. Se koostuu siitä, että tiedosto alkaa DOS-otsikolla, jota seuraa tynkä, ts. Pieni EXE-tiedosto DOS-muodossa. Kun yrität ladata tiedoston DOS:sta, suoritetaan tynkä ja kun lataat tiedoston Windowsin käynnistyslatain jäsentää DOS-otsikon ja poimii siitä offsetin suoritettavan tiedoston todelliseen otsikkoon.

b DOS-otsikkorakennetta kutsutaan nimellä IMAGE_DOS_HEADER. En kuvaile DOS-otsikkoa täysin, koska... Olemme kiinnostuneita vain kahdesta alasta, nimittäin:

b 2-tavuinen (WORD) allekirjoitus, joka sijaitsee offsetissa 0 (e_magic) ja yhtä suuri kuin "MZ" (IMAGE_DOS_SIGNATURE);

b 4-tavuinen (DWORD) siirtymä tiedoston alusta PE-otsikkoon, joka sijaitsee offsetissa 0x3C (e_lfanew).

Kun lataat PE-tiedostoa, sinun on ensin tarkistettava DOS-allekirjoitus, löydettävä sitten PE-otsikon siirtymä ja tarkistettava sen otsikon alussa oleva PE-allekirjoitus. Tämä allekirjoitus koostuu 4 tavusta ja on yhtä suuri kuin "PE" (nimitys IMAGE_NT_SIGNATURE).

Muut tiedostot (Win16 ja OS/2 suoritettavat tiedostot ja Windows 9x VxD -ajurit) käyttävät samaa kaksoiskäynnistysmallia, joten PE-allekirjoituksen oikeellisuuden tarkistaminen on pakollista.

Tyypillisesti DOS-teksti näyttää viestin, kuten "Tämä ohjelma vaatii Microsoft Windowsin", ja poistu. Ohjelmaa rakennettaessa voimme kuitenkin määritellä sisään komentorivi kerätä mikä tahansa DOS EXE -tiedosto tynkäksi. Tämän avulla voit luoda "kaksoisohjelmia", jotka toimivat sekä DOS- että Windowsissa.

DOS-otsikon rakenne

typedef struct _IMAGE_DOS_HEADER ( // DOS.EXE-otsikko

USHORT e_magic; // Maaginen numero

USHORT e_cblp; // Tavujen määrä per viimeinen sivu tiedosto

USHORT e_cp; // Tiedoston sivujen lukumäärä

USHORT e_crlc; // Muutokset

USHORT e_cparhdr; // Otsikon koko kappaleissa

USHORT e_minalloc; // Ylimääräisiä kappaleita tarvitaan vähintään

USHORT e_maxalloc; // Ylimääräisiä kappaleita tarvitaan enintään

USHORT e_ss; // SS-rekisterin alkuperäinen (suhteellinen) arvo

USHORT e_sp; // Alkuarvo rekisteröi SP

USHORT e_csum; // Tarkista summa

USHORT e_ip; // IP-rekisterin alkuarvo

USHORT e_cs; // CS-rekisterin alkuperäinen (suhteellinen) arvo

USHORT e_lfarlc; // Tiedoston osoite edelleenlähetystaulukkoon

USHORT e_ovno; // Peittokuvien määrä

USHORT e_res; // Varattu

USHORT e_oemid; // OEM-tunniste (e_oeminfo)

USHORT e_oeminfo; // OEM-tiedot; e_oemid-kohtainen

USHORT e_res2 ; // Varattu

PITKÄ e_lfanew; // Osoite uudessa .exe-otsikkotiedostossa

) IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

Tärkein kenttä tässä on e_lfanew, joka sisältää 4-tavun siirtymän tiedoston alusta PE-otsikkoon. Ensimmäinen e_magic-rakenteen kenttä sisältää suoritettavan tiedoston allekirjoituksen. Kaikilla MS-DOS-yhteensopivilla suoritettavilla tiedostoilla on allekirjoitus 0x54AD, joka esitetään ASCII-merkeissä kahdella MZ-merkillä. Tästä syystä DOS-otsikkoa kutsutaan usein MZ-otsikoksi.

PE-otsikon rakenne

PE-otsikko (IMAGE_NT_HEADERS) koostuu kolmesta osasta (katso taulukko 2.2):

Taulukko 2.2 - Otsikkorakenne

struct IMAGE_NT_HEADERS (

DWORD-allekirjoitus;

IMAGE_FILE_HEADER Tiedoston otsikko;

IMAGE_OPTIONAL_HEADER Valinnainen otsikko;

PE-otsikko alkaa aina 4-tavuisella "PE"-allekirjoituksella (IMAGE_NT_SIGNATURE). Sitä seuraa kaksi otsikkoa: tiedoston otsikko (IMAGE_FILE_HEADER) ja valinnainen otsikko (IMAGE_OPTIONAL_HEADER). Nimestään huolimatta IMAGE_OPTIONAL_HEADER on aina PE-tiedostossa (se on valinnainen näkökulmasta yleinen muoto COFF, koska sitä ei käytetä objekti- ja kirjastotiedostoissa).

Tiedoston otsikko

Tiedoston otsikko koostuu 0x14 tavusta (määritelmä IMAGE_SIZEOF_FILE_HEADER), sijoitetaan välittömästi allekirjoituksen jälkeen ja sisältää yleisen kuvauksen tiedostosta. Se koostuu seuraavista kentistä:

Taulukko 2.3 - Tiedoston otsikkorakenne

Kuvaus kenttien tarkoituksesta.

Konekenttä

16-bittinen numero, joka määrittää prosessorin arkkitehtuurin, jossa ohjelma voi toimia.

TimeDateStamp-kenttä

32-bittinen luku, joka sisältää luomispäivämäärän ja -ajan tästä tiedostosta. Tämän kentän muoto on dokumentoimaton, mutta Microsoftin kerääjät syöttävät ajan tähän sekuntimääränä 01.1.1970 keskiyöstä UTC:ssä (eli käyttävät C-kielen aikafunktion palauttamaa Unix-aikamuotoa). Tämä muuten tarkoittaa, että PE-muodon nykyinen tila on voimassa vain 18.1.2038 asti.

Koska tämän kentän muoto on dokumentoimaton, jotkut kolmannen osapuolen kerääjät tallentavat sen arvon muihin muotoihin. Tämä voi olla tärkeää, koska... Tätä kenttää käytetään linkitettäessä dynaamisesti tuontia DLL-tiedostoista.

PointerToSymbolTable- ja NumberOfSymbols-kentät

COFF-standardin mukaan näiden 4-tavuisten kenttien on tarjottava pääsy tiedoston virheenkorjaustietoihin. Kaikki tuntemani kerääjät sisältävät kuitenkin nollia, ja virheenkorjaustietojen saamiseksi käytetään eri menetelmää (katso virheenkorjaustietohakemisto).

SizeOfOptionalHeader-kenttä

16-bittinen luku, joka määrittää valinnaisen otsikon koon. Se on 0xE0 PE32-tiedostoille (IMAGE_SIZEOF_NT_OPTIONAL32_HEADER) ja 0xF0 PE32+-tiedostoille (IMAGE_SIZEOF_NT_OPTIONAL64_HEADER).

Ala Ominaisuudet

16-bittinen lippukenttä, joka sisältää tiedoston COFF-attribuutit.

Valinnainen otsikko

Valinnaisessa otsikossa on kaksi erilaisia ​​formaatteja: PE32:lle ja PE32+:lle. Vastaavia rakenteita kutsutaan nimellä IMAGE_OPTIONAL_HEADER32 ja IMAGE_OPTIONAL_HEADER64. Niiden kentät on yhteenveto taulukossa 2.4:

Taulukko 2.4 - Valinnainen otsikkorakenne

16-bittinen kenttä, joka sisältää otsikon allekirjoituksen. Voi ottaa arvoja (katso taulukko 2.4):

Taulukko 2.4 - Kelvolliset arvot Maagiset kentät

MajorSubsystemVersion- ja MinorSubsystemVersion-kentät

16-bittiset numerot osoittavat odotetun Windowsin version. Toisin kuin kaikki muut versionumerokentät, tämä kenttä analysoitiin, kun ohjelmia ladattiin NT 4.0:aan ja 95:een. Jos ohjelma oli graafinen sovellus eikä tämä kenttä sisältänyt versiota 4.0, ohjelman katsottiin olevan kehitetty NT 3.51:lle ja tämän käyttöjärjestelmän käyttäytymistä simuloitiin (erityisesti kolmiulotteisten dialogityylien puute jne.). Tällä hetkellä ei käytössä ja lähes aina yhtä suuri kuin 4.0.

Tarkistussumma-kenttä

32-bittinen tiedoston tarkistussumma. Tarkistettu vain Windows NT:ssä, kun ladataan ytimen ohjaimia ja useita järjestelmän DLL:t. Laskenta-algoritmi tarkistussumma on dokumentoimaton, mutta voit laskea sen käyttämällä IMAGEHLP.DLL-kirjaston CheckSumMappedFile-järjestelmäfunktiota.

Alajärjestelmä-kenttä

16-bittinen numero, joka ilmaisee, missä Windows API-alijärjestelmässä tiedosto tulee suorittaa. Sen mahdolliset arvot on esitetty taulukossa 2.5:

Taulukko 2.5 - Alijärjestelmä-kentän kelvolliset arvot

DLLCharacteristics kenttä

16-bittinen lippukentän määrittely lisäattribuutteja tiedosto. Mahdolliset lippujen arvot on esitetty taulukossa 2.6.

Taulukko 2.6 - DLLCharacteristics-kentän lippujen mahdolliset arvot

NumberOfRvaAndSizes- ja DataDirectory-kentät

Valinnaisen otsikon lopussa on 32-bittinen numero, joka tallentaa tietohakemiston kahvojen lukumäärän. Tätä seuraa joukko itse kuvauksia, joista jokainen näyttää tältä:

struct IMAGE_DATA_DIRECTORY (

DWORD VirtualAddress;

Tällä hetkellä NumberOfRvaAndSizes-kenttä sisältää aina luvun 16 (symbolinen nimi IMAGE_NUMBEROF_DIRECTORY_ENTRIES). Vastaavasti DataDirectory-taulukko koostuu myös 16 kuvaajasta. Jokainen kuvaaja sisältää yhden tietohakemiston RVA:n ja koon. Jos hakemistoa ei ole tiedostossa, sen kuvaajan molemmat kentät ovat nolla.

Jokainen tietohakemisto sisältää tiettyjä palvelutietoja. Näiden tietojen tyyppi määräytyy kuvaustaulukon hakemistonumeron mukaan. Koska tietohakemistot sijaitsevat tyypillisesti osioiden sisällä, niiden sisältöön pääsemiseksi meidän on ensin tutkittava osiorakenne.

Osion otsikot

Välittömästi PE-otsikon jälkeen tiedostossa on joukko osiootsikoita. Sen koko määritetään tiedoston otsikon NumberOfSections-kentässä. Jokainen osion otsikko koostuu 0x28 tavusta ja sillä on seuraava rakenne (katso taulukko 2.7):

Taulukko 2.7 - Osion otsikkorakenne

Osion nimi

Osion nimi sisältää 0–8 ASCII-merkkiä. Vakion 8 sijasta voit käyttää määritelmää IMAGE_SIZEOF_SHORT_NAME. Jos nimi on alle 8 merkkiä pitkä, se täytetään nollalla tavulla. Jos se koostuu täsmälleen kahdeksasta merkistä, siinä ei ole päättävää nollatavua. On tärkeää huomata, että osion nimi ei yleisesti ottaen korreloi millään tavalla sen sisällön kanssa. Jokaisella kääntäjällä on oma osion nimeämiskäytäntönsä, joten et voi luottaa osion nimeen sitä jäsennettäessä. Ainoa luotettava tapa määrittää, mitä tietty osio sisältää, on tutkia sen attribuutteja ja sen sisältämiä tietoluetteloita.

Osion attribuutit

32-bittinen Ominaisuudet-kenttä sisältää joukon lippuja, jotka kuvaavat tämän osan sisältöä. Suoritettavan tiedoston osilla voi olla seuraavat attribuutit (katso Taulukko 2.8):

Taulukko 2.8 - Osion attribuutit

Itse osiot sijaitsevat tiedostossa kaikkien osioiden otsikoiden jälkeen. Jokainen osa on tasattu valinnaisen otsikon FileAlignment-rajaan.

Osioiden sisältöä analysoitaessa tulee ottaa huomioon, että tämä sisältö voi olla heterogeenista. Esimerkiksi yksi osa voi sisältää sekä suoritettavan koodin että tuontitaulukon.

Typedef struct _IMAGE_FILE_HEADER ( WORD Machine; WORD Osioiden lukumäärä; DWORD Aikapäiväleima; DWORD PointerTo SymbolTable; DWORD NumberOf Symbols; WORD SizeOf OptionalHeader; WORD Ominaisuudet; ) IMAGE_FILE_HEADER,LELEFI
Kuvailen näitä kenttiä vain kuivana, koska... nimet ovat intuitiivisia ja edustavat suoria merkityksiä, eivät VA, RVA, RAW ja muita pelottavia, kiehtovia asioita, joista olemme toistaiseksi kuulleet vain vanhoilta merirosvoilta. Vaikka olemme jo kohdanneet RAW:n - nämä ovat vain siirtymiä suhteessa tiedoston alkuun (niitä kutsutaan myös raakaosoittimiksi tai tiedostosiirtymäksi). Eli jos meillä on RAW-osoite, tämä tarkoittaa, että meidän on siirryttävä tiedoston alusta RAW-paikkoihin ( ptrFile+ RAW). Sitten voit aloittaa arvojen lukemisen. Hämmästyttävä esimerkki tästä tyypistä on e_lfnew- josta keskustelimme edellä Dos-otsikossa.

*Kone: WORD - tämä numero (2 tavua) määrittää prosessorin arkkitehtuurin, jossa Tämä hakemus voidaan esittää.
Osioiden lukumäärä: DWORD - osien määrä tiedostossa. Osat (jäljempänä kutsumme niitä osioiden taulukoksi) seuraavat välittömästi otsikon jälkeen (PE-Header). Dokumentaation mukaan osioiden määrä on rajoitettu 96:een.
TimeDateStamp: WORD - numero, joka tallentaa tiedoston luontipäivämäärän ja -ajan.
PointerToSymbolTable: DWORD on symbolitaulukon siirtymä (RAW), ja SizeOfOptionalHeader on tämän taulukon koko. Tämä taulukko on tarkoitettu virheenkorjaustietojen tallentamiseen, mutta osasto ei huomannut sotilaan menetystä heti palvelussuhteen alkaessa. Useimmiten tämä kenttä tyhjennetään nollilla.
SIzeOfOptionHeader: WORD - valinnaisen otsikon koko (joka seuraa välittömästi nykyistä otsikkoa) Dokumentaatiossa kerrotaan, että objektitiedostolle se on asetettu 0...
*Ominaisuudet: WORD - tiedoston ominaisuudet.

* - kentät, jotka määritetään arvoalueella. Taulukot mahdollisia arvoja esitetty toimiston rakennekuvauksessa. verkkosivuilla, eikä niitä näytetä tässä, koska Niissä ei ole mitään erityisen tärkeää muodon ymmärtämisen kannalta.

Jätetään tämä saari! Meidän on edettävä. Viitepisteenä on maa nimeltä Optional-Header.

"Missä kartta on, Billy? Tarvitsen kartan."
(Aarre saari)

Valinnainen-otsikko (IMAGE_OPTIONAL_HEADER)

Tämän maanosan nimi ei ole kovin hyvä. Tämä otsikko on pakollinen, ja siinä on kaksi muotoa PE32 ja PE32+ (IMAGE_OPTIONAL_HEADER32 ja IMAGE_OPTIONAL_HEADER64). Muoto tallennetaan kenttään Taika: WORD. Otsikko sisältää tiedoston lataamiseen tarvittavat tiedot. Kuten aina :

IMAGE_OPTIONAL_HEADER

typedef struct _IMAGE_OPTIONAL_HEADER ( WORD Magic; BYTE MajorLinkerVersion; BYTE MinorLinkerVersion; DWORD SizeOfCode; DWORD SizeOfInitializedData; DWORD SizeOfUninitializedData; DWORD AddressOfCordDaf; DWORD AddressOfCodeffa; DWORDDaf; Base ; DWORD SectionAlignment; DWORD-kokoOfRvaAndSizes , *PIMAGE_OPTIONAL_HEADER;

AddressOfEntryPoint: DWORD - tulopisteen RVA-osoite. Voi osoittaa mihin tahansa kohtaan osoiteavaruudessa. .exe-tiedostojen aloituspiste vastaa osoitetta, josta ohjelma aloittaa suorittamisen, eikä se voi olla nolla!
BaseOfCode: DWORD - ohjelmakoodin alun RVA (koodiosio).
BaseOfData: DWORD - ohjelmakoodin alun RVA (tietoosat).
ImageBase: DWORD - ensisijainen perusosoite ohjelman lataamiseen. On oltava 64 kt:n kerrannainen. Useimmissa tapauksissa se on 0x00400000.
Osion Tasaus: DWORD - osion tasauskoko (tavuina) latauksen aikana virtuaalinen muisti.
FileAlignment: DWORD - tiedoston sisällä olevan osan tasauskoko (tavuina).
SizeOfImage: DWORD - tiedostokoko (tavuina) muistissa, mukaan lukien kaikki otsikot. On oltava SectionAligmentin kerrannainen.
SizeOfHeaders: DWORD - kaikkien otsikoiden koko (DOS, DOS-Stub, PE, Section) kohdistettuna FileAligmentiin.
NumberOfRvaAndSizes: DWORD - hakemistotaulukon hakemistojen määrä (itse taulukko on alla). Päällä Tämä hetki tämä kenttä on aina yhtä suuri kuin symbolinen vakio IMAGE_NUMBEROF_DIRECTORY_ENTRIES, joka on yhtä suuri kuin 16.
DataDirectory: IMAGE_DATA_DIRECTORY - tietohakemisto. Yksinkertaisesti sanottuna tämä on taulukko (koko 16), jonka jokainen elementti sisältää 2 DWORD-arvon rakenteen.

Katsotaanpa, mikä on IMAGE_DATA_DIRECTORY-rakenne:

Typedef-rakenne _IMAGE_DATA_DIRECTORY (DWORD VirtualAddress; DWORD Size; ) IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;
Mitä meillä on? Meillä on 16 elementin joukko, joista jokainen sisältää osoitteen ja koon (mitä? miten? miksi? kaikki minuutissa). Herää kysymys, mitä nämä ominaisuudet tarkalleen ovat. Tätä varten Microsoftilla on erityiset vakiot vastaavuuteen. Ne näkyvät rakennekuvauksen lopussa. Sillä välin:

// Hakemistomerkinnät #define IMAGE_DIRECTORY_ENTRY_EXPORT 0 // Vie hakemisto #define IMAGE_DIRECTORY_ENTRY_IMPORT 1 // Tuo hakemisto #define IMAGE_DIRECTORY_ENTRY_RESOURCE 2 // Resurssihakemisto #define IMAGE_DIRECTORY_ENTRY_DIRECTORY TORY_ENTRY _SECURITY 4 // Suojaushakemisto #define IMAGE_DIRECTORY_ENTRY_BASERELOC 5 / / Perussiirtotaulukko #define IMAGE_DIRECTORY_ENTRY_DEBUG 6 // Virheenkorjaushakemisto // IMAGE_DIRECTORY_ENTRY_COPYRIGHT 7 // (X86:n käyttö) #define IMAGE_DIRECTORY_ENTRY_ARCHITECTURE 7 // Tiettyjen IMAGE_DIRECTORY_ENTRY_ARCHITECTURE_GARITE______Tiedon______________________________________________________COPYRIGHT 8 // GP:n RVA #define IMAGE_D IRECTORY_ENTRY_TLS 9 // TLS-hakemistonumero define IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG 10 // Lataa konfigurointihakemisto #define IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT 11 // Sidottu tuontihakemisto otsikoissa #define IMAGE_DIRECTORY_ENTRY_IAT 12 // Tuo osoitteen määrittäminen IMAGE_DIRECTORY_1 aseta Lataa tuontikuvaukset #define IMAGE_DIRECTORY_ENTRY_ COM_DESCRIPTOR 14 // COM Runtime Descriptor
Joo! Näemme, että taulukon jokainen elementti on vastuussa siihen liitetystä taulukosta. Mutta voi ja ah, nämä rannat ovat edelleen meille saavuttamattomissa, koska... emme osaa työskennellä VA- ja RVA-osoitteiden kanssa. Ja oppiaksemme meidän on tutkittava, mitkä osat ovat. He kertovat rakenteestaan ​​ja työstään, minkä jälkeen selviää miksi VA:ta, RVA:ta ja linjauksia tarvitaan. Tässä artikkelissa käsittelemme vain vientiä ja tuontia. Muiden kenttien käyttötarkoitus löytyy toimistolta. asiakirjoissa tai kirjoissa. Joten tässä se on. Varsinaiset kentät:

Virtuaaliosoite: DWORD - RVA taulukolle, jota taulukkoelementti vastaa.
Koko: DWORD - taulukon koko tavuina.

Niin! Päästäksemme sellaisille eksoottisille rannoille, kuten tuonti-, vienti-, resurssitaulukot ja muut, meidän on suoritettava seikkailu osien kanssa. No, mökkipoika, katsotaanpa yleistä karttaa, selvitetään missä olemme nyt ja siirrytään eteenpäin:

Ja olemme suoraan osien laajojen avoimien tilojen edessä. Meidän on ehdottomasti selvitettävä, mitä he piilottelevat, ja lopulta keksittävä toisenlainen osoitus. Haluamme todellisia seikkailuja! Haluamme nopeasti mennä sellaisiin tasavalloihin kuin tuonti- ja vientitaulukot. Vanhat merirosvot sanovat, etteivät kaikki päässeet tavoittamaan heitä, mutta ne, jotka onnistuivat, palasivat kultaa ja naisia, joilla oli pyhää tietoa valtamerestä. Lähdimme liikkeelle ja suuntaamme kohti osan otsikkoa.

"Olet syrjäytynyt, Silver! Pois tynnyriltä!"
(Aarre saari)

Osion otsikko (IMAGE_SECTION_HEADER)

Heti sarjan takana DataDirectory osat seuraavat toisiaan. Osiotaulukko edustaa suvereenia valtiota, joka on jaettu Osioiden lukumäärä kaupungit. Jokaisella kaupungilla on omat kulkunsa, omat oikeutensa ja myös koko 0x28 tavua. Osioiden lukumäärä ilmoitetaan kentässä Osioiden lukumäärä, joka on tallennettu Tiedosto-otsikkoon. Joten katsotaanpa rakennetta:

Typedef struct _IMAGE_SECTION_HEADER ( BYTE Nimi; liitto ( DWORD PhysicalAddress; DWORD VirtualSize; ) Misc; DWORD VirtualAddress; DWORD SizeOfRawData; DWORD PointerToRawData; DWORD PointerToRelocations; DWORD PointerToRelocations; DWORD PointerToRelocations; DWORD-osoitinnumero; WORD-numero; ominaisuudet ) IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;
Nimi: BYTE - osion nimi. Tällä hetkellä se on 8 merkkiä pitkä.
VirtualSize: DWORD - osion koko virtuaalimuistissa.
SizeOfRawData: DWORD - osion koko tiedostossa.
Virtuaaliosoite: DWORD - RVA-osion osoite.
SizeOfRawData: DWORD - osion koko tiedostossa. Täytyy olla monikerta FileAlignment.
PointerToRawData: DWORD - RAW-siirtymä osan alkuun. Täytyy olla myös monikerta FileAlignment…
Ominaisuudet: DWORD - pääsyn attribuutit osioon ja säännöt sen lataamiseksi virtuaaliseen. muisti. Esimerkiksi attribuutti osan sisällön määrittelemiseksi (alkutiedot, ei-alkutiedot, koodi). Tai käytä määritteitä - lue, kirjoita, suorita. Tämä ei ole heidän koko valikoimansa. Ominaisuudet asetetaan saman WINNT.h:n vakioilla, jotka alkavat numerolla IMAGE_SCN_. Voit tutustua osioiden ominaisuuksiin tarkemmin. Myös Chris Kasperskyn kirjojen attribuutit on kuvattu hyvin - lähdeluettelo on artikkelin lopussa.

Nimen suhteen kannattaa muistaa seuraava - resurssien osiossa tulee aina olla nimi.rsrc. Muutoin resursseja ei ladata. Mitä tulee muihin osioihin, nimi voi olla mikä tahansa. Yleensä siellä on merkityksellisiä nimiä, esim. .data, .src jne... Mutta tapahtuu myös:

Osat ovat alue, joka puretaan virtuaalimuistiin ja kaikki työ tapahtuu suoraan näiden tietojen kanssa. Virtuaalimuistissa olevaa osoitetta, ilman siirtymiä, kutsutaan virtuaaliosoitteeksi, lyhennettynä VA. Ensisijainen osoite sovelluksen lataamista varten, aseta kenttään ImageBase. Tämä on kuin kohta, josta sovellusalue alkaa virtuaalimuistissa. Ja RVA-siirtymät (suhteellinen virtuaaliosoite) mitataan suhteessa tähän pisteeseen. Eli VA = ImageBase+ RVA; ImageBase tiedämme aina ja koska meillä on käytössämme VA tai RVA, voimme ilmaista toista toisen kautta.

Täällä ollaan ilmeisesti tottuneet. Mutta tämä on virtuaalimuisti! Ja olemme fyysisessä tilassa. Virtuaalimuisti on meille nyt kuin matka muihin galakseihin, joita voimme vain kuvitella. Emme siis pääse tällä hetkellä virtuaalimuistiin, mutta voimme selvittää, mitä siellä on, koska se on otettu tiedostostamme.

Tasaus

Kuvatakseen oikein lataamista virtuaalitilaan. muisti, on välttämätöntä ymmärtää sellainen mekanismi kuin kohdistus. Katsotaanpa ensin kaaviota siitä, kuinka osiot sivutetaan muistiin.

Kuten näet, osaa ei ladata muistiin sen koon mukaan. Tässä käytetään kohdistuksia. Tämä on arvo, jonka on oltava muistissa olevan osan koon kerrannainen. Jos katsomme kaaviota, näemme, että osion koko on 0x28 ja osan koko on 0x50. Tämä johtuu kohdistuksen koosta. 0x28 "ei saavuta" arvoa 0x50 ja sen seurauksena osio puretaan ja jäljellä oleva tila koossa 0x50-0x28 nollataan. Ja jos osan koko oli suurempi koko linjaus, mitä sitten? Esimerkiksi osion koko= 0x78, a osio Tasaus= 0x50, ts. pysyi ennallaan. Tässä tapauksessa osio vie muistissa 0xA0 (0xA0 = 0x28 * 0x04) tavua. Eli arvo, joka on monikertainen osio Tasaus ja peittää kokonaan osion koko. On huomattava, että tiedoston osat on tasattu samalla tavalla, vain koon mukaan FileAlignment. Saatuamme tarvittavan pohjan voimme selvittää, kuinka muuntaa RVA: sta RAW: ksi.

"Tämä ei ole tasango, ilmasto täällä on erilainen."
(V.S. Vysotsky)

Pieni aritmeettinen oppitunti

Ennen kuin suoritus voidaan aloittaa, osa ohjelmasta on lähetettävä prosessorin osoiteavaruuteen. Osoitetila on prosessorin fyysisesti osoittaman RAM-muistin määrä. Osoiteavaruudessa olevaa "palaa", josta ohjelma puretaan, kutsutaan käytännössä(virtuaalikuva). Kuvalle on tunnusomaista peruslatausosoite (Image base) ja koko (Image size). Joten VA (Virtual address) on osoite suhteessa virtuaalimuistin alkuun ja RVA (Relative Virtual Address) on suhteessa paikkaan, josta ohjelma purettiin. Kuinka selvittää sovelluksen latausosoite? Tätä tarkoitusta varten valinnaisessa otsikossa on erillinen kenttä nimeltä ImageBase. Tämä oli pieni alkusoitto muistin virkistämiseksi. Katsotaanpa nyt kaavamaista esitystä eri osoitteista:

Joten kuinka voit silti lukea tietoja tiedostosta polttamatta sitä virtuaalimuistiin? Tätä varten sinun on muunnettava osoitteet muotoiksi RAW-muodossa. Sitten voimme astua tiedoston sisään tarvitsemamme alueelle ja lukea tarvittavat tiedot. Koska RVA on virtuaalimuistin osoite, johon tiedot projisoitiin tiedostosta, voimme tehdä käänteisen prosessin. Tätä varten tarvitsemme avaimen yhdeksän x kuusitoista yksinkertaisen aritmeettisen. Tässä on joitain kaavoja:

VA = ImageBase + RVA; RAW = RVA - osaRVA + raakaOsa; // rawSection - siirtymä osioon tiedoston alusta // osion RVA - osion RVA (tämä kenttä on tallennettu osion sisään)
Kuten näet, RAW:n laskemiseksi meidän on määritettävä osa, johon RVA kuuluu. Voit tehdä tämän käymällä läpi kaikki osiot ja tarkistamalla seuraavat ehdot:

RVA >= §VitualAddress && RVA< ALIGN_UP(sectionVirtualSize, sectionAligment) // sectionAligment - выравнивание для секции. Значение можно узнать в Optional-header. // sectionVitualAddress - RVA секции - хранится непосредственно в секции // ALIGN_UP() - функция, определяющая сколько занимает секция в памяти, учитывая выравнивание
Laittamalla kaikki palapelit yhteen, saamme tämän luettelon:

Typedef uint32_t DWORD; typedef uint16_t WORD; typedef uint8_t BYTE; #define ALIGN_DOWN(x, align) (x & ~(align-1)) #define ALIGN_UP(x, align) ((x & (align-1))?ALIGN_DOWN(x,align)+align:x) // IMAGE_SECTION_HEADER osiot; // init-taulukon osat 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 >= aloita && 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; }
*En sisällyttänyt koodiin tyyppimääritystä tai taulukon alustusta, vaan toimitin vain toimintoja, jotka auttavat osoitteiden laskemisessa. Kuten näette, koodi ei ollut kovin monimutkainen. Vain vähän hämmentävää. Tämä häviää... jos käytät hieman enemmän aikaa .exe-tiedoston parissa disassemblerin kautta.

HURRAA! Selvitimme sen. Nyt voimme mennä resurssien maihin, tuonti- ja vientikirjastoihin ja yleensä minne vain sydämemme haluaa. Opimme juuri työskentelemään uudenlaisen osoitteen kanssa. Lähdetään tien päälle!

"-Ei paha, ei paha! Silti he saivat tämän päivän annoksensa!”
(Aarre saari)

Vie taulukko

Matriisin ensimmäisessä elementissä DataDirectory RVA on tallennettu vientitaulukkoon, jota edustaa rakenne IMAGE_EXPORT_DIRECTORY. Tämä taulukko on yhteinen dynaamisille kirjastotiedostoille (.dll). Taulukon päätarkoitus on liittää viedyt funktiot niiden RVA:han. Kuvaus esitetään toimistossa. Tekniset tiedot:

Typedef struct _IMAGE_EXPORT_DIRECTORY ( DWORD-ominaisuudet; DWORD-aikaleima; WORD-pääversio; WORD-alaversio; DWORD-nimi; DWORD-kanta; DWORD-toimintojen numero; DWORD-nimi;DWORDNimi;DWORDO-osoite;DWORD-osoite; ) IMAGE_EXPORT_DIRECTORY,*PIMAGE_EXPORT_DIRECTORY;
Tämä rakenne sisältää kolme osoitinta kolmeen eri taulukkoon. Tämä on taulukko nimistä (funktioista) ( AddressOfNames), järjestysluvut ( AddressOfNamesOrdinals), osoitteet ( AddressOfFunctions). Nimi-kenttä tallentaa dynaamisen kirjaston nimen RVA:n. Ordinaal on kuin välittäjä nimitaulukon ja osoitetaulukon välillä, ja se on joukko hakemistoja (indeksin koko on 2 tavua). Selvyyden vuoksi harkitse kaaviota:

Katsotaanpa esimerkkiä. Oletetaan, että names-taulukon i. elementti osoittaa funktion nimen. Sitten tämän funktion osoite voidaan saada käyttämällä osoitetaulukon i:ttä elementtiä. Nuo. olen ordinaalinen.

Huomio! Jos otat esimerkiksi järjestystaulukon 2. elementin, se ei tarkoita 2:ta - se on järjestysluku nimi- ja osoitetaulukoille. Indeksi on arvo, joka on tallennettu järjestyslukutaulukon toiseen elementtiin.

Arvojen määrä nimitaulukoissa ( NumberOfNames) ja järjestysluvut ovat yhtä suuret eivätkä aina täsmää osoitetaulukon elementtien lukumäärän kanssa ( NumberOfFunctions).

"He tulivat hakemaan minua. Kiitos huomiostasi. Nyt heidän täytyy tappaa!"
(Aarre saari)

Tuo taulukko

Tuontitaulukko on olennainen osa kaikkia dynaamisia kirjastoja käyttäviä sovelluksia. Tämä taulukko auttaa korreloimaan kutsuja dynaamisiin kirjastotoimintoihin vastaavien osoitteiden kanssa. Tuonti voi tapahtua kolmessa eri tilassa: vakio, sidottu tuonti ja viivästetty tuonti. Koska Tuonnin aihe on melko monitahoinen ja ansaitsee erillisen artikkelin, kuvailen vain vakiomekanismia, ja loput kuvailen vain "luurankona".

Normaali tuonti- V DataDirectory Tuontitaulukko on tallennettu hakemistoon IMAGE_DIRECTORY_ENTRY_IMPORT(=1). Se on joukko elementtejä, joiden tyyppi on IMAGE_IMPORT_DESCRIPTOR. Tuontitaulukko tallentaa (taulukossa) funktioiden/järjestyslukujen nimet ja mihin lataajan tulee kirjoittaa tämän funktion tehokas osoite. Tämä mekanismi ei ole kovin tehokas, koska Suoraan sanottuna kaikki riippuu siitä, että etsitään koko vientitaulukosta jokaista vaadittua toimintoa varten.

Sidottu tuonti- tällä työkaaviolla kenttiin (vakiotuontitaulukon ensimmäisessä elementissä) TimeDateStamp ja ForwardChain syötetään -1 ja tiedot sidonnasta tallennetaan soluun DataDirectory indeksillä IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT(=11). Tämä on siis eräänlainen lippu lataajalle, että sinun on käytettävä sidottua tuontia. Myös "sidotulla tuontiketjulla" on omat rakenteensa. Toimintaalgoritmi on seuraava: sovelluksen virtuaalimuisti tyhjenee tarvittava kirjasto ja kaikki tarvittavat osoitteet "sidotaan" käännösvaiheessa. Yksi haitoista on, että kun käännät dll-tiedostoa uudelleen, sinun on käännettävä itse sovellus uudelleen, koska toimintojen osoitteet muuttuvat.

Viivästynyt tuonti- klo tätä menetelmää oletetaan, että .dll-tiedosto on liitetty suoritettavaan tiedostoon, mutta sitä ei pureta muistiin välittömästi (kuten kahdessa edellisessä menetelmässä), vaan vasta kun sovellus käyttää ensimmäistä kertaa symbolia (tämä poistaa elementtejä dynaamisista kirjastoista kutsutaan). Toisin sanoen ohjelma suoritetaan muistissa ja heti kun prosessi on saavuttanut funktion kutsumisen dynaamisesta kirjastosta, kutsutaan erityinen käsittelijä, joka lataa dll:n ja jakaa sen funktioiden tehokkaat osoitteet. Viivästetyssä tuonnissa lataaja ottaa yhteyttä DataDirectoryyn (nimikenumero 15).

Kun tuontitapoja on käsitelty hieman, siirrytään suoraan tuontitaulukkoon.

"Tämä on merimies! Hänen vaatteensa olivat merihenkisiä. - Niin? Luulitko löytäväsi piispan täältä?"
(Treasure Island - John Silver)

Tuontikuvaus (IMAGE_IMPORT_DESCRIPTOR)

Jotta voimme selvittää tuontitaulukon koordinaatit, meidän on käytettävä taulukkoa DataDirectory. Nimittäin IMAGE_DIRECTORY_ENTRY_IMPORT-elementtiin (=1). Ja lue taulukon RVA-osoite. Tässä on yleinen kaavio polusta, joka on valittava:

Sitten saamme RVA:lta RAW:n yllä annettujen kaavojen mukaisesti ja sitten "askelemme" tiedoston läpi. Nyt olemme aivan IMAGE_IMPORT_DESCRIPTOR-nimisen rakenteiden joukon edessä. Taulukon loppu on merkitty "nolla"-rakenteella.

Typedef struct _IMAGE_IMPORT_DESCRIPTOR ( liitto ( DWORD-ominaisuudet; DWORD OriginalFirstThunk; ) DUMMYUNIONNAME; DWORD TimeDateStamp; DWORD ForwarderChain; DWORD Name; DWORD FirstThunk; ) IMAGE_IMPORT_MCRIPTORIM,*_PICRIPTORIM,*_PICRIPTORIM;
En löytänyt linkkiä msdn:n rakenteen kuvaukseen, mutta näet sen WINNT.h-tiedostossa. Aloitetaan selvittää se.

OriginalFirstThunk: DWORD - RVA tuontinimitaulukosta (INT).
TimeDateStamp: DWORD - päivämäärä ja aika.
ForwarderChain: DWORD - ensimmäisen edelleenlähetetyn merkin indeksi.
Nimi: DWORD - RVA-merkkijono kirjaston nimellä.
FirstThunk: DWORD - tuontiosoitetaulukon (IAT) RVA.

Kaikki täällä on vähän samanlaista kuin vienti. Myös nimitaulukko (INT) ja siinä myös osoiterätti (IAT). Myös kirjaston nimen RVA. Vain INT ja IAT viittaavat IMAGE_THUNK_DATA-rakenteiden joukkoon. Se esitetään kahdessa muodossa - 64- ja 32-järjestelmille ja eroavat vain kenttien koosta. Katsotaanpa esimerkkinä x86:ta:

Typedef struct _IMAGE_THUNK_DATA32 ( liitto ( DWORD ForwarderString; DWORD-funktio; DWORD Ordinaal; DWORD AddressOfData; ) u1; ) IMAGE_THUNK_DATA32,*PIMAGE_THUNK_DATA32;
Siihen on tärkeää vastata lisätoimia riippuu rakenteen merkittävimmästä osasta. Jos se on asetettu, loput bitit edustavat tuotavan merkin numeroa (tuo numerolla). Muussa tapauksessa (merkittävin bitti tyhjennetään) loput bitit määrittävät tuotavan symbolin RVA:n (tuonti nimellä). Jos meillä on tuonti nimellä, osoitin tallentaa osoitteen seuraavaan rakenteeseen:

Typedef-rakenne _IMAGE_IMPORT_BY_NAME ( WORD Vihje; BYTE:n nimi; ) IMAGE_IMPORT_BY_NAME, *PIMAGE_IMPORT_BY_NAME;
Tässä Vihje on funktion numero ja Nimi- Nimi.

Mitä varten tämä kaikki on? Kaikki nämä taulukot, rakenteet... Tarkastellaan selvyyden vuoksi upeaa kaaviota

Luento 3. Tiedoston rakenne

Kirjallisuus

o Nykyaikaiset käyttöjärjestelmät, E. Tanenbaum, 2002, Pietari, Pietari, 1040 sivua, (djvu 10,1 MB) lisää>>

o Verkkokäyttöjärjestelmät N. A. Olifer, V. G. Olifer (zip-arkisto 1,1 Mt)

o Verkkokäyttöjärjestelmät N. A. Olifer, V. G. Olifer, 2001, St. Petersburg, Peter, 544 s., (djvu 6,3 MB)lisää>>

Tiedostot

Tietojen säilytysvaatimukset:

o kyky tallentaa suuria tietomääriä

o tiedot on säilytettävä prosessin päättämisen jälkeen

o useilla prosesseilla on oltava samanaikaisesti pääsy tietoon

2.1.1Tiedostojen nimeäminen

Tiedoston nimen pituus riippuu käyttöjärjestelmästä, se voi olla 8 (MS-DOS) - 255 (Windows, LINUX) merkkiä.

Käyttöjärjestelmät voivat erottaa isot ja pienet kirjaimet. Esimerkiksi WINDOWS ja Windows MS-DOS:lle ovat samat, mutta UNIXissa ne ovat eri tiedostoja.

Monissa käyttöjärjestelmissä tiedostonimi koostuu kahdesta pisteellä erotetusta osasta, esimerkiksi windows.exe. Pisteen jälkeistä osaa kutsutaan tiedostopääte. Järjestelmä käyttää sitä tiedostotyypin erottamiseen.

MS-DOSissa laajennus on 3 merkkiä. Sen avulla järjestelmä erottaa tiedostotyypin ja sen, voidaanko se suorittaa vai ei.

UNIXissa tunniste on rajoitettu 255 merkin tiedostonimen kokoon, ja UNIXilla voi olla useita tunnisteita, mutta laajennuksia käytetään enemmän sovellusohjelmia, ei käyttöjärjestelmä. UNIX ei voi määrittää, onko tiedosto suoritettava vai ei sen laajennuksen perusteella.

2.1.2 Tiedoston rakenne

Kolme päätiedostorakennetta:

1. Tavusekvenssi- Käyttöjärjestelmä ei ole kiinnostunut tiedoston sisällöstä, se näkee vain tavuja. Tällaisen järjestelmän tärkein etu on sen joustavuus käytössä. Käytetään Windowsissa ja UNIXissa.

2. Tietueiden järjestys- kiinteän pituiset tietueet (esimerkiksi reikäkortti) luetaan peräkkäin. Ei käytössä nyt.

3. Sisääntulopuu- jokaisessa tietueessa on avain, tietueita luetaan avaimella. Tällaisen järjestelmän tärkein etu on hakunopeus. Käytetään edelleen keskuskoneissa.

Kolme tiedostorakennetyyppiä.

2.1.3 Tiedostotyypit

Päätiedostotyypit:

o Säännöllinen- sisältää käyttäjätietoja. Käytetään Windowsissa ja UNIXissa.

o Luettelot- järjestelmätiedostot, jotka tarjoavat rakennetukea tiedostojärjestelmä. Käytetään Windowsissa ja UNIXissa.

o Merkki- Input-output -mallinnukseen. Käytetty vain UNIXissa.

o Lohko- levyjen mallintamiseen. Käytetty vain UNIXissa.

Tavallisten tiedostojen päätyypit:

o ASCII-tiedostoja- koostuu tekstistä. Jokainen rivi päättyy rivinvaihtoon (Windows), rivinvaihtoon (UNIX) ja molempiin (MS-DOS). Siksi, jos avaat UNIXissa kirjoitetun tekstitiedoston Windowsissa, kaikki rivit sulautuvat yhdeksi suureksi riviksi, mutta MS-DOSissa ne eivät sulaudu ( tämä on melko yleinen tilanne). ASCII-tiedostojen tärkeimmät edut:
- voidaan näyttää näytöllä ja tulostaa tulostimelle ilman muuntamista
- voidaan muokata lähes kaikilla editoreilla

o Binaaritiedostot- muut tiedostot (ei-ASCII). Yleensä niillä on sisäinen rakenne.

Binääritiedostojen päätyypit:

o Suoritettava- ohjelmat, jotka voidaan käsitellä itse käyttöjärjestelmä, vaikka ne on kirjoitettu tavujonoksi.

o Ei suoritettavissa- muuta.

Esimerkkejä suoritettavista ja ei-suoritettavista tiedostoista

"Maaginen numero"- tiedoston tunnistaminen suoritettavaksi.

2.1.4 Tiedostojen käyttö

Pääasialliset tiedostojen käyttötavat:

o Johdonmukainen- tavut luetaan järjestyksessä. Käytettiin kun oli magneettinauhaa.

2.1.5 Tiedoston attribuutit

Tärkeimmät tiedostoattribuutit:

o Suojaus - kuka voi käyttää tiedostoa ja miten (käyttäjät, ryhmät, luku/kirjoitus). Käytetään Windowsissa ja UNIXissa.

o Salasana - tiedoston salasana

o Luoja - kuka loi tiedoston

o Omistaja - tiedoston nykyinen omistaja

o Vain luku -merkki - 0 - luku/kirjoitus, 1 - vain luku. Käytetään Windowsissa.

o "Piilotettu" lippu - 0 - näkyvissä, 1 - näkymätön hakemistotiedostojen luettelossa (oletus). Käytetään Windowsissa.

o Lippu "järjestelmä" - 0 - normaali, 1 - järjestelmä. Käytetään Windowsissa.

o Merkitse "arkisto" - valmis tai ei arkistointia varten (ei pidä sekoittaa pakkaamiseen). Käytetään Windowsissa.

o Merkitse "pakattu" - tiedosto on pakattu (samanlainen kuin zip-arkistot). Käytetään Windowsissa.

o Merkitse "salattu" - salausalgoritmia käytetään. Jos joku yrittää lukea tiedostoa, jolla ei ole siihen lupaa, hän ei voi lukea sitä. Käytetään Windowsissa.

o ASCII/binäärilippu - 0 - ASCII, 1 - binääri

o Random access -lippu - 0 - vain peräkkäinen, 1 - satunnainen pääsy

o Merkitse "väliaikainen" - 0 - normaali, 1 - poistaaksesi tiedoston prosessin lopussa

o Estomerkki - estää pääsyn tiedostoon. Jos hänellä on kiire editoimiseen.

o Luomisaika - luomispäivämäärä ja -aika. UNIX on käytössä.

o Viimeisin käyttöaika - viimeisen käytön päivämäärä ja aika

o Aika viimeinen mahdollisuus- viimeisen muutoksen päivämäärä ja aika. Käytetään Windowsissa ja UNIXissa.

o Nykyinen koko - tiedostokoko. Käytetään Windowsissa ja UNIXissa.

2.1.6 Toiminnot tiedostojen kanssa

Perus järjestelmäpuhelut tiedostojen käsittelyyn:

o Luo - tiedoston luominen ilman tietoja.

o Poista - poista tiedosto.

o Avaa - avaa tiedosto.

o Sulje - tiedoston sulkeminen.

o Read - lukee tiedostosta nykyisestä tiedoston sijainnista.

o Kirjoita - kirjoita tiedostoon nykyiseen tiedoston sijaintiin.

o Liitä - lisääminen tiedoston loppuun.

o Etsi - asettaa tiedostoosoittimen tiettyyn kohtaan tiedostossa.

o Hanki attribuutit - saa tiedostoattribuutit.

o Aseta attribuutit - aseta tiedostomääritteet.

o Nimeä uudelleen - nimeä tiedosto uudelleen.