Entwickler-Ecke :: Thema anzeigen - Prozess komplett in Windows verbergen

Entwickler-Ecke

Windows API - Prozess komplett in Windows verbergen

ShadowCaster - Mo 14.04.03 09:52
Titel: Prozess komplett in Windows verbergen

Hi Leute,

ich hab mir neulich Gedanken gemacht, dass es trojanern oder anderen Viren sicherlich möglich wäre, sich komplett im taskmanager in der Anwendungs und in der Prozesssparte zu verbergen. Nur woher soll ich dann noch wissen, dass ich ein solches Programm auf dem PC hab was womöglich noch kein Virenscanner kennt?

Wie geht das überhaupt dass man eine Anwendung komplett verschwinden lassen kann? Gehen muss es ja. wie ich sie in der Anwendungssparte im Taskmanager verberge weiß ich, aber nicht wie ich sie ganz verberge. Zudem wäre das Wissen ganz nützlich da ich gern ein Securityprogramm für meinen PC schreiben will, was sich nicht mit dem Taskmanager beenden lässt. Das wäre schön. Da könnt ich mein System gegen neugierige Leute abschotten, vielmehr meinen Desktop.

Also wenn ihr wisst wie es geht, dann hoffe ich dass ihr mir helft und was auch nicht schlecht wäre, wenn es einen Codeschnipsel gäb, der solche Anwendungen wieder sichtbar macht.

Meine Idee war bisher, dass eine Anwendung dem Kernel vorgaukeln müsste, sie wäre eine direkte System-Dll bzw. -Anwenung des Kernels, damit sie nicht angezeigt wird.

Schonmal danke für eure Hilfe :wink:

UGrohne - Mo 14.04.03 10:50

Warum willst Du ein Security(???)-Programm schreiben, dass sich im Taskmanager versteckt? Wer sich schützen will, würde das Programm eh nicht beenden. Und wenn, es geht nicht, dass man ein Programm im Taskmanager versteckt, höchstens wenn Du es als Dienst laufen lässt.... Auch die ganzen Trojaner sind unter NT-Kerneln im TM sichtbar und können dort beendet werden.

Soweit ich weiß, müsstest Du Dein Programm in einen anderen Runlevel bekommen und das ist nur schwer möglich....

blackbirdXXX - Mo 14.04.03 11:06

Ich kenne nur die Metode für Win9x und ME:

Quelltext

1:
2:
3:
4:
5:
6:

function RegisterServiceProcess(dwProcessID, dwType: DWord): DWord;stdcall;

function RegisterServiceProcess; external 'KERNEL32.DLL' name 'RegisterServiceProcess';

RegisterServiceProcess(0,1);    // verstecken
RegisterServiceProcess(0,0);    // anzeigen

Du kannst aber Strg+Alt+Entf deaktivieren

Quelltext

1:
2:
3:
4:
5:

//Task-Manager aus
SystemParametersInfo(SPI_SCREENSAVERRUNNING,1,Nil,0);

//Task-Manager ein
SystemParametersInfo(SPI_SCREENSAVERRUNNING,0,Nil,0);

Allerdings sollte man dies nicht für schlechte Zwecke verwenden!
Wichtig! Sollte dein Programm unter Win9x hängen bleiben kannst du es nicht mehr beenden! Das kann zu einem Problem werden wenn das Programm eine SChleife für den Festplattenzugriff verwendent!
Vorsicht!!! :mahn:

Moderiert von Klabautermann: Color-Tag korrigiert.

ShadowCaster - Mo 14.04.03 12:11

naja, mich hat das auch für XP interessiert. Allerdings muss ich ja die dwProcessID noch herausfinden, damit es funzt. Woher soll ich wissen, welche PID mein Programm hat?

Die Funktion RegisterServiceProcess, tut die nur einmal die Anwendung im Arbetisspeicher als solchen Prozess registrieren, dass sie immer automatisch als Prozess geladen wird oder nur einmal zur laufzeit dass ich das jedes Mal neu machen muss?

Mir gings darum, dass in meinem XP-Rechner keiner so einfach über den Taskmanager meine Securityanwendung beenden kann. Damit logge ich nämlich auch die Vorgänge auf meinem PC.

Für negative Dinge werd ich das sicher nicht nutzen. Ich bin schließlich kein Krimineller und halte es für absolut *mist*e, wenn jemand solche Informationen für schlechte Dinge ausnutzt. :x

Motzi - Mo 14.04.03 12:44

ShadowCaster hat folgendes geschrieben:

naja, mich hat das auch für XP interessiert. Allerdings muss ich ja die dwProcessID noch herausfinden, damit es funzt. Woher soll ich wissen, welche PID mein Programm hat?

Stichwort: GetCurrentProcessID

Zitat:

Die Funktion RegisterServiceProcess, tut die nur einmal die Anwendung im Arbetisspeicher als solchen Prozess registrieren, dass sie immer automatisch als Prozess geladen wird oder nur einmal zur laufzeit dass ich das jedes Mal neu machen muss?

Jeder Prozess hat eine eigene ProcessID, du müsstest es also für jede Instanz deines Progs einzeln aufrufen.

Zitat:

Mir gings darum, dass in meinem XP-Rechner keiner so einfach über den Taskmanager meine Securityanwendung beenden kann. Damit logge ich nämlich auch die Vorgänge auf meinem PC.

Mit einem Service.. sofern ein Prozess allerdings das SeDebugPrivilege aktiviert hat kann sich dieser auch für Services ein gültiges Prozess-Handle holen und diese daher mit TerminateProcess abschießen!

Beste Lösung: MSGINA.DLL ersetzen. Siehe dazu im MSDN unter dem Thema WLX - Windows Logon Extension
WARNUNG: Wer mit der MSGINA.DLL spielt spielt mit dem Herz von Windows!

ShadowCaster - Mo 14.04.03 13:04

Hey danke euch, das ist echt eine schöne Hilfe :) Vielleicht schreib ich mir mal einen Ramscanner der nach solchen versteckten Anwendungen scannt und diese auf Wunsch abschießen kann. Nicht, dass es sowas nicht schon geben würde. Wäre eher eine Lernübung.

Delete - Mo 14.04.03 15:55

Jetzt wo du sagst, dass du XP benutzt verstehe ich dein Anliegen nicht mehr so ganz. :shock: Schalt das automatische Einloggen ab und es kommen nur Leute an den PC die dazu befugt sind.

ShadowCaster - Di 15.04.03 09:08

Darum gehts nicht. Ich will so ein Tool, was mir alles über das System verwaltet mal selbst proggen. Da kommen dann später auch Makroprogramme rein und Taskplaner, etc. Naja, mal schauen, wann ich richtig Zeit dazu hab. :wink: Ich hab nämlich nicht rausgefunden wie man in XP die Arbeitsstation sperren kann. Man muss glaub ich auf Benutzer wechseln gehen und dann kann man sich wieder einloggen, weil die Anwendungen nicht beendet werden. Aber naja, ist nicht so sauber. :(

Delete - Di 15.04.03 09:14

API: LockWorkStation.

ShadowCaster - Di 15.04.03 12:38

Danke :) Ich wusste gar nicht, dass windows XP das kann. :wink:

Delete - Di 15.04.03 13:30

Das konnte NT auch schon. Aber der API-Befehl ist erst seit Windows 2000 dokumentiert bzw. verfüg- und nutzbar.

ShadowCaster - Di 15.04.03 14:56

Danke :) Gut zu wissen.

olliterski - Do 17.04.03 09:03

... wäre interessant zu wissen welche Programme das schon machen und unter XP auch schon funktionieren!

Ist zwar jetzt keine Programmiererfrage, aber bei mir treibt eine Anwendung Namens 'F' ihr Unwesen! Sie lässt sich manchmal nicht beenden, was natürlich um so merkwürdiger ist als das ich sie nicht starte!!!

Bisher haben alle Programme (NAV, Winforce,...) versagt und mir dieses Programm nicht angezeigt!

Wenn jemand einen Tip hat mit welchen Programmen man alle Prozesse unter Windows auslesen kann, dann her damit!

Viele Grüße
Oliver

Delete - Do 17.04.03 09:07

Ist es eventuell ein Service?

ShadowCaster - Do 17.04.03 09:27

ich denke in diesem Thread ist soeben eine Marktlücke für anti-viren-tools entdeckt worden ;) wenn das die normalen virenscanner nicht schon erkennen... Wäre wirklich nicht schlecht, eine solche Anwendung zu sehen und dann zu beenden. Dann müsste man aber die Registry absuchen, damit die Anwendung sich nicht wieder neu startet. Oft ist es aber auch so dass solche Anwendungen aus anderen Anwendungen heraus erstellt werden. Bsp: du hast eine Anwendung namens Aidemplayer (frei erfundener Name :twisted:) z.B. und der erstellt diese kleinen Buggyprogramme die dein System ausspionieren und die Infos ins Internet senden. Dann gehst du her und löschst die Buggyprogramme komplett von der Festplatte und beim nächsten Neustart wunderst du dich, dass sie wieder da sind. Tja, was also machen? Die ganze Software wegwerfen. Das Problem ist nur, dass immer mehr kommerzielle Programme eine solche Art von Anwendungen oder Dll's generieren die dein System ausspionieren. Das beste Beispiel ist Babylon (ein Übersetzungsprogramm für Windows). Es hat soviel ich weiß eine pcload.dll und eine pcload.exe oder so ähnlich heist das. Diese Teile sollte man sofort löschen...

Naja, lange Rede, kurzer Sinn. Ich werd mich glaub ich mal dran machen, ein Erkennungsprogramm zu schreiben, was mir diese Prozesse auflistet.

ShadowCaster - Do 17.04.03 09:31

ich hab mal gegoogled und wenn die F-Anwendung das ist was ich denke... ei ei ei.. dann hat dein PC wohl ne Grippe :-( aber die Grippe wär harmlos... :wink:

http://securityresponse.symantec.com/avcenter/venc/data/trojan.lovead.html

Delete - Do 17.04.03 09:33

Zitat:

Trojan horse that is written in Microsoft Visual Basic 5

:shock: oder besser: :mrgreen:

ShadowCaster - Do 17.04.03 09:36

harmlos... das Ding... nur damit der Autor Klicks auf seiner Homepage bekommt... lol... ich glaub son Teil prog ich auchmal... :mrgreen: :dance:

olliterski - Do 17.04.03 12:32

...mag sein das die Grippe harmlos ist ... in diesem Fall!
Aber irgendwann wird das Ding nicht mehr harmlos sein - unter einem anderen Namen von nem anderen Programmierer!

Ehrlich gesagt find ich die Dinger total Käse!

Da holt man sich ne Firewall, ´n Virusscanner und die Teile bleiben so gut wie unentdeckt!
Schön wäre natürlich wenn man eine Übersicht hätte - ähnlich Winforce - in der wirklich alle Prozesse auftauchen.

Interessant wäre in diesem Zusammenhang aber auch ein Plug-in für Outlook, bzw. die Möglichkeit Spam-Mails in ein Programm zu kopieren und der wahre Absender sowie der Provider bekommen mal ne Mail was da gelaufen ist und das der Mist doch in Zukunft unterbleibt.

Da beides einher geht wäre es vielleicht ne interessante Kombination!

Viele Grüße

Oliver

Delete - Do 17.04.03 12:40

Wie so bleibt das Ding unentdeckt bei einem Firewall? Jedem Programm, was bei mir raus will, muß ich es erst gestatten, weil der Firewall "aufpoppt" und mir sagt, "da will was raus". Und dann kucke ich was es ist und entscheide, ob es darf oder nicht. Und wenn es was ist, was ich nicht kenne, dann darf es eben nicht. Basta.

ShadowCaster - Do 17.04.03 13:39

ja luckie, da hast du recht, was die Firewall angeht. Das ist in der Tat richtig. Man kann eigentlich alles verbieten. Man kann auch verbieten, dass einkommende zip-Dateien nicht von der Firewall aufgemacht werden. Wenn du nämlich 2 GB mit lauter F's in eine Zip-Datei packst wird die vielleicht 50 kb groß. Dann schickst du die 10 mal an eine Firewall die alle gezipten Pakete aufmacht und scannt und dann ist die Firewall ausm Netz *g*.

Aber um auf das Problem zurückzukommen. Es wäre gar nicht schlecht ein Programm zu schreiben, was geziehlt Programme im System finden kann, die neu dazugekommen sind und versteckt im Ram laufen. Dann kann man sehen: Aha, ich hab gestern babylon installiert und heute läuft eine pcload.dll im Speicher. Was hat die da zu suchen? Weiterer Schritt ist dann: Anwendung kriegt ein Terminate-Signal und das Prog fliegt von der Platte :)

Delete - Do 17.04.03 13:44

Seit wann ist ein Firewall ein Packet-Sniffer? :shock:

Ein Firewall kuckt welches Programm raus will oder von wo von außen auf welchen Port zugegriffen wird. Die Daten interessieren ihn nicht, nur von wem sie kommen und wohin sie sollen.

ShadowCaster - Do 17.04.03 14:24

naja, bei einigen Firewall-Programmen lässst sich einstellen, dass reinkommende Packete gleich gescannt werden, so auch Zip-Dateien oder andere gepackte und für die firewall lesbare Packete.

chucky - Fr 18.04.03 20:42

Um zum thema zurückzukommen: würde es aber auch gerne mal wissen wie man sein programm komplett versteckt (unter 2k/XP)

die variante hier um sein programm in ME/98 zu verstecken ist etwas umständlich, das geht auch einfach. aber unter XP hab ich noch nirgends was dazu gefunden.

Motzi - Fr 18.04.03 22:13

chucky hat folgendes geschrieben:

aber unter XP hab ich noch nirgends was dazu gefunden.

Aus einem einfachen Grund - es geht nicht! (zumindest gibt es soweit ich weiß keine bekannte Möglichkeit und schon gar kein dokumentierte!)

chucky - Sa 19.04.03 16:18

es geht sehr wohl, sonst könnten es andere programme nicht auch :)

Motzi - Sa 19.04.03 16:44

chucky hat folgendes geschrieben:

es geht sehr wohl, sonst könnten es andere programme nicht auch :)

Nenn mir nur ein einziges! :roll:

ShadowCaster - Mi 23.04.03 11:50

naja, es wär eigentlich fast schade, dass ich kein Programm unter XP oder NT verbergen kann, wenn das wirklich nicht geht...

Delete - Mi 23.04.03 11:54

Gibt es denn einen Grund dafür? Ich sehe keinen, außer mal will einen Virus oder Trojaner schreiben. Ich hatte bisher noch nie das Bedürfnis meine Adress-Datenbank zu verstecken. :roll:
Desweiteren weiß ich eben gerne was so läuft und habe auch gerne die Möglichkeit es zu beenden, wenn es nicht mehr reagiert.

Motzi - Mi 23.04.03 12:27

Motzi hat folgendes geschrieben:

chucky hat folgendes geschrieben:

es geht sehr wohl, sonst könnten es andere programme nicht auch :)

Nenn mir nur ein einziges! :roll:

Irgendwie kommt da nix mehr... ;)

ShadowCaster hat folgendes geschrieben:

naja, es wär eigentlich fast schade, dass ich kein Programm unter XP oder NT verbergen kann, wenn das wirklich nicht geht...

Wieso willst du das unbedingt machen? Wenn es eine Sicherheits-Software werden soll dann konzipier sie als Service. Damit kann sie mit dem Standard-Taskmanager nicht beendet werden (außer über ein Zusatz-Prog wurde das SeDebugPrivilege gesetzt) und ein normaler User hat sowieso keinen Zugriff auf deine Services. Wenn du noch einen Schritt weitergehen willst dann konzipier das ganze als Teil des Betriebssystems und ersetz die MSGINA.DLL.

ShadowCaster - Do 24.04.03 09:08

lol... msgina.dll ersetzen... :lol: reicht ja schon, wenn man den service nicht beenden kann... Das würd mir reichen, meinen PC zu schützen.

Motzi - Do 24.04.03 12:56

ShadowCaster hat folgendes geschrieben:

lol... msgina.dll ersetzen... :lol:

Wieso lol? Das ist ein guter (um nicht zu sagen der beste) und sogar von Microsoft dokumentierter Weg das OS selbstständig um ein sicherheitssystem zu erweitern (Stichwort WLX - Windows Logon Extension) Einziges Manko: es ist wahrscheinlich auch am kompliziertesten und gefährlichsten...!

Zitat:

reicht ja schon, wenn man den service nicht beenden kann... Das würd mir reichen, meinen PC zu schützen.

Na dann an die Arbeit! ;)

SpeedyGTD - Do 24.04.03 22:42

ääähm, iss vieleicht der falsche Tipp, aber wenn ich verhindern will das jemmand mein Prog beendet, dann sag ich ihm wenn es geschlossen wird soll es den PC runterfahren, dann isses egal ob's beendet wird.

Delete - Do 24.04.03 22:47

Übernimmst du auch die Schandesersatzansprüche, wenn dabei wichtige Daten verloren gehen? :roll:

ShadowCaster - Fr 25.04.03 09:53

Das Problem ist wenn ich die msgina.dll ersetzen will muss ich eine Kopie des Quelltextes vom microsoft vorliegen haben, damit ich Funktionen in die DLL hinzufügen und sie verändern kann (deswegen lol). Den Quelltext rückt microsoft ja nich raus, nur eine ziemlich große Abhandlung (hab sie mir mal gezogen), wie ich die msgina.dll ersetze. Aber soviel ich sehe ist die msgina.dll ein Grafik-Interface... was hat das eigentlich mit der Verbergung eines Prozesses in Windows zu tun? Würd mich mal interessieren, da ich auf diesem Gebiet wenig bis gar nicht bewandert bin. :wink: (also bitte entschuldigt, wenn einige Aussagen in meinem Text nicht zutreffen, ich bin ja lernfähig)

Motzi - Fr 25.04.03 10:59

ShadowCaster hat folgendes geschrieben:

Wieso brauchst du den Code? Es gibt Dokumentationen wie man die MSGINA.DLL ersetzt und du schreibst ja im nächsten Satz selbst dass du eine solche besitzt..! :roll:

Zitat:

Den Quelltext rückt microsoft ja nich raus, nur eine ziemlich große Abhandlung (hab sie mir mal gezogen), wie ich die msgina.dll ersetze. Aber soviel ich sehe ist die msgina.dll ein Grafik-Interface... was hat das eigentlich mit der Verbergung eines Prozesses in Windows zu tun? Würd mich mal interessieren, da ich auf diesem Gebiet wenig bis gar nicht bewandert bin. :wink: (also bitte entschuldigt, wenn einige Aussagen in meinem Text nicht zutreffen, ich bin ja lernfähig)

Wenn du nicht weißt was das ganze mit der Verbergung eines Prozesses zu tun hat, dann lies dir mal deine Abhandlung durch! ;) Wenn du eine eigene GINA-Dll (GINA = Graphical Identification and Authentication) schreibst brauchst du deinen Prozess nicht mehr verstecken, da er dann einen (wichtigen!) Teil des Betriebssystems darstellt!

Nachtrag: bei den Jedis findest du unter "WLX" (Windows Logon Extension) auch eine Delphi-Portierung von Nico!

Delete - Fr 25.04.03 12:23

Ich denke mal von Nico wäre auch als einzigester hier in der Runde, in der Lage das vernünftig zu schaffen. Aber ich glaube, der ist so vernünftig und macht das nur, wenn ihn jemand eien Pistole an den Kopf setzt oder er entsprechend Geld bekommt und er einen sinnvollen Grund sieht. UInd nur, um eine eigene Anwendung zu verstecken reicht wohl nicht. Erklär mal einen SysAdmin, er soll wegen deinem programm die Gina ersetzen. :mrgreen:

ShadowCaster - Fr 25.04.03 12:51

Das Problem ist doch folgendes: Die MS-Gina Dll scheint ja ein Bestandteil des Systems zu sein. Also werden auch alle Funktionen die die Dll zur Verfügung stellt benötigt. Wenn ich also so enifach mal eben eine eigene Dll schreiben soll und die gina-dll ersetzen soll, dann muss ich doch auch alle bisherigen Funktionen dieser Dll in meiner auch zu Verfügung stellen, sonst kommts zum Systemcrash... oder etwa nicht? Das war jetzt keine Aussage, sondern nur eine Annahme von mir. :(

Delete - Fr 25.04.03 12:58

Ja. Aber du mußt sie nicht hardcoden, du kannst sie von deiner an die original DLL durchreichen.

Motzi - Fr 25.04.03 13:05

Luckie hat folgendes geschrieben:

Ich weiß! ;) Ich wollte eigentlich auch nur zeigen was für ein Aufwand das ganze ist und damit sich die Leute das mal anschaun und einen Vorgeschmack darauf bekommen wie komplex eigentlich das ganze System von Windows ist und ein Gefühl dafür bekommen was es bedeutet ein gutes Sicherheitssystem zu schreiben! ;)

ShadowCaster - Mo 28.04.03 10:51

Naja Leute, ich muss euch was interessantes berichten. Hier eine kleine Story von mir die ganz gut zu dem Thema passt:

Am WE ist mir folgendes passiert. Also ich hab mir doch so 64-k Demos von farb-rausch.com runtergeladen. Die sind echt super geil und ich bin auch ein fan davon (blabla ... hehe). Also da ist mir am Freitag abend so um 19:30 Uhr letzter Woche aufgefallen dass ein Demo kein Hintergrundbild mehr hatte (war so ein playerprogramm für Synthiedateien (dieses Demo heißt glaub ich BrullWurfel)). Hab dann in den Explorer geschaut und gesehen, dass meine 64k - Exe plötzlich 211 k groß war. ... *g* ich gleich gedacht. Da ist ein Virus drinnen! Und so war es auch. Immer mehr Dateien wuchsen um 177kb.

Also hab ich glein ein neues Update vom Virenscanner draufgehauen. Hat er mir gesagt: 16 Dateien mit dem Virus "pinfi" infiziert. Naja ich hab in den Taskmanager geschaut (habe windowsXP) und kein Prozess war sichtbar, schon komisch.

Ok, dann hab ich meinen Virenscanner die infizierten Dateien bereinigen lassen. So und jetzt kommt die Härte. Nach dem Systemneustart schau ich in die Verzeichnisse der infizierten Dateien und mein Virenscanner hat folgendes gemacht: Er hat alle infizierten Dateien kopiert und in infected umbenannt und ins quarantäne-Verzeichnis von sich geschoben, mehr nicht. Er hat nicht die infizierten Dateien gelöscht wie er sollte oder wie er gesagt hat. Dann hab ich ihn nochmal scannen lassen und 260 Dateien waren infiziert (nur Exe-Dateien)

Jede Exe wuchs um 177624-177690 Bytes. Hab mir dann mal den Hexeditor genommen und mir das mal angeschaut. In jeder Exe wo der infizierte Code drinnen war, sah der infizierte Code etwas anders aus. Hab Windows neu installiert und nach der Installation war er wieder drauf. Ich depp hatte wohl ne infizierte Datei ausgeführt. Und mein Virenscanner kannte den Virus plötzlich nicht mehr. Konnte nurnoch sehen wie immer mehr Dateien infiziert wurden und konnte nix machen. Sogar der Virenscanner selbst war infiziert. Ich kann gar nicht verstehen wie Norman Antivirus 5.5 Testsieger in der PC-Welt 2002 wurde. Das ist mir rätselhaft. Der Virenscanner sollte sich selbst doch als erstes checken ob er verändert wurde (also die eigenen Exe-Dateien). Ganz schön dumm von den Herstellern. Das müssen irgendwelche Anfänger gewesen sein, die den Normen-Virenscanner programmiert haben, irgendwelche Daus (MAN BIN ICH SAUER!!! :x ) Naja, habe mir ein Analyseprogramm in Delphi geschrieben und das hat folgendes zu Tage gebracht:

----------------------------------------------------------
Dateiwachstum der infizierten Dateien: 177624-177690 Byte
Virus infiziert Exe- und Scr-Dateien

Der infizierte Code der Dateien benutzt die Winapi-Funktion LoadLibraryA und GetProcAddress (wohl um eine Dll oder einen Prozess im Arbeitsspeicher zu erzeugen)

- Virus ist als Prozess unter XP im Taskmanager nicht sichtbar und resistent (das ist also der beste Beweis dafür dass es Anwendungen unter Windows gibt, deren Prozess nicht sichtbar ist)

- Infiziert offenbar nicht den Bootsektor des Systems (Virenscanner hat nur Exe- und Scr - Files entdeckt).

- Virus verschlüsselt sich mit einem 4 Byte langen XOR-Schlüssel

- Virus verändert PE-Header von Exe-Dateien und beschädigt eine Exe sogut wie nicht. Infizierter Code wird beim Start der Exe ausgeführt, nicht beim Beenden.

------------------------------------------------------------
Die Software von mir geschrieben extrahiert nur die infizierten Adressbereiche einer Exe und erstellt einen Logfile der Bereiche. Das hat folgende Details ans Licht gebracht.

Der PE-Header der Exe wird mit einer Größenänderung der Datei und einer Jump-Adresse an den Beginn eines Codes in der Mitte der Datei versehen. Dort steht wahrscheinlich ein Entschlüsselungscode mit einem Random-Schlüssel, der den Hauptteil des infizierten Virencodes verschlüsselt (alle infizierten Dateien sahen leicht anders aus). Der Schlüssel ist offenbar 4 Byte lang und wird mit XOR über den Viruscode gelegt. Der Entschlüsselungsteil der Exe ist ca. 20 Byte lang und der Code der Exe der vorher an dieser Stelle stand ist zerstört. Das führt dazu, dass einige Exe-Dateien abstürzen (beim Start). Von dem Entschlüsselungsteil folgt eine Jumpadresse an den eigentlich infizierten Teil des Viruses. Ich bin mit einem Hexeditor hergegangen und hab diesen Code mit Nullen überschrieben und beim Start der Exe kam dann: "Prozedureinstiegspunkt nicht gefunden". Genau das bestätigte, dass der Code am Anfang der Datei ausgeführt wurde. Charakteristisch für den Virus ist, dass der eigentliche Virencode am Ende der datei, der angefügt wird immer mit Hex 90 anfängt. Ab da variert der Code dank der Verschlüsselung in jeder infizierten Datei. Es wurden Dateien auch infiziert, obwohl der Explorer und sonstige Exe-Files im Arbeitsspeicher nicht infiziert waren und wenn ich keine Exe-Datei ausgeführt hatte. Das deutet auf einen Prozess im Arbeitsspeicher hin. Leider sind die geänderten Adressbereiche in den Exe-Dateien ziemlich unterschiedlich. Das macht die Erkennung des Viruses schwer.

Folgendes ist mir noch nicht gelungen: den Schlüssel zum Entschlüsseln des Virencodes rauszufinden, da der Virencode in jeder Exe anders verschlüsselt wird. Einen Virenscanner dafür hab ich noch nicht. Progge mir aber heute abend einen, und zwar einen der mir ne Sicherung aller Exe-Dateien vom System macht und dann nach jedem Scan des Systems schaut ob neue Dateien mit dem Virus infiziert worden sind und diese wiederherstellt. Allerdings muss ich noch herausfinden wie ich den Virenprozess beenden kann, vielleicht durch sofortigen Neustart des Systems nachdem alle infizierten Dateien gelöscht und wiederherstellt wurden, damit der versteckte Prozess keine Chance mehr hat, eine Datei zu infizieren.

Nach berichten auf der Norman-Antivirenhomepage hängt sich der Virus an den Explorer-Prozess, infiziert explorer.exe jedoch nicht. Aber deshalb ist er unsichtbar. ich müsste also den Explorer neu starten.
------------------------------------------

Offizielle Berichte des Viruses:

http://www.harmonysecurity.com/kungfoo.html (LoadLibraryA und GetProcAddress)
http://securityresponse.symantec.com/avcenter/venc/data/w32.pinfi.html (Abhandlung des Viruses)

Motzi - Mo 28.04.03 11:57

ShadowCaster hat folgendes geschrieben:

Nach berichten auf der Norman-Antivirenhomepage hängt sich der Virus an den Explorer-Prozess, infiziert explorer.exe jedoch nicht. Aber deshalb ist er unsichtbar. ich müsste also den Explorer neu starten.

Du schreibst es ja selbst.. der Virus hängt sich an exe-Dateien an und läuft damit in deren Prozessraum und stellt keinen selbstständigen Prozess dar..!

ShadowCaster - Mo 28.04.03 12:13

Doch, er stellt einen stelbständigen Prozess dar. Er extrahiert eine Datei ins Temp-Verzeichnis vom System und erstellt einen Registryschlüssel. Der explorer.exe wird nicht infiziert, jedoch hängt sich der Virus über den Kernel an den Explorer im Arbeitsspeicher. Insofern ist der Prozess nicht sichtbar.

Motzi - Mo 28.04.03 12:22

Gut.. wenn ich über CreateRemoteThread einen Thread in einem Fremden Prozess erstelle und dort meine Aktionen ausführe so ist dieser auch "versteckt", allerdings würde ich das nicht als "saubere" Vorgehensweise betrachten!

ShadowCaster - Mo 28.04.03 12:26

Naja, soweit ich mir den infizierten Code angeschaut habe, ist der schon von einem Profi programmiert worden. Jede Exe die infiziert wurde, sieht anders aus. Der benutzt einen ganz einfachen Schlüssel zur Verschlüsselung. 2-3 Jumpbefehle. Insgesamt ändert der Virus 50-200 Bytes in der infizierten Exe, mehr nicht. Dann kopiert er sich mit einem neuen schlüssel ans Ende der Datei und das wars.

Motzi - Mo 28.04.03 12:44

Naja.. die Verschlüsselung selbst sollte kein Problem darstellen (XOR ist absolut simpel und kann auch einfach geknackt werden!) Den Entry-Point im PE Header kann man eigentlich auch recht einfach ändern und ein Jump an den Original-Entry-Point nachdem der Virus ausgeführt wurde ist eigentlich auch simpel.

Aber das ganze scheint trotzdem recht interessant.. kannst du mal von einer Infizierten Exe den angehängten Teil rausschneiden und mir schicken? Würd mir das gern mal anschaun.. vielleicht kann ich das Ding auch entschlüsseln...

ShadowCaster - Mo 28.04.03 12:55

ja klar, das kann ich gern machen.. vielleicht morgen. ich hab auch schon dran gedacht, den Virus zu entschlüsseln. Also ich schick dir dann eine infizierte und eine nicht infizierte Exe-Datei und die beiden Dateien, die mein Programm kreirt hat, was alles vom Virus verändert wurde. (allerdings variieren die Änderungen in jeder Datei, so dass man nicht sagen kann: Die und die Adresse wieder auf den Originalpunkt setzen). Ich würde sagen, das Passwort sei "Pinfi"... werd dir morgen mal ein Zip damit schicken. Aber ich werde die Exe-Dateien in Dat-dateien umbenennen, damit du sie nicht versehentlich ausführst.

Der Virus benutzt das Temp-Verzeichnis von Windows um sich zu reproduzieren. dort erstellt er eine Temp-datei (die Dll oder exe). Dann erstellt er noch einen Registry-Eintrag. Kannst du alles in der offiziellen Abhandlung nachlesen. (hab ich oben gepostet)

Motzi - Mo 28.04.03 13:11

ShadowCaster hat folgendes geschrieben:

Dankeschön..!

Zitat:

Der Virus benutzt das Temp-Verzeichnis von Windows um sich zu reproduzieren. dort erstellt er eine Temp-datei (die Dll oder exe). Dann erstellt er noch einen Registry-Eintrag. Kannst du alles in der offiziellen Abhandlung nachlesen. (hab ich oben gepostet)

Jo, hab ich schon gelesen... falls du die Datei die er im Temp-Verzeichnis erstellt auch hast bitte auch schicken..!

ShadowCaster - Mo 28.04.03 13:30

logo, werd ich machen. *G*... mein System ist immer noch infiziert aber scheiß egal. Hab meine Daten (keine Exe-Dateien) gesichert.

Sag hättest du bock, an einem Projekt für einen Virenscanner zu arbeiten? Wäre doch ganz witzig ;)

ShadowCaster - Mo 28.04.03 13:35

Noch ein Problem bei den ADressangaben in der EXE im PE-header: Also da werden Lowbyte und highbyte vertauscht. Wie sieht das jetzt aus wenn ich 11223344 hexadezimal abspeicher? Das ist das Problem. Denn die im PE-header veränderten Adressen sind alle utopische werde. Ich schätze, da sind die Low- und Highbytes vertauscht aber wie sieht das jetzt im Hex-Stream aus?

Motzi - Mo 28.04.03 14:11

Beim Speichern werden die 4 Bytes in umgekehrter Reihenfolge gespeichert. zb:
1 normal = 00 00 00 01
1 gespeichert = 01 00 00 00

oder
123456789 normal = 07 5B CD 15
123456789 gespeichert = 15 CD 5B 07

ShadowCaster - Mo 28.04.03 14:54

und wie wird hexadezimal "11223344" gespeichert?

Motzi - Mo 28.04.03 15:12

11223344 normal = 00 AB 41 30 -> gespeichert = 30 41 AB 00

ShadowCaster - Mo 28.04.03 15:18

ich rede von hexadezimal 11223344 also je ein HAlbbyte

also wenn das umgekehrt gespeichert wird, dann müsste das anschließend 44332211 sein?

ShadowCaster - Mo 28.04.03 15:28

ok, habs geblickt.. weiß jetzt auch woher ich den virus hab. War mein Verdacht richtig. Ein bekannter hat mri ein Prog geschickt und das war von einer Lanparty versaut worden.

Werd mich mal heute abend an die Entschlüsselung des infizierten Codes machen. Sollte nicht so schwer sein. Der Schlüssel scheint ja mit XOR drüber gelegt zu werden. Es sieht aus als wäre die Datei eine ausführbare und asl wären am Ende lauter 0000000-en und verschlüsselt sehen die z.B. so aus. 03FA00DA 03FA00DA 03FA00DA...

Ich schätze, so kann ich an den Schlüssel kommen. In Exe-Dateien oder Dll's ist es meistens so, dass noch eine Reihe von Nullen am Ende der Datei frei sind. Ich sag morgen bescheid, wie weit ich bin.

Motzi - Mo 28.04.03 17:22

Das mit dem entschlüsseln dürfte nicht so ein Problem sein... XOR-Verschlüsselung ist sehr leicht zu knacken und ein 4Byte Schlüssel ist extrem kurz!

ShadowCaster - Di 29.04.03 09:40

Hi Motzi, hi all,

ich hab den Virus gestern abend entschlüsselt. Man muss nur die letzten 4 Byte der Exe-Datei nehmen und mit XOR über die Datei legen. War sehr simple und klappt immer. So wie der Header des Teils aussieht, handelt es sich dabei um eine Exe (172kb groß) aber scheint nicht ausführbar zu sein. Vielleicht ist es auch eine Dll.

Jetzt mal ein paar Detailinformationen über den Pinfi-Virus:

- er ist in c++ programmiert
- er nutzt UDP-Komponenten um sich übers Netzwerk zu zerstreuen
die infizierte Exe besteht aus folgenden Teilen:
- dem veränderten PE-Header
- kurz hinter dem PE-Header wird noch was gändert
- mitten in der exe werden ein paar Sachen geändert (vermutlich ist das der Entschlüsselungscode, der den Prozess in den Ram lädt.
- Am Ende der exe wird ein verschlüsselter Code angefügt, der immer mit hexadezimal 90 beginnt. Ein Teil des Codes am Anfang des verschlüsselten Teils ist unverschlüsselt. Er beinhaltet ein paar Funktionen (LoadLibraryA, GetProcAddress). vielleicht steht hier auch der Entschlüsselungscode und die Funktion dafür, damit es nicht auffällt.

So wie der Virus aussieht, ist der nicht mal ein bisschen in assembler geschrieben..., war also kein Profi der den programmiert hat. 177 k sind echt viel.

Achja, mir ist es jetzt schonmal möglich, einen Virenscanner zu schreiben ;) und ich muss nurnoch die PE-Header für Exe-Dateien haben und dann auf ans werk und ich schreib ein Prog, was das System wieder cleaned. Ich muss nur ein Prog oder eine Prozedur haben, was den Explorer-Prozess beenden kann(hart terminieren). :wink:

Motzi - Di 29.04.03 10:05

Der Hexcode 90 entspricht dem ASM-Befehl NOP = No Operation
Wär interessant welche Dll mit LoadLibrary geladen wird und von welcher Funktion die Adresse gesucht wird.
Den Explorer kann man recht leicht killen, einfach mit OpenProcess ein Process-Handle besorgen und mit TerminateProcess abschießen. Falls OpenProcess kein gültiges Handle zurückliefert (Fehlermeldung = Kein Zugriff) musst du erst noch das SeDebugPrivilege aktivieren.

ShadowCaster - Di 29.04.03 10:09

Ok, ich werd mir mal die Infos holen. Dank des viruses hab ich derzeit kein Netz daheim (no Internet). Werd dir den Virus schicken sobald daheim alles wieder online ist. Das Problem ist, wenn ich die hexadezimale 90 mit 00 überschreibe, dann bringt mir das Programm die Meldung "Prozedureinstiegspunkt nicht gefunden". Komisch. :(

Motzi - Di 29.04.03 10:26

ShadowCaster hat folgendes geschrieben:

Das Problem ist, wenn ich die hexadezimale 90 mit 00 überschreibe, dann bringt mir das Programm die Meldung "Prozedureinstiegspunkt nicht gefunden". Komisch. :(

Vielleicht ist es in diesem Fall auch einfach ein Teil einer Jump-Adresse...

ShadowCaster - Di 29.04.03 10:28

Stimmt das könnte möglich sein. Vielleicht ist das eine Jumpadresse in den internen Viruscode weil ja ein teil des infizierten Codes ist nicht verschlüsselt und beinhaltet Funktionen, den Virus in den Arbeitsspeicher zu laden. Werd mir das mal reinziehen.

ShadowCaster - Mi 30.04.03 13:56

Hi Leute,

hab den Virus gestern abend disassembliert. Gut 98 % des Codes sind nicht lesbar, da nur Hex-zahlen. Mein Disassembler ist nicht so gut, muss mir mal einen besseren holen. Ansonsten ist es stark zu sehen, wie das Ding aufgebaut ist. Die Datei ist allein 5,5 MB groß. Einen Scanner hab ich auch fast fertig. Brauch nurnoch die PE-Header einer Exe und dann sehe ich mal, ob ich einen Antivirenscanner (ups... Aussage ist nicht korrekt, muss Antivirus heißen :oops: ) dafür geproggt krieg. Am Freitag gibt es mehr! :D

ShadowCaster - Fr 02.05.03 16:35

So, der Virenscanner ist fertig. Er scannt die Registry und jede Exe im System, die geöffnet werden kann. :) So genial... es funktioniert.

Das witzigste ist, dass der Virus die BitBlt-Funktion von Windows mit einem Offset benutzt, um sich selbst hu verschlüsseln. Das heißt, es wird auf jeden 4Byte-Wert ein Offset aufgerechnet mit XOR....

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!