| |
| |
|
 | Hallo Leute...
Der virtuelle Speicher jedes Prozesses ist in zwei Teile unterteilt:
Ein Bereich bis ca. 2GB, der für den User einseh und auslesbar ist und ein Bereich oberhalb von 2GB, in den Strukturen des Kernels gespeichert werden (wie wohl z.B. der Access-Token). Mein größter Wunsch ist es irgendwann und irgendwie einmal den Kernelspeicher lesen zu können,
Ich kann mit meinem Prozess (z.B. mit [...]  ) den Kernelspeicher nicht auslesen - aber ich denke, irgendein Prozess (oder ein Teil davon) wird dies wohl können. Der Prozess System ist mir diesbezüglich etwas ins Auge gefallen - nicht nur des Namens wegen, sondern auch wegen anderer Geschichten:
Ich habe zwar die ID des Prozesses und kann ein Handle mit allen möglichen Zugriffsrecchten öffnen, aber nur ein Teil der APIs funktioniert auch wirklich mit diesem Handle. Das Auslesen von Modulen z.B. klappt nicht und das einschleusen einer DLL mittels [...] auch nicht, obwohl ich ein Handle auf System mit den erforderlichen Zugriffsrechten öffnen kann.
[box:176c01f1f3]
Kann System den Kernelspeicher lesen?
Was könnte genau verursachen, das einzelne APIs nicht mit diesem Handle funktionieren? Liegt das an eingebauten Abfragen auf die Prozess-ID (oder ähnlichem) innerhalb der APIs, oder liegt es vielleicht sogar an dem Handle selbst?
[/box:176c01f1f3]
Was denkt ihr? Git es irgendwo Infos? Alles was ich bislang gefunden habe, ist NT bezogen und wohl veraltet. |
|
| |
| |
| |
|
|
| Aaaaaaaaaaaah  ...
Ich habe mir mit [...]  mal den Process System etwas näher angesehen:
Wenn MS verhinder möchte, das so ein Schwachkopf wie ich an die von System geladenen Module kommt, sollte dann wohl besser auch das Bearbeiten und Auslesen des Prozessspeichers von System verboten werden   .
In System wird bei mir unter Windows2000 an Adresse 2005401600 (ich will hoffen, ich habe mich nicht versehen  ) die Datei WIN32K.SYS geladen. Diese Datei ist laut Internetquellen das Modul, das das Auslesen von Speicherbereichen oberhalb von 2GB ermöglicht. WIN32K.SYS dürfte wohl für Windows 32 Kernel stehen und das Prozesserzeugende Modul von System sein. Demnach ist es jetzt wohl sicher, das System als einziger Prozess Speicher oberhalb von 2GB auslesen und beschreiben kann. Weitere Module, die in diesen Prozess geladen werden, dürften KERNEL32.DLL und NTDLL.DLL sein - ist aber noch nicht genau getestet.
Wie läuft die Mechanik ab, die verhindert ein gültiges Handle auf System zu bekommen? Hat jemand eine Erklärung? |
|
| |
| |
| |
|
|
 | | Vielleicht über einen Teilungsrest? |
|
| |
| |
| |
|
|
| | Wie meinst du das? Wenn du da irgendeine Idee hast (egal ob es abwegig ist oder nicht) Teils mir bitte mit - ich brauche Ideen. |
|
| |
| |
| |
|
|
| Naja viele Möglichkeiten gibts ja nicht. Grunsätzlich bleibt ja nur a) die Liste und b) die Funktion.
Da hier Performance gefragt ist tippe ich auf Funktion. Und hierbei bietet es sich doch an das wenn das Handle durch X restbehaftet teilbar ist es (k)ein Syshandle ist. Die Frage hierbei ist natürlich nach dem X. |
|
| |
| |
| |
|
|
Michael
Wodrich | Auf den Iczelion-Seiten hatte ich etwas zu MMF MemoryMappedFiles gefunden.
Dort wurde der Speicherbereich genau beschrieben, was alles unterhalb von 4GB liegt und was darüber - und der Grund warum MMF nur max 4 GB (oder waren es 2) beschreiben kann.
Hatte mich erstaunt, was da alles angesprochen wurde ( der Guru war denn auch ein Techniker in MS-Diensten).
Ich grabe mal, vielleicht hat das Teil ja den Weg auf meine Platte gefunden...
Schöne Grüße
Michael Wodrich |
|
| |
| Programmieren, das spannendste Detektivspiel der Welt. | 07.09.2006 ▲ |
|
| |
|
|
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:
KompilierenMarkierenSeparierenDef @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 | 08.09.2006 ▲ |
|
| |
|
|
| 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 | 08.09.2006 ▲ |
|
| |
|
(766)
Deutsch
English
Français
Español
Italia