| |
| |
|
 | ¡Hola Personas...
Der virtuelle Speicher cada Prozesses es en zwei Teile unterteilt:
Ein Zona a ca. 2GB, el para el User einseh y auslesbar es y una Zona oberhalb de 2GB, en el Estructuras des Kernels gespeichert voluntad (como wohl z.B. el Access-Token). Mein größter Wunsch es irgendwann y irgendwie una vez el Kernelspeicher lesen a puede,
Puedo con mi Prozess (z.B. con [...]  ) el Kernelspeicher no auslesen - pero yo denke, irgendein Prozess (oder una Teil su) se dies wohl puede. Der Prozess Sistema me está diesbezüglich algo en el Auge gefallen - no sólo des Namens wegen, pero auch wegen otro Geschichten:
Yo habe zwar el ID des Prozesses y kann una Handle con allen möglichen Zugriffsrecchten abierto, aber sólo una Teil el APIs funktioniert auch wirklich con diesem Handle. Das Auslesen de Modulen z.B. klappt no y el einschleusen uno DLL mittels [...] auch no, obwohl Yo una Handle en Sistema con el erforderlichen Zugriffsrechten abierto kann.
[box:176c01f1f3]
Kann Sistema el Kernelspeicher lesen?
Was podría genau verursachen, el einzelne APIs no con diesem Handle trabajo? Liegt el a eingebauten Abfragen en el Prozess-ID (oder ähnlichem) innerhalb el APIs, oder liegt lo tal vez incluso a el Handle incluso?
[/box:176c01f1f3]
Was denkt ihr? Git lo irgendwo Infos? Alles Yo bislang gefunden habe, es NT bezogen y wohl veraltet. |
|
| |
| |
| |
|
|
| Aaaaaaaaaaaah  ...
Yo habe me con [...]  veces el Process Sistema algo näher angesehen:
Wenn MS verhinder möchte, el así una Schwachkopf Yo a el de Sistema geladenen Module kommt, debería entonces wohl mejor auch el Editar y Auslesen des Prozessspeichers de Sistema verboten voluntad   .
In Sistema se en me bajo Windows2000 a Adresse 2005401600 (Yo voluntad hoffen, Yo mich no versehen  ) el Expediente WIN32K.SYS geladen. Diese Expediente es laut Internetquellen el Modul, el el Auslesen de Speicherbereichen oberhalb de 2GB ermöglicht. WIN32K.SYS dürfte wohl para Windows 32 Kernel posición y el Prozesserzeugende Modul de Sistema ser. Demnach es ahora wohl sicher, el Sistema como einziger Prozess Speicher oberhalb de 2GB auslesen y beschreiben kann. Weitere Module, el en esta Prozess geladen voluntad, dürften KERNEL32.DLL y NTDLL.DLL ser - es aber todavía no genau getestet.
Como se ejecuta el Mechanik de, el verhindert una gültiges Handle en Sistema a bekommen? Sombrero alguien una Erklärung? |
|
| |
| |
| |
|
|
 | | Tal vez encima una Teilungsrest? |
|
| |
| |
| |
|
|
| | Como media Si es usted el? Wenn du como irgendeine Concepto hast (egal si abwegig o no) Teils me Por favor, con - Yo brauche Ideen. |
|
| |
| |
| |
|
|
| Naja viele Möglichkeiten gibts sí no. Grunsätzlich restos sí sólo a) el Liste y b) el Función.
Como hier Performance gefragt es tippe I Función. Und hierbei bietet lo doch a el si el Handle por X restbehaftet teilbar es (k)una Syshandle es. El Cuestión hierbei es natürlich después de el X. |
|
| |
| |
| |
|
|
Michael
Wodrich | Auf el Iczelion-Páginas Tuve algo a MMF MemoryMappedFiles gefunden.
Dort wurde el Speicherbereich genau beschrieben, qué alles unterhalb de 4GB liegt y qué darüber - y Grund por qué MMF sólo max 4 GB (oder waren lo 2) beschreiben kann.
Hatte mich erstaunt, qué como alles angesprochen wurde ( el Guru war porque auch una Techniker en MS-Diensten).
Yo grabe veces, tal vez ha el Teil sí el Weg en mi Platte gefunden...
Schöne Grüße
Michael Wodrich |
|
| |
| Programmieren, das spannendste Detektivspiel der Welt. | 07.09.2006 ▲ |
|
| |
|
|
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:
KompilierenMarcaSeparaciónDef @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 | 08.09.2006 ▲ |
|
| |
|
|
| ¡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 | 08.09.2006 ▲ |
|
| |
|
(767)
Deutsch
English
Français
Español
Italia