Newsgroup: it.comp.programmare.win32
Titolo: GDI: strutture interne [HELP!]

Un anno fa passai settimane a disassemblare Windows, SoftIce e TRW2000 per
capire come facevano ad acquisire il BaseAddress, la risoluzione e altro del
desktop.
Alla fine ho scoperto una struttura che ho definito come segue:
GDI_DATA struc
 gdSign  dw ? ; "dovrebbe" essere "PR". Vedi Nota.
 gdXRes  dw ?
 gdYRes  dw ?
 gdUnk1  dw ?
 gdPlanes db ?
 gdBpp  db ?
 gdUnk2  dd ?
 gdLnSz  dw ?
 gdUnk3  dd ?
 gdSelfSel dw ? ; punta a questa stessa struttura (base address)
 gdVMOff  dd ? ; offset da aggiungere al base address di gdVMSel
 gdVMSel  dw ? ; selettore per la memoria video (FLAT)
GDI_DATA ends
Questa struttura la trovo cercando tra gli HEAP delle GDI.
Ogni volta che la risoluzione cambia questa struttura viene aggiornata
immediatamente in modo da rispecchiare le modifiche.
Sotto programmi DirectX il discorso cambia un po' a causa del Double o
Triple Buffer, ma quello č un altro discorso....
Da quando ho installato la Radeon 8500 LE (prima avevo una GF GTS2) le mie
routine non trovano piů la struttura giusta!!!
Qualcuno conosce un metodo piů ortodosso per acquisire l'indirizzo di questa
struttura e magari compatibile con varie versioni delle GDI?
Kiuhnm
P.S. Intanto dovrň reimmergermi nei meandri di queste funzioni che ho
scritto un anno fa e di cui non mi ricordo un accidente...
P.P.S. Inutile dirvi che non posso e non voglio utilizzare nessun genere di
API :-)

API :-)
Ciao, come programmatore a base di API Win32 non so darti la risposta,
pero' se vuoi toglimi una curiosita': come mai ti sei cimentato con la
decompilazione di Windows ? Che benefici ti porta rispetto alla
programmazione in C++ e Win32 API pure ?
Ciao
Stefano "HappyMan" (Lago Maggiore - NO)
--
Personal Web 
http://www.sgr.info
Email 
happyman...@libero.it
 [Togliere nospam per scrivermi]
Salsa Web 
http://web.tiscali.it/happyman
 [Foto salseri/e & I.A.B.L.A. Ring]

 programmazione in C++ e Win32 API pure ?
Sto lavorando da tempo a un kernel debugger.
I kernel debugger devono poter scrivere sullo schermo (v. SoftIce) in
Interrupt Time e nessuna API o servizio Vxd permette di fare questo (Windows
non è rientrante, ecc... ecc...)
L'unico modo è di ottenere forzatamente l'indirizzo della memoria video e
scriverci direttamente (con dei bei mov, stosd, ecc...) come si faceva un
tempo sotto DOS.
Ovviamente il codice deve supportare 8/15/16/24/32 bit e renderizzare le
lettere pixel per pixel. Per ora il file graphics.asm è lungo all'incirca
4500 righe di asm.
Le funzioni più ad alto livello disegnano delle finestre tipo quelle di
Windows, gestiscono il refresh dello schermo, ecc...
Comunque ho capito che cosa è cambiato.
Prima il campo 'gdSelfSel' conteneva un selettore alla struttura stessa,
mentre adesso contiene semplicemente 0!
Non so perchè, ma comunque sarà sufficiente fare una piccola modifica al
debugger.
All'inizio si aggiungono sempre molti controlli in modo da non scegliere
strutture sbagliate poi piano piano si eliminano in modo da rendere il
codice più compatibile...
Se qualcuno conosce un metodo migliore si faccia vivo ugualmente!!!
Kiuhnm

 4500 righe di asm.
scusa la mia ignoranza...ma non potresti scriverne solo una piccola 
parte in assembler (quella a diretto contatto con l'hw) e poi usare il 
c/c++ per il resto?
...o c'e' davvero bisogno di 4500 righe di asm?!??
PS: ma le conoscenze tecniche per spingerti ad un livello cosi' avanzato 
della programmazione dove le hai apprese (voglio dire: bypassare 
completamente il sistema operativo, ecc.)? avresti libri da consigliare 
a riguardo, sui meccanismi interni di windows e simili? thx
ciao

 a riguardo, sui meccanismi interni di windows e simili? thx
Le ho apprese da Orc, Fravia e via discorrendo.
Magari li hai sentiti nominare :-)
Comunque ho dovuto consolidare le conoscenze studiando i 3 manualoni Intel,
i manuali sul PIC, sul PIT (Timer), tastiera, mouse, il formato NE, PE, e
altro ancora...
Le info ci sono, ma sono lunghe e all'apparenza poco interessanti.
Di tanto in tanto sono perfino costretto a vagare nei meandri di Windows, ma
questo solo dopo un mese infruttuoso con 
google.com
 :-)
Kiuhnm

 Magari li hai sentiti nominare :-)
no, mai ?_? sono siti con tutorial?? l'unica cosa che sapevo era di un 
libro di matt pietrik mi pare sugli "internals" di win95...
(tieni conto che comunque io codo sotto windows in c/c++ e non mi sono 
mai spinto nei "meandri" del OS, anche se - ripeto - mi piacerebbe 
apprenderne i meccanismi interni di funzionamento)

 apprenderne i meccanismi interni di funzionamento)
Beh, quando ti senti pronto leggiti i manualini Intel :-)
Kiuhnm

 wrote in message
news:ZbO29.161662$Jj7.3...@news1.tin.it...


 sarebbe interessante, che ne dici?
Molta altra gente (per es. i signori della Numega) non lo fa. Un motivo ci
sarą pure?
Il codice del mio debugger č ampiamente documentato, ma la documentazione č
parte integrante di un programma commerciale e quindi non mi sembra giusto
renderla pubblica.
Programmare un kernel debugger non significa semplicemente leggere libri
sulla programmazione, ma anche spendere tantissimo tempo a decompilare gran
parte di Windows.
Distribuire la documentazione sarebbe come distribuire il codice sorgente
del mio debugger.
Inoltre questo renderebbe il mio debugger molto pił debole agli attacchi.
Kiuhnm

Inoltre questo renderebbe il mio debugger molto più debole agli attacchi.
A quali attacchi?
--
Rhymes (rhy...@NOSPAMmyself.com)
http://www26.brinkster.com/rhymes
" ride or die "

 >Inoltre questo renderebbe il mio debugger molto più debole agli attacchi.
Attacchi da parte di protezioni.
Per esempio, sapendo su quali strutture fa affidamento il TRW2000, potrei
modificarne leggermente una in modo che Windows funzioni, ma che il TRW
s'inchiodi :-)
Per quanto riguarda il tipo di protezione utilizzata, sarà qualcosa del
tipo:
* utilizzo di funzioni one-way ==> impossibile scrivere key-maker
* controlli random, stratificati e inline (per intenderci il debugger potrà
saltare dopo mezz'ora come dopo due ore e non "funzionare bene", dopo un
numero random di lettere digitate, ecc...)
* anti-tracing ==> qualsiasi tipo di tracing sul debugger riavvierà il
sistema
Per fare questo utilizzo MACRO del tipo ProtBeginProc e ProtEndProc che
aggiungono protezioni all'interno della funzione in punti sempre diversi. In
questo modo due versioni del debugger (o anche la stessa se riassemblata)
avranno i controlli in punti sempre diversi.
Kiuhnm

avranno i controlli in punti sempre diversi.
idem come sopra sopra sopra (ie. ah boh)


 idem come sopra sopra sopra (ie. ah boh)
Allora ne riparleremo piů avanti magari su qualche ng dedicato...
Kiuhnm