Guten Tag,
ich hoffe ich bin hier in der Sparte richtig.. sonst evt. Dateizugriff..

Ich kenne Programme, die Listen alle Datenpackete auf, die geschickt werden (z.B. Strings werden angezeigt woher sie kommen (Anwendungsname) und wohin sie gehen sollen (IP + Port)..). Dazu gibt es Inline-Änderungen, die zB. seinen String abändern können und diese "Datenpackete" werden erst auf Knopfdruck abgeschickt...

Ich wollte mal fragen, ob man auch in Delphi eine solche "Packetkontrolle" programmieren könnte, bzw. wie.

Warum? Ganz einfach ich möchte mal wissen was geschickt wird und wie man daran kommen könnte.. ebenfalls würde ich, wenn ich es schon "abfangen" kann diese auch mal ändern (z.B. bei Chats einfach mal testen)


Wissen: Alles was verschickt wird, besteht aus 1 und 0 (logisch), der Typ ist meineswissen NICHT enthalten, oder?
Daher müsste man es als "alles" betrachten können (z.B. 0100 0001 = 65 (Byte) = 'A' (Char) etc.)

Ich fände es intressant zu erfahren wie man soetwas "erkennen" kann und woran.. Sind Strings am #0 am Ende zu erkennen, und wie sicher ist eine solche Erkennung?

mfG IHopeOnlyReader

Mit Delphi wird das so kaum gehen, da du damit keine Treiber schreiben kannst (jedenfalls nicht sinnvoll). Wie so etwas geht siehst du im Wireshark Quelltext, der ja als Open Source einsehbar ist:
sourceforge.net/projects/wireshark/

IhopeonlyReader hat folgendes geschrieben :

Ich wollte mal fragen, ob man auch in Delphi eine solche "Packetkontrolle" programmieren könnte, bzw. wie.

jaenicke hat folgendes geschrieben :

Mit Delphi wird das so kaum gehen, da du damit keine Treiber schreiben kannst (jedenfalls nicht sinnvoll).

Ich muss mich da anschließen. Du könntest allerdings WinPCap mit Delphi verwenden. Dafür gibt es bereits eine Freeware-OpenSource-Komponente, den KolSniffer, der die Daten aus WinPCap entgegennimmt.


P.S. "Paket" im Deutschen, "Package" im Englischen

Naja, das stimmt nicht ganz, das geht sehrwohl mit Delphi auch.
Vorallem weil ich soetwas hier am Laufen habe (zwar nicht immer, aber wenn ich mal etwas analysieren will).

Ich hab mir dein Profil angesehen - sofern du soetwas realisieren willst, müsstest du dir ein bisschen mehr Wissen über folgende Themen aneignen:
- Hooking (IAT-Hooks, Global DLL Hooks)
- DLL Programmierung (API, Dlls erstellen usw)
- IPC Kommunikation
- (das wichtigste) Protokoll-Reversing Skills (oder Nachschlagwerk)

Funktionsweise:
Die Netzwerkkommunikation läuft über 5-10 wichtige API-Befehle ab (die in der WinSock bzw diversen anderen Dlls definiert sind).
Wichtig sind uA: send(), sendTo(), recv(), recvFrom()
(und die WSA Versionen davon).
Das sind nämlich genau jene Funktionen, die du belauschen musst.

Jede Applikation verwendet für diesen Zweck genau diese Funktionen - daher haben all diese Anwendungen auch die dafür notwendigen Dlls geladen (im Speicher).

Was nun getan werden muss, ist, ne (eigene) Dll zu schreiben, die beim Hook-Start nach der einen Dll, die die Netzwerkfunktionen bereitstellt, im Speicher sucht und diese dann IAT-Hookt. Wichtig ist auch, dass man diese (eigene) Dll so programmiert, dass sie über IPC mit einem bestimmten Prozesss kommuniziert (mit der eigenen GUI dann, damit die Daten angezeigt werden können).

Wichtig ist, dass man das Setzen von globalen Hooks windowsseitig auch versteht - SetWindowsHookEx() sorgt dafür, dass der zu setzende "globale Hook" (die eigene Dll) bei allen Prozessen "geladen" wird. Dadurch spielen die beiden Hooks "miteinander" - dh du sagt per API Befehl SetWindowsHookEx() dass eine bestimmte Dll als Hook gesetzt werden soll, Windows sorgt dafür, dass die Dll bei allen Prozessen (natürlich mit gleichen Rechten - daher ist dieser Usermode Hook auch eingeschränkt) nachgeladen wird.
Beim Starten der Dll wird eben der IAT-Hook intern für jeden Prozess ausgeführt - dieser, wie bereits beschrieben, "belauscht" dann die oben genannten Netzwerk-Funktionen.
Wetiers kommunizieren alle Dlls (also alle Instanzen die in den verschieden Anwendungen nachgeladen wurden) mit deiner GUI über IPC.

Nun der wichtigste Punkt:
Sofern du nicht weißt, was für ne Art von Protokoll benützt wird (Blockbox-Analyse), musst du diverse Techniken anwenden, um das Protokoll zu reverse-engineer'en.
Du bekommst nämlich nur Datenblöcke gemeldet - beispielsweise soetwas hier:
0x04 0x41 0x41 0x42 0x42
Für das geübte Auge ist leicht zu erkennen:
Hierbei handelt es sich um einen (Pascal)-String - das erste Byte gibt die Länge vom String an (4)
was folgt ist "AABB" (in ASCII Darstellung)

Protokolle sind nicht einfach zu reversen. Die Kunst an dem Ganzen liegt genau darin.

[OT]
Btw. da wo ich das gerade so ausführlich erklärt habe, möchte ich kurz an alle UPX-Gegner ne Message schicken:
"Einer der Nachteile von UPX ist der Verbrauch von mehr Speicher" ist einner der Argumente -- im Grunde braucht UPX nur eine Entpackroutine, um zur Laufzeit die Daten im RAM zu entpacken (auch mal selber programmiert). Diese Entpackroutine braucht seinen Speicher - auf der HD benötigt sie weniger Speicher, da die originale EXE/DLL ja gepackt (verkleinert ist) und der Entpack-Stub nur wenige Byte bis KB braucht. Jedoch hat man die Entpackroutine bei der Laufzeit auch noch im Hauptspeicher rumfliegen, daher sind sie zur Laufzeit minimal größer / beanspruchen ein bisschen mehr Speicher.
Das Problem ist nun bei den globalen Hooks - hier wird richtig hochskaliert.
Wenn die Dll 1x gestartet ist und der Stub beispielsweise nur 2 kb ist, so brauchts ca 2kb mehr Speicher. Durch den globalen Hook wird die Dll jedoch öfters geladen - also "x" mal - dadurch benötigt das ganze dann x*2kb mehr Speicher - das ist der einzige Grund, warum man UPX nicht verwenden soll (mal abgesehen von den AV-false-positives).
(Könnte mich jeman aufklären bzgl Shared-Memory? Kann es sein, dass Dlls wirklich nur 1x im Hauptspeicher liegen (laut Theorie werden unveränderbare Daten einmal geladen (sprich Code usw) - jedoch ist gepackter Code != unveränderbar))
Conclusio - UPX schlecht für globale Hooks, gut für alles andere!
[/OT]

Klingt für den Anfang evt ein bisschen schlimm, ists aber gar nicht..

MfG

Emre, schonmal danke

mit send, sendto wusste ich
wie ich diese belausche wusste/weiß ich noch nicht... mit Hooks habe ich ebenfalls noch nicht gearbeitet
Aber das wäre dann wohl das nächste gebiet
Vielen Dank für deine Inofs, wie fange ich am besten an?
Hooks "üben" oder Dlls? oder doch ganz wo anders..

wenn ich ehrlich bin, versteh ich das Prinzip schon, aber für die Umsetzung in Delphi fehlt mir dafür eigentlich alles...

bitte um Starthilfe

Nun du kannst selber entscheiden, was du zuerst recherchierst und lernst.
Die drei genannten Punkte sind Basics. Der vierte Punkt ist, wie gesagt, der (rel.) schwerste.

Ich folgendermaßen rangehen:
- Dll Programmierung lernen, eigene Funktionen exportieren/importieren (API~),
- IPC (Luckie oder Assabard hat da mal ein Tutorial veröffentlicht; ist eig. rel. einfach)
- was sind Hooks (globale Hooks [einfacher für den Start], dann den IAT-Hook [steht für Import-Adress-Table Hook]).
Die Import Table befindet sich in EXE/DLLs und gibt an, welche Funktionen importiert werden. Hier kannste dann die Adressen "umbiegen".. Recherchiere am besten selber, ich kann dir das alles nicht erklären, soviel Zeit hab ich gar nicht xD
Hierfür benötigst du Wissen über die PE Struktur (PE=Portable Executable = EXE & DLL --> auf der www.wotsit.org findest du die Spezifikation)
(für diesen Punkt kannste, sofern du es nicht unbedingt verstehen willst, diverse Libraries verwenden... eine meiner Libraries sollten im Umlauf sein; als Alternative gibts auch noch die große Library-Sammlung von madshi verwenden)

Mr_Emre_D hat folgendes geschrieben :

auf der HD benötigt sie weniger Speicher, da die originale EXE/DLL ja gepackt (verkleinert ist) und der Entpack-Stub nur wenige Byte bis KB braucht.

Was heutzutage in 99,9% der Fälle genau Nullkommanull Vorteile bringt... die ausführbaren Dateien an sich sind im Vergleich zu anderen Daten schlicht so klein, dass es keinen Unterschied macht, ob die .exe komprimiert ist oder nicht.
Deshalb sehe ich keinen Grund deshalb Virenscanner misstrauisch zu machen.

Schlecht ist das Packen jedenfalls z.B., wenn es darum geht Fehler zu finden. Normale Anwendungen kann man einfach mit den Debugdateien ausstatten (.dbg) und bekommt von Windows ggf. genau serviert wo ein Problem aufgetreten ist und kann zur Laufzeit auch jederzeit feststellen wo welcher Thread ist (Process Explorer) um z.B. Deadlocks zu finden. Mit gepackten Anwendungen ist das so nicht möglich.

Was jedenfalls Hooks angeht:
Bist du sicher, dass man damit alle Funktionen nachbilden kann, die ein echter Sniffer kann?

Zitat:

Mr_Emre_D hat folgendes geschrieben : auf der HD benötigt sie weniger Speicher, da die originale EXE/DLL ja gepackt (verkleinert ist) und der Entpack-Stub nur wenige Byte bis KB braucht. Was heutzutage in 99,9% der Fälle genau Nullkommanull Vorteile bringt... die ausführbaren Dateien an sich sind im Vergleich zu anderen Daten schlicht so klein, dass es keinen Unterschied macht, ob die .exe komprimiert ist oder nicht. Deshalb sehe ich keinen Grund deshalb Virenscanner misstrauisch zu machen.

Ja, eig. schon; nicht jeder hat eine super Leitung wo er mit mehreren hundert kb/s (geschweige den mb/s) runterladen kann. Für solche Zwecke ist es wunderbar!

Zitat:

Schlecht ist das Packen jedenfalls z.B., wenn es darum geht Fehler zu finden. Normale Anwendungen kann man einfach mit den Debugdateien ausstatten (.dbg) und bekommt von Windows ggf. genau serviert wo ein Problem aufgetreten ist und kann zur Laufzeit auch jederzeit feststellen wo welcher Thread ist (Process Explorer) um z.B. Deadlocks zu finden. Mit gepackten Anwendungen ist das so nicht möglich.

Bist du dir da sicher? Zur Laufzeit befindet sich der Code nämlich im Originalzustand im Speicher (meistens auch an selber Stelle, wo es wäre, wenn nicht komprimiert).
Ansonsten - ich lass immer nen externen Debugger drüber laufen (OllyDbg) oder ich bau direkt ein Logging-System für die Debug-Version ein.
Aber du hast evt. recht! Könnte ein Minus-Punkt sein.

Zitat:

Was jedenfalls Hooks angeht: Bist du sicher, dass man damit alle Funktionen nachbilden kann, die ein echter Sniffer kann?

Die Frage ist zu unspezifisch. "Echte" Sniffer laufen im Kernelmode (Treiberebene). Im Grunde arbeiten diese fast genauso - nur sind sie nicht so eingeschränkt.
Also um ganz ehrlich zu sein, habe ich selber noch keine Erfahrung mit Kernelmode Dingern gemacht - ich hab nur allgemeines Wissen darüber!

Was ich aber sagen kann, ist, dass man im Grunde eigentlich auch im Usermode mehr oder weniger vieles anstellen kann; Restriktionen wie z.b in höher priviligierte Prozesse Hooks installieren geht ja nicht ohne weiteres - dazu muss dann der Hook-Installer auch mit denselben Rechten laufen usw. - dieses Problem hat man im Kernelmode meines Wissens nach nicht - es gibt sicher wetiere Restriktionen!

Edit: Also sein Vorhaben lässt sich - wie beschrieben - realisieren!

Mr_Emre_D hat folgendes geschrieben :

Zitat: Mr_Emre_D hat folgendes geschrieben : auf der HD benötigt sie weniger Speicher, da die originale EXE/DLL ja gepackt (verkleinert ist) und der Entpack-Stub nur wenige Byte bis KB braucht. Was heutzutage in 99,9% der Fälle genau Nullkommanull Vorteile bringt... die ausführbaren Dateien an sich sind im Vergleich zu anderen Daten schlicht so klein, dass es keinen Unterschied macht, ob die .exe komprimiert ist oder nicht. Deshalb sehe ich keinen Grund deshalb Virenscanner misstrauisch zu machen. Ja, eig. schon; nicht jeder hat eine super Leitung wo er mit mehreren hundert kb/s (geschweige den mb/s) runterladen kann. Für solche Zwecke ist es wunderbar!

klick
klick

Hallo,

Mr_Emre_D hat folgendes geschrieben :

Ja, eig. schon; nicht jeder hat eine super Leitung wo er mit mehreren hundert kb/s (geschweige den mb/s) runterladen kann. Für solche Zwecke ist es wunderbar!

Ist es nicht, wenn UPX-gepackte Programme das System + Virenscanner in's Schwitzen bringen.
Das hatte ich gerade und Win8 hat das gar nicht gemocht und schlichtweg die Weiterarbeit verweigert.
Deshalb mein Tip: Hände weg von UPX!

Die beiden von Boldar angegeben Links genügen wohl, um eine Exe "klein zu kriegen".

Beste Grüße
Mathematiker

Das System nicht, nur manche AVs, wobei das auch nur in der Vergangenheit so war - heutzutage können die meisten AVs die Dinge beim Überprüfen entpacken!
Das sind sehr oberflächliche Argumente!

Mr_Emre_D hat folgendes geschrieben :

Das System nicht, nur manche AVs

Ich habe das schon ein paarmal gehört, aber nie selbst gesehen. Trotzdem würde ich es nicht bestreiten, dass das passieren kann, nur weil es mir noch nie selbst passiert ist... das halte ich für etwas arrogant, falls du das so meintest.

Mr_Emre_D hat folgendes geschrieben :

Das sind sehr oberflächliche Argumente!

Stimmt, da ist "haha, ich spare ein paar Megabyte auf ner Festplatte von nen paar hundert Gigabyte" natürlich ein viel besseres Argument...

okay... ich denke ich weiß nun, wie ich anfangen muss.. wann ich dazu komme weiß ich leider noch nicht..

Und jaenicke und Mr_Emre_D bitte nicht streiten wir wollen alle nur helfen

Zitat:

Mr_Emre_D hat folgendes geschrieben : Das System nicht, nur manche AVs Ich habe das schon ein paarmal gehört, aber nie selbst gesehen. Trotzdem würde ich es nicht bestreiten, dass das passieren kann, nur weil es mir noch nie selbst passiert ist... das halte ich für etwas arrogant, falls du das so meintest.

Arrogant? Ich weiß nunmal, wie Packer funktionieren. Ich habe viel in diese Richtung gemacht - das einzige, was das System beeinträchtigen kann, ist die AV-Software, die meistens tief verankert im System drinnen sitzt. Das Problem ist dann aber nicht das System sondern die AV Software! Ich sehe da keine Arroganz!
Edit: Nun gut, es kann etwas geben, was ich in dieser Hinsicht noch nicht kenne/weiß.. Ich mags einfach nicht, wenn einer etwas schlecht macht und dabei nur oberflächlich argumentiert - weil ich hauptsächlich vom Gegenteil überzeugt bin!

Zitat:

Mr_Emre_D hat folgendes geschrieben : Das sind sehr oberflächliche Argumente! Stimmt, da ist "haha, ich spare ein paar Megabyte auf ner Festplatte von nen paar hundert Gigabyte" natürlich ein viel besseres Argument...

Ja schon, weil das nicht genauer begründet worden ist. Ein AV-Loses System (kann ich übrigens nur empfehlen; warum?) leidet darunter kaum! Und Speicher zu sparen ist besser als kein Speicher zu sparen - ganz egal wie marginal das ist.
Paar kbs weniger machen viel aus z.B. in der Demoscene oder wenn man mal Anwendungen für Embedded Systems entwickeln will!
Hier gehts um Prinzip...

Hallo,

Mr_Emre_D hat folgendes geschrieben :

Zitat: Mr_Emre_D hat folgendes geschrieben : Das sind sehr oberflächliche Argumente! Stimmt, da ist "haha, ich spare ein paar Megabyte auf ner Festplatte von nen paar hundert Gigabyte" natürlich ein viel besseres Argument... Ja schon, weil das nicht genauer begründet worden ist.

Nun ist aber es gut! Ich wollte mich zwar zurückhalten, aber das ist doch zuviel!

Mir persönlich ist es sch...egal, ob das System abschmiert oder der Virenscanner das System zum Stehen bringt. Steht der Rechner, bin ich stocksauer.
Und wenn eine UPX-gepackte Exe der Auslöser ist, dann liegt es an UPX! Greift ein Programm auf eine Art und Weise in den Rechner ein, wie es normalerweise nur Schadprogramme tun, dann müssen doch nicht die Virenprogramme sich UPX (es ist ja kein Windows-Standard) anpassen.
Und das hat Nichts mit Oberflächlichkeit der Argumentation zu tun. Dabei ist es mir auch egal, ob Du Dich mit Packern auskennst. Jedes Programm, dass mein System zum Stehen bringt, fliegt 'runter.

Und bevor Du dem Virenscanner die Schuld gibst ... Der bleibt! Schließlich schützt er mich ja gerade vor solchen Programmen, die sich "nicht normal" verhalten.

Beste Grüße
Mathematiker

Zu diesem Thread fällt mir nur eins ein....

Zitat:

"Multiple exclamation marks are a sure sign of a diseased mind." -Terry Pratchett

Beim Threadthema sind wir hier schon lange nicht mehr, ich mach also erstmal zu. Wenn ihr euch weiter über UPX unterhalten wollt, bitte (z.B. per VA) melden und ich fummle den Teil dann hier raus. Tut mir leid für den Threadersteller, aber das führt hier sonst nur zu noch mehr Chaos.