XProfan

- Seite 3 -

Frank
Abbing

Die verwendet auch nur GDI...

Nochmals zum Subclassing => bereits GetWindowLong für die Fensterprozedur lief damals bei mir ins leere. Hatte dafür folgende Erklärung:
Wäre es möglich, Fenster fremder Anwendungen ohne weiteres zu subclassen, könnte man per Message direkt eine beliebige API-Funktion oder Adresse anspringen und, ähnlich wie bei der Shatter Attacke, das Sicherheitssystem ausschalten um erweiterte Privilegien zu erhalten. Allein aus diesem Grund dürfte ein Subclassing fremder Fenster eigentlich nicht funktionieren...

Frank
Abbing

Klingt absolut logisch. Und wird wohl so sein.

Sebastian
König

[quote:4e9eea8f3c]Nochmals zum Subclassing => bereits GetWindowLong für die Fensterprozedur lief damals bei mir ins leere. Hatte dafür folgende Erklärung:[/quote:4e9eea8f3c]
Hallo Andreas,

was genau hattest Du denn versucht? Einfach mit SetWindowLong() die Fenster-Prozedur eines fremden Fensters auf eine XProfan-CallBack-Funktion [via ProcAddr()] zu setzen? Oder hattest Du schon eine Funktions-Adresse innerhalb des fremden Prozesses durch DLL-Injection zur Verfügung?

MfG

Sebastian

Windows XP, XProfan/Profan² 4.5 bis 11
Profan2Cpp-Homepage: [...]

Alte Profan²-Seite: [...]

Hallo Sebastian...

Vorneweg => es geht hier um NT-basierende Systeme, also um 2000 und XP vor allem, getestet habe ich mit Windows2000 Servicepack 2:
Kompilieren Markieren Separieren

Def @GetWindowLong(2) !"USER32","GetWindowLongA"
Def @GetWindowThreadProcessId(2) !"USER32","GetWindowThreadProcessId"
DEF @GetDlgCtrlID(1) !"USER32","GetDlgCtrlID"
DEF @ButtonClicked(1) @GetDlgCtrlID(@&(1))=-%MENUITEM
DEF @AHFormatMessage(7) !"KERNEL32","FormatMessageA"
Def @GetCurrentProcessID(0) !"KERNEL32","GetCurrentProcessId"
Def @GetCurrentThreadId(0) !"KERNEL32","GetCurrentThreadId"
Def @GetLastError(0) !"KERNEL32","GetLastError"
Def @SetLastError(1) !"KERNEL32","SetLastError"
Declare AHRückgabe&,AHGETERROR_Buffer#,AHGETERROR_Buffer$
Declare Button&,Fenstertitel$,Fensterhandle&,Prozess_ID&,Thread_ID&,Prozeduradresse&
Windowstyle 31
Window 0,0-640,440
Windowtitle "Fensterprozedur ermitteln"
Let Button&=@Create("Button",%HWND,"Fenster auslesen",100,10,300,30)

While 0=0

    Waitinput

    IF @ButtonClicked(Button&)

        Clearlist
        ADDWINDOWS ""
        LET Fenstertitel$=@LIstBox$("Fenstertitel (biite ein Fenster auswählen):",3)

        IF Fenstertitel$<>""

            LET Fensterhandle&=@FindWindow(Fenstertitel$)
            LET Thread_ID&=@GetWindowThreadProcessId(Fensterhandle&,@ADDR(Prozess_ID&))
            @SetLastError(0)
            LET Prozeduradresse&=@GetWindowLong(Fensterhandle&,$FFFFFFFC)
            Let AHRückgabe&=@GetLastError()
            Fehlercode_bestimmen
            CLS
            Locate 5,0
            Print "Name des Fensters: "+Fenstertitel$
            Print "Handle des Fensters: "+@STR$(Fensterhandle&)
            Print "Ausgelesene Adresse der Fensterprozedur: "+@STR$(Prozeduradresse&)
            Print "Letzter API Fehler: "+@STR$(AHRückgabe&)
            Print "API Meldung: "+AHGETERROR_Buffer$
            Print "ID des erzeugenden Prozesses: "+@STR$(Prozess_ID&)
            Print "ID meines Prozesses: "+@STR$(@int(@GetCurrentProcessID()))
            Print "ID des erzeugenden Threads: "+@STR$(Thread_ID&)
            Print "ID meines Threads: "+@STR$(@int(@GetCurrentThreadID()))

        endif

    endif

Wend

Proc Fehlercode_bestimmen

    DIM AHGETERROR_Buffer#,32000
    @AHFormatMessage($1000,0,AHRückgabe&,0,AHGETERROR_Buffer#,32000,0) Wandelt Fehlercode in Landesspezifische Message um.
    Let AHGETERROR_Buffer$=@STRING$(AHGETERROR_Buffer#,0)
    Dispose AHGETERROR_Buffer#

Endproc

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).

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

Windows XP, XProfan/Profan² 4.5 bis 11
Profan2Cpp-Homepage: [...]

Alte Profan²-Seite: [...]

[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:
[...]

Bild1.jpg

107 kB

Kurzbeschreibung:

BILD 1

Hochgeladen:

04.09.2006

Bild2.jpg

78 kB

Kurzbeschreibung:

BILD 2

Hochgeladen:

04.09.2006

Bild3.jpg

98 kB

Kurzbeschreibung:

BILD 3

Hochgeladen:

04.09.2006

Bild4.jpg

98 kB

Kurzbeschreibung:

BILD 4

Hochgeladen:

04.09.2006

Bild5.jpg

74 kB

Kurzbeschreibung:

BILD 5

Hochgeladen:

04.09.2006

Bild6.jpg

55 kB

Kurzbeschreibung:

BILD 6

Hochgeladen:

04.09.2006

04.09.2006 ▲

Nicht uninteressant zum Thema: [...]

08.09.2006 ▲

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.

08.09.2006 ▲

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.

08.09.2006 ▲