XProfan

- Página 1 -

Michael
Wodrich

Keine Idea si el ya alles war oder sólo el Teil innerhalb des Texto-Tutoriales. Aber dies es alles Yo wiederfand - Sorry:

[quote:9033556722]
Win95/98 Virtual Address Espacio 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 a exception if a read/write attempt occurs.

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

From 0x00400000 to 0x7FFFFFFF. This 2 GB partition is the private address
space assigned to every running process. Each win32 application receives a
unshared, private 2 GB chunk of virtual address space (dont forget to
subtract the 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 from now on) judiciously commits and maps physical storage
the every process virtual address space according to its growing necessities.

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

From 0xC0000000 to 0xFFFFFFFF. This partition is also 1 GB long; here is
where the operative system code resides. Unfortunately, this area is also
accessible to all 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 the subject of this
tutorial.

Managing memory under win98 can be 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 en memory, mainly files like EXE, DLL (which explains the name of
this method), to be more accurate, both the user and the operative system
can map files en memory, for instance, the operative system loads files like
kernel32.dll using this feature.
[/quote:9033556722]
Quelle: mmf.txt (irgendwo de el Iczelion-Universum)

Schöne Grüße
Michael Wodrich

Programmieren, das spannendste Detektivspiel der Welt.

07.09.2006 ▲

¡Hola Michael...

Nur kurz sobrevolados:
In el Artikel es en Windows95/98 => el se ejecuta bajo NT algo anders. Bajo Windows95/98 puede ser 3GB ansprechen, bajo NT sólo 2GB. El DLL son bajo NT en el Speicherbereich de ca 1GB a 2GB gemappt. Das en Adressen de 0xC0000000 a 0xFFFFFFFF ebenfalls de allen Prozessen de zugegriffen voluntad kann, halte Yo sólo veces para una Gerücht

(siehe TNT). Lies veces hay Infos en Adresse -16 bajo Windows98 de

. Das el Adressen aber en el gleichen realen Speicherbereiche verweisen, Yo incluso ya vermutet.
Bajo Windows95/98 muß kein Speicher para Zugriffsrechte Sicherheitsbeschreibungen oder el Token previsto voluntad - solche Sachen sabe sólo NT - deshalb es hier el no zugängliche Speicherbereich auch wesentlich kleiner.

@IF:
Kompilieren Marca Separación

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

El Zahl des Handles es abhängig su, wann al Handle öffnet. Zwischen el individual Handles besteht una Abstand de 4 - scheinen se also, ähnlich como beim Speicher, Adressen detrás de él a verbergen. Mit Teilen läßt se como desafortunadamente nichts berechnen, porque el Zahl des Handles sagt nichts darüber de, si gültig o no. Das einzige, qué tal vez de el Zahl des Handles ersehen podría, wäre el Art des Handle.

Anders sieht el con el ID des Prozesses de:

El ID des Prozesses Sistema liegt siempre en 8. Der Nächste Prozess legt entonces otra vez en encima 100 los.
Beim Disassemblen el Características, el con el Sistema-Handle fehl schlagen, podría Yo aber nirgendwo una 8 entdecken

. Tal vez como en Bezug en el ID una Kleiner-como-Abfrage con un Sprung enthalten?

PS: Das Handle des Prozesses Sistema bekommst du sólo, si du el Ver código fuente como Service con Systemrechten startest.

...Yo tener me el de Sistema geladenen Module nochmals con TNT angesehen:
Sistema läd WIN32K.SYS y el NTDLL.DLL, aber no el KERNEL32.DLL.
Das kann eigentlich sólo bedeuten, el WIN32K.SYS el Kernelspeicher incluso ausliest - oder, qué para mich sólo una vez wahrscheinlicher es, undokumentierte Características de el NTDLL.DLL dafür nutzt.

Jac
de
Lad

Tuve veces gehört, dass Windows 98 ur 512 MB Hauptspeicher verwalten kann, aber esta Information es ahora offenbar ü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

¡Hola Jacob...

Lo va en el virtuellen Prozessspeicher, no en el realen Speicher. Jeder Prozess verwaltet una ´virtuellen Prozessspeicher de ca.4GB. Diesen virtuellen Prozesspeicher muß du dir como una Art Landkarte vorstellen, en jede Adresse uno realen Adresse en el RAM oder en el Auslagerungsdatei zugeordnet voluntad kann. Kann heißt, no jede Adresse muß necesariamente RAM zugeordnet ser, pero Adressen puede auch unbelegt ser. El unteren 2GB dieses Speichers kann el User verwalten y beschreiben /en no NT basierten Systemen el unteren 3GB), el Rest es para el Nutzung des Betriebsystems reserviert. Yo hoffe, Yo algo Klarheit en el Sache gebracht.

Mi Überlegung: Wenn lo gelänge, por Patching de Betriebsystem DLL en el Speicher des eigenen Prozesse una gültiges Handle en el Sistema Prozess a erlangen en DLL hay a injizieren, podría uno evtl. auch Zugriff en Speicherbereiche obtener, el eigentlich sólo el OS nutzen kann y mann podría quasi Windows el Unterwäsche ausziehen en una Blick en nackte Tatsachen a erlangen...

Jac
de
Lad

¡Hola Andreas,

danke para el Ausführung. Jaja, Yo weiß qué virtueller Speicher es, pero yo pensamiento lo va hier en physikalischen Speicher. Dazu Yo aber nix a sagen.

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

- Página 2 -

An algunos Stellen Yo en diesem Hilo porque Yo bislang no mejor wußte algo Mist verzapft:

Im Prozess Sistema befinden se bajo Windows2000 el Module WIN32K.SYS, HAL.DLL y NTOS y Ntoskrnl.exe, aber no el NTDLL.DLL.
El Ntoskrnl.exe entspricht en vielen Teilen el NTDLL.DLL, y son se auch en el Encabezamiento scheinbar como esta de.

El virtuelle Adresse geladener Systemmodule verweist doch en allen Prozessen en el gleiche reale Speicheradresse. Escribe uno aber en una geladenes Modul, voluntad esta veränderten Bytes (genauer gesagte, el gesammte Speicherseite, el esta Bytes umgibt) a una otro reale Speicheradresse geschrieben, y el virtuelle Adresse en el Prozess verweist entonces a esta Punto (mapping). Dafür son auch el Zugriffsrechte copy-on-write y copy-on-read.

Ein Prefix, el me en Bezug el Auslesen des Kernelspeichers besonders auffällt, es Zw. Tiempo sehen, si Yo así weiterkomme (sin direkt una Treiber a escribir).

Saludo

Andreas

11.09.2006 ▲

Mmh...

Como Yo el en el Augenblick sehe, muß Yo en Ring 0 kommen. Das kann Yo sólo, si yo una Service, una Kernel Treiber, escribir.
Mmmh....

una Service en API a installieren es sí todavía bastante simplemente - pero si Yo el correcto verstanden habe, muß danach una Callback-Función registriert voluntad, el laufend una Statusbericht son. Sombrero alguien Idea de Services y cómo esta Callback auszusehen ha? Como uno una Service installiert, weiß Yo. Sombrero alguien interesse, con me a tüfteln?

Saludo

Andreas

13.09.2006 ▲

Como muß sowieso MASM her, Yo tener el Eindruck, el va no con Profano. Werd mich en el nächsten Tagen sólo veces en el Service kümmern.

Und entonces gibts como a guter letzt todavía el problema, cómo Kontakt para Desktop aufnimmt, en Ergebnisse Mostrar que se oder el Scanner a bedienen - schwierig, schwierig...

16.09.2006 ▲

Habs veces con un Treiber y ZwQueryVirtualMemory intenta => totaler Fehlschlag. Zugriff en Speicherbereiche oberhalb de 2GB Yo en un Treiber, el es fest (getestet). Yo muß el komplett otro Wege gehe - tener ya una Concepto, como el ir podría.

Noch unos pocos Fragen:
Como genau sieht el Speicherbereich oberhalb de 2GB en un Prozess de? Sieht el en allen Prozessen igual de? Verweisen Así que el virtuellen Adressen en diesem Zona siempre en el gleichen realen Speicheradressen, oder hay como Unterschiede?

Sombrero alguien Idea oder Vorstellungen??

Saludo

Andreas

29.11.2006 ▲

Mi Thesen:
1

Treiber son en alleProzesse gemappt y esta gemappten Adressen verweisen en el Regel (siehe Windows98) en el gleichen realen Speicheradressen.
2.) Prozessspezifische Estructuras son sólo en el jeweiligen Prozessspeicher para encontrar.

¿Por qué denke Yo el? Lo son innerhalb el Nativo API una spezielle Función para Laden de Treibern, deren Existenz Yo anders no erklären kann.

29.11.2006 ▲

Durchbruch! Posesiones heute una Möglichkeit gefunden, auslesbare Adressen en el Kernel a bestimmen!

03.12.2006 ▲