In pratica, windows E' opensource, basta saper leggere l'assembler :P. Basta prendere come esempio Matt Pietrek che del vecchio windows 95  aveva riscritto molte cose in pseudocodice partendo dal reversing del kernel. L'unico passo avanti concreto che vedremo sara' negli emulatori di win su piattaforme linux, per il resto la eco del windows source leak si e' gia' spenta. Detto questo abbiamo una overview generale dell'argomento. E' ora di  scendere nei dettagli!

:: ORGANIZZAZIONE SORGENTI ::

Se non volete perdervi nel mare di righe di codice sara' meglio fare una mappa dei vari componenti. Innanzitutto vediamo 3 directory principali,\bsc,\private,\public. La prima contiene i dati per glimpse per il search engine, l'ultima contiene l'sdk e l'oak. Sono entrambe di scarsa utilita'. Quello che serve e' la \private, sede di tutto il codice. Nei sorgenti di nt4 e' presente solo \private. Ora la \private come potrete notare e' bella grossa, quindi non ve la posso commentare tutta. Vediamo invece di farci una "cartina topografica" dei vari componenti:

modulo: ntoskrnl.exe
locazione: \private\ntos
descrizione: il kernel di win2k, l'equivalente del bzImage di linux

modulo: ntdll.dll
locazione: \private\ntos\dll
descrizione: gateway per le transizioni um->km (syscalls)

modulo: kernel32.dll
locazione: \private\windows\base\client
descrizione: la parte usermode del kernel di windows

modulo: user32.dll
locazione: \private\ntos\w32\ntuser\client
descrizione: modulo per varie utilita', tipo creazione finestre,
manipolazione testo etc

modulo: advapi32.dll
locazione: \private\windows\screg\winreg
descrizione: api per il registry

questi sono i principali componenti, anche se noi ci concentreremo al 90% sul kernel. In \private\windows\shell\ trovate i source di regedit, del taskmanager, giochi e applicazioni varie. Ci sono anche i source di altre dll come comdlg32 etc. Le cose gravi che mancano sono:

• ntfs.sys - driver che gestisce ntfs
• gdi32.dll - libreria per le funzioni grafiche di base

nella versione dei source di 2k manca anche il bootloader, presente invece nei sorgenti per nt4, precisamente nella directory:

\private\ntos\boot

ci sono rispettivamente il bootsector, ntloader, ntdetect, setup loader ognuno in una propria subdirectory. In particolare c'e' il bootsector relativo a ogni fs, compreso ntfs. Tornando ai sorgenti di win 2k  troviamo parte del codice relativo alla rete in:

\private\inet

cioe' parte del codice di ie (mshtml), urlmon, wininet. Detto questo abbiamo una idea generale della struttura del source, se cercate altre cose non menzionate non vi sara' difficile trovarle, magari usate un buon grep :)

:: SI PARTE DAL BOOT ::

Ok e' ora di iniziare a toccare con mano il codice. Uhm da dove possiamo partire? Dal boot? Vada per il boot. Come visto sopra dobbiamo andare a cercare nella directory \private\ntos\boot. Il bootsector vero e proprio sta nella subdir \bootcode, nel quale ci sono diversi source rispettivi a diversi file system. Prima di tutto vediamo che il punto di partenza e' il source in \mbr, cioe' il codice fisico che risiedera' nel master boot record. E' il primissimo pezzo di sistema operativo che viene eseguito al boot subito dopo il codice del bios (x86mboot.asm). Come leggete dai commenti e' il codice STANDARD per ogni pc, cioe' il codice legge la partition table alla fine del master boot record, trova la partizione marcata come bootabile, ne copia il bootsector in memoria e lo esegue. Il mbr infatti e' fatto in questo modo:

+------------+ -- MBR --
| BootCode   | Executable Code
| Partition1 | PartitionTable
| Partition2 |
| Partition3 |
| Partition4 |
+------------+ -- END MBR --
| Partition1 | Partizioni
|            |
.            .
.            .

Quindi il bootcode non fara' altro che rilocarsi all'indirizzo 0:0600, saltare al codice rilocato, leggere l'entry bootabile della partition table, copiarne il bootsector all'indirizzo std di boot (0:7C00), ed infine eseguirlo, cosi' e' come se il bios avesse bootato direttamente la partizione bootabile descritta nella partition table. Uhm notate che in x86mboot.asm alla riga 48 dopo che il codice si auto-reloca all'indirizzo 0:0600 poi per saltarci usa un jmp far encodato a mano, cioe' i byte che vedete:

db 0EAh
db ...blabla...

sono i byte relativi all'opcode dell'istruzione jmp 0:0600, il cui address viene risolto a compile time. Ritroverete questo jump scritto a mano anche quando trovato il sector bootabile, il codice saltera' di nuovo all'address 0:7C00 per bootare il bootsector. A questo punto il bootcode cambia, infatti nella sottodirectory ntos\boot\bootcode\ oltre che \mbr troviamo altre directory, ognuna relativa a un file system:

\etfs Electronic Tariff Filing System
\fat fat32 per la precisione
\hpfs Pinball File System (per OS2)
\ntfs il fs nativo di nt
\ofs cucu'! La direcotry e' vuota!

In realta' sono supportati fat e ntfs, ed e' altamente sconsigliabile installare win nt su una partizione fat32. Ora possiamo concentrarci sul bootsector relativo a ntfs, gli altri funzionano allo stesso modo. Il compito di questo pezzo di codice (ntfsboot.asm) e' semplicemente quello di leggere il file ntldr, mapparlo in memoria all'indirizzo 2000:0000 e poi eseguirlo. Notate che siamo ancora in real mode per cui tutto il codice e' ancora a 16 bit. Come vediamo questo codice e' un po' troppo e non ci sta tutto nei 512 bytes del primo settore: infatti il bios mappa il primo settore del disco (traccia 0, testina 0, settore 1) in memoria all'indirizzo fisico 7C00. Ora in realta' qui non e' stato il bios a mappare in memoria il primo settore della partizione bootabile ma e' stato il codice del mbr. Perche' allora tale codice non mappa tutto il codice necessario (che per l'ntfsboot e' piu' grande di 512 bytes)? Ovviamente per compatibilita' con altri sistemi operativi. Ecco quindi che il ntfsboot appena mappato ha subito il problema di doversi mappare tutto il resto del codice. Ed infatti il codice inizia a leggere dal disco dal primo settore tutto il bootsector e lo riloca all'address 0D00:0000, cosi' avremo in memoria a quell'indirizzo sia il bootsector che i settori successivi che contengono il codice che serve. Una volta letto e mappato il codice, salta all'indirizzo 0D00:0200, cioe' al secondo settore letto dal disco (il primo e' gia' stato eseguito e non serve piu'). Questo si trova all'indirizzo fisico D200, al di sotto  dell'indirizzo fisico 20000h dove verra' mappato il file ntldr, quindi niente problemi di interferenza. Di nuovo vediamo che il salto al nuovo codice rilocato avviene (alla riga 165) con una forma:

push seg
push offset
ret

sembra che abbiano problemi a scrivere in assembler i jmp far! Vabbe' niente di rilevante. Quindi ora l'esecuzione si sposta al secondo settore alla procedura mainboot. Prima di questa procedura nel codice vediamo alcuni dati e la signature "55AA" che sta alla fine del primo settore. La mainboot procedure fa la lettura vera e propria del file ntldr (potete vedere molte funzioni usate per leggere da ntfs), e alla fine restituisce l'esecuzione all'immagine in memoria di ntldr che come abbiamo gia' detto si trova a 2000:0000. I bootsector relativi agli altri tipi di file system agiscono allo stesso modo, cambia solo il codice che legge il file dal disco. Adesso quindi ci dobbiamo spostare sul codice di ntldr. Notate che finora non si e' ancora fatto nulla delle inizializzazioni standard, tipo settare il paging, il protected mode etc etc. Siamo ancora in realmode, quindi ntldr iniziera' la sua esecuzione a 16bit e poi fara' il passaggio al protected mode e quindi ai 32 bit. Okay quindi ora ci dobbiamo spostare al file

\ntos\boot\startup\i386\su.asm

vi ricordo che siamo sempre nei source di nt4. Vediamo che la prima riga consiste in un jmp RealStart. Tra questo jmp e la routine stessa c' è del codice riguardante FAT. Se infatti si e' bootato il sistema da FAT32 allora il codice deve ancora occuparsi di leggere ntldr e mapparlo in memoria prima di eseguirlo. Nel nostro caso stiamo considerando ntfs per cui non ci interessa. La routine RealStart non fa altro che preparare i segmenti e lo stack e poi passare l'esecuzione alla procedura SuMain che si trova nel file:

\ntos\boot\startup\i386\main.c

finalmente ci spostiamo su un po' di codice C. Tenete comunque a mente il file su.asm perche' esporta la funzione di enabling del protected mode che vedremo fra poco. Questa procedura inizializza il subsystem video (InitializeVideoSubSystem in display.c), spegne il motore del  floppy in caso il sistema e' stato bootato da floppy (TurnMotorOff in su.asm), fa altri lavori di inizializzazione, tipo calcolare il size della memoria necessaria per l'Os Loader, quindi dopo questa robaccia arriva al punto cruciale: il passaggio a 32bit! Infatti vediamo che il codice abilita la linea A20 (EnableA20 in a20.asm), reloca le strutture IDT e GDT che dovra' usare in protected mode. Quindi e' l'ora di settare il pm ed il paging (EnableProtectPaging in su.asm). Da notare che il paging non verra' abilitato alla prima volta che si esegue questa procedura, in quanto lo startup loader non ha ancora determinato un descrittore valido per PDE e PTE. L'abilitazione al paging verra' fatta all'inizio dell'os loader, codice che vedremo tra poco. In particolare vediamo che imposta anche il selettore per il PCR nel segmento FS, cioe' il Processor Control Region, una struttura fondamentale del kernel, quindi ci aspettiamo che presto il codice andra' a finire al modulo ntoskrnl. Inoltre sono impostate le aree di memoria relative a IDT e GDT mentre la LDT e' azzerata, infatti nt non la usa mai al contrario di consumer windows. Quindi il switch in pm avviene tramite:

mov eax, c30
... (la prima volta evita l'abilitazione del paging)
or eax,PROT_MODE
mov cr0,eax

pero' non abbiamo ancora finito tutto il passaggio a 32 bit, per ora il codice sta impostando i segmenti, le strutture e il descrittore TSS. Il controllo ritorna alla procedura SuMain, che chiama la funzione RelocateLoaderSections per calcolare l'indirizzo corretto al quale si trova l'entry point dell'os loader. Questo infatti e' un coff PE valido, ovviamente embedded dentro l'ntldr, quindi lo possiamo considerare il primo vero processo che windows esegue. Il passaggio dell'esecuzione all'os loader avviene tramite la funzione TransferToLoader usando come entry point l'address appena calcolato con la precedente funzione di reloc. Quindi ora ci spostiamo nella directory

\ntos\boot\lib\i386

dove ci sono i vari file che ci interessano. In particolare nel file entry.c c'e' l'entry point del suddetto PE, identificato dalla funzioncina NtProcessStartup. Analizziamola e vediamo che DoGlobalInitialization e' la prima funzione ad essere chiamata. Anche qui vediamo la prima funzione chiamata, cioe' la InitializeMemorySubsystem. Parentesi: molte funzioni usano come parametro il BootContextRecord, potete vederne la dichiarazione in bootx86.h (struttura _BOOT_CONTEXT). Torniamo alla funzione InitializeMemorySubsystem nel file memory.c. In questo file ci troviamo anche una mappa della memoria (immagini dei componenti e relativi stacks / heaps) che ci possono sempre tornare utili. Questa funzione ha subito un while che cicla per tutti MemoryDescriptor che si trovano nel BootContextRecord. Ogni memory descriptor infatti e' una struttura con due campi, BlockBase e BlockSize, descrivono l'indirizzo di partenza di un'area di memoria e la sua grandezza. Quindi BootContext->MemoryDescriptorList e' un array di memory descriptor che appunto descrivono tutti i blocchi di memoria che servono. Tenete a mente che siamo in protected mode ma senza il paging abilitato, per cui in questo momento ogni indirizzo che usiamo corrisponde ad un indirizzo fisico! Ecco quindi che questo while prepara gli indirizzi di memoria (rispettando il page boundary) per tutti i blocchi di memoria gia' noti. Il loader non utilizza la memoria al di sopra di 16 mega (per non dover gestire i data transfer dai bus isa), quindi tutta quella al di sopra dei 16 mega viene marcata come MemoryFirmwareTemporary. Una volta finito il while, tutta la memoria fisica e' stata descritta (con le funzioni MempAllocDescriptor e MempSetDescriptorRegion), l'array di descrittori e' mantenuto nella variabile globale MDArray[] (definita in arcemul.c). Adesso sono stati creati dei "macro" descritttori che descrivono sommariamente la memoria fisica, quindi dopo il while c'e' il codice che si occupa di descrivere il primo mega di memoria. Infatti qui ci sono tutti i componenti di memoria utili al loader, come la interrupt vector area, heaps di sistema ecc. Notate che il primo mega di memoria virtuale coincidera' con il primo mega di memoria fisica, per permettere allo osloader di continuare l'esecuzione sotto il primo mega e di mappare la memoria dedicata al kernel. Sempre tramite MempAllocDescriptor vediamo che dall'MDArry iniziale vengono ricavati dei sotto-descrittori per le aree di memoria sotto il mega. Finito tutto questo lavoro di creazione di descrittori, finalmente giungiamo alla MempTurnOnPaging! Questa funzione non fa altro che fare un walk dell'MDArray in modo da chiamare la funzione MempSetupPaging con la quale vengono create le entry per le PDE\PTE per tutta la memoria necessaria che si e' calcolata pocanzi. Le variabili globali sono PDE per la PDE e HalPT per la PTE. Una volta fatto il walk dei memory descriptors, la PDE\PTE e' stata impostata correttamente, quindi la funzione MempTurnOnPaging abilita il paging:

mov eax,PDE
mov cr3,eax
mov eax,cr0
or eax,CR0_PG
mov cr0,eax

e' la prima volta che avviene da quando abbiamo bootato! Come vedete nel page directory base register (CR3) viene impostato il ptr all'array di PDE, quindi in CR0 viene abilitato il flag relativo al paging. Ok, dopo l'abilitazione la funzione InitializeMemorySubsystem chiama MempCopyGdt per spostare la GDT e IDT in una nuova area di memoria. Ok la funzione e' finlamente finita e torniamo a DoGlobalInitialization. Vediamo che c'e' qualche altra robaccia ed infine la chiamata alla funzione InitializeMemoryDescriptors, che come vediamo dai commenti sarebbe il passo 2 della InitializeMemorySubsystem. Infatti prima sono state create le PDE\PTE per passare al paging, ora questa funzione si occupa di tornare nell'MDArray e allocare la memoria per tutti i descrittori che avevano marcato la memoria come "reserved". Fatto cio' abbiamo finito anche la DoGlobalInitialization. Back to the NtProcessStartup, abbiamo qualche funzione di inizializzazione, che si occupano di trovare la partizione da cui abbiamo bootato, di inizializzare la memoria di sistema e l'I/O system, quindi arriviamo a BlStartup. Vediamo che subito dopo c'e' un codice:

// we should never get here!
do {
GET_KEY();
} while ( 1 );

il che vuol dire che il compito di ntldr termina dentro la funzione BlStartup, che si trova nel file initx86.c nella directory:

\ntos\boot\bldr\i386

cosa fa questa funzione? Si occupa di aprire il drive e leggere il file boot.ini, dove sono definite tutte le entry bootabili. Tali entry sono mostrate con il classico menu di scelta, quindi una volta selezionata l'entry da bootare l'os determina disco/partizione/path e arriviamo alla funzione BlOsLoader, che si trova nel file:

\ntos\boot\bldr\osloader.c

ci siamo quasi, come vedete poco prima di questa funzione compaiono le definizioni dei nomi "ntoskrnl.exe" e "hal.dll", saranno questi i componenti che saranno caricati. Come vedete il codice e' commentato molto bene, per cui e' facile capire cosa succede: apre le partizioni di boot e di sistema, apre l'input/output console, inizializza la  memoria con la funzione BlMemoryInitialize, presente nella directory:

\ntos\boot\lib

nel file blmemory.c, dove sono inizializzati lo stack, l'heap e la memory allocation list. In questo caso l'unico memory descriptor che e' stato allocato e' quello relativo all'os loader, visto che non sono stati caricati altri programmi, per cui la funzione cerchera' il primo memory descriptor sotto l'os loader, poi alloca l'heap al piu' alto indirizzo possibile, alloca lo spazio per il loader parameter block, quindi il loader stack e il loader heap. Poi dopo la memory init vediamo altre inizializzazioni (i/o e resource section), quindi vediamo che c'e' la gestione dei parametri di boot che erano stati specificati nel boot.ini, infatti sono gestiti i parametri /KERNEL= /HAL= che permettono di specificare un kernel e un hal diversi da quelli di default, cosa che di solito torna utile quando si vogliono caricare dei checked environment per il driver testing. Fatto cio', genera i path dei due componenti e dell'hive di sistema, che vedremo tra poco. Il primo ad essere caricato e' ntoskrnl.exe con la funzione BlLoadImage, che appunto ne carica l'immagine eseguibile in memoria. Quindi il loader determina il tipo di fs usato e prende gli eventuali argomenti da passare al kernel. Ora e' il turno di hal.dll, anche lui caricato con la BlLoadImage. Vi ricordo che anche questi due moduli sono dei coff PE, infatti la funzione si trova nel file:

\ntos\boot\lib\peldr.c

che non e' il pe loader completo, infatti poco dopo nel codice dello osloader viene usata la funzione BlScanImportDescriptorTable con la quale trova manualmente le dll importate dai moduli caricati e a sua volta le carica e fa il bind delle api import/export. Caricato il kernel, l'hal e tutti i relativi moduli importati, e' giunto il momento di caricare i driver. Per farlo deve consultare l'hive di sistema. Che cos'e' questo hive? Gli hive sono i file che contengono le informazioni gestite dal registry. In particolare ora ci occupiamo dell'hive \windows\config\system che contiene tutte le impostazioni dell' hardware e i relativi drivers. Caricati i driver c'e' la funzione BlSetupForNt che si occupa di fare alcune inizializzazioni hardware, tipo la  relocazione dell'abios, del tss etc. Finalmente il loader ha finito il suo compito, e arriviamo alla riga:

(SystemEntry)(BlLoaderBlock);

con la quale viene chiamato l'entry point del modulo ntoskrnl. Da adesso passiamo ai sorgenti di win2k, possiamo abbandonare quelli di nt4. L'entry point del kernel si trova nel file:

\win2k\private\ntos\ke\i386\newsysbg.asm

ed e' la funzione KiSystemStartup che prende come argomento il loader block di cui si e' parlato qualche riga piu' su. Qui termina questa prima parte, abbiamo visto cosa fa il boot etc etc, siamo arrivati al kernel, nel prossimo articolo quindi vedremo  l'inizializzazione del kernel e qualche altra roba. Alla prossima!
See ya!
AndreaGeddon

Note finali

Ciauz a tutta la UIC e #crack-it, un saluto a Giulia e alla sua nuova ezine (della quale presto avrete notizie!), un saluto a Ironspark che ha fatto da poco il compleanno! Ciaooooooooooooooooooooo!

Disclaimer

Io non so niente non ho visto niente non ho sentito niente non ho fatto niente! Arrestate Que!! Ve lo vendo per 30 denari!

---