Alternative zu FindFirst/Next im SpeedCommander ??

[wido]

Also mit der von dir oben beschriebenen Methode wird das hinten und vorne nix.

Du hast da gleich mehrere Probleme:
1. SC hat keine komplette Import Address Table weils mit ASProtect versehen ist. Das wäre nicht ganz so schlim, aber ...
2. Du injezierst über nen Message Hook. Bedeutet im Endeffekt Du gelangst erst in den Prozess nachdem der ASProtect Stub die vollständige IAT aufgebaut hat via LoadLibrary/GetProcAddress.

Im Endeffekt gibts 2 Lösungen:
1. Benutz eine andere Methode zum Injezieren.
2. Benutz Code Overwriting zum Hooken.

Welche Du davon nutzt bleibt Dir überlassen. Google ist übrigens Dein Freund .

Zitat von F.W.:

Ich habe das gerade mal ausprobiert. Ich benutze in meinen Programmen meist nur die einfache FindFirst Version, wenn ich in der Dll aber jetzt nur die Unicode Varianten patche, bekomme ich gar nichts mehr. Also sind zumindest gerade diese keine Wrapper. Oder es hängt damit zusammen, dass ich die Adressen im Programm patche und wenn ein Programm eben FindFirst oder FindFirstA aufruft ist ja klar, dass ich dann nichts mehr mitbekomme.

Wie Du siehst ruft auch FindNextFileA nur FindNextFileW auf:

Code:

.text:7C834EB1 ; Exported entry 218. FindNextFileA
.text:7C834EB1
.text:7C834EB1 ; =============== S U B R O U T I N E =======================================
.text:7C834EB1
.text:7C834EB1 ; Attributes: bp-based frame
.text:7C834EB1
.text:7C834EB1 ; BOOL __stdcall FindNextFileA(HANDLE hFindFile, LPWIN32_FIND_DATAA lpFindFileData)
.text:7C834EB1                 public FindNextFileA
.text:7C834EB1 FindNextFileA   proc near
.text:7C834EB1
.text:7C834EB1 var_268         = dword ptr -268h
.text:7C834EB1 var_264         = byte ptr -264h
.text:7C834EB1 var_25C         = byte ptr -25Ch
.text:7C834EB1 var_25A         = word ptr -25Ah
.text:7C834EB1 var_258         = dword ptr -258h
.text:7C834EB1 FindFileData    = _WIN32_FIND_DATAW ptr -254h
.text:7C834EB1 var_4           = dword ptr -4
.text:7C834EB1 hFindFile       = dword ptr  8
.text:7C834EB1 lpFindFileData  = dword ptr  0Ch
.text:7C834EB1
.text:7C834EB1 ; FUNCTION CHUNK AT .text:7C836601 SIZE 00000016 BYTES
.text:7C834EB1 ; FUNCTION CHUNK AT .text:7C83C993 SIZE 0000000D BYTES
.text:7C834EB1
.text:7C834EB1                 mov     edi, edi
.text:7C834EB3                 push    ebp
.text:7C834EB4                 mov     ebp, esp
.text:7C834EB6                 sub     esp, 268h
.text:7C834EBC                 mov     eax, dword_7C8846CC
.text:7C834EC1                 push    ebx
.text:7C834EC2                 push    esi
.text:7C834EC3                 mov     esi, [ebp+lpFindFileData]
.text:7C834EC6                 lea     ecx, [ebp+FindFileData]
.text:7C834ECC                 mov     [ebp+var_4], eax
.text:7C834ECF                 mov     eax, [ebp+hFindFile]
.text:7C834ED2                 push    ecx             ; lpFindFileData
.text:7C834ED3                 push    eax             ; hFindFile
.text:7C834ED4                 call    FindNextFileW
[...]

Allerdings ist das Problem mehr oder weniger, daß Deine Hook Methode nur Calls hooken kann, die sich auf die IAT stützen. FindNextFileW wird von der Anwendung nicht direkt aufgerufen, folglich gibts halt auch keine Möglichkeit den Call mit nem IAT Hook zu erwischen. Code Overwriting hilft da.