wywołanie do WriteFile znajduje się w ichniejszym pliku aplikacja.dll
Nie powinno to mieć znaczenia , pewnie gdzieś popełniłeś błąd .
A co to znaczy nie pakuje ?
Jeśli masz znalezione wejście w Kernel32 do WriteFile w procesie to biblioteka
musi wywołać twoją Fun.
Jeśli znalazłeś tylko wejście w importach .exe to nie przechwycisz wywołania
z .dll .
Problem jest jeszcze tego rodzaju że aby zrobić loga musisz użyć WriteFile .
Czyli twoja fun podmieniona powinna wywołać oryginalną Proc WriteFile do własnych
celów , i ponownie oryginalną dla właściwego kodu coś ala [trochę pomyśleć trzeba] :
BOOL WriteFile_Moja(Handle_Pliku_Original, lpBuffer_Original,NumberOfBytesToWrite_Orig,Orig..
{
Original_WriteFile(Moj_plik, lpBuffer_Original < -- czytamy dane z bufora .
return Original_WriteFile(Handle_Pliku_Original, lpBuffer_Original itd
}
Napisz sobie najpierw prostą aplikację , spróbuj podpiąć się pod WriteFile z dll .
Jak uzyskasz prawidłowe wyniki to temat można ciągnąć dalej .
Dokładny kod gdzieś mi wcieło a na razie nie mam czasu pisać od nowa ...
Prawdopodobnie można jeszcze podpiąć się pod sekcję importów biblioteki która
używa WriteFile , ale nie próbowałem w .exe owszem .
Mało informacji trochę podałeś i kodu 000000 odnośnie sposobu przechwycenia WriteFile.
I dosyc niejasne ...
Zatem CreateFileA podmienione, tworzy zamiast pliku Named Pipea.
Zamiast ...? z tymi zmianami to bym nie przesadzał , lepiej dodatkowo od zamiast .
Zmiana sposobu funkcjonowania aplikacji może jej nie wyjść na dobre , lepiej (łatwiej)
zrobić to tak aby hook nie wpływał na oryginalny wykonujący się kod .
Jakie są szanse i sposoby na to
Szanse Wielkie .
Sposoby -> jeśli nie możesz podpiąć się pod obcą aplikację :
Piszesz własną aplikację zawierającą fun. na podstawie Obcego, własne .dll , sprawdzasz , testujesz [czasami do usr.. śmierci] aż zadziała .
Potem atakujesz Obcego wciskając ten dll-owy kit...