XProfan

- Seite 1 -

Andre
Rohland

@Peter (Specht):

Frage 1.) Ungefähr so etwas wie Mach bitte keinen Mist...
Frage 2.) Das sind die sogenanten Nutzungsbedingungen von Microsoft
Frage 3.)Nein !!!, was Du vermutlich meinst sind die sogen. Terminate and Stay Resistent Programme, dieses hier überlebt mit Sicherheit keinen Reset... .
Frage 4.) habe ich an IF weitergeleitet, weiss auch nicht so genau, was er damit meint... .
Frage 5.) ganz trivial: wenn Du was Böses mit dem Code machst... .

Gruß André

05.03.2009 ▲

Andre Rohland

@Peter (Specht):

Frage 5.) ganz trivial: wenn Du was Böses mit dem Code machst...

Geh doch einfach mal davon aus, dass er bereits jetzt schon viel bösere Codes schreiben könnte, als Du Dir vielleicht wiederum vorstellen kannst.

Es gibt keine Sicherheit (sicheren Betriebssysteme) und Aufklärung schadet selten.

05.03.2009 ▲

@Andre: Vielleicht machen wir das zunächst an einem klaren Anwendungsbeispiel fest welches nützlich sein kann.

Hast Du hierzu eine Idee?

05.03.2009 ▲

- Seite 2 -

Matthias
Arlt

Andre Rohland

...dass ein und diesselbe programmiertechnische Verfahrensweise zu guten Zwecken ( = Spezialfälle ), wie auch zu bösen Zwecken ( = injizieren von Malwarecode z.B. in explorer.exe, svchost.exe etc.) verwendet werden kann...

Das liegt nun mal im Wesen der Sache an sich...und dies in allen Bereichen auch jenseits der Programmierung. Eine leidige, aber unabänderbare Tatsache.

Andre Rohland

Sei Dir bitte auch darüber im Klaren, dass nicht nur unsere Community diesen Beitrag lesen kann, sondern jeder, der irgendwo im Netz diesen Beitrag findet...

Ich verstehe durchaus Deine Intention und diesbzgl. Zurückhaltung. Nur, all das könnte ein potentieller Interessent aber andernorts auch erfahren. Und er würde vmtl. noch weit eher fündig, als hier. Denn noch bewegt sich (X)Profan (m.M.n. ungerechtfertigt) eher im Randbereich der allg. Wahrnehmung. Der didaktische Nutzen einer Offenlegung dürfte daher einen befürchteten Negativ-Effekt (sofern dieser überhaupt eintritt) bei Weitem überwiegen...

Die mögliche Alternative...ich weiß was, sags aber nicht, hatten wir schon. Und sie hat sich lediglich nur als destruktiv erwiesen...

Gruß
Matthias

WinXP SP2, Win7 - XProfan 10/11/FreeProfan32 - Xpia

06.03.2009 ▲

E.T.

@Andre: Vielleicht machen wir das zunächst an einem klaren Anwendungsbeispiel fest welches nützlich sein kann.

So ein Anwendungsbeispiel wäre ja ggf. auch nicht schlecht, um zu testen, wie div. Sicherheits-Software damit umgeht, wenn ein laufendes Programm injiziert wird (rein Test-mäßig

Grüße aus Sachsen... Mario
WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte...

06.03.2009 ▲

Andre
Rohland

Das wäre dann wohl mein derzeitiges Projekt,
ich habe aber leider noch nicht fertig...

1.) Der Hintergrund...

ist ein Teenager mit dem Problem Schule versus Computergaming.
Man trifft sich eben so bei MMORPGs ( a.k.a Onlinegaming ) und geht dann entsprechend früh zu Bett ( manchmal sogar schon um 01.00 Uhr).
Dabei ignoriert man großzügig den Umstand, dass man um 06.00 Uhr aufzustehen und einen Schulweg von ca. 7 km zu bewältigen hat. Die schulischen Ergebnisse übernächtigter Teenies brauche ich sicherlich nicht auszuführen...

( Bitte aber jetzt keine guten Ratschläge zur Erziehung eines 18-jährigen Teenagers... )

2.) Spezialfall und Legitimität des Projektes...

Es gibt haufenweise sogen. Kindersicherungsprogramme, die die Computerzeit einteilen und den Computer zu einer bestimmten Zeit herunterfahren, die alle als legitim eingestuft werden.
Sie teilen sich in zwei Hauptgruppen:
- der überwiegende Teil arbeitet mit Zugriffsbeschränkungen ( Systemeinstellungen, Uhrzeiteinstellung, Taskmanager verbieten usw.) meist via Registry-Hacks oder Policies.
- der kleinere Teil greift tiefer in das System ein, die Restriktionen sind nicht immer nachvollziehbar und im Fehlerfall auch als Admin nicht immer rückgängig zu machen.

Diese Situation empfinde ich als unbefriedigend.
Das Sperren des Taskmanagers halte ich z.B. für mehr als bedenklich, weil dem User die Möglichkeit entzogen wird, einen fehlerhaften Prozess zu beenden und die Systemstabilität zu erhalten. Stattdessen bleibt unter Umständen nur ein Neustart übrig.
Was zum Beispiel, wenn ich gerade 13 Seiten für eine Hausarbeit mühevoll zusammengeschrieben habe und der Abgabetermin bedenklich nahe liegt...

Spezialfall ?

Ich denke schon, aus folgenden Gründen:
- mein Sohn soll alle Rechte als Admin auf seinem Computer behalten und nach Belieben in seinem System schalten und walten können, bis auf den Umstand, dass die Kiste an Vorabenden von Schultagen eben 21.50 Uhr herunterfährt.
- dazu wird nur diese eine Funktion gebraucht, der Funktionsumfang üblicher Programme ist überflüssig und bremst das System u.U. nur aus, was dem Schlachten der heiligen Kuh eines jeden Gamefreaks gleichkommt...
- ich möchte auf dem System keinen Kernel-Mode-Code fremder Anbieter ausführen lassen, den ich nicht wirklich kontrollieren kann
- das Programm dient ausschließlich privaten Zwecken, eine kommerzielle Verwendung ist nicht vorgesehen.

3.) Ein Anwendungsbeispiel

liegt eigentlich schon vor. Die prozess2.exe soll später die Aufgabe übernehmen, den Computer an Schultagen um 21.50 Uhr herunterzufahren. Sie wird durch den injizierten Code überwacht und gegebenenfalls neu gestartet.

Die einzubauende(n) Funktion(en):
- Uhrzeit aus dem Internet holen ( deshalb habe ich die Daytime Protocol Unit geschrieben )
- verbleibende Zeit bis 21.50 Uhr in Sekunden umrechnen
- GetTickCount + verbleibende Zeit in Variable speichern und alle 30s mit GetTickCount vergleichen
- Countdown ca. 1 min vor dem Herunterfahren einleiten (z.B Piep über Systemlautsprecher)
- Herunterfahren

Hier ist der aktuelle Quelltext von Prozess2.exe
Kompilieren Markieren Separieren

windowstyle 24
Window 600,100
WindowTitle Back to Live Prozess ( prozess2.exe )
cls ($00FF00)
color 0,10
Font 2

if %Parcount

    color 4,10
    print Du hast versucht mich zu killen, pfui Teufel !
    print
    print Zum Schließen bitte zuerst Muttertier.exe beenden... .

else

    color 0,10
    print Programm wurde ordnungsgemäß zum ersten Mal gestartet.

endif

waitkey
end

Bitte beachtet, dass die Abfrage der Parameteranzahl voraussetzt, dass Prozess2 zur Exe kompiliert wird.

Damit habt Ihr jetzt ein Anwendungsbeispiel, welches Ihr selbst verändern, ausbauen und testen könnt.

Fortsetzung heute Nachmittag...
André

07.03.2009 ▲

Andre
Rohland

Fortsetzung...

Die Überschrift des Beitrages sagte es zwar schon, aber ich möchte es lieber noch mal erklären:
- Direct Code Injection bedeutet, dass weder Hooks verwendet werden, noch Funktionen aus DLLs irgendwo gemappt werden, sondern
- es wird ausführbarer Code direkt in den Speicherbereich eines Prozesses geschrieben und ausgeführt.

Die Methode zur direkten Injizierung des Codes ist (für sich genommen) recht einfach, das Problem ist der Code selbst.
Er muss an sich unabhängig und ausführbar sein, es kann also keine Exe-Datei sein ( sondern nativer Bytecode ).
Da fällt uns allen eigentlich nur Assembler ein... .

Mit dem MASM32 hat sich Assembler-Programmierung schon fast zu einer Hochsprache entwickelt, es liegt also nahe, diesen Assembler zu verwenden.

Wenn ich ganz ehrlich sein soll, dann werde ich für eigenständige XProfan-Programme, die aus Perfomancegründen auf Assembler-Routinen zugreifen auch weiterhin den XPIA von Frank verwenden.

Das funktioniert leider in unserem Falle nicht, wir brauchen überwiegend die Low Level- Syntax des Assemblers, denn es werden nicht alle Elemente der High Level-Syntax unterstützt.

Wer also richtig pushen und poppen kann ist ganz klar im Vorteil. (tschuldigung).

Im Klartext heißt das dann wohl: Es wird ein kleines Tutorial geben müssen, welches die von Euch geäußerten Wünsche an die Nachvollziehbarkeit erfüllen wird... . Da hab ich mir ja was eingeproggt !

@IF:
War das so in etwa Deine Intention ?

@E.T. (Mario):
Ich setze mal nochne Exe rauf, mit der Du das Verhalten von AV-Programmen versuchen kannst zu testen, allerdings erst morgen... .

Soviel für Heute, warte auf Eure Antworten.

Gruß
André

07.03.2009 ▲

E.T.

Hab das mal mit dem Beispiel aus Post1( [...]

) getestet:
FreeAV (Avira) scheind das überhaupt nicht zu interessieren (bedenklich ??

). Zumindest konnte ich in keinem Log was finden. FreeAV kontrolliert m.E. halt nur, ob in der (den) Datei(n) ein Schadcode drinn ist. Wird ein schädlicher Code erst beim Injizieren erstellt (wie es viele Trojaner, Viren etc: ja auch machen), würde das Avira ggf. gar nicht merken (darum von mir nur zu Test-Zwecken benutzt

).

Scanner mit Überwachung der Programm-Aktivitäten merken schon, das da was passiert, auch das injizieren wird registriert und überwacht:
Kaspersky z.B. registriert fein säuberlich die Aktivitäten, überprüft die Datein und den Code, und wenn nix verdächtiges gemacht oder im Code gefunden wird, dann lässt es gewähren. Am Log kann man sehr schön sehen, das hier alles gecheckt wird :

(Die langen Pausen zwischen den Programm-Starts resultieren aus deem Deep-Scann...)
Das injizieren eines laufenden Prozesses mit irgendwas kann also schon ganz schön missbraucht werden (auch aus Profan-Progs heraus), ein guter Scanner würde das aber auf jeden Fall merken und die Ausführung des Codes verhindern (hoffe ich, bis jetzt wars bei mir so).
Aber das kann man ja ganz leicht testen, indem man dem guten Code beim injizieren einfach mal einen Testvirus beifügt (würde mich doch glatt interessieren, Andre, baust du das mal in deinem Beispiel für mich ein??

injector-test.png	8 kB

Hochgeladen:	08.03.2009

Ladeanzahl:
		Herunterladen

Grüße aus Sachsen... Mario
WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte...

Andre
Rohland

Nochmal ein Programm zum testen...

Ich weise ausdrücklich auf folgendes hin:

- Das Programm dient ausschließlich dazu, zu ermitteln, wie sich Programme verhalten, in die Code injiziert wird, bzw. wie Antiviren-Software auf solche Code Injections reagiert !
- Das aufmerksame Lesen aller Beiträge zu diesem Thema, besonders aber der von IF gegebenen Hinweise in seiner ersten Antwort zum Thema ( bezüglich Injizierung von Code in M$-Programme ) ist absolute Pflicht !!!
- vielleicht überflüssig, weil schon erwähnt, aber nochmals: Ich übernehme keinerlei Verantwortung, die ( hoffentlich nicht blindwütige ) Benutzung des Programms erfolgt auf eigene Gefahr !

Beschreibung des Programms:

Das Programm lässt die Auswahl eines laufenden Prozesses zu und injiziert eine Assembler-Routine, die eine Messagebox aufruft. Beim Anklicken von OK erscheint die Messagebox nach ca. 2 Sekunden erneut, beim Anklicken von Abbruch wird der Thread mit der Assembler-Routine beendet.

Da das aufrufende Programm nach Start der Routine in einem anderen Prozess beendet wird, damit diese eigenständig weiterläuft, erfolgt keine Speicherfreigabe bei Beendigung des RemoteThreads ! Man sollte deshalb vielleicht nicht gerade 1000-mal in den selben Prozess injizieren, wenn dieser nicht zwischendurch mal geschlossen und neu gestartet wird, sonst macht man aus einer Mücke einen Elefanten...

XProfan-Teil

- Vervollständigung einer bereits als Include vorliegenden Assembler-Routine ( Bereichsvariable )mit den Adressen der Funktionen( Messagebox ), ( ExitThread ) und ( Sleep ), sowie weiteren Parametern dafür
- Öffnen eines Prozesshandles mit PROCESS_ALL_ACCESS - Rechten ( OpenProcess )
- Reservierung virtuellen Speichers, 1000 Bytes ( VirtualAllocEx )
- Startadresse des reservierten Speicher in die ASM-Routine ( Bereichsvariable ) schreiben
- 200 Bytes der Bereichsvariable ( ASM-Routine ) in den reservierten Speicher ab Startadresse mit ( WriteProcessMemory ) schreiben
- RemoteThread starten mit Startadresse der Routine ( CreateRemoteThread )
- selbst beenden

Assembler-Teil

label:
- Messagebox Weiter ?
- OK --> sleep 2000 ---> Springe zu label:
- Abbruch ExitThread,0 selbst beenden

Eine ausführlichere Beschreibung geht wohl nur in einem entsprechenden Tutorial mit konkretem Quelltext als Beispiel. Vorschläge für Beispiele und Tutorial ???

Gruß
André

InjectCodeTest.rar	356 kB

Hochgeladen:	08.03.2009

Ladeanzahl:
		Herunterladen

Andre
Rohland

Hoppla, Mario

Du warst mit Deinem Beitrag ein klein wenig schneller als ich.

Gleich mal zu Deiner Frage: Definitiv NEIN !

1.) habe ich nicht wirklich Ahnung, wie man einen Testvirus schreibt...
2.) gibt es überhaupt Testviren ??? Für mich ist Virus = Virus. Testvirus hört sich für mich eher an wie: ein bißchen schwanger oder ein bißchen tot...
3.) Vorausgesetzt, es gäbe einen Testvirus, so dürfte er ( weil er doch nur ein Testvirus ist ) keinen Schaden auf Deinem System anrichten... ? In diesem Falle würde jedoch Dein Kaspersky weiter pennen und sich auf eine Protokollierung dieser Aktivität beschränken, weil es keine bekannten Schadroutinen findet ?
4.) Offenlegung, Erklärung der konkreten Mechanismen und na ja, nun sogar auch noch Tutorial habe ich nicht umsonst an eine moralische Verantwortung geknüppert und Diskussionsbeiträge/ Meinungen dazu gefordert...
5.) bin ich fest davon überzeugt, dass Du ein Guter bist und Deine Frage an mich wegen derselben Bedenken erfolgte, die ich anfangs zur Diskussion gestellt habe

Ein guter Scanner ??? HÄ ???

Also: Meines Wissens hängen alle AV-Programme der aktuellen Entwicklung neuer Viren einen Tick nach und man nennt dies auch die Produktivkraft des Verbrechens. Schließlich muss der neue Virus untersucht, analysiert und letztlich müssen Erkennungsroutinen geschrieben werden. Reine Viren sind übrigens in der Szene relativ out, man konzentriert sich neuderdings stärker auf die Programmierung von Würmern, die sich selbst verbreiten und vestecken können. Den eigentlichen Malware-Code laden sie meist erst aus dem Netz herunter ( keylogger, Passwort-Spione...).

Nur relativ wenige AV-Scanner versuchen sich ( im sogen. ON ACCESS - Modus = Zugriffe/ Dateistarts, etc... ) an der Erkennung von Malware-Code. Das ist nämlich gar nicht so einfach, denn wo fängt denn eigentlich der SchadCode an ???

Ein Beispiel für Dich, warum Dein Kaspersky bei gut geproggter Malware (Virus) versagen könnte:
( Ich versuchs auch kurz zu machen...)

Mein Programm, ein winziger, unscheinbarer Kernel-Mode-Treiber verändert mit der sogen. DKOM-Methode ( = Direct Kernel Object Manipulation ) die Verkettung von Systemstrukturen, z.B. mit dem Ergebnis, dass für das System ein ganzer Ordner incl. aller Dateien gar nicht existent ist.

FRAGE 1: Wie soll Kasper diese Dateien ( mit seiner ON ACCESS oder erst recht mit der ON DEMAND- Methode untersuchen können ?

Selbst wenn:
In diesem Ordner befindet sich einfach mal gar kein Virus, sondern ein einfaches Proggi, welches alle Festplatten formatiert... ( = guter Code ? ).

FRAGE 2: Springt Kasper etwa an, wenn Du die Festplatte oder eine Partion formatieren möchtest ???
(ich glaube nicht...)

Aber weiter: Mein kleiner böser Treiber wird mit großer Wahrscheinlichkeit von Kaspersky gar nicht untersucht werden können, weil er in der untersten Ausführungsschicht des Systems läuft ( = ring 0 ), d.h. er wird ausgeführt, bevor es überhaupt zu einem Login von Windoof kommt.

Und schon wieder das Selbst wenn:

Es werden ja nur ein paar Zeigeroperationen ausgeführt... . Wenn Kasper das alles verbieten würde, dann Gute Nacht..., weil ja auch legitime Treiber so etwas ausführen, z.B. bei direkten I/O-Port-Operationen ( Maus-Kontrollprogramme usw. ).

Und wieder weiter:
Mein kleiner böser Treiber hockt nun auch nach der Anmeldung im System rum und wartet darauf, dass ich ihn mal etwas frage... .
Zum Beispiel danach, wie ich die format.exe im ausgeblendeten Ordner aufrufen kann... !!!!!!!!

This could be My Way ???:
Wie könnte das funktionieren ???
Also: ich starte z.B. Explorer.exe über die System.ini als Shell, mit einem Parameter.
Dieser ist natürlich die Injector.exe. Damit User X mir nicht dazwischenpfuscht, verbiete ich ihm gleich mal den Zugriff auf die System.ini...

FRAGE 3:
Muckt Kasper etwa auf, wenn Du mit dem Befehl cacls.exe in der Eingabeaufforderung den Zugriff auf einen Ordner/ Datei sperrst ?
(wohl kaum...)

Und nochmal einen Schritt zurück:
Der Kasper stellt nun zwar fest, dass ein Prozess (z.B. in Explorer.exe ) eingeschleust worden ist, kann aber damit nichts anfangen, da jede Operation genauso von anderen ( lieben ) Prozessen ausgeführt werden könnte und protokolliert das erst mal zur Sicherheit - hahaha.

Und nun der absolute Hammer:
Für die Ermittlung der Möglichkeiten zum Starten von format.exe benötigt der eingeschleußte Prozess ( ASM-Code )nur Millisekunden.
Noch bevor Du auch nur zum Lesen des Protokolls von Kaspersky-AV überhaupt kommst, ist format.exe doch schon gestartet... .

Sorry für die Horrorversion, aber ich gehe mittlerweile davon aus, dass AV-Programme mehr eine Art von Selbstberuhigung sind...

FRAGE 4: Noch weitere Fragen ?

Sei nicht traurig, weil ich Dir hier so eine Abfuhr erteilen muß... .

Sollten wir uns hier gemeinsam zu dieser Problematik verständigen können, so wird es ein Tutorial geben, mit dem Du tiefer in die ganzen Probleme eindringen und vielleicht sogar Deinen eigenen Testvirus schreiben kannst, wovon ich Dir aber nach wie vor dringend abraten würde... .

Nochmals @ALLE:
Vielleicht versteht ja nach diesem Beispiel jetzt auch jeder, warum ich eine solche Diskussion gefordert habe, die leider teilweise nicht ganz so ernst genommen wurde, wie ich erwartet hätte.

Um das auch nochmals klarzustellen:
- wer lesen kann, ist sicherlich in der Lage, meinen letzten Beiträgen zu entnehmen, dass ich grundsätzlich bereit bin, mein Wissen zu vermitteln ( da ich nicht weiß, auf welchem programmiertechnischen Level sich die Leser dieses Themas bewegen, habe ich sogar ein Tutorial in Erwägung gezogen...)
- Wollt Ihr das wirklich ???
- Ein, wenn auch noch so kleines, Tutorial zu schreiben bedeutet richtig Arbeit, zumal ich mich nicht immer kurz fassen kann...

- Ohne Anregungen, Vorstellungen über ein Demo-Projekt läuft deshalb nichts... .

P.S.: @Mario:
Wenn ich unter 1.) geschrieben habe, dass ich keine Ahnung habe, so heisst das nicht, dass ich mich mit diesem Problem nicht auseinandergesetzt habe ( bin selbst mal ziemlich böse gehackt worden...)

Ich habe fertig. Puuuhhh !

Gruß
André

E.T.

Huch, für solch lange Posts ist doch Dietmar zuständig

@Andre: Du sollst mir natürlich keinen Testvirus schreiben, sowas gibts ganz offiziell (von vielen Großen sogar freigegeben): [...]

Dieser Link zeigt auf die Erklärungs-Seite, nicht auf einen Virus !!! Nutze ich ganz gern, um zu zeigen, das der Schutz auch wirklich da ist

...Aber weiter: Mein kleiner böser Treiber wird mit großer Wahrscheinlichkeit von Kaspersky gar nicht untersucht werden können, weil er in der untersten Ausführungsschicht des Systems läuft ( = ring 0 ), d.h. er wird ausgeführt, bevor es überhaupt zu einem Login von Windoof kommt....

> Das macht m.E. auch einen guten Scanner aus, der ist vor WIN da !!! Und Änderungen z.B. am Systemstart werden nachgefragt bevor diese zugelassen werden (wie eben das laden eines unbekannten Treibers), wenn ich es dann natürlich (aus Unwissenheit oder auch Dummheit oder was auch immer) zulasse, dann natürlich Gute Nacht.

Aber wir wollen ja nicht über gute und schlechte Scanner diskutieren, und auch nicht darüber,

wann welches AV-Prog aktuell ist, das wird wird es wohl nie 100-Prozentig geben.

Sei nicht traurig, weil ich Dir hier so eine Abfuhr erteilen muß... .

Och, das bin ich gewohnt....

Um mal wieder zum Anfang zurück zu kommen:
Warum soll denn das, was du vor hast (den Rechner zu bestimmter Zeit abschalten oder so) überhaupt durch das injizieren einer Anderen Anwendung erfolgen ??
Würde es da nicht genügen, (D)ein Programm einfach (vor dem Taskmanager) zu verstecken ??

Grüße aus Sachsen... Mario
WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte...

Andre
Rohland

@Mario:

... Leider eben nicht einfach...
Einen Prozess unter WinXP zu verstecken geht meines Wissens nur über API-Hooking ( via IAT-Patching ) oder DKOM ( Direct Kernel Object Manipulation ) durch das Verbiegen von Zeigern in der doppelten Verkettung der EPROCESS-Strukturen, also durch Rootkittechnologie, was meist durch Treiberprogrammierung erledigt wird. Die Wahrscheinlichkeit, dass Antiviren-Software Alarm schlägt, ist also sehr hoch...

Andere Gründe sind:
1.) Systemweite Hooks können sich auch ziemlich negativ auf die Systemleistung auswirken.
2.) Mein Kontrollprogramm hat eine ( natürlich passwortgeschützte ) Benutzeroberfläche, damit ich Zeitvorgaben ändern kann, bzw. in den Ferien das Programm vollständig deaktivieren kann. Es soll also sichtbar sein ( nur eben nicht die Routine, die es überwacht )!
Noch mehr Gründe habe ich schon weiter oben Spezialfall ? genannt.

Wenn Du die InjectCodeTest.exe gestartet hast und wartest, bis sie sich beendet hat, wirst Du die laufende ASM-Routine nicht unter Prozessen im XP-Taskmanager finden, sie befindet sich ja in einem der bereits angezeigten laufenden Prozesse.

Lediglich für die Zeit der Anzeige der Messagebox wird die Routine unter Anwendungen im XP-Taskmanager als Caption angezeigt, was daran liegt, dass ein Window aufgemacht wird.

Meine ASM-Kontrollroutine ( exakt die gleiche, wie in Injektion.rar ) verwendet indessen kein Fenster...

Mit der Injizierung in ein beim Systemstart ausgeführtes Programm ( beispielsweise ein Chatprogramm ) ist meine Routine recht gut aufgehoben und als solche auch nicht sichtbar.

Gruß
André

09.03.2009 ▲