| |
| |
|
| - Página 1 - |
|
 | ¡Hola Profaner..
Sombrero veces alguien Lust a testen, si [...]  bajo XP generell gefixt es?
- Einen Service a programieren es dafür no necesariamente nötig, normales Programa con RUN AS (auch con PrivAktivate posible) como Admin starten y el Angreiferprogramm en un Account con eingeschränkten Rechten ausführen.
- In el Hauptprogramm una Temporizador einfügen (muß natürlich una Ventana haben).
- Im Angreiferprogramm una Procedimiento escribir, el una Messagebox ausgibt, el Proc pero no ausführen dejar.
- Mit ProcAddr el Adresse el Procedimiento ermitteln.
- Mit PostMessage (oder tal vez SendMessage) WM_TIMER con el Adresse el Procedimiento vom Angreiferprogramm a el Hauptprogramm senden.
Klapp el???
 |
|
| |
| |
| |
|
| |
| |
| - Página 2 - |
|
|
Frank
Abbing | ¡Hola,
el Adresse kann eigentlich no virtuelle Adresse ser, porque ellos direkt angesprungen voluntad kann. Puedo el Prozedure auch direkt en media Code setzten y starten.
Yo vermute más, dass Windows testet, si el Speicher, el ausgeführt voluntad se, para Programa gehört. Also de Programa belegt wurde.
Lo son wohl una Vielzahl a Möglichkeiten, otro Task una Adresse mitzuteilen. El einfachste es sicherlich encima el Userspeicher uno Fensters (GWL_USERDATA). Aber auch el klappt definitiv no. Tuve el ya damals getestet, como Yo, el Profano-Inline-Ensamblador geschrieben hatte.
Darum denke Yo, el wir dieses Schlupfloch-Thema getrost abhaken puede. |
|
| |
| |
| |
|
|
| ¿Por qué el no ging, me está glaube Yo ahora klar:
[quote:16fcb7769f=Frank Abbing]¡Hola,
el Adresse kann eigentlich no virtuelle Adresse ser, porque ellos direkt angesprungen voluntad kann. Puedo el Prozedure auch direkt en media Code setzten y starten.
[/quote:16fcb7769f]
Im eigenen Prozess kein Problema - aber en el fremden? Der Code, el uno ausführen voluntad, befindet se sí en el eigenen Prozessbereich y cada Prozess verfügt encima seinen eigenen virtuellen Speicherbereich...
[quote:16fcb7769f=Frank Abbing]
Yo vermute más, dass Windows testet, si el Speicher, el ausgeführt voluntad se, para Programa gehört. Also de Programa belegt wurde.
[/quote:16fcb7769f]
Yo voluntad hoffen, daß wir no aneinander vorbeireden:
Como una Prozessor sí a Tiempo auch sólo siempre una Prozess ausführen kann, podría Yo incluso vorstellen, daß el se el auszuführende Code physikalisch a el Tiempo, a el él eigentlich el Prozessor como Programmcode para Ausführen disponible posición debería, en RAM-Gefilden befindet, en dener él como auszuführender Code gar nichts nutzt.
Man muß also el auszuführenden Code sólo una vez en el Speicherbereich des anzugreifenden Prozesses bringen.
Und ahora kommt el Debugger en el Spiel - gemeint son hier APIs para Debuggen de Programmen el una DLL en el Speicherbereich uno fremden Prozesses injizieren puede, no una Programa.
Zum injizieren uno DLL hay mehrere Möglichkeiten - el Autor scheint hier una Möglichkeit gefunden a haben, el sólo unzureichend encima Privilegien y Zugriffsrechte abgesichert es. Yo bin me en el Augenblick aber bastante sicher, el zumindestens el anzugreifende Prozess encima cierto Sicherheitsmängel verfügen muß, el el injizieren zulassen.
[quote:16fcb7769f=Frank Abbing]
Lo son wohl una Vielzahl a Möglichkeiten, otro Task una Adresse mitzuteilen.
[/quote:16fcb7769f]
Sí, bajo anderem Subclassing. |
|
| |
| |
| |
|
|
| | So - Yo glaube, me es klar geworden, como el gemacht ha. Werde el en el nächsten Jahr veces testen... |
|
| |
| |
| |
|
|
| Das eigentliche Problema es, daß cada Prozess seinen eigenen virtuellen Speicherbereich ha. Will Yo also, el una fremder Prozess media Ver código fuente ausführt, muß dieser Ver código fuente se en el Speicher des Prozesses befinden, el ihn ausführen se. Aber como bekomme Yo Ver código fuente en una fremden Prozess? Es eigentlich el kleinere Problema:
Jedes Control, en el Yo irgendwie Ihnhalte mittels uno Message senden kann, bietet eigentlich esta Möglichkeit - al einfachsten va el con un Multiedit (el natürlich vorher ya en el Prozess disponible ser muß).
Mittels WM_SETTEXT läßt se a una Multiedit sí Texto senden, el entonces en el Editar sichtbar y editierbar es - aber por qué sólo Texto, por qué no DLL con Ver código fuente? Sende Yo una DLL (natürlich no de el Festplatte, pero de el Speicher meines Prozesses heraus) a el Multiedit des fremden Prozesses, befindet el DLL entonces en el Speicherbereich des femden Prozesses y kann nun auch mittels WM_TIMER angesprochen voluntad (bislang sólo Trockenschwimmen, como Yo kein MASM kann, müßte aber klappen).
Mittels EM_GETHANDLE läßt se entonces el Handle des Textes (el DLL) en el Editar ermitteln - y nun kommt el eigentliche Problema, Yo brauche no el Handle, pero el Adresse.
Mittels folgendem Ver código fuente querer nosotros ahora veces algo näher a Adresse kümmern - bajo 2000/XP natürlich:
KompilierenMarcaSeparaciónWindowstyle 31
Windowtitle "Multiedit"
Window 0,0-640,440
Def @GlobalSize(1) !"KERNEL32","GlobalSize"
Def @GlobalLock(1) !"KERNEL32","GlobalLock"
DEF @CopyMemory(3) !"kernel32","RtlMoveMemory"
Def @GlobalReAlloc(3) !"KERNEL32","GlobalReAlloc"
Def @SetParent(2) !"USER32","SetParent"
Declare edit&,Text$,ADDR&,Handle&,Text#
Dim Text#,256
LET EDIT&=@Createmultiedit(%HWND,"Test ",20,130,200,200)
LET Text$="ABCD"
LET Handle&=@sendmessage(edit&,$BD,0,0)
Print "Handle des Edits: "+@str$(Edit&)
Settext Edit&,@STR$(Handle&)
Let Addr&=@val(@Input$("Adresse des Edits:","Addresse",""))
Let Addr&=@GlobalLock(Handle&)
@CopyMemory(Addr&,@ADDR(Text$),32)
@CopyMemory(text#,Addr&,32)
Print "Adresse: "+@str$(Addr&)
Print "Breichshandle: "+@str$(Handle&)
Print "Kopierter Text: "+@String$(Text#,0)
PrINT "Bereichgröße: "+@str$(@GlobalSize(Handle&))+" Bytes"
Dispose text#
While 0=0
Waitinput
wend
Como Profano algo verschwenderisch con Heaps umgeht, debería uno el Ver código fuente con Profano2Cpp compilieren.
Beim me sieht todos entonces en etwa así de:
BILD 1
Im Editar es hier el Handle des Textes.
Nun starten wir [...] , wählen el Testprozess con el Multiedit de y dejar uns dessen Heaps listen.
BILD 2
Nun tun wir veces así como wäre el Handle des Textes (en me 44630028) una Adresse y dejar uns el Doubleword a dieses Adresse de [...] una vez auslesen.
BILD 3
BILD 4
Heraus kommt en me: X1=38184920
Jetzt tun wir wiederum así, como wäre 38184920 y schauen bajo el Heaps después de, si wir irgendwo esta Adresse encontrar y dejar uns el Inhalt des Heapblocks como String darstellen:
BILD 5
Como uno sieht, haben wir el Adresse des Textes en el Editar gefunden! Diese Adresse kann como Offset para el Función genommen voluntad, el wir mittels WM_TIMER später en el fremden Prozess ansprechen querer. Dazu muß el Adresse el auszuführenden Función de el Nullpunkt el DLL addiert voluntad - el zeigt [...] (Hoffentlich) bastante bien a => fertig Es el Adresse para WM_TIMER!
Als Administrator alles kein Problema - aber para Auslesen de Prozesspeicher necesidad Yo PROCESS_VM_READ y PROCESS_VM_OPERATION - y como User con eingeschränkten Rechten Yo esta Rechte definitiv no!
...aber bajo welchen Voraussetzungen ändert el Adresse überhaupt??? Tiempo schaun:
Yo starte el Prozess erneut => gleiche Adresse! El Adresse scheint Así que el nächste freiliegende Adresse a ser y no es zufällig gewählt.
Yo dar más que 32 Signo en Edit una => neue Adresse - es sí klar, si mehr zusammenhängender Speicher gebraucht se y dieser a dieser Punto no disponible es, muß se auch el Adresse ändern.
Aber auch alles qué vorher en el Heap geschrieben se (y se ändert) kann esta Adresse beeinflussen. In unserem Fall liegt el Adresse en el ersten Heap, el Standardheap des Prozesses. Schauen wir veces después de, qué sonst todavía alles antes dieser Adresse es. Hier veces unos pocos Auszüge:
G : W I N N T S y s t e m 3 2 W I N M M . D L L => Name de vom Prozess geladener DLL
F:EIGENESTasks and TokenMultiedit_cppMultiedit.exe => Gestarteter Prozess con Parametern
E G I S T R Y U S E R S - 1 - 5 - 2 1 - 8 6 1 5 6 7 5 0 1 - 1 0 6 0 2 8 4 2 9 8 - 1 9 5 7 9 9 4 4 8 8 - 1 0 0 0 => User String-SID
Auch Umgebungsvariablen uno Prozesses Yo ya en Heaps gefunden.
Como uno hier ya erkennt, Es el Adresse also Systemabhängig, así es also no posible, una vernünftige Anwendung a escribir, de una normalen Useraccount cada Rechner sin weiteres knackt sin ihn vorher zig(tausend)male para Choque a bringen. Das dürfte el Grund ser, por qué Microsoft en el Artikel, el Ausgangspunkt dieser Postings war, no großartig reagiert ha - el Grundaussage dieses Artikels war aber una otro, nämlich daß lo insgesammt una Sicherheitsrisiko es, Messages ungefragt a otro Programas senden a dürfen; y el stimme Yo ahora veces bastante heftig a...
Und wer se ahora fragt, por qué Yo hier así viel blödsinn hingeschrieben habe:
Yo habe hier eben veces nebenbei una Möglichkeit a DLL-Injektion aufgezeigt, el natürlich auch con otro Controls como una Multiedit funktioniert  . |
 |
| |
| |
| |
|
|
| Yo muß el, Yo hier en el letzten Posting de me gegeben habe, wohl algo revidieren.
Folgende Überlegung:
Der Texto des Edits landet siempre en el ersten Heap. El Startadresse des ersten Heaps (auch hier quasi el Handle), dürfte en el gleichen Betriebsystem (y el auch en unterschiedlichen Rechnern) siempre a el gleichen Punto mentira.
Yo habe en me bajo Windows2000 veces con WM_TIMER algo herumexperimentiert...
Espectáculos Parámetro vier en una no auslesbaren Zona, entsteht selbstverständlich una Zugriffsverletzung. Espectáculos Parámetro vier aber en auslesbare Bereiche el no ausführbaren Ver código fuente enthalten, passiert scheinbar kein schwerwiegender Fehler.
Theorethisch müßte lo also posible ser, el Startadresse (el Handle) des ersten Heaps como Ausgangspunkt a nehmen y así largo beim Senden el Message una Byte dazuzurechnen, a WM_TIMER el Ver código fuente ausführt.. El Startadresse des Heaps podría uno de una otro Rechner beziehen, en el el gleiche Anwendung se ejecuta. Selbst con XProfan dürfte el todavía en annehmbarer Geschwindigkeit a regeln ser.
Yo bin a Tiempo a otro Sachen dran y podría dies desafortunadamente todavía no más testen, como Yo hier aber genug lauffähigen Ver código fuente habe, voluntad Yo el Chatter Attack en nächster Tiempo veces nachbauen. Lo se nichts großartig spektakuläres y ser el DLL el ausgeführt se, se el Test-DLL con el Messagebox ser, el me Franco damals freundlicherweise programmiert ha - Yo möchjte trotzdem aber veces nachfragen, si Yo así una Programa hier überhaupt puesto darf? |
|
| |
| |
| |
|
|
Frank
Abbing | Na, el Cuestión va wohl más a IF.
Mich jedenfalls sería dein Test interés. |
|
| |
| |
| |
|
|
 | |
| |
| |
| |
|
|
| Mmmh - después de einiger Euphorie verliere Yo en el Augenblick veces otra vez el Vertrauen en el Warheitsgehalt el Aussagen des Artikels. El kleinste Hürde (- el Yo en el Augenblick todavía no überwunden habe - ), wäre el Einfügen de Nullbytes en una Editar sin el Recht PROCESS_VM_WRITE a haben; como es aber todavía wesentlich mehr en el Wege...
Einmal a Franco: Como groß son el Chancen, daß uno con dieser Método wirklich una aktuellen Rechner knacken kann? Schau dir dazu veces el Prozesse con TNT a, el en deinem Rechner en el Sistema-Account laufen - porque a es hier. Siehst du irgendwo una solchen Service, el una Editar oder una Multiedit besitzt???
Wenn du dir mi otro Artikel una vez aufmerksam durchliest y incluso con TNT algo herumexperimentierst, wirst du wohl muy rápidamente determinar, daß todos otro Ventana para solche Aktionen no a gebrauchen son (bin also kein Böser Bube ). Was mich a diesem Artikel interessiert, Es el Möglichkeit el DLL-Injektion como Administrator en una Prozess, el kein Service es - aber incluso como sehe Yo en el Augenblick Problemas,, para el lo todavía no Solución son... |
|
| |
| |
| |
|
|
| [quote:91bd3aedf7=Frank Abbing]Na, el Cuestión va wohl más a IF.
Mich jedenfalls sería dein Test interés.[/quote:91bd3aedf7]
Mmh... - Ver código fuente voluntad Yo vorerst a DLL-Injektionen todavía no de el Hand geben. Zumindestens el, qué TNT macht dürfte para euch beide aber auch sin Problemas sin Ver código fuente nachzuvollziehen ser, direkte Fragen a mi Mailadresse beantworte Yo ebenfalls gerne.
Saludo
AH |
|
| |
| |
| |
|
|
| | Zum Abschluß como Demonstration qué como wirklich así alles posible gewesen es, nochmals qué a diesem Thema. Desde que el kleine Anwendung, el Yo diesbezüglich geschrieben habe, no así gerne bajo el Personas bringen möchte, also en Form uno Animation: |
|
| |
| |
| |
|
|
| | Drum es sí para Glück auch una altes Windows ;) |
|
| |
| |
| |
|
|
| 
Fakt es, el lo encima Jahre hinweg (auch bajo XP) posible gewesen es, para una normalen Mitarbeiter cada Firmenrechner auszuhebeln (y el bajo XP todavía mejor como bajo Windows2000).
Fakt es auch, el se al Grundprinzip de Windows nichts geändert ha. Ob todavía irgendwo en el OS weitere undokumentierte Messages con gleichem Potential verborgen son, es ebenfalls no sicher. EM_SETWORDBREAKPROC y otro Messages fueron meines Wissens después de todavía no una vez gefixt.
Fakt es auch, el en vielen, (auch kommerziell genutzten) Rechnern todavía veraltete Servicepacks laufen - siehe media Test en el Internetcaffee.
Shatter es also una Geschichte, el uno muy genau en el Auge behalten debería - gerade si en neuere Betriebsysteme va. Besonders brisant finde Yo el Geschichte, el no una vez nötig es Ver código fuente en fremde Anwendungen una Message einzuschleuse - el Möglichkeit Ver código fuente anzuspringen reicht siempre de! |
|
| |
| |
| |
|
(520)
Deutsch
English
Français
Español
Italia
