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
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 .
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
Quote:
---------------------------
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.
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(...):
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?
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 :>
Quote:
- 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 ^^
Quote:
- 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
Quote:
- 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 )
Quote:
- 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.
Quote:
- 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
Quote:
- 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
Quote:
- 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).
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'>
Quote:
- 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[/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
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.
Code:
type Irgendwas = {blub, blab}
<!--QuoteBegin--rEdoX@Sep 11 2006, 13:59 danke fuer die gute und lange kritik [/quote]
Kein Problem ;-)
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.
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
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.
.
)
