WPE weiterentwicklung

[reijin]

Originally posted by rEdoX@Aug 29 2006, 12:58
Ich habe mir ein eigenes format ausgedacht mit dem man die packets speichern/laden kann. Nen konverter koennen andere machen

Ab jetzt wird es laenge rdauern bis updates kommen, da ich die woche nicht viel zeite habe und es jetzt anfaegt schwieriger zu werden.

schade^^
aber ok, das macht nix, halt uns einfach aufm laufenden

wann gibts voraussichtlich das erste Release?

[img]text2schild.php?smilienummer=1&text=gruuuuuuuß' border='0' alt='gruuuuuuuß' />

[rEdoX]

So, ich melde mich hier mal wieder mir einem neuen feature :O



Den Filtern, was meiner meinung nach mit einer der schwersten parts gewesen ist.
Die Filter funktionieren genauso wie in WPE, habe sie bis jetzt nur in WS1::Send eingebaut, einerseits wegen zeitmangels andererseits weils ne sau tipp arbeit ist und ich solche sachen imemr vor mir her schiebe (genau so wie SendTo/RecvFrom :? )

Da wir in den wochen bis zu den herbstferien 8 klausuren schreiben, wird das nächste update auf sich warten lassen .

so far

//Edit: uppps screen vergessen :>

[Dodge]

könntest du vlt einen PreRelease oder so rausgeben?^^
brauche nur packtes log und anzeige was drin drin steht (als hex und als plaintext)^^

brauch nen genaus o ein tool, finde wpe nirgends =/


MfG DodgeX

[Kingdingelling]

<,< bisl suchen ja

[Dodge]

<,< bisl suchen ja

hm ja google 4tw aber boardsuche vergessen T_T""


Sorry XD

[rEdoX]

Habe mich dazu entschloßen hier mal die aktuelle version zum download freizugeben.

Download weiter unten

Würde mich ueber kritik und/oder anregungen freuen.

Wenn ihr fehler findet bitte posten, danke.

Die file ist zu 100% virenfrei :>


/!&#092; Ich übernehme keinerlei verantwortung fuer folgeschäden oder sonstiges /!&#092;

[CyRuSTheViRuS]

Hm scheint noch etwas buggy zu sein...
Hab ma paar packets von mirc gesnifft nach ner zeit kam irgend ne fehlermeldung und mirc is abgekackt das selbe mit ro und msn messenger

ich versuch die fehler mal zu rekonstruieren und poste die meldung ;D

---------------------------
FormDLL: mirc.exe - Fehler in Anwendung
---------------------------
Die Anweisung in "0x0174669f" verweist auf Speicher in "0x00000000". Der Vorgang

"written" konnte nicht auf dem Speicher durchgeführt werden.


Klicken Sie auf "OK", um das Programm zu beenden.
Klicken Sie auf "Abbrechen", um das Programm zu debuggen.
---------------------------
OK Abbrechen
---------------------------

Glaub der Fehler tritt auf wenn man auf File New geht also um packets vom n andren prozess zu sniff000r0000rn oder so ;o

Das Interface ist auch etwas buggy, nämlich wenn man was aufgenommen hat dann stop drückt und nomma was aufnehmen will überschneiden sich die ziffern irgendwie.

[rEdoX]

Wie gesagt es ist ne beta ->

Das mit File New ist mir bekannt, werde ich eben ausbauen.

download weiter unten

Kannst du mal nen sceenshot machen von der gui, verstehe nicht ganz was du meinst :> ?

[SilonVier]

Originally posted by rEdoX@Sep 6 2006, 18:06
Den Filtern, was meiner meinung nach mit einer der schwersten parts gewesen ist.

Der schwerste Teil ist der Userkontakt mit dem rauskitzeln von brauchbaren Informationen zur Behebung des unerwünschten Verhalten der Applikation (um das Wort "Bug" zu vermeiden )

Ich habe mir deinen Packet Editor ein wenig angeguckt, hier meine Vorschläge:

- Du prüfst an keiner Stelle in deiner Software ob der Benutzer die nötigen Rechte hat, du gehst davon aus das die Software als Administrator ausgeführt wird (ich für meinen Teil arbeite am System mit minimalen Rechten).

- In der Funktion wo du die Pointer für die Winsock APIs und das Handle für die benötigten Dlls ermittelst, solltest du die Rückgabewerte vor dem Aufrufen der SetHook-Funktion(oder wie immer du sie bei dir genannt hast) prüfen als mit einem ungesetzten Hook aus der SetHook-Funktion zu kommen (was du übrigens auch nicht prüfst ob das erfolgreich war - soweit ich das korrekt gesehen habe)

- In der gleichen Funktion wie gerade beschrieben, rufst du unnötigerweise mehrfach die GetModuleHandle API auf, wo du nur 1 Aufruf und 1 lokale Variable brauchst.

- Wenn die ws2_32.dll oder wsock32.dll noch nicht geladen sind, kannst du sie ruhig selbst in den Prozess laden und deine Hooks schon mal setzen. Falls die Zielapplikation auf die Idee kommt die gleichen Dlls noch mal zu laden, kriegt es als HMODULE das geladene zurück.

- Du solltest auch einen Hook auf FreeLibrary/LoadLibrary setzen (das letztere für eine Alternative für meinen obigen Vorschlag). Es kann vorkommen dass das Spiel die ws2_32.dll entläd und später wieder läd. Würde das dein Packet Editor mitkriegen und die hooks noch einmal setzen? -> So könntest du in der IDE eine entsprechende Meldung darstellen.

- Du könntest dazu SetUnhandledExceptionFilter benutzen und im Filter die Exceptions/Register loggen. Falls du gerissen bist, addierst du zum EIP immer eine Eins und lässt die Applikation fortfahren. Damit stürzt die nicht mehr ab aber vielleicht bemerkt der User nicht das eigenartige Verhalten ... NEIN, das war nur Spass, das solltest du NICHT tun ;-)

- Das folgende sieht einfach nur unschön aus(...):

00398B24 . A1 D0AC3900 MOV EAX,DWORD PTR DS:[39ACD0] ; kannst du dir sparen
00398B29 . C640 0C 00 MOV BYTE PTR DS:[EAX+C],0
00398B2D . C600 00 MOV BYTE PTR DS:[EAX],0
00398B30 . C640 01 00 MOV BYTE PTR DS:[EAX+1],0
00398B34 . C640 02 00 MOV BYTE PTR DS:[EAX+2],0
00398B38 . C640 03 00 MOV BYTE PTR DS:[EAX+3],0
00398B3C . C640 04 00 MOV BYTE PTR DS:[EAX+4],0
00398B40 . C640 05 00 MOV BYTE PTR DS:[EAX+5],0
00398B44 . C640 06 00 MOV BYTE PTR DS:[EAX+6],0
00398B48 . C640 07 00 MOV BYTE PTR DS:[EAX+7],0
00398B4C . C640 08 00 MOV BYTE PTR DS:[EAX+8],0
00398B50 . C640 09 00 MOV BYTE PTR DS:[EAX+9],0
00398B54 . C640 0A 00 MOV BYTE PTR DS:[EAX+A],0
00398B58 . C640 0B 00 MOV BYTE PTR DS:[EAX+B],0
00398B5C . A1 C0A93900 MOV EAX,DWORD PTR DS:[39A9C0]
00398B61 . C600 00 MOV BYTE PTR DS:[EAX],0

Ich weiss nicht ob das von dir stammt, oder es sich um ein Resultat des Compilers handelt. Einer der Gründe hier ZeroMemory (sollte in Delphi geben; ich bin kein Delphi-Entwickler) aufzurufen, wäre, dass wenn du die struct erweiterst, nicht ständig manuell die Stelle anpassen musst. Wozu die restlichen Operationen im Codeschnipsel darstellen sollen, will ich nicht so richtig Wissen ;-)
Ist das die struct die du später benutzt um die GUI zu informieren?

[rEdoX]

Der schwerste Teil ist der Userkontakt mit dem rauskitzeln von brauchbaren Informationen zur Behebung des unerwünschten Verhalten der Applikation (um das Wort "Bug" zu vermeiden wink.gif)

Verstehe nicht so recht was du mir damit sagen willst :>

- Du prüfst an keiner Stelle in deiner Software ob der Benutzer die nötigen Rechte hat, du gehst davon aus das die Software als Administrator ausgeführt wird (ich für meinen Teil arbeite am System mit minimalen Rechten).

Ich arbeite auch mit eingeschränkten rechten und sehe keine stelle wo ich admin rechte verlange ^^

- In der Funktion wo du die Pointer für die Winsock APIs und das Handle für die benötigten Dlls ermittelst, solltest du die Rückgabewerte vor dem Aufrufen der SetHook-Funktion(oder wie immer du sie bei dir genannt hast) prüfen als mit einem ungesetzten Hook aus der SetHook-Funktion zu kommen (was du übrigens auch nicht prüfst ob das erfolgreich war - soweit ich das korrekt gesehen habe)

Programmierer sind von natur aus faul :O, werde ich aendern

- In der gleichen Funktion wie gerade beschrieben, rufst du unnötigerweise mehrfach die GetModuleHandle API auf, wo du nur 1 Aufruf und 1 lokale Variable brauchst.

c&p geht schneller als das ganze mit einer variable zu machen :P (Spass werde ich auch aendern )

- Wenn die ws2_32.dll oder wsock32.dll noch nicht geladen sind, kannst du sie ruhig selbst in den Prozess laden und deine Hooks schon mal setzen. Falls die Zielapplikation auf die Idee kommt die gleichen Dlls noch mal zu laden, kriegt es als HMODULE das geladene zurück.

Ist mir bekannt, wird auch geaendert.

- Du solltest auch einen Hook auf FreeLibrary/LoadLibrary setzen (das letztere für eine Alternative für meinen obigen Vorschlag). Es kann vorkommen dass das Spiel die ws2_32.dll entläd und später wieder läd. Würde das dein Packet Editor mitkriegen und die hooks noch einmal setzen? -> So könntest du in der IDE eine entsprechende Meldung darstellen.

Sehr gute idee, danke dafuer

- Du könntest dazu SetUnhandledExceptionFilter benutzen und im Filter die Exceptions/Register loggen. Falls du gerissen bist, addierst du zum EIP immer eine Eins und lässt die Applikation fortfahren. Damit stürzt die nicht mehr ab aber vielleicht bemerkt der User nicht das eigenartige Verhalten ... NEIN, das war nur Spass, das solltest du NICHT tun ;-)

und warum nicht? xD

- Das folgende sieht einfach nur unschön aus(...):

Ich weiss nicht ob das von dir stammt, oder es sich um ein Resultat des Compilers handelt. Einer der Gründe hier ZeroMemory (sollte in Delphi geben; ich bin kein Delphi-Entwickler) aufzurufen, wäre, dass wenn du die struct erweiterst, nicht ständig manuell die Stelle anpassen musst. Wozu die restlichen Operationen im Codeschnipsel darstellen sollen, will ich nicht so richtig Wissen ;-)
Ist das die struct die du später benutzt um die GUI zu informieren?

Nein, das sollten die die einzelnen (12) capture structs sein (fuer jede funktion ein bool -> 0 = false).

00398B24 . A1 D0AC3900  MOV EAX,DWORD PTR DS:[39ACD0]&#59;bin mir nicht so sicher woher das kommt :/
00398B29 . C640 0C 00  MOV BYTE PTR DS:[EAX+C],0       &#59;RecvFrom_WSA : bool = false
00398B2D . C600 00    MOV BYTE PTR DS:[EAX],0         &#59;Send_WS_1 : bool = false
00398B30 . C640 01 00  MOV BYTE PTR DS:[EAX+1],0       &#59;Send_WS_2 : bool = false
00398B34 . C640 02 00  MOV BYTE PTR DS:[EAX+2],0       &#59;usw ^^
00398B38 . C640 03 00  MOV BYTE PTR DS:[EAX+3],0
00398B3C . C640 04 00  MOV BYTE PTR DS:[EAX+4],0
00398B40 . C640 05 00  MOV BYTE PTR DS:[EAX+5],0
00398B44 . C640 06 00  MOV BYTE PTR DS:[EAX+6],0
00398B48 . C640 07 00  MOV BYTE PTR DS:[EAX+7],0
00398B4C . C640 08 00  MOV BYTE PTR DS:[EAX+8],0
00398B50 . C640 09 00  MOV BYTE PTR DS:[EAX+9],0
00398B54 . C640 0A 00  MOV BYTE PTR DS:[EAX+A],0
00398B58 . C640 0B 00  MOV BYTE PTR DS:[EAX+B],0
00398B5C . A1 C0A93900  MOV EAX,DWORD PTR DS:[39A9C0]
00398B61 . C600 00    MOV BYTE PTR DS:[EAX],0         &#59;capture : bool = false

danke fuer die gute und lange kritik

[SilonVier]

Originally posted by rEdoX+Sep 11 2006, 13:59--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>QUOTE (rEdoX @ Sep 11 2006, 13:59)</td></tr><tr><td id='QUOTE'>

und warum nicht? xD[/b]

Es gibt viele Gründe, z. B.:
- Du weisst nicht wo genau eine Exception beim User aufgetreten ist um sie zu beheben.
- Exceptions sind langsam. Bei einer 4 byte Instruktion die eine Exception verursacht, schmeisst es im besten Fall 4 mal eine Exception und führt den nächsten Befehl korrekt aus. Vielleicht nimmt es aber auch nach 2 Exceptions die nächsten 2 byte(s) und verbindet diese mit der nächsten Instruktion und fügt dann über lange Codeabschnitte sehr unsinnige Sachen aus und die Prozessorauslastung ist bei 100%. Man müsste das also mit einem kleinen Disassembler verbinden und bei der ersten Exception ermitteln wie lang(byte(s)) der Befehl ist und die Länge wird zu EIP addiert (statt immer nur eine Eins). Damit würden die Befehle korrekt sein aber nicht zwangsläufig das Resultat

Originally posted by -rEdoX@Sep 11 2006, 13:59

00398B24 . A1 D0AC3900  MOV EAX,DWORD PTR DS:[39ACD0];bin mir nicht so sicher woher das kommt :/
00398B29 . C640 0C 00  MOV BYTE PTR DS:[EAX+C],0      &#59;RecvFrom_WSA : bool = false
00398B2D . C600 00    MOV BYTE PTR DS:[EAX],0         &#59;Send_WS_1 : bool = false
00398B30 . C640 01 00  MOV BYTE PTR DS:[EAX+1],0       &#59;Send_WS_2 : bool = false
00398B34 . C640 02 00  MOV BYTE PTR DS:[EAX+2],0       &#59;usw ^^
00398B38 . C640 03 00  MOV BYTE PTR DS:[EAX+3],0
00398B3C . C640 04 00  MOV BYTE PTR DS:[EAX+4],0
00398B40 . C640 05 00  MOV BYTE PTR DS:[EAX+5],0
00398B44 . C640 06 00  MOV BYTE PTR DS:[EAX+6],0
00398B48 . C640 07 00  MOV BYTE PTR DS:[EAX+7],0
00398B4C . C640 08 00  MOV BYTE PTR DS:[EAX+8],0
00398B50 . C640 09 00  MOV BYTE PTR DS:[EAX+9],0
00398B54 . C640 0A 00  MOV BYTE PTR DS:[EAX+A],0
00398B58 . C640 0B 00  MOV BYTE PTR DS:[EAX+B],0
00398B5C . A1 C0A93900  MOV EAX,DWORD PTR DS:[39A9C0]
00398B61 . C600 00    MOV BYTE PTR DS:[EAX],0         &#59;capture : bool = false

Vielleicht hätte ich mir den Code gestern nüchtern ansehen sollen - der erste Befehl ist notwendig, vorher gibt es keine Zuweisung.
Wäre hier ein enum nicht sinnig? Ich habe zwar Zuweisungen in deinen gehookten Funktionen gesehen, aber dem nicht viel Beachtung geschenkt.

type Irgendwas = {blub, blab}

<!--QuoteBegin--rEdoX@Sep 11 2006, 13:59
danke fuer die gute und lange kritik [/quote]
Kein Problem ;-)

[rEdoX]

Bei mir ist das ganze als record deklariert:

 foobar: record
  send1, send2, recv1, usw, capture : boolean;
 end;

Finde das eigentlich auch ganz sinnvoll so ^^
Ist ja auch erstmal nur nen "grundgeruest" die optimierung kommen nachher

Habe gerade einen bug in den wsa funktionen festgestellt, die zu der von cyrus geposteten av passen. Kann mir aber nicht erklären woher die kommen.

Download weiter unten

[mr.rattlz]

Meiner Meinung nach wären Hotkeys zum starten und stoppen des loggings ganz praktisch, da man dann nicht zwischen dem untersuchten Programm und dem Packet Editor hin und her tabben müsste.

[emjay]

huhu redox, eine frage auf deinem screenshot habe ich direkt erkannt dass du den source (des sniffers) aus einem winsock beispiel für delphi "geklaut/geliehen" hast.
immer wieder wenn ich mit winsock programmierung anfange /weitermache muss ich an das porgramm denken aber ich komm weder auf den exe namen noch auf den des coders, als meine frage könntest du das rohprogramm, auf den du "dein" programm aufbaust bitte posten, bzw den source dazu (name würde mir auch schon reichen). ich wäre dir sehr dankbar habe schon endlose stunden damit verbracht das ding zu suchen aber ohne erfolg.
das grundgerüst war (soweit ich in erinnerung habe) viel sauberer als alles was ich je mit winsock programmiert habe

[rEdoX]

huhu redox, eine frage auf deinem screenshot habe ich direkt erkannt dass du den source (des sniffers) aus einem winsock beispiel für delphi "geklaut/geliehen" hast.

Da muss ich dich entaeuschen, der source ist von grund auf von mir gecodet ;o
Welchen screen meinst du denn?

Und deshalb crashed es auch noch manchmal, ka wieso -.-''

Da ich gerade sehr sehr wening zeit habe, wirds noch nen bisschen dauern, bis es fertig gecodet wird.