leggere eseguibile.

[telluccio]

forse meglio passare al settaccio i post prima di copiare e incollare..
io che sono pratico, da nubio ho capito alcune cose.
ho fatto un programma che legge un file binario dividendolo per stringhe ('\n') ad ogni stringa il programma si blocca e visualizza il valore in hex delle prime 2 word per passare alla succesiva..
tutti gli eseguibili fatti da me iniziano sempre con la stessa stringa di 119 byte:

Z�   ÿÿ ¸ @ € º ´ Í!¸
LÍ!This program cannot be run in DOS mode.

poi le successive stringhe cambiano a seconda dell eseguibile...pero capitano gruppi di stringhe che sono uguali (o diverse solo nel valore dell ultimo byte della seconda word)come valore delle prime 2 word...
e giusto pensare che il processore inerpreta la stringa dal valore delle prime word??
ps:
molte cose che gentilmente mi spiegate non le conosco..
ciao

[71104]

non ho ben capito la domanda, ma tutti i programmi che fai iniziano come hai scritto tu (a parte che ti sei scordato la M iniziale) perché quella parte che vedi è il vecchio header di DOS seguito dallo stub program che stampa a video quella stringa se sta girando in DOS anziché in Windows (utilizza qualche interrupt del BIOS).
per leggere un file PE da un programma C devi (come è scritto nella documentazione Microsoft del formato PE) saltare subito all'offset 0x3C, leggere un DWORD, saltare all'offset specificato da quel DWORD, e poi leggere i nuovi headers PE.
è impossibile leggere un programma con Blocco Note... per ricavare informazioni da un file PE esistono altri strumenti, tipo il PEView e il Resource Hacker .

[bottomap]

Ciao,

Direi che hai fatto tutte ottime precisazioni... un post completo sull'argomento sarebbe in effetti piuttosto oneroso - pagine e pagine solo di introduzione.

Gli eseguibili NE sono, come hai intuito gli eseguibili di win3.1 anche se il formato è stato introdotto con OS/2... ancora numerosi VXD e diverse applicazioni (queste ultime almeno fino a win98) utilizzano questo formato. La signature NE è proprio quella di questo tipo di eseguibili... sono comunque abbastanza frequenti per piccole applicazioni o programmi vecchiotti, non è impossibile che ti capiti sottomano... win 32/64bit è ovviamente sempre in grado di caricarli ed eseguirli.

Il campo e_lfanew è effettivamente l'offset 0x3C di cui parli, praticamente l'unico punto "fisso" di tutto l'eseguibile...

Non sapevo che l'optional header fosse opzionale solo sotto windows... quali altri SO utilizzano il PE come formato di eseguibile?

Tutte le sezioni, probabilmente non ho postato in maniera chiara, possono non essere presenti (a parte, ovviamente, quella contenente il codice)... file privi di .rsrc sono comuni, .idata è un po'più raro che non ci sia, .edata è presente quasi solo nelle DLL... .rdata in generale contiene informazioni di debug (quindi non è generalmente presente nelle versioni release dei programmi), tutto questo almeno con i compilatori MS, non so se altri compilatori la utilizzano in altro modo...

Cito, a questo riguardo MSDN:

The .rdata section is used for at least two things. First, in Microsoft linker-produced EXEs, the .rdata section holds the debug directory, which is only present in EXE files. (In TLINK32 EXEs, the debug directory is in a section named .debug.) The debug directory is an array of IMAGE_DEBUG_DIRECTORY structures. These structures hold information about the type, size, and location of the various types of debug information stored in the file. Three main types of debug information appear: CodeView®, COFF, and FPO.

Il discorso sulla EntryPoint striminzita riguarda, come ho postato, MFC e VB... nel primo caso ci sono due chiamate a funzioni Afx (che impostano il framework mfc e ricevono un puntatore ad una lunga vtable - che rappresenta poi l'oggetto CWinApp), dopodiché la funzione di Entry termina...
Lo stesso avviene più o meno per VB...

Ma forse ho unito la start con la WinMain in questa mia considerazione... la funzione start che inizia effettivamente il programma (in pratica imposta tutto il necessario alla CRT per proseguire) è praticamente sempre uguale sotto lo stesso compilatore... ed in genere non influisce nello studio del codice.

Ad ogni modo, per questo motivo andare a rintracciare una funzione all'interno dell'intero asm può essere complicato... soprattutto in un'applicazione con bottoni, menù e quant'altro è estremamente difficile capire esattamente lo schema degli eventi che si susseguono (es: il CListView si aggiorna, invia un WM_ ad una delle CEdit che nella sua OnChange invia un WM_ ad un altro controllo, il tutto mentre alla CWinApp arrivano n messaggi NC_ dai controlli) se si ha a disposizione solo l'asm.

Per la creazione dei selettori non sono del tutto sicuro... credo ne vengano creati due (data e codice) giusto per impostarne il flag per i diritti di accesso...

Per il formato DOS si deve distinguere tra .EXE e .COM...

Il secondo (COM), come dici è codice puro (deve essere contenuto tutto in un segmento, inizia l'esecuzione all'offset 0x100 e nei primi 256 bytes è presente il PSP - ProgramSegmentPrefix che contiene un bel po'di informazioni, tra cui la linea di comando). Nei .COM non è possibile utilizzare registri di segmento, per cui codice, stack e dati devono stare tutti in 64k.

Il primo (EXE) contiene un IMAGE_DOS_HEADER come i PE e gli NE che danno informazioni oltre che sull'entry point (in questo caso è variabile) sulla corretta segmentazione (in genere viene creato un CS, un DS=ES ed un SS), sulla dimensione dello stack e numerose altre cose. DS ed ES puntano inizialmente al PSP del programma.
Al caricamento da parte del loader vengono creati i segmenti, vengono rilocati gli indirizzi e l'esecuzione parte dall'entry point definita nell'IMAGE_DOS_HEADER (per completezza, negli eseguibili PE questo EntryPoint DOS punta ad una funzione di stub a 16bit che in genere stampa il messaggio "Questo programma richiede windows" o qualcosa del genere, sicuramente l'avrai vista).

Ciaociao

[71104]

Originariamente inviato da bottomap

Non sapevo che l'optional header fosse opzionale solo sotto windows... quali altri SO utilizzano il PE come formato di eseguibile?

nessuno
il concetto dell'header opzionale sarebbe che può variare da un sistema all'altro, ma alla fine l'unico SO che usa il PE è Windows
Windows CE forse ha un header opzionale diverso, ma non ne sono neanche troppo sicuro

.rdata in generale contiene informazioni di debug (quindi non è generalmente presente nelle versioni release dei programmi), tutto questo almeno con i compilatori MS, non so se altri compilatori la utilizzano in altro modo...

veramente .rdata dovrebbe contenere più in generale dati a sola lettura... in teoria potrebbe anche essere presente nei programmi compilati in modalità release...

Ad ogni modo, per questo motivo andare a rintracciare una funzione all'interno dell'intero asm può essere complicato... soprattutto in un'applicazione con bottoni, menù e quant'altro è estremamente difficile capire esattamente lo schema degli eventi che si susseguono (es: il CListView si aggiorna, invia un WM_ ad una delle CEdit che nella sua OnChange invia un WM_ ad un altro controllo, il tutto mentre alla CWinApp arrivano n messaggi NC_ dai controlli) se si ha a disposizione solo l'asm.

per tracciare i messaggi ci sono gli hook globali
vedi Spy++, è un tool molto utile.

Per la creazione dei selettori non sono del tutto sicuro... credo ne vengano creati due (data e codice) giusto per impostarne il flag per i diritti di accesso...

no, i segmenti penso che siano uno per ogni processo, ma non sono sicuro neanche di questo, forse sono un paio in tutto il sistema (user space e kernel space).