XProfan

- Seite 1 -

Michael
Wodrich

Keine Ahnung ob das schon alles war oder nur der Teil innerhalb des Text-Tutorials. Aber dies ist alles was ich wiederfand - Sorry:

[quote: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 an 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 an
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 DLLs 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 in 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 in memory, for instance, the operative system loads files like
kernel32.dll using this feature.
[/quote:9033556722]
Quelle: mmf.txt (irgendwo aus dem Iczelion-Universum)

Schöne Grüße
Michael Wodrich

Programmieren, das spannendste Detektivspiel der Welt.

07.09.2006 ▲

Hallo Michael...

Nur kurz überflogen:
In dem Artikel geht es um Windows95/98 => das läuft unter NT etwas anders. Unter Windows95/98 kann man 3GB ansprechen, unter NT nur 2GB. Die DLLs sind unter NT in den Speicherbereich von ca 1GB bis 2GB gemappt. Das auf Adressen von 0xC0000000 bis 0xFFFFFFFF ebenfalls von allen Prozessen aus zugegriffen werden kann, halte ich erst mal für ein Gerücht

(siehe TNT). Lies mal dort Infos über die Adresse -16 unter Windows98 aus

. Das die Adressen aber auf die gleichen realen Speicherbereiche verweisen, habe ich selbst schon vermutet.
Unter Windows95/98 muß kein Speicher für Zugriffsrechte Sicherheitsbeschreibungen oder den Token bereitgestellt werden - solche Sachen kennt nur NT - deshalb ist hier der nicht zugängliche Speicherbereich auch wesentlich kleiner.

@IF:
Kompilieren Markieren Separieren

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

Die Zahl des Handles ist abhängig davon, wann man das Handle öffnet. Zwischen den einzelnen Handles besteht ein Abstand von 4 - scheinen sich also, ähnlich wie beim Speicher, Adressen dahinter zu verbergen. Mit Teilen läßt sich da leider nichts berechnen, denn die Zahl des Handles sagt nichts darüber aus, ob es gültig ist oder nicht. Das einzige, was man vielleicht aus der Zahl des Handles ersehen könnte, wäre die Art des Handle.

Anders sieht das mit der ID des Prozesses aus:

Die ID des Prozesses System liegt immer bei 8. Der Nächste Prozess legt dann wieder bei über 100 los.
Beim Disassemblen der Funktionen, die mit dem System-Handle fehl schlagen, konnte ich aber nirgendwo eine 8 entdecken

. Vielleicht ist da in Bezug auf die ID eine Kleiner-als-Abfrage mit einem Sprung enthalten?

PS: Das Handle des Prozesses System bekommst du erst, wenn du den Quelltext als Service mit Systemrechten startest.

...ich hab mir die von System geladenen Module nochmals mit TNT angesehen:
System läd WIN32K.SYS und die NTDLL.DLL, aber nicht die KERNEL32.DLL.
Das kann eigentlich nur bedeuten, das WIN32K.SYS den Kernelspeicher selbst ausliest - oder, was für mich erst einmal wahrscheinlicher ist, undokumentierte Funktionen aus der NTDLL.DLL dafür nutzt.

Jac
de
Lad

Ich hatte mal gehört, dass Windows 98 ur 512 MB Hauptspeicher verwalten kann, aber diese Information ist jetzt 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

Hallo Jacob...

Es geht um den virtuellen Prozessspeicher, nicht um den realen Speicher. Jeder Prozess verwaltet einen ´virtuellen Prozessspeicher von ca.4GB. Diesen virtuellen Prozesspeicher muß du dir wie eine Art Landkarte vorstellen, bei der jede Adresse einer realen Adresse im RAM oder in der Auslagerungsdatei zugeordnet werden kann. Kann heißt, nicht jede Adresse muß unbedingt RAM zugeordnet sein, sondern Adressen können auch unbelegt sein. Die unteren 2GB dieses Speichers kann der User verwalten und beschreiben /bei nicht NT basierten Systemen die unteren 3GB), der Rest ist für die Nutzung des Betriebsystems reserviert. Ich hoffe, ich habe etwas Klarheit in die Sache gebracht.

Meine Überlegung: Wenn es gelänge, durch Patching von Betriebsystem DLLs im Speicher des eigenen Prozesse ein gültiges Handle auf den System Prozess zu erlangen um DLLs dort zu injizieren, könnte man evtl. auch Zugriff auf Speicherbereiche erhalten, die eigentlich nur das OS nutzen kann und mann könnte quasi Windows die Unterwäsche ausziehen um einen Blick auf nackte Tatsachen zu erlangen...

Jac
de
Lad

Hallo Andreas,

danke für die Ausführung. Jaja, ich weiß was virtueller Speicher ist, aber ich dachte es geht hier um physikalischen Speicher. Dazu habe ich aber nix zu 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

- Seite 2 -

An einigen Stellen habe ich in diesem Thread weil ich es bislang nicht besser wußte etwas Mist verzapft:

Im Prozess System befinden sich unter Windows2000 die Module WIN32K.SYS, HAL.DLL und NTOS und Ntoskrnl.exe, aber nicht die NTDLL.DLL.
Die Ntoskrnl.exe entspricht in vielen Teilen der NTDLL.DLL, und gibt sich auch im Header scheinbar als diese aus.

Die virtuelle Adresse geladener Systemmodule verweist doch in allen Prozessen auf die gleiche reale Speicheradresse. Schreibt man aber in ein geladenes Modul, werden diese veränderten Bytes (genauer gesagte, die gesammte Speicherseite, die diese Bytes umgibt) an eine andere reale Speicheradresse geschrieben, und die virtuelle Adresse im Prozess verweist dann an diese Stelle (mapping). Dafür sind auch die Zugriffsrechte copy-on-write und copy-on-read.

Ein Prefix, der mir in Bezug auf das Auslesen des Kernelspeichers besonders auffällt, ist Zw. Mal sehen, ob ich damit weiterkomme (ohne direkt einen Treiber zu schreiben).

Gruß

Andreas

11.09.2006 ▲

Mmh...

Wie ich das im Augenblick sehe, muß ich in Ring 0 kommen. Das kann ich nur, wenn ich einen Service, einen Kernel Treiber, schreibe.
Mmmh....

einen Service über die API zu installieren ist ja noch recht einfach - aber wenn ich das richtig verstanden habe, muß danach eine Callback-Funktion registriert werden, die laufend einen Statusbericht gibt. Hat jemand Ahnung von Services und wie diese Callback auszusehen hat? Wie man einen Service installiert, weiß ich. Hat jemand interesse, mit mir zu tüfteln?

Gruß

Andreas

13.09.2006 ▲

Da muß sowieso MASM her, ich hab den Eindruck, das geht nicht mit Profan. Werd mich in den nächsten Tagen erst mal um den Service kümmern.

Und dann gibts da zu guter letzt noch das Problem, wie man Kontakt zum Desktop aufnimmt, um Ergebnisse anzeigen zu lassen oder den Scanner zu bedienen - schwierig, schwierig...

16.09.2006 ▲

Habs mal mit einem Treiber und ZwQueryVirtualMemory versucht => totaler Fehlschlag. Zugriff auf Speicherbereiche oberhalb von 2GB habe ich in einem Treiber, das steht fest (getestet). Ich muß das komplett andere Wege gehe - hab schon eine Idee, wie das gehen könnte.

Noch ein paar Fragen:
Wie genau sieht der Speicherbereich oberhalb von 2GB in einem Prozess aus? Sieht der bei allen Prozessen gleich aus? Verweisen also die virtuellen Adressen in diesem Bereich immer auf die gleichen realen Speicheradressen, oder gibt es da Unterschiede?

Hat jemand Ahnung oder Vorstellungen??

Gruß

Andreas

29.11.2006 ▲

Meine Thesen:
1

Treiber sind in alleProzesse gemappt und diese gemappten Adressen verweisen in der Regel (siehe Windows98) auf die gleichen realen Speicheradressen.
2.) Prozessspezifische Strukturen sind nur im jeweiligen Prozessspeicher zu finden.

Warum denke ich das? Es gibt innerhalb der Native API eine spezielle Funktion zum Laden von Treibern, deren Existenz ich mir anders nicht erklären kann.

29.11.2006 ▲

Durchbruch! Habe heute eine Möglichkeit gefunden, auslesbare Adressen im Kernel zu bestimmen!

03.12.2006 ▲