XProfan

- page 1 -

Michael
Wodrich

je n'en sais rien si cela déjà alles était ou bien seulement qui partie dedans des Text-Tutoriels. mais ca ist alles quoi je wiederfand - Sorry:

[quote-part:9033556722]
Win95/98 Virtual Address Space Memory Layout:
---------------------------------------------
From 0x00000000 to 0x00000FFF. These first 4KB is used to maintain
compatibility with Win16 and DOS programs. It is unaccessible to any process
raising à exception si a read/write attempt occurs.

From 0x00001000 to 0x003FFFFF. This 4 MB area is alors used for compatibility
issues but is accessible by any process. Off course, il is not recommended
to play with this area.

From 0x00400000 to 0x7FFFFFFF. This 2 GB partition is le private address
space assigned to every running process. Each win32 application receives à
unshared, private 2 GB chunk of virtual address space (dont forget to
subtract le bottom 4MB describe above). At this point, you should not
confuse yourself, windows does not assign 2 GB of your precious memory to
every running thread; this is virtual address space, not physical memory.
Win95/98 (Win98 à partir de now on) judiciously commits and maps physical storage
le every process virtual address space according to its growing necessities.

From 0x80000000 to 0xBFFFFFFF. This partition is 1 GB long and is shared
among espace Win32 process. Here, Win98 maps espace memory allocations, dynamic
link libraries (KERNEL32.DLL, USER32.DLL, GDI32.DLL, ADVAPI32.DLL), memory
mapped files (MMF à partir de now on) and Win16 applications. It is useful to say
that DLL sont always mapped to le same fixed virtual addresses.

From 0xC0000000 to 0xFFFFFFFF. This partition is alors 1 GB long; here is
where le operative system code resides. Unfortunately, this area is alors
accessible to espace win32 processes and that is why Win98 is more prone to
crashing than WinNT.

Now that you know how this wonderful 4 GB world is constrained by
invisible barriers, is time to discuss about le subject of this
tutorial.

Managing memory under win98 can être achieved by three different
strategies: virtual memory allocation, memory mapped files and heaps. Each
method is best suited for certain tasks. MMF is used to access large buffers
of data dans memory, mainly files like EXE, DLL (which explains le nom of
this method), to être more accurate, both le user and le operative system
can map files dans memory, for instance, le operative system loads files like
kernel32.dll using this feature.
[/quote-part:9033556722]
source: mmf.txt (irgendwo aus dem Iczelion-Universum)

belle Grüße
Michael Wodrich

Programmieren, das spannendste Detektivspiel der Welt.

07.09.2006 ▲

allô Michael...

seulement kurz survolés:
dans dem Artikel ca va um Windows95/98 => cela fonctionne sous NT quelque chose anders. sous Windows95/98 peux on 3GB ansprechen, sous NT seulement 2GB. qui DLL sommes sous NT dans den Speicherbereich de ca 1GB jusqu'à 2GB gemappt. cela sur Adressen de 0xC0000000 jusqu'à 0xFFFFFFFF également de allen Prozessen aus zugegriffen volonté peux, halte je seulement la fois pour un Gerücht

(siehe TNT). Lies la fois là Infos sur qui Adresse -16 sous Windows98 aus

. cela qui Adressen mais sur qui gleichen realen Speicherbereiche verweisen, habe je selbst déjà vermutet.
sous Windows95/98 doit ne...aucune grenier pour Zugriffsrechte Sicherheitsbeschreibungen ou bien den Token bereitgestellt volonté - solche Sachen kennt seulement NT - c'est pourquoi ist ici qui pas zugängliche Speicherbereich aussi wesentlich kleiner.

@IF:
Kompilieren Marque Séparation

Def @OpenProcess(3) !"KERNEL32","OpenProcess"
Def @CloseHandle(1) !"KERNEL32","CloseHandle"
Def @GetCurrentProcessID(0) !"KERNEL32","GetCurrentProcessId"
Declare Prozess_SYSTEM&,Prozess&,ID$,ID2$,Prozess2&
Windowstyle 31
Windowtitle "Handletest"
Window 0,0-640,440
LET ID$=@INPUT$("ID eines Prozesses eingeben:","Prozess-ID",@STR$(@INT(@GetCurrentProcessID())))
LET ID2$=@INPUT$("ID eines Prozesses eingeben:","Prozess-ID",@STR$(@INT(@GetCurrentProcessID())))
LET Prozess&=@OpenProcess($400,0,@GetCurrentProcessID())
LET Prozess2&=@OpenProcess($400,0,@GetCurrentProcessID())
LET Prozess_SYSTEM&=@OpenProcess($400,0,8)
@CloseHandle(Prozess_SYSTEM&)
@CloseHandle(Prozess2&)
@CloseHandle(Prozess&)
PRINT "Handle des ersten Prozesses: "+@STR$(Prozess&)
PRINT "Handle des zweiten Prozesses: "+@STR$(Prozess2&)
PRINT "Handle von System: "+@STR$(Prozess_SYSTEM&)

While 0=0

    Waitinput

Wend

qui numéro des Handles ist dépendant en, quand on cela Handle ouvrez. entre den individuel Handles besteht un la distance de 4 - sembler sich alors, ähnlich comment beim grenier, Adressen derrière elle trop cacher. avec partager läßt sich là malheureusement rien berechnen, car qui numéro des Handles sagt rien par-dessus aus, si es gültig ou non. cela einzige, quoi on peut-être aus qui numéro des Handles ersehen pourrait, wäre qui Art des Handle.

Anders sieht cela avec qui ID des Prozesses aus:

qui ID des Prozesses System liegt toujours chez 8. qui prochain Prozess legt ensuite wieder chez sur 100 à l'attaque.
Beim Disassemblen qui Funktionen, qui avec dem System-Handle fehl schlagen, konnte je mais nirgendwo une 8 entdecken

. Peut-être là dans Bezug sur qui ID une Kleiner-comme-Abfrage avec einem Sprung enthalten?

PS: cela Handle des Prozesses System bekommst du seulement, si du den Voir le texte source comme Service avec Systemrechten startest.

...je hab mir qui de System geladenen Module nochmals avec TNT angesehen:
System läd WIN32K.SYS et qui NTDLL.DLL, mais pas qui KERNEL32.DLL.
cela peux eigentlich seulement bedeuten, cela WIN32K.SYS den Kernelspeicher selbst ausliest - ou bien, quoi pour mich seulement einmal wahrscheinlicher ist, undokumentierte Funktionen aus qui NTDLL.DLL pour utilise.

Jac
de
Lad

je hatte la fois est, dass Windows 98 ur 512 MB RAM verwalten peux, mais cet information ist maintenant évident überflüssig...

Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP

allô Jacob...

und dir um den virtuellen Prozessspeicher, pas um den realen grenier. chacun Prozess verwaltet une ´virtuellen Prozessspeicher de ca.4GB. Diesen virtuellen Prozesspeicher doit du dir comment une Art la carte présenter, chez qui chacun Adresse einer realen Adresse im RAM ou bien dans qui Auslagerungsdatei zugeordnet volonté peux. peux est, pas chacun Adresse doit absolument RAM zugeordnet son, mais Adressen peut aussi unbelegt son. qui unteren 2GB cet Mémoire peux qui User verwalten et décrire /chez pas NT basierten Systemen qui unteren 3GB), qui reste ist pour qui Nutzung des Betriebsystems reserviert. je hoffe, j'ai quelque chose Klarheit dans qui l'affaire gebracht.

mon Überlegung: si es gelänge, par Patching de Betriebsystem DLL im grenier des eigenen Prozesse un gültiges Handle sur den System Prozess trop erlangen um DLL là trop injecter, pourrait on peut-être. aussi Zugriff sur Speicherbereiche conservé, qui eigentlich seulement cela OS nutzen peux et homme pourrait quasi Windows qui Unterwäsche ausziehen um une perspective sur nackte Tatsachen trop erlangen...

Jac
de
Lad

allô Andreas,

merci pour qui Ausführung. Jaja, je sais quoi virtueller grenier ist, mais je dachte und dir ici um physikalischen grenier. en supplément habe je mais nix trop dire.

Jac

Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP

- page 2 -

à einigen se mettre habe je dans diesem Fil weil je es jusqu'alors pas besser wußte quelque chose Mist verzapft:

Im Prozess System befinden sich sous Windows2000 qui Module WIN32K.SYS, HAL.DLL et NTOS et Ntoskrnl.exe, mais pas qui NTDLL.DLL.
qui Ntoskrnl.exe entspricht dans vielen partager qui NTDLL.DLL, et gibt sich aussi im En-tête scheinbar comme cet aus.

qui virtuelle Adresse geladener Systemmodule verweist doch dans allen Prozessen sur qui gleiche reale Speicheradresse. écrit on mais dans un geladenes Modul, volonté cet veränderten Bytes (genauer gesagte, qui gesammte Speicherseite, qui cet Bytes umgibt) à une autre reale Speicheradresse geschrieben, et qui virtuelle Adresse im Prozess verweist ensuite à cet Stelle (mapping). Pour cette sommes aussi qui Zugriffsrechte copy-on-write et copy-on-read.

un Prefix, qui mir dans Bezug sur cela Lecture des Kernelspeichers besonders auffällt, ist Zw. la fois voyons, si je avec cela weiterkomme (sans direct une Treiber trop écrivons).

Salut

Andreas

11.09.2006 ▲

Mmh...

comment je cela im Augenblick vois, doit je dans Ring 0 venons. cela peux je seulement, si je une Service, une Kernel Treiber, schreibe.
Mmmh....

une Service sur qui API trop installer ist oui encore droite simple - mais si je cela richtig verstanden habe, doit après une Callback-Funktion registriert volonté, qui laufend une Statusbericht gibt. Hat quelqu'un Ahnung de Services et comment cet Callback auszusehen hat? comment on une Service installiert, sais je. Hat quelqu'un intérêt, avec mir trop tüfteln?

Salut

Andreas

13.09.2006 ▲

là doit sowieso MASM her, je hab den impression, cela allez pas avec Profan. Werd mich dans den prochain Tagen seulement la fois um den Service kümmern.

et ensuite gibts là trop bon letzt encore cela Problem, comment on contact zum Desktop aufnimmt, um Ergebnisse Montrer trop laisser ou bien den Scanner trop servir - schwierig, schwierig...

16.09.2006 ▲

Tricolore la fois avec einem Treiber et ZwQueryVirtualMemory versucht => totaler insuccès. Zugriff sur Speicherbereiche au-dessus de de 2GB habe je dans einem Treiber, cela steht fest (getestet). je dois cela komplett autre Wege vais - hab déjà une concept, comment cela aller pourrait.

encore un paire Fragen:
comment oui c'est ca sieht qui Speicherbereich au-dessus de de 2GB dans einem Prozess aus? Sieht qui chez allen Prozessen juste aus? Verweisen alors qui virtuellen Adressen dans diesem Bereich toujours sur qui gleichen realen Speicheradressen, ou bien gibt es là Unterschiede?

Hat quelqu'un Ahnung ou bien Vorstellungen??

Salut

Andreas

29.11.2006 ▲

mon Thesen:
1

Treiber sommes dans alleProzesse gemappt et cet gemappten Adressen verweisen dans qui règle (siehe Windows98) sur qui gleichen realen Speicheradressen.
2.) Prozessspezifische Strukturen sommes seulement im jeweiligen Prozessspeicher pour trouver.

pourquoi denke je cela? il y a dedans qui Native API une spezielle Funktion zum magasin de Treibern, en Existenz je mir anders pas expliquer peux.

29.11.2006 ▲

Durchbruch! Habe aujourd'hui une Possibilité trouvé, auslesbare Adressen im Kernel trop bestimmen!

03.12.2006 ▲