shlwapi.dll



  • merker schrieb:

    WebFritzi schrieb:

    Hö ja, und wo bitte?

    Steht so im Arbeitsspeicher.
    Ich benutze einen "API-Hook-Detektor" auf User-Ebene, der kontrolliert, ob der Code bei der Einsprungadresse einer API-Funktion der gleiche ist wie in der DLL.
    Dazu muss man den Code im Arbeitsspeicher mit dem Code der DLL vergleichen. Und SHLWAPI.PathFileExistsA ruft KERNEL32.GetFileAttributesA auf.

    Aha. Wieder was dazugelernt. 🙂

    merker schrieb:

    Wenn "DWORD buf_len = GetTempPath(0, NULL);" null zurückgibt, lassen sich die Exceptions von Optimizer und CodeFinder simulieren (-> BufferOverflow).

    Ich hatte vorher aber einen konstanten anstatt einem dynamischen Array, wo ich die Funktion GetTempPath() nur einmal aufgerufen habe, und auch da gab es eine Access-Violation. Das kann also nicht der Fehler sein...

    merker schrieb:

    Prüf auch mal folgendes Szenario :

    -> Der User startet das Programm zum ersten Mal.
    -> Der User hat aber kein TEMP(TMP)-Verzeichnis definiert.
    -> GetTempPath () liefert dann das "Current Directory".
    -> Dort gibt es aber kein Schreibrecht.

    Warum sollte ich das testen? 😕



  • WebFritzi schrieb:

    Warum sollte ich das testen?

    Damit u.a. fehlende Rechte als Fehlerursache ausgeschlossen werden können.

    WebFritzi schrieb:

    ...auch da gab es eine Access-Violation. Das kann also nicht der Fehler sein...

    ***achtung vermutung folgt***

    Offenbar benimmt sich SHLWAPI.DLL in manchen Installationen genauso "mimosenhaft" wie COMCTL32.DLL.
    Allerdings gibt es dort die Funktion InitCommonControls ().
    Probier so eine Funktion mal zu simulieren :
    Ruf nur PathFileExists () irgendwo im Programm auf noch bevor der User auf "game->new" klickt und alles auslöst was mit diesem Klick verbunden ist.


Anmelden zum Antworten