Quote:
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(...):
Quote:
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?