Süsteem käivitatavatele failidele allkirjade automaatseks loomiseks. Tarkvarakomponentide struktuur. Mis tüüpi laiendus on käivitatavatel failidel? Kõige tavalisem

2.1 Failid

Teabe säilitamise nõuded:

ladustamisvõimalus suured mahud andmeid

teave tuleb säilitada pärast protsessi lõpetamist

peab olema mitu protsessi samaaegne juurdepääs teabele

2.1.1 Faili nimetamine

Faili nime pikkus sõltub operatsioonisüsteemist, see võib olla 8 (MS-DOS) kuni 255 (Windows, LINUX) tähemärki.

OS suudab eristada suurtähti ja väiketähti. Näiteks WINDOWS ja Windows MS-DOS-i jaoks on samad, kuid UNIX-i jaoks on need erinevad failid.

Paljudes operatsioonisüsteemides koosneb failinimi kahest punktiga eraldatud osast, näiteks windows.exe. Punktijärgset osa nimetatakse faililaiendit. Süsteem kasutab seda failitüübi eristamiseks.

MS-DOS-i puhul on laiend 3 tähemärki. Seda kasutades eristab süsteem faili tüübi ja selle, kas seda saab käivitada või mitte.

UNIXis on laiendi failinime suurus piiratud 255 tähemärgiga ja UNIXil võib olla mitu laiendit, kuid laiendeid kasutatakse rohkem rakendusprogrammid, mitte OS. UNIX ei saa selle laiendi põhjal kindlaks teha, kas fail on käivitatav või mitte.

2.1.2 Faili struktuur

Kolm peamist failistruktuuri:

Baitide jada- OS-i ei huvita faili sisu, see näeb ainult baite. Sellise süsteemi peamine eelis on selle kasutamise paindlikkus. Kasutatakse Windowsis ja UNIXis.

Kirjete jada- fikseeritud pikkusega kirjeid (näiteks perfokaart) loetakse järjestikku. Praegu pole kasutusel.

Sissepääsupuu- igal kirjel on võti, kirjeid loetakse võtme abil. Sellise süsteemi peamine eelis on otsingu kiirus. Kasutatakse endiselt suurarvutitel.

Kolme tüüpi failistruktuurid.

2.1.3 Failitüübid

Peamised failitüübid:

Regulaarne- sisaldab kasutajateavet. Kasutatakse Windowsis ja UNIXis.

Kataloogid - süsteemifailid, pakkudes tuge failisüsteemi struktuurile. Kasutatakse Windowsis ja UNIXis.

Iseloom- sisend-väljund modelleerimiseks. Kasutatud ainult UNIX-is.

Blokeeri- ketaste modelleerimiseks. Kasutatud ainult UNIX-is.

Tavaliste failide peamised tüübid:

ASCII failid- koosneb tekstistringidest. Iga rida lõpeb käru tagastamisega (Windows), reavahetusega (UNIX) ja mõlemaga (MS-DOS). Seega, kui avate tekstifail kirjutatud UNIX-is, Windowsis, siis liidetakse kõik read üheks suureks reaks, kuid MS-DOS-is neid ei liideta ( see on üsna tavaline olukord). ASCII-failide peamised eelised:
- saab kuvada ekraanil ja väljastada printerisse ilma teisendamiseta
- saab redigeerida peaaegu iga toimetajaga

Binaarfailid- muud failid (mitte-ASCII). Reeglina on neil sisemine struktuur.

Peamised binaarfailide tüübid:

Täidetav- programmid, neid saab töödelda operatsioonisüsteem ise, kuigi need on kirjutatud baitide jadana.

Mittekäivitav- muu.

Näited käivitatavatest ja mittekäivitatavatest failidest

"Maagiline number"- faili tuvastamine käivitatavana.

2.1.4 Juurdepääs failidele

Peamised failijuurdepääsu tüübid:

Järjepidev- baite loetakse järjekorras. Kasutatakse siis, kui olid magnetlindid.

2.1.5 Faili atribuudid

Peamised failiatribuudid:

Kaitse – kes ja kuidas pääseb failile juurde (kasutajad, rühmad, lugemine/kirjutamine). Kasutatakse Windowsis ja UNIXis.

Parool – faili parool

Looja – kes faili lõi

Omanik – faili praegune omanik

Kirjutuskaitstud lipp – 0 – lugemiseks/kirjutamiseks, 1 – kirjutuskaitstud. Kasutatakse Windowsis.

"Peidetud" lipp - 0 - nähtav, 1 - nähtamatu kataloogifailide loendis (vaikimisi). Kasutatakse Windowsis.

Lipp "süsteem" - 0 - normaalne, 1 - süsteem. Kasutatakse Windowsis.

"Arhiivi" lipp - arhiveerimiseks valmis või mitte (mitte segi ajada tihendamisega). Kasutatakse Windowsis.

Märkige "tihendatud" - fail on tihendatud (sarnaselt zip-arhiivid). Kasutatakse Windowsis.

"Krüpteeritud" lipp – kasutatakse krüpteerimisalgoritmi. Kui keegi proovib lugeda faili, millel pole selleks luba, ei saa ta seda lugeda. Kasutatakse Windowsis.

ASCII/binaarne lipp - 0 - ASCII, 1 - binaarne

Juhusjuurdepääsu lipp – 0 – ainult järjestikune, 1 – juhuslik juurdepääs

Märkige "ajutine" - 0 - tavaline, 1 - faili kustutamiseks protsessi lõpus

Blokeerimislipp – failile juurdepääsu blokeerimine. Kui ta on toimetamistega hõivatud.

Loomise aeg – loomise kuupäev ja kellaaeg. Kasutusel on UNIX.

Viimase juurdepääsu aeg – viimase juurdepääsu kuupäev ja kellaaeg

Aeg viimane muudatus- viimase muudatuse kuupäev ja kellaaeg. Kasutatakse Windowsis ja UNIXis.

Praegune suurus on faili suurus. Kasutatakse Windowsis ja UNIXis.

2.1.6 Failitoimingud

Põhiline süsteemikõned failidega töötamiseks:

Loo - faili loomine ilma andmeteta.

Kustuta – faili kustutamine.

Ava - faili avamine.

Sule – faili sulgemine.

Loe – failist lugemine, faili praegusest asukohast.

Kirjutamine – faili kirjutamine praegusesse faili asukohta.

Lisa – lisamine faili lõppu.

Otsi – seab failikursori failis kindlasse kohta.

Hangi atribuudid – failiatribuutide hankimine.

Määra atribuudid – määra faili atribuudid.

Nimeta ümber – nimeta fail ümber.

2.1.7 Mälu aadressiruumi vastendatud failid

Mõnikord on mugav kuvada faili mälus (te ei pea failiga töötamiseks kasutama I/O süsteemikutseid) ja töötada mäluga ning seejärel kirjutada muudetud fail kettale.

Kasutades lehe korraldus mälu, ei laadita kogu faili, vaid laaditakse ainult vajalikud leheküljed.

Kasutades segmendi korraldus mälu, laaditakse fail eraldi segmenti.

Näide faili kopeerimisest mälukaardistamise kaudu.

Algoritm:

Faili 1 jaoks luuakse segment

Fail kuvatakse mällu

Faili 2 jaoks luuakse segment

1. segment kopeeritakse segmenti 2

Segment 2 salvestatakse kettale

Selle meetodi puudused:

Väljundfaili pikkust on raske määrata

Kui üks protsess on faili mällu vastendanud ja seda muutnud, kuid faili pole veel salvestatud, avab teine protsess sama faili ja töötab vananenud failiga.

Fail võib olla suur, suurem kui segment või virtuaalne ruum.

2.2 Kataloogid

2.2.1 Ühetasandilised kataloogisüsteemid

Selles süsteemis asuvad kõik failid ühes kataloogis.

Ühe kataloogiga süsteem, mis sisaldab nelja faili, kahte faili A, kuid erinevaid omanikke

Süsteemi eelised:

Lihtsus

Võimalus faili kiiresti leida, pole vaja katalooge läbi ronida

Süsteemi puudused:

Erinevad kasutajad saavad luua samade nimedega faile.

2.2.2 Kahetasandilised kataloogisüsteemid

Igal kasutajal on oma kataloog.

Kahetasandiline kataloogisüsteem

Kui kasutaja logib sisse, suunatakse ta oma kataloogi ja töötab ainult sellega. See muudab süsteemifailide kasutamise problemaatiliseks.

Seda probleemi saab lahendada loomisega süsteemi kataloog, üldise juurdepääsuga.

Kui ühel kasutajal on palju faile, võib ta vajada ka samanimelisi faile.

2.2.3 Hierarhilised kataloogisüsteemid

Iga kasutaja saab luua nii palju katalooge, kui ta vajab.

Hierarhiline kataloogisüsteem

Peaaegu kõik kaasaegsed universaalsed operatsioonisüsteemid on selliselt korraldatud. Spetsiaalne OS ei pruugi seda vajada.

2.2.4 Tee nimi

Kataloogipuu korraldamiseks peate faili määrama mingil viisil.

Kaks peamist meetodit faili määramiseks:

absoluutne tee nimi- näitab teed juurkataloogist, näiteks:
- Windowsi jaoks \usr\ast\postbox
- UNIX-i jaoks /usr/ast/postbox
- MULTICS >usr>ast>postkasti jaoks

suhtelise tee nimi- tee näidatakse praegusest kataloogist (töökataloogist), näiteks:
- Kui praegune kataloog/usr/ siis absoluutne tee/usr/ast/mailbox kirjutatakse ümber kaustaks ast/mailbox
- kui praegune kataloog on /usr/ast/, siis absoluutne tee /usr/ast/postbox kirjutatakse ümber postkasti
- kui praegune kataloog on /var/log/, siis absoluutne tee /usr/ast/mailbox kirjutatakse ümber ../../usr/ast/mailbox

./ - tähendab praegust kataloogi

../ - tähendab ülemkataloogi

2.2.5 Toimingud kataloogidega

Põhilised süsteemikutsed kataloogidega töötamiseks:

Loo – loo kataloog

Kustuta – kataloogi kustutamine

OpenDir – sulge kataloog

CloseDir – kataloogi sulgemine

Nimeta ümber – nimeta kataloog ümber

Typedef struct _IMAGE_FILE_HEADER ( WORD Machine; WordOfSections; DWORD TimeDatestamp; DWORD PointerTo SymbolTable; DWORD NumberOf Symbols; WORD SizeOfOfOptional Header; WORD Characteristics; ) IMAGE_FILE_HEADER, *_PILE_HEADER;
Kirjeldan neid põlde vaid kuivalt, sest... nimed on intuitiivsed ja esindavad otseseid tähendusi, mitte VA, RVA, RAW ja muid hirmutavaid, intrigeerivaid asju, millest seni oleme kuulnud vaid vanadelt piraatidelt. Kuigi oleme juba kohanud RAW-d - need on lihtsalt nihked faili alguse suhtes (neid nimetatakse ka töötlemata osutiteks või failinihkeks). See tähendab, et kui meil on RAW-aadress, tähendab see, et peame liikuma faili algusest RAW-positsioonidesse ( ptrFile+ RAW). Seejärel saate hakata väärtusi lugema. Ilmekas näide seda tüüpi on e_lfnew- mida arutasime ülalpool Dosi pealkirjas.

*Masin: WORD – see arv (2 baiti) määrab protsessori arhitektuuri, millel seda rakendust saab käivitada.
Sektsioonide arv: DWORD – jaotiste arv failis. Jaotised (edaspidi nimetame neid jaotiste tabeliks) järgnevad vahetult pärast päist (PE-Header). Dokumentatsioon ütleb, et sektsioonide arv on piiratud 96-ga.
TimeDateStamp: WORD – number, mis salvestab faili loomise kuupäeva ja kellaaja.
PointerTo SymbolTable: DWORD on sümbolitabeli nihe (RAW) ja SizeOfOptionalHeader on selle tabeli suurus. See tabel mõeldud ladustamiseks silumisinfo, kuid üksus ei märganud võitleja kaotust juba teenistuse algusest peale. Enamasti tühjendatakse see väli nullidega.
SIzeOfOftionHeader: WORD - valikulise päise suurus (mis järgneb kohe praegusele) Dokumentatsioonis on kirjas, et objektifaili puhul on selleks määratud 0...
*Omadused: WORD - faili omadused.

* - väljad, mis on määratletud väärtusvahemikuga. Võimalike väärtuste tabelid on toodud kontori struktuurikirjelduses. veebisaiti ja seda siin ei loetleta, sest Need ei sisalda midagi eriti olulist vormi mõistmiseks.

Lahkume sellelt saarelt! Peame edasi liikuma. Võrdluspunktiks on riik nimega Optional-Header.

„Kus kaart on, Billy? Mul on kaarti vaja."
(Aarete saar)

Valikuline päis (IMAGE_OPTIONAL_HEADER)

Selle kontinendi pealkiri pole kuigi hea. See päis on nõutav ja sellel on kaks vormingut PE32 ja PE32+ (vastavalt IMAGE_OPTIONAL_HEADER32 ja IMAGE_OPTIONAL_HEADER64). Vorming salvestatakse väljale Maagia: SÕNA. Päis sisaldab faili allalaadimiseks vajalikku teavet. Nagu alati :

IMAGE_OPTIONAL_HEADER

typedef struct _IMAGE_OPTIONAL_HEADER ( WORD Magic; BYTE MajorLinkerVersion; BYTE MinorLinkerVersion; DWORD SizeOfCode; DWORD SizeOfInitializedData; DWORD SizeOfUninitializedData; DWORD AddressOfWORDDaf; DWORDDafO Base; Base ; DWORD SectionAlignment; DWORD SizeOfRvaAndSizes , *PIMAGE_OPTIONAL_HEADER;

*Nagu alati, uurime ainult peamisi välju, millel on kõige suurem mõju allalaadimise mõistmisele ja failiga edasi liikumisele. Lepime kokku - selle struktuuri väljad sisaldavad väärtusi VA (virtuaalne aadress) ja RVA (suhteline virtuaalne aadress) aadressidega. Need ei ole RAW-aadressid ja neid peab oskama lugeda (või õigemini lugeda). Kindlasti õpime seda tegema, kuid kõigepealt analüüsime üksteisele järgnevaid struktuure, et mitte segadusse sattuda. Praegu pidage meeles – need on aadressid, mis pärast arvutusi osutavad failis kindlale asukohale. Samuti kohtate uut kontseptsiooni – joondus. Vaatleme seda koos RVA aadressidega, sest need on üsna tihedalt seotud.

AddressOfEntryPoint: DWORD – sisenemispunkti RVA aadress. Võib osutada mis tahes punktile aadressiruumis. exe-failide puhul vastab sisestuspunkt aadressile, kust programm täitmist alustab, ja see ei saa olla võrdne nulliga!
BaseOfCode: DWORD - programmi koodi alguse RVA (koodiosa).
BaseOfData: DWORD - programmi koodi alguse RVA (andmeosad).
ImageBase: DWORD – programmi laadimise eelistatud baasaadress. Peab olema 64 kb kordne. Enamikul juhtudel on see võrdne 0x00400000.
Sektsioonide joondamine: DWORD – sektsiooni joondussuurus (baitides) virtuaalmällu mahalaadimisel.
Failide joondamine: DWORD – faili sees oleva sektsiooni joondussuurus (baitides).
SizeOfimage: DWORD – faili suurus (baitides) mälus, sealhulgas kõik päised. Peab olema jaotise SectionAligment kordne.
SizeOfHeaders: DWORD – kõigi päiste (DOS, DOS-Stub, PE, Section) suurus, mis on joondatud FileAligmentiga.
NumberOfRvaAndSizes: DWORD - kataloogide arv kataloogitabelis (tabel ise on allpool). Hetkel on see väli alati võrdne sümboolse konstandiga IMAGE_NUMBEROF_DIRECTORY_ENTRIES, mis on võrdne 16-ga.
DataDirectory: IMAGE_DATA_DIRECTORY – andmekataloog. Lihtsamalt öeldes on see massiiv (suurusega 16), mille iga element sisaldab 2 DWORD-väärtuse struktuuri.

Vaatame, milline on IMAGE_DATA_DIRECTORY struktuur:

Typedef struct _IMAGE_DATA_DIRECTORY ( DWORD VirtualAddress; DWORD Size; ) IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;
Mis meil on? Meil on 16 elemendist koosnev massiiv, mille iga element sisaldab aadressi ja suurust (mida? kuidas? miks? kõik minutiga). Tekib küsimus, mis need omadused täpsemalt on. Microsoftil on selleks sobitamiseks spetsiaalsed konstandid. Neid saab näha struktuurikirjelduse lõpus. Samal ajal:

// Kataloogikirjed #define IMAGE_DIRECTORY_ENTRY_EXPORT 0 // Kataloogi eksportimine #define IMAGE_DIRECTORY_ENTRY_IMPORT 1 // Kataloogi importimine #define IMAGE_DIRECTORY_ENTRY_RESOURCE 2 // Ressursikataloog #define IMAGE_DIRECTORY_ENTRY_DIRECTORY TORY_ENTRY _SECURITY 4 // Turvakataloog #define IMAGE_DIRECTORY_ENTRY_BASERELOC 5 / / Baasümberpaigutamise tabel #define IMAGE_DIRECTORY_ENTRY_DEBUG 6 // Kataloog silumise 8 // GP RVA #define IMAGE_D IRECTORY_ENTRY_TLS 9 // TLS-i kataloog # define IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG 10 // Laadi konfiguratsioonikataloog #define IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT 11 // Seotud impordikataloog päistes #define IMAGE_DIRECTORY_ENTRY_IAT 12 // Import Aadress TIMY_1 laadi importimise deskriptorid #define IMAGE_DIRECTORY_ENTRY_ COM_DESCRIPTOR 14 // COM Runtime deskriptor
Jah! Näeme, et massiivi iga element vastutab sellele lisatud tabeli eest. Aga paraku ja ah, need kaldad on meile ikkagi kättesaamatud, sest... me ei tea, kuidas VA ja RVA aadressidega töötada. Ja selleks, et õppida, peame uurima, millised on lõigud. Nad räägivad teile oma struktuurist ja tööst, pärast mida saab selgeks, miks on vaja VA, RVA ja joondusi. Käesolevas artiklis käsitleme ainult eksporti ja importi. Ülejäänud väljade otstarbega saab tutvuda kontoris. dokumentides või raamatutes. Nii et siin see on. Tegelikud väljad:

Virtuaalne aadress: DWORD – RVA tabeli jaoks, millele massiivi element vastab.
Suurus: DWORD – tabeli suurus baitides.

Nii et! Et jõuda sellistele eksootilistele randadele nagu impordi, ekspordi, ressursside ja muu tabelid, peame läbima sektsioonide otsingu. Noh, kajutipoiss, vaatame üldist kaarti, teeme kindlaks, kus me praegu oleme, ja liigume edasi:

Ja me asume otse sektsioonide laiade avatud ruumide ees. Peame kindlasti välja selgitama, mida nad varjavad, ja lõpuks välja mõtlema teist tüüpi adresseerimise. Soovime tõelisi seiklusi! Tahame kiiresti minna sellistesse vabariikidesse nagu impordi- ja eksporditabelid. Vanad piraadid räägivad, et kõigil ei õnnestunud nendeni jõuda, kuid need, kes jõudsid, naasid kulla ja naistega pühade teadmistega ookeani kohta. Asume teele ja suundume Sektsiooni päise poole.

„Sa oled vallandatud, Silver! Tulge tünnilt maha!"
(Aarete saar)

Jaotise päis (IMAGE_SECTION_HEADER)

Otse massiivi taga DataDirectory sektsioonid järgnevad üksteisele. Sektsioonitabel tähistab suveräänset riiki, mis on jagatud Sektsioonide arv linnad. Igal linnal on oma käsitöö, oma õigused ja ka suurus 0x28 baiti. Sektsioonide arv on märgitud väljale Sektsioonide arv, mis on salvestatud faili päisesse. Niisiis, vaatame struktuuri:

Typedef struct _IMAGE_SECTION_HEADER ( BYTE nimi; liit ( DWORD PhysicalAddress; DWORD VirtualSize; ) Misc; DWORD VirtualAddress; DWORD SizeOfRawData; DWORD PointerToRawData; DWORD PointerToRelocations; DWORD PointerToRelocations; DWORD PointerToRelocations; DWORD PointerToLine Number; toimingud ) IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;
Nimi: BAIT – sektsiooni nimi. Praegu on see 8 tähemärki pikk.
Virtuaalne suurus: DWORD – sektsiooni suurus virtuaalmälus.
SizeOfRawData: DWORD – jaotise suurus failis.
Virtuaalne aadress: DWORD – RVA sektsiooni aadress.
SizeOfRawData: DWORD – jaotise suurus failis. Peab olema kordne Failide joondamine.
PointerToRawData: DWORD – RAW nihe jaotise algusesse. Peab olema ka mitmekordne Failide joondamine…
Omadused: DWORD - juurdepääsu atribuudid jaotisele ja reeglid selle virtuaalsesse laadimiseks. mälu. Näiteks atribuut jaotise sisu määratlemiseks (algandmed, mittealgandmed, kood). Või pääsete juurde atribuutidele – lugege, kirjutage, käivitage. See ei ole kogu nende valik. Karakteristikud määravad sama WINNT.h konstandid, mis algavad tähega IMAGE_SCN_. Sektsioonide atribuutidega saab lähemalt tutvuda. Ka Chris Kaspersky raamatute atribuudid on hästi kirjeldatud – viidete loetelu on artikli lõpus.

Nimega seoses tuleks meeles pidada järgmist – ressurssidega sektsioonis peaks alati olema nimi.rsrc. Vastasel juhul ressursse ei laadita. Ülejäänud jaotiste nimi võib olla ükskõik milline. Tavaliselt on seal tähendusrikkad nimed, näiteks .data, .src jne... Aga juhtub ka:

Sektsioonid on ala, mis laaditakse virtuaalmällu ja kogu töö toimub otse nende andmetega. Virtuaalses mälus olevat aadressi ilma nihketeta nimetatakse virtuaalseks aadressiks, lühendatult VA. Eelistatud aadress rakenduse allalaadimiseks, määratud väljale ImageBase. See on nagu punkt, kust rakendusala virtuaalmälus algab. Ja RVA (suhtelise virtuaalse aadressi) nihkeid mõõdetakse selle punkti suhtes. See tähendab, VA = ImageBase+ RVA; ImageBase me teame alati ja kui meie käsutuses on VA või RVA, saame väljendada üht läbi teise.

Tundub, et nad on siin harjunud. Aga see on virtuaalmälu! Ja me oleme füüsilises. Virtuaalne mälu on meie jaoks praegu nagu reis teistesse galaktikatesse, mida suudame vaid ette kujutada. Nii et me ei pääse praegu virtuaalmällu, kuid saame teada, mis seal on, sest see on võetud meie failist.

Joondamine

Virtuaalsesse üleslaadimise õigeks esitamiseks. mälu, on vaja mõista sellist mehhanismi nagu joondamine. Kõigepealt vaatame diagrammi, kuidas jaotised mällu lapitakse.

Nagu näete, ei laadita jaotist mällu selle suuruse järgi. Siin kasutatakse joondusi. See on väärtus, mis peab olema mälus oleva jaotise suuruse kordne. Kui vaatame diagrammi, näeme, et jaotise suurus on 0x28 ja jaotise suurus on 0x50. See on tingitud joonduse suurusest. 0x28 "ei ulatu" 0x50-ni ja selle tulemusena laaditakse sektsioon maha ja ülejäänud ruum suuruses 0x50-0x28 nullitakse. Ja kui sektsiooni suurus oli suurem suurus joondus, mis siis? Näiteks jaotise suurus= 0x78, a jaotis Joondamine= 0x50, st. jäi muutumatuks. Sel juhul hõivaks sektsioon mälus 0xA0 (0xA0 = 0x28 * 0x04) baiti. See tähendab, et väärtus, mis on kordne jaotis Joondamine ja katab täielikult jaotise suurus. Tuleb märkida, et faili jaotised on joondatud sarnaselt, ainult suuruse järgi Failide joondamine. Olles saanud vajaliku baasi, saame välja mõelda, kuidas RVA-st RAW-i teisendada.

"See pole tasandik, siinne kliima on erinev."
(V.S. Võssotski)

Väike aritmeetikatund

Enne täitmise alustamist tuleb osa programmist saata protsessori aadressiruumi. Aadressiruum on töötleja poolt füüsiliselt adresseeritud andmete hulk. muutmälu. Kutsutakse välja "tükk" aadressiruumis, kuhu programm maha laaditakse virtuaalselt(virtuaalne pilt). Pilti iseloomustavad põhi allalaadimisaadress (Image base) ja suurus (Image size). Seega on VA (virtuaalne aadress) aadress virtuaalmälu alguse suhtes ja RVA (Relative Virtual Address) on suhteline selle kohaga, kus programm maha laaditi. Kuidas teada saada rakenduse allalaadimise baasaadressi? Selleks on valikulises päises eraldi väli nimega ImageBase. See oli väike eelmäng teie mälu värskendamiseks. Vaatame nüüd erinevate adressaatide skemaatilist esitust:

Niisiis, kuidas saate ikkagi failist teavet lugeda ilma seda virtuaalmällu salvestamata? Selleks peate aadressid teisendama RAW-vormingusse. Seejärel saame astuda faili sisse vajalikku ala ja lugeda vajalikud andmed. Kuna RVA on virtuaalse mälu aadress, kuhu andmed failist projitseeriti, saame teha vastupidise protsessi. Selleks vajame lihtsat aritmeetikat üheksa korda kuusteist. Siin on mõned valemid:

VA = ImageBase + RVA; RAW = RVA - sektsioonRVA + rawSection; // rawSection - nihe jaotisele faili algusest // sektsioonRVA - jaotise RVA (see väli salvestatakse jaotise sees)
Nagu näete, peame RAW arvutamiseks määrama jaotise, kuhu RVA kuulub. Selleks peate läbima kõik jaotised ja kontrollima järgmisi tingimusi:

RVA >= jaotisVituaalneAadress && RVA< ALIGN_UP(sectionVirtualSize, sectionAligment) // sectionAligment - выравнивание для секции. Значение можно узнать в Optional-header. // sectionVitualAddress - RVA секции - хранится непосредственно в секции // ALIGN_UP() - функция, определяющая сколько занимает секция в памяти, учитывая выравнивание
Kui kõik mõistatused kokku panna, saame järgmise loendi:

Typedef uint32_t DWORD; typedef uint16_t WORD; typedef uint8_t BYTE; #define ALIGN_DOWN(x, joondus) (x & ~(joonda-1)) #define ALIGN_UP(x, joondus) ((x & (joonda-1))?ALIGN_DOWN(x,joonda)+joonda:x) // IMAGE_SECTION_HEADER jaotised; // init massiivi lõigud 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; }
*Ma ei lisanud koodi tüübideklaratsiooni ega massiivi lähtestamist, vaid andsin ainult funktsioonid, mis aitavad aadresse arvutada. Nagu näete, polnud kood väga keeruline. Lihtsalt veidi segane. See kaob... kui veedate natuke rohkem aega .exe-faili kallal disassembleri kaudu nokitsemisele.

HURRA! Me mõtlesime selle välja. Nüüd saame minna ressursside maale, impordi- ja ekspordiraamatukogudesse ja üldiselt kuhu iganes süda ihkab. Õppisime just, kuidas töötada uut tüüpi adresseerimisega. Asume teele!

"- Pole paha, pole paha! Ometi said nad tänaseks oma toiduportsjoni kätte!”
(Aarete saar)

Ekspordi tabel

Massiivi kõige esimeses elemendis DataDirectory RVA salvestatakse eksporditabelis, mida esindab struktuur IMAGE_EXPORT_DIRECTORY. See tabel on ühine dünaamilise teegi (.dll) failidele. Tabeli peamine eesmärk on seostada eksporditud funktsioonid nende RVA-ga. Kirjeldus esitatakse kontoris. Tehnilised andmed:

Typedef struct _IMAGE_EXPORT_DIRECTORY ( DWORD karakteristikud; DWORD-i ajatempel; WORD-peaversioon; WORD-alaversioon; DWORD-i nimi; DWORD-i alus; DWORD-i funktsioonide arv; DWORD-i nimede nimi; ) IMAGE_EXPORT_DIRECTORY,*PIMAGE_EXPORT_DIRECTORY;
See struktuur sisaldab kolme viidet kolmele erinevale tabelile. See on nimede (funktsioonide) tabel ( AddressOfNames), järgarvud ( AddressOfNamesOrdinals), aadressid ( Funktsioonide aadress). Väljale Nimi salvestatakse nime RVA dünaamiline raamatukogu. Ordinaal on nagu vahelüli nimetabeli ja aadressitabeli vahel ning on indeksite massiiv (indeksi suurus on 2 baiti). Suurema selguse huvides vaadake diagrammi:

Vaatame näidet. Oletame, et nimede massiivi i-s element näitab funktsiooni nime. Seejärel saab selle funktsiooni aadressi saada aadressi massiivi i-nda elemendi poole pöördudes. Need. ma olen ordinaal.

Tähelepanu! Kui võtate näiteks järgarvude tabeli 2. elemendi, ei tähenda see 2-t – see on nimede ja aadresside tabelite järg. Indeks on järgarvude massiivi teise elemendi salvestatud väärtus.

Väärtuste arv nimetabelites ( Nimede arv) ja järgarvud on võrdsed ega kattu alati aadressitabelis olevate elementide arvuga ( Funktsioonide arv).

"Nad tulid mulle järele. Tänan tähelepanu eest. Nüüd nad vist tapavad!"
(Aarete saar)

Impordi tabel

Imporditabel on kõigi dünaamilisi teeke kasutavate rakenduste lahutamatu osa. See tabel aitab korreleerida dünaamiliste teegi funktsioonide kõnesid vastavate aadressidega. Import võib toimuda kolmes erinevad režiimid: standardne, seotud import ja viivitusega import. Sest Imporditeema on üsna mitmetahuline ja väärib eraldi artiklit, kirjeldan ainult standardmehhanismi ja ülejäänut kirjeldan ainult kui "skeletti".

Standardne import- V DataDirectory Imporditabel on salvestatud indeksi IMAGE_DIRECTORY_ENTRY_IMPORT(=1) alla. See on IMAGE_IMPORT_DESCRIPTOR tüüpi elementide massiiv. Imporditabel salvestab (massiivina) funktsioonide/järgarvude nimed ja kuhu laadija peaks kirjutama selle funktsiooni efektiivse aadressi. See mehhanism ei ole väga tõhus, sest Ausalt öeldes taandub see kõik iga vajaliku funktsiooni otsimisele kogu eksporditabelist.

Seotud import- selle põldudel töötamise skeemiga (esimeses elemendis standardne tabel import) TimeDateStamp ja ForwardChain on seatud väärtusele -1 ja sidumisteave salvestatakse lahtrisse DataDirectory indeksiga IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT(=11). See tähendab, et see on laadija jaoks omamoodi lipp, mida peate seotud importimiseks kasutama. Samuti on "seotud impordiahelal" oma struktuurid. Tööalgoritm on järgmine - rakenduse virtuaalmälu laaditakse maha vajalik raamatukogu ja kõik vajalikud aadressid on koostamise etapis "köidetud". Üks puudusi on see, et dll-i uuesti kompileerimisel peate rakenduse ise uuesti kompileerima, kuna funktsiooni aadressid muudetakse.

Impordi viivitus- kell seda meetodit Eeldatakse, et .dll-fail on lisatud käivitatavale failile, kuid seda ei laadita kohe mällu (nagu kahes eelmises meetodis), vaid alles siis, kui rakendus pääseb esimest korda juurde sümbolile (see laadib dünaamiliste teekide elemente maha kutsutakse). See tähendab, et programm käivitatakse mälus ja niipea, kui protsess on jõudnud funktsiooni kutsumiseni dünaamilisest teegist, kutsutakse välja spetsiaalne töötleja, mis laadib dll-i ja jagab selle funktsioonide tõhusad aadressid. Edasilükatud impordi puhul võtab laadija ühendust DataDirectoryga (üksus number 15).

Olles impordimeetodeid veidi käsitlenud, liigume otse imporditabeli juurde.

„See on meremees! Tema riided olid merelised. - Jah? Kas sa arvasid, et leiad siit piiskopi?”
(Aarete saar – John Silver)

Impordi deskriptor (IMAGE_IMPORT_DESCRIPTOR)

Imporditabeli koordinaatide väljaselgitamiseks peame ligipääsu massiivile DataDirectory. Nimelt elemendile IMAGE_DIRECTORY_ENTRY_IMPORT (=1). Ja lugege tabeli RVA aadressi. Siin üldine skeem tee, mida peate valima:

Seejärel saame RVA-st vastavalt ülaltoodud valemitele RAW ja seejärel “sammume” failist läbi. Nüüd oleme otse struktuuride massiivi ees, mida nimetatakse IMAGE_IMPORT_DESCRIPTOR. Massiivi lõppu tähistab struktuur "null".

Typedef struct _IMAGE_IMPORT_DESCRIPTOR ( liit ( DWORD omadused; DWORD OriginalFirstThunk; ) DUMMYUNIONNAME; DWORD TimeDateStamp; DWORD ForwarderChain; DWORD Name; DWORD FirstThunk; ) IMAGE_IMPORT_MCRIPTORIM,*_PICRIPTORIM,*_PICRIPTORIM;
Ma ei leidnud linki msdn-i struktuuri kirjeldusele, kuid näete seda failis WINNT.h. Hakkame seda välja mõtlema.

OriginalFirstThunk: DWORD – impordi nimetabeli (INT) RVA.
TimeDateStamp: DWORD – kuupäev ja kellaaeg.
ForwarderCain: DWORD – esimese edastatud märgi indeks.
Nimi: DWORD – RVA string teegi nimega.
FirstThunk: DWORD – impordi aadressitabeli (IAT) RVA.

Kõik siin sarnaneb mõneti ekspordiga. Samuti nimede tabel (INT) ja sellel ka aadresside lapp (IAT). Samuti raamatukogu nime RVA. Ainult INT ja IAT viitavad IMAGE_THUNK_DATA struktuuride massiivile. See on esitatud kahel kujul - 64 ja 32 süsteemi jaoks ning erinevad ainult väljade suuruse poolest. Vaatame näitena x86:

Typedef struct _IMAGE_THUNK_DATA32 ( liit ( DWORD ForwarderString; DWORD Function; DWORD Ordinaal; DWORD AddressOfData; ) u1; ) IMAGE_THUNK_DATA32,*PIMAGE_THUNK_DATA32;
Oluline on sellele vastata edasisi tegevusi sõltuvad struktuuri kõige olulisemast osast. Kui see on määratud, esindavad ülejäänud bitid imporditava märgi numbrit (import numbri järgi). Vastasel juhul (kõige olulisem bitt kustutatakse) määravad ülejäänud bitid imporditava sümboli RVA (import nime järgi). Kui meil on nimeline import, salvestab kursor aadressi järgmisesse struktuuri:

Typedef struct _IMAGE_IMPORT_BY_NAME ( WORD vihje; BYTE nimi; ) IMAGE_IMPORT_BY_NAME, *PIMAGE_IMPORT_BY_NAME;
Siin Vihje on funktsiooni number ja Nimi- Nimi.

Mille jaoks see kõik on? Kõik need massiivid, struktuurid... Selguse huvides vaatleme imelist diagrammi

mälu operatsioonisüsteemi laadija poolt ja seejärel käivitatakse. Operatsiooniruumis Windowsi süsteem Käivitatavatel failidel on tavaliselt laiendid ".exe" ja ".dll". Laiendus ".exe" sisaldab programme, mida kasutaja saab otse käivitada. Laiendil ".dll" on niinimetatud dünaamiliselt lingitud teegid ( dünaamiline link raamatukogud). Need teegid ekspordivad teiste programmide kasutatavaid funktsioone.

Operatsioonisüsteemi alglaaduri korrektseks laadimiseks käivitatav fail mällu, peab selle faili sisu vastama selles operatsioonisüsteemis aktsepteeritud vormingule käivitatavad failid. Erinevatel operatsioonisüsteemidel eri aegadel eksisteeris ja eksisteerib endiselt palju erinevaid vorminguid. Selles peatükis vaatleme kaasaskantava käivitatava (PE) vormingut. PE-vorming on Windowsi operatsioonisüsteemis käivitatavate failide salvestamise esmane vorming. Assambleed. NET-faile salvestatakse ka selles vormingus.

Lisaks saab esitamiseks kasutada PE-vormingut objektifailid. Objektifaile kasutatakse programmi eraldi kompileerimise korraldamiseks. Eraldi kompileerimise mõte seisneb selles, et programmi osad (moodulid) kompileeritakse iseseisvalt objektifailideks, mis seejärel linkeri poolt üheks lingitakse. käivitatav fail.

Ja nüüd – väike ajalugu. PE-vormingu lõid Windows NT arendajad. Varem kasutas Windowsi operatsioonisüsteem käivitatavate failide esitamiseks ja salvestamiseks vorminguid New Executable (NE) ja Linear Executable (LE). objektifailid Kasutati Object Module Format (OMF) vormingut. NE-vorming oli mõeldud 16-bitise jaoks Windowsi rakendused, ja algselt OS/2 jaoks välja töötatud LE-vorming oli juba 32-bitine. Tekib küsimus: miks? Windowsi arendajad NT otsustas loobuda olemasolevad vormingud? Vastus saab selgeks, kui pöörata tähelepanu asjaolule, et enamik meeskonda, kes töötasid Windowsi loomine NT, varem töötas Digital Equipment Corporationis. Nad töötasid DEC-s välja tööriistu VAX/VMS operatsioonisüsteemi jaoks ning neil olid juba oskused ja valmis kood vormingus esitatud käivitatavate failidega töötamiseks. Ühine objekt Failivorming (COFF). Sellest lähtuvalt viidi COFF-vorming veidi muudetud kujul üle Windows NT-sse ja sai nimeks PE.

".NET Frameworki sõnastik" ütleb, et PE on rakendus Microsofti vorming COFF. Samas öeldakse, et PE on käivitatav failivorming ja COFF on formaat objektifailid. Üldiselt võime täheldada segadust Microsofti dokumentatsioon vormingu nimetuse kohta. Mõnes kohas kutsuvad nad seda COFF-iks ja mõnes kohas PE. Tõsi, võib märgata, et uutes tekstides kasutatakse nime COFF üha vähem. Lisaks areneb PE-vorming pidevalt. Näiteks lõpetas Microsoft mitu aastat tagasi silumisteabe salvestamise käivitatavas failis ja seetõttu ei kasutata nüüd paljusid COFF-vormingus struktuurides olevaid välju. Lisaks on COFF-vorming 32-bitine ja viimane väljaanne PE-vormingut (nimetatakse PE32+) saab kasutada 64-bitistel riistvaraplatvormidel. Seetõttu ilmselt liiguvad asjad sinnapoole, et COFF nime enam üldse ei kasutata.

Huvitav on märkida, et Windows toetab endiselt pärandvormingus NE ja LE käivitatavaid faile. NE-vormingus käivitatavaid faile saab käivitada NTVDM-is (NT Virtual DOS Machine) ja LE-vormingut kasutatakse virtuaalsete seadmedraiverite jaoks (

Käivitatavad failivormingud

Protsessi virtuaalmälu koosneb mitmest segmendid või piirkondades mälu. Segmentide suuruse, sisu ja asukoha mälus määrab nii programm ise, näiteks teekide kasutamine, koodi ja andmete suurus kui ka selle programmi käivitatava faili formaat. Enamik kaasaegseid UNIX-i operatsioonisüsteeme kasutavad kahte standardne formaat käivitatavad failid - COFF (Common Object File Format) ja ELF (käivitatav ja linkimisvorming).

Käivitatavate failivormingute kirjeldus võib tunduda üleliigne, kuid operatsioonisüsteemi tuuma põhifunktsioonide kirjeldamiseks on vaja neid mõista. Eelkõige võimaldab COFF- ja ELF-vormingus täitmisfailides salvestatud teave vastata paljudele küsimustele, mis on rakenduse ja süsteemi kui terviku toimimiseks väga olulised:

Millised programmi osad tuleb mällu laadida?

Kuidas luuakse initsialiseerimata andmete ala?

Millised protsessi osad tuleks salvestada vahetusketta alale ( eriline ala kettaruum, mis on mõeldud protsessi aadressiruumi fragmentide ajutiseks salvestamiseks), näiteks lehekülgede asendamisel ja milliseid saab vajadusel failist lugeda ja seega salvestamist ei nõua?

Kus mälus asuvad programmi juhised ja andmed?

Milliseid teeke on programmi käitamiseks vaja?

Kuidas on kettal olev käivitatav fail, mälus olev programmipilt ja kettavahetusala seotud?

Joonisel fig. 2.3 on antud põhistruktuur mälu protsesside jaoks, mis laaditakse käivitatavatest failidest vastavalt COFF- ja ELF-vormingus. Kuigi segmentide paigutus on kahe vormingu vahel erinev, on põhikomponendid samad. Mõlemal protsessil on koodi (teksti), andmete ja virna segmendid. Nagu jooniselt näha, võib andmete ja virnasegmentide suurus muutuda ning selle muutuse suuna määrab täitmisfaili formaat. Operatsioonisüsteem muudab virna suurust automaatselt, samas kui andmesegmendi suurust kontrollib rakendus ise. Me käsitleme neid probleeme üksikasjalikult selle peatüki hilisemas jaotises "Mälu eraldamine".

Riis. 2.3. Käivitatavad programmipildid COFF- ja ELF-vormingus

Andmesegment sisaldab lähtestatud andmeid, mis kopeeritakse mällu täitmisfaili vastavatest osadest, ja initsialiseerimata andmeid, mis täidetakse enne protsessi käivitamist nullidega. Initsialiseerimata andmeid nimetatakse sageli BSS-i segmendiks.

Raamatust Photoshop CS2 ja digifotograafia (Tutorial). Peatükid 1-9 autor Solonitsõn Juri

Raamatust Linux for the User autor Kostromin Viktor Aleksejevitš

11.4.2. Fondi failivormingud Viimasel ajal sõna otseses mõttes iga graafiline redaktor või avaldamisprogramm kasutas oma fondi failivormingut ja reeglina ei toetanud mõned programmid teiste vorminguid. Aja jooksul tegelikult kasutatud vormingute arv

Raamatust Adobe Photoshop CS3 autor Zavgorodniy Vladimir

4. peatükk Vormingud graafilised failid Rastergraafika salvestamiseks on suur hulk erinevaid failivorminguid. Nende hulgas on nii universaalseid vorminguid, mis ei ole seotud ühegi konkreetse programmiga, kui ka konkreetseid "isiklikke" rastervorminguid

Raamatust Adobe InDesign CS3 autor Zavgorodniy Vladimir

Graafilised failivormingud Adobe InDesign suudab importida erinevas vormingus graafilisi faile – nii levinumaid AI, BMP, EPS, GIF, JPEG, PDF, PSD, TIFF kui ka haruldasemaid DCS, EMF, PCX, PICT, PNG, SCT (ScitexCT) ), WMF.All graafilised vormingud ja failid on eraldatud nende teabe tüübi järgi

Dr. Bobi raamatust Internet Solutions autor Swart Bob

1. Interneti-failide kodeerimisvormingud Interneti-failivormingud võib jagada mitmeks rühmaks. Esiteks failiedastusvormingud FTP kaudu, mille jaoks töötati ammu välja uuencode/decode skeem, mis hiljem asendati xxencode/decode-ga. Hiljem keelduti Base64 ja MIME kasuks,

autor Raymond Eric Stephen

3.1.6. Binaarfailivormingud Kui teie operatsioonisüsteem kasutab tundlike andmete (nt kasutajakontode) jaoks binaarvorminguid, on tõenäoline, et inimloetava kasutamise traditsioon tekstivormingud rakenduste jaoks ei looda. Detailides

Raamatust Photoshop CS3: Koolituskursus autor Timofejev Sergei Mihhailovitš

Graafilised failivormingud Mis tahes graafiline pilt Olenemata sellest, kas see on vektor- või raster, saab selle salvestada arvutisse ainult eraldi faili kirjutades. Igal failil on alati konkreetne vorming

Raamatust The Art of Programming for Unix autor Raymond Eric Stephen

3.1.6. Binaarfailivormingud Kui operatsioonisüsteem kasutab tundlike andmete (nt kasutajakontode) jaoks binaarvorminguid, siis tõenäoliselt ei teki rakenduste jaoks loetavate tekstivormingute kasutamise traditsiooni. Lisateavet selle kohta

Raamatust Võrgutööriistad Linux autor Smith Roderick W.

Fondifailivormingud On kahte tüüpi fonte: bitmap- ja kontuurifondid (kontuurifonte nimetatakse sageli skaleeritavateks fontideks). Nendel fonditüüpidel on erinevad omadused ja neid töödeldakse erineval viisil. Enamik fondiservereid on loodud töötama

Raamatust HTML 5, CSS 3 ja Web 2.0. Kaasaegsete veebisaitide arendamine. autor Dronov Vladimir

Raamatust HTML 5, CSS 3 ja Web 2.0. Kaasaegsete veebisaitide arendamine autor Dronov Vladimir

Failivormingud ja kodeerimisvormingud Multimeediumifailivorminguid on sama palju kui graafilisi failivorminguid. Nagu Interneti-graafika puhul, ei toeta kõik veebibrauserid multimeediumvormingud, kuid ainult mõned. (Ma tahaksin autorit

Raamatust Arvuti helitöötlus autor Zagumennov Aleksander Petrovitš

Ad Lib Sample SMP helifailivormingud Seda vormingut kasutab Ad Lib Gold helikaart instrumendi näidiste laadimiseks. Toetab 8/16-bitist heli, mono/stereo, 4-bitine Yamaha ADPCM tihendus. Selles vormingus failid on laiendiga . smp.Amiga SVXSeda failitüüpi kasutatakse

Raamatust Viiruse ja viirusetõrje loomine autor Guliev Igor A.

Lisa A EXE-faili päise vormingud Tavalise EXE-faili päise vorming EXE-faili alguses on EXE-faili päise vormindatud osa (tabel A-1) Järgmisena tuleb ümberpaigutamistabel, mis koosneb pikkadest osutitest (nihe: segment). ) nende kohta

Photoshop CS4 raamatust autor Žvalevski Andrei Valentinovitš

Graafika failivormingud Vorming on viis pildi failina salvestamiseks. Graafikafailivorminguid on üsna palju, kuid enamasti kasutatakse vaid mõnda. Igal neist on iseloomulikud omadused, seega soovitame

Raamatust Digitaalne fotograafia. Trikid ja efektid autor Gurski Juri Anatolievitš

Failivormingud Kujutise teabe salvestamiseks on palju võimalusi ja seega palju failivorminguid. Tähelepanu! Andmekao vältimiseks salvestage piltidega töötades need TIFF-vormingus või redigeerimisprogrammi algvormingus. JPEGВ

Raamatust Windows 10. Saladused ja seade autor Almametov Vladimir

3. loeng. Faili struktuur

Kirjandus

o Kaasaegsed operatsioonisüsteemid, E. Tanenbaum, 2002, Peterburi, Peterburi, 1040 lk, (djvu-s 10,1 MB) rohkem>>

o Võrgu operatsioonisüsteemid N. A. Olifer, V. G. Olifer (zip-arhiiv 1,1 MB)

o Võrgu operatsioonisüsteemid N. A. Olifer, V. G. Olifer, 2001, Peterburi, Peter, 544 lk, (djvu-s 6,3 MB)veel>>

Failid

Teabe säilitamise nõuded:

o võime salvestada suuri andmemahtusid

o teave tuleb säilitada pärast protsessi lõpetamist

o mitmel protsessil peab olema samaaegne juurdepääs teabele

2.1.1 Failidele nime andmine

Faili nime pikkus sõltub operatsioonisüsteemist, see võib olla 8 (MS-DOS) kuni 255 (Windows, LINUX) tähemärki.

OS-id suudavad eristada suur- ja väiketähti. Näiteks WINDOWS ja Windows MS-DOS-i jaoks on samad, kuid UNIX-i jaoks on need erinevad failid.

MS-DOS-i puhul on laiend 3 tähemärki. Seda kasutades eristab süsteem faili tüübi ja selle, kas seda saab käivitada või mitte.

UNIX-is on laiendi failinime suurus piiratud 255 tähemärgiga ja UNIXil võib olla mitu laiendit, kuid laiendusi kasutavad rohkem rakendusprogrammid, mitte OS. UNIX ei saa selle laiendi põhjal kindlaks teha, kas fail on käivitatav või mitte.

2.1.2 Faili struktuur

Kolm peamist failistruktuuri:

1. Baitide jada- OS-i ei huvita faili sisu, see näeb ainult baite. Sellise süsteemi peamine eelis on selle kasutamise paindlikkus. Kasutatakse Windowsis ja UNIXis.

2. Kirjete jada- fikseeritud pikkusega kirjeid (näiteks perfokaart) loetakse järjestikku. Praegu pole kasutusel.

3. Sissepääsupuu- igal kirjel on võti, kirjeid loetakse võtme abil. Sellise süsteemi peamine eelis on otsingu kiirus. Kasutatakse endiselt suurarvutitel.

Kolme tüüpi failistruktuurid.

2.1.3 Failitüübid

Peamised failitüübid:

o Regulaarne- sisaldab kasutajateavet. Kasutatakse Windowsis ja UNIXis.

o Kataloogid- süsteemifailid, mis toetavad failisüsteemi struktuuri. Kasutatakse Windowsis ja UNIXis.

o Iseloom- sisend-väljund modelleerimiseks. Kasutatud ainult UNIX-is.

o Blokeeri- ketaste modelleerimiseks. Kasutatud ainult UNIX-is.

Tavaliste failide peamised tüübid:

o ASCII failid- koosneb tekstistringidest. Iga rida lõpeb käru tagastamisega (Windows), reavahetusega (UNIX) ja mõlemaga (MS-DOS). Seega, kui avate Windowsis UNIX-is kirjutatud tekstifaili, siis liidetakse kõik read üheks suureks reale, kuid MS-DOS-is neid ei liideta ( see on üsna tavaline olukord). ASCII-failide peamised eelised:
- saab kuvada ekraanil ja väljastada printerisse ilma teisendamiseta
- saab redigeerida peaaegu iga toimetajaga

o Binaarfailid- muud failid (mitte-ASCII). Reeglina on neil sisemine struktuur.

Peamised binaarfailide tüübid:

o Täidetav- programmid, neid saab töödelda operatsioonisüsteem ise, kuigi need on kirjutatud baitide jadana.

o Mittekäivitav- muu.

Näited käivitatavatest ja mittekäivitatavatest failidest

"Maagiline number"- faili tuvastamine käivitatavana.

2.1.4 Juurdepääs failidele

Peamised failijuurdepääsu tüübid:

o Järjepidev- baite loetakse järjekorras. Kasutatakse siis, kui olid magnetlindid.

2.1.5 Faili atribuudid

Peamised failiatribuudid:

o Kaitse – kes ja kuidas pääseb failile juurde (kasutajad, rühmad, lugemine/kirjutamine). Kasutatakse Windowsis ja UNIXis.

o Parool – faili parool

o Looja – kes faili lõi

o Omanik – faili praegune omanik

o Kirjutuskaitstud lipp - 0 - lugemine/kirjutamine, 1 - kirjutuskaitstud. Kasutatakse Windowsis.

o "Peidetud" lipp - 0 - nähtav, 1 - nähtamatu kataloogifailide loendis (vaikimisi). Kasutatakse Windowsis.

o Lipp "süsteem" - 0 - normaalne, 1 - süsteem. Kasutatakse Windowsis.

o Märkige "arhiiv" - arhiveerimiseks valmis või mitte (mitte segi ajada tihendamisega). Kasutatakse Windowsis.

o Märkige "tihendatud" – fail on tihendatud (sarnaselt zip-arhiividele). Kasutatakse Windowsis.

o "Krüpteeritud" lipp – kasutatakse krüpteerimisalgoritmi. Kui keegi proovib lugeda faili, millel pole selleks luba, ei saa ta seda lugeda. Kasutatakse Windowsis.

o ASCII/binaarne lipp - 0 - ASCII, 1 - binaarne

o Juhusliku juurdepääsu lipp - 0 - ainult järjestikune, 1 - juhuslik juurdepääs

o Märkige "ajutine" - 0 - tavaline, 1 - faili kustutamiseks protsessi lõpus

o Blokeerimislipp – failile juurdepääsu blokeerimine. Kui ta on toimetamistega hõivatud.

o Loomise aeg – loomise kuupäev ja kellaaeg. Kasutusel on UNIX.

o Viimase juurdepääsu aeg – viimase juurdepääsu kuupäev ja kellaaeg

o Viimase muudatuse aeg – viimase muudatuse kuupäev ja kellaaeg. Kasutatakse Windowsis ja UNIXis.

o Praegune suurus – faili suurus. Kasutatakse Windowsis ja UNIXis.

2.1.6 Toimingud failidega

Põhilised süsteemikutsed failidega töötamiseks:

o Loo – faili loomine ilma andmeteta.

o Kustuta – faili kustutamine.