| |
| |
|
| - Seite 1 - |
|
 | Hallo alle zusammen...
Innerhalb von Windows sind einige Zaubereien möglich, die normalerweise gar nicht funktionieren sollten. Eine davon ist die DLL Einschleusung in fremde Prozesse. Ich denke, das ich eine weitere Möglichkeit der DLL-Injektion auch mit Profan hinbekomme. Sollte man das hier posten??? |
|
| |
| |
| |
|
|
| |
| |
| - Seite 3 - |
|
Sebastian
König | Hallo Andreas,
[quote:e603eb83d3]Wie gesagt, wenn Subclassing von Fenstern fremder Prozesse ohne DLL Injektion auf neueren NT-basierenden Systemen wirklich funktionieren würde, würde mich das sehr erschrecken, denn es wäre für mich mit Sicherheit kein Problem innerhalb weniger Minuten ein Programm zu schreiben, was alle aktuellen Windowsversionen sicherheitstechnisch aushebelt (wie bei Shatter).[/quote:e603eb83d3]
abgesehen davon, dass der GetWindowLong()-Aufruf [und damit sicher auch SetWindowLong()] für das fremde Fenster erfreulicherweise fehlschlägt, gibt es ja zum Glück auch noch das prinzipielle Hindernis der getrennten Adressräume für verschiedene Prozesse (nicht nur unter WinNT/2000/XP sondern grundsätzlich seit Win95).
Aber weil Du so betonst, dass es Dir um NT-basierte Systeme geht: Funktioniert das Auslesen mit GetWindowLong() unter Win9x/ME tatsächlich?
MfG
Sebastian |
|
| |
| |
| |
|
|
| [quote:8a5d6faacd=Sebastian König]Hallo Andreas,
abgesehen davon, dass der GetWindowLong()-Aufruf [und damit sicher auch SetWindowLong()] für das fremde Fenster erfreulicherweise fehlschlägt,
[/quote:8a5d6faacd]
Ja, das ist wirklich erfreulich. SetWindowLong schlägt natürlich (zum Glück) auch fehl.
[quote:8a5d6faacd=Sebastian König]
gibt es ja zum Glück auch noch das prinzipielle Hindernis der getrennten Adressräume für verschiedene Prozesse (nicht nur unter WinNT/2000/XP sondern grundsätzlich seit Win95).
[/quote:8a5d6faacd]
Wenn es darum geht, Windows zu knacken, läßt sich das ohne Probleme umgehen - genauer gesagt, man kann das außer acht lassen. Das hatte der Autor der Shatter Attacke damals auch nicht gesehen - MS scheint das aber zum Glück noch erkannt zu haben. 
[quote:8a5d6faacd=Sebastian König]
Aber weil Du so betonst, dass es Dir um NT-basierte Systeme geht: Funktioniert das Auslesen mit GetWindowLong() unter Win9x/ME tatsächlich?
MfG
Sebastian[/quote:8a5d6faacd]
Definitiv ja! Da hier sowieso keine unterschiedlichen Rechte vorhanden sind, wurde das wohl außer acht gelassen. |
|
| |
| |
| |
|
|
| Ach ja - apopo außer acht lassen:
Als mein großer Bruder sein ABI nachgemacht hat, hat er sich gedacht, er kann Deutsch außer acht lassen - und ist dann teilweise gar nicht zu den Prüfungen erschienen  . Heute hat er einen Doktortitel in einem Informatikbereich.
Fazit: Wenn man bei allem, was man tut überlegt, was man ruhig unter den Tisch kehren kann, kommt man im Leben wesentlich weiter  ...
Beste Gruße
Andreas (der jetzt seine Katzen füttern geht) |
|
| |
| |
| |
|
|
| Ist nun doch in [...]  drin => Exportfunktionen in können nun in fremden Prozessen angesprochen werden, d.h. ich kann quasi von außen bestimmen, was in einem Prozess geschieht.
Einige Einschränkung:
Die Funktion darf nur einen Parameter haben.
Ausreichend Rechte müssen auf den jeweiligen Prozess vorhanden sein.
Wie geht das?
Wir starten zuerst Wordpad und danach [...] . Als nächstes schauen wird uns im ersten Thread von Wordpad die Fenster an, un merken uns das Hauptfensterhandle.
Danach klicken wir wieder aud den Wordpad Prozess und klicken mit der rechten Maustaste ins Treeview.
[...]
Nach dem Klick aud DLL einschleusen sehen wir das hier...
[...]
...und wählen mal wieder Franks ProSpeed.DLL aus , die danach unter dem Prozess von Wordpad wiederzufinden ist.
[...]
Jetzt wählen wir im Listview der Registrierkarte Objekt-Infos die Funktion Version aus und klicken danach mit der rechten Maustaste ins Listview.
[...]
Jetzt Funktion in fremdem Prozess ausführen anklicken.
Im dann erscheinenden Dialog ins Edit das Handle des Wordpad Fensters eingeben.
[...]
Danach Funktion ausführen anklicken. Das gibts als Ergebnis:
[...] |
 |
| |
| |
| |
|
|
 | | Nicht uninteressant zum Thema: [...] |
|
| |
| |
| |
|
|
| Hallo IF...
Gut gefunden, doch es geht einfacher und sicherer (in der Funktion) - man arbeitet ja nicht mehr mit Windows98 ...
Zur Speicheraufteilung entspricht das dem, was man mit [...] nachvollziehen kann. Insgesammt die beste Erklärung zu dem Thema, die ich bislang gesehen habe. |
|
| |
| |
| |
|
|
| Ich habs im Augenblick nur schnell überflogen, aber bei IFs Link ist mir ein Absatz doch etwas sauer aufgestoßen:
[quote:196bfa3cd0]
Dasselbe Verfahren, also Code in mehrere virtuelle Adressräume gleichzeitig einzublenden, wendet Windows bei DLLs an, die ja an mehrere Prozesse gleichzeitig gebunden sein können.
Denn das ist ja gerade einer der Vorzüge einer DLL: Man kann den von mehreren Anwendungen benötigten Code in DLLs bündeln und dann eben diesen Code nur einmal in den physischen Speicher laden, obwohl er von mehreren unabhängigen Prozessen verwendet wird. Dadurch kann immens Speicher gespart werden. Dies ist wohl einer der Gründe warum ein Großteil des Windowsbetriebssystems auf der DLL-Technik basiert.
[/quote:196bfa3cd0]
 Das bedeutet für mich: Windows lädt z.B. die NTDLL.DLL, und wenn ein anderer Prozess diese ebenfalls lädt,, zeigt der virtuelle Prozessspeicher an die gleiche reale RAM-Adresse. Aber ist das wirlich so? Auch das kann man mit TNT sehr einfach überprüfen:
1.) WORDPAD starten.
2.) Mit TNT ein Byte im virtuellen Prozessspeicher von WORDPAD ändern, das innerhalb des geladenen Moduls NTDLL.DLL liegt. Ist diese Änderung auch in andern Prozessen zu sehen? Wenn dem so wäre, wäre das die Katastrophe unter NT - und dem wird wohl (hoffentlich) nicht so sein. |
|
| |
| |
| |
|
| |
| |
| - Seite 4 - |
|
|
Michael
Wodrich | DLLs:
das gleiche Codesegment, eigene Datensegmente.
Du bekommst also den Text des anderen Prozesses nicht zu sehen.
Eine DLL kann auch ein Datensegment enthalten, aber: diese Vorgabe-Daten werden kopiert und die variablen Datenbereiche, da hat jeder Prozess seinen eigenen Topf.
Oder versuchst Du in den Code-Bereich zu schreiben???
Der sollte eigentlich ReadOnly sein, sonst ists Essig mit der Sicherheit. |
|
| |
| Programmieren, das spannendste Detektivspiel der Welt. | 08.09.2006 ▲ |
|
| |
|
|
| | Ja, in den Codebereich meine ich. Readonely kann man mit [...] ändern (schon getan). Ist das Byte in jedem Prozess vorhanden? |
|
| |
| |
| |
|
|
| | DLLs zu patchen, nachdem sie geladen wurden, ist kein Problem. Würde ich eine DLL in meinem Bereich patchen und ein Zeiger eines anderen Prozesses würde auf den gleichen Codebereich zeigen, würde auch der Code im anderen Prozess geändert werden. Ist das wirklich so? Ich denke nicht. |
|
| |
| |
| |
|
|
| | ...wie gesagt, es ist kein Problem, das mit [...] zu testen - genau dafür wurde das Programm geschrieben. Da ich im Augenblick auf einem anderen OS festsitze gibts die Testergebnisse erst morgen. |
|
| |
| |
| |
|
|
| Hallo Michael...
Auch hier gilt natürlich: Windows ist nicht gleich Windows, und das was hier steht, ist unter NT-basierenden Systemen so:
So, dann mal los.
Als erstes starten wir mal WordPad und dann [...] . Nach dem Auswählen des WordPad Prozesses klicken wir dann auf die von WordPad geladene NTDLL.DLL. Die Funktion CsrAllocateCaptureBuffer hat bei mir die Adresse 2005459760 (hexadezimal $7788E330). An dieser Adresse müßte also auf jeden Fall Code stehen und kein Datensegment sein.
[...]
Wer Zweifel hat, kann mit DASM32 disassemblen und erhält dann das:
[...]
Mittels Recchtsklick auf WordPad.exe in [...] können wir uns nun den Speicher an dieser Stelle anzeigen lassen.
[...]
Wir wählen als hexadezimale Bytefolge und lesen ein Byte aus.
[...]
Bei mir kommt da 8B heraus.
Nun wieder Rechtsklick auf WordPad.exe und diesmal Speicherbereich ändern wählen.
Beim neuen Inhalt geben wir jetzt zum Spaß mal AB ein und klicken dann auf Speicherbereich ändern.
Lesen wir jetzt die besagte Adresse aus, sehen wir, das dort auch wirklich AB drin steht.
Nun klicken wir auf einen anderen Prozess und lassen uns dort die gleiche Adresse auslesen:
Da steht immer noch 8B, aber nicht AB.
Fazit => kein Pointer auf eine gemeinsame reale Adresse im Speicher, was zu beweisen war.
Auch den Schutz der Seiten in denen Code steht kann man mit [...] sehr einfach ermitteln. Einfach nach dem Rechtsklick Infos über Adresse auslesen anklicken und im Edit die Codeadresse eingeben.
Wie gesagt: Schreibschutz kann man (in bestimmtem Rahmen) per API ändern .
Da nicht alles in einen Topf geschmissen wird und im RAM auf der selben Adresse landet, ist es auch nicht Essig mit der Sicherheit. Zwar kann man Quellcode von DLLs ohne Probleme ändern, aber nur für den eigenen Prozess. Microsoft achtet (in der Regel) sehr gut darauf, das Sicherheitsabfragen immer Empfängerseitig gelöst werden - wenn ich ausgeschlafen habe, kommt ein Beispiel mit Quelltext zum Shatter Bugfix - aber in einem anderen Thread.
So, und nun warte ich auf jemanden, der mit eigenen Test meine Aussagen widerlegt. |
|
| |
| |
| |
|
(1.098)
Deutsch
English
Français
Español
Italia
