Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Utworzenie wątku w innym procesie powoduje natychmiastowe zamknięcie
#1
Próbując debugować, zostawiam próbę przejścia przez jakąś lokalizację, w której nie mam dostępu do symboli lub źródła (rzeczy z Windowsa).   Oto mój kod:       Kod:   BOOL WINAPI DllMain (HINSTANCE hInstDll, DWORD fdwReason, LPVOID lpvReserved) {switch (fdwReason) {case DLL_PROCESS_ATTACH: {// DisableThreadLibraryCalls (hInstDll); CreateThread (0, 0, LPTHREAD_START_ROUTINE (CheatMain), 0, 0, 0); przerwa ; } case DLL_PROCESS_DETACH: {CleanUp (); przerwa ; } default: {return UNKNOWN_CALL; }} return SUCCESSFUL_CALL; }   Oto sprowadzanie tego, co się dzieje: 1. Biblioteka ładuje i wywołuje wtryskiwacz w zdalnym procesie (działa dla innych plików DLL bez awarii). 2. Pierwsze wywołanie (do przyłączenia procesu) działa poprawnie, zostaje uruchomiona funkcja tworzenia wątku. 3. Nagle moja biblioteka ponownie się nazywa, tym razem do odłączenia. 4. Oczyść, wyjdź. 5. "Program Middleman.exe przestał działać" (testowano wiele aplikacji)   Niektóre aplikacje (np. Discord) po prostu zamyka program i nie wyświetla okna dialogowego "przestał działać".   Wątek nigdy nie jest tworzony, więc funkcja CheatMain () nigdy nie jest wywoływana.   Próbowałem std :: thread i wtryskiwacz się zawiesił z jakiegoś powodu D: Zakładam, że std :: thread próbuje przejąć kontrolę nad instrukcją switch, ale nie jestem lekarzem, więc nie mam pojęcia.
Reply
#2
A co ze stanem wątku CheatMain na etapie 4? Może masz uruchomiony wątek podczas usuwania biblioteki?
Reply
#3
Zacytować: Originally Posted by v1rtuoz A co ze stanem wątku CheatMain na etapie 4? Może masz uruchomiony wątek podczas usuwania biblioteki? CheatMain nie ma nic oprócz AllocConsole () Przed wywołaniem odłączenia nie jest przydzielana żadna konsola. Mam również punkt przerw w CheatMain, aby sprawdzić, czy jest on nawet wywoływany, a nie jest Czy to możliwe, ponieważ rzucam CheatMain? To nieważny func.
Reply
#4
zorientowałem się, że moje wyliczenie było źle ustawione. SUCCESSFUL_CALL, UNKNOWN_CALL zostały odwrócone, więc po powrocie zwracano zero.
Reply
#5
Zacytować: Originally Posted by hftd zorientowałem się, że moje wyliczenie było źle ustawione. SUCCESSFUL_CALL, UNKNOWN_CALL zostały odwrócone, więc po powrocie zwracano zero. https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx przejdź do wartości zwracanej i przeczytaj
Reply
#6
Zacytować: Napisał początkowo ReactiioN https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx przejdź do wartości zwracanej i przeczytaj Wiem, dlaczego to nie działało, miałem właśnie pierdnięcie mózgu podczas dokonywania wyliczenia. naprawiłem to już, kiedy zrobiłem tę odpowiedź. Zacytować: Jeśli zwrócona wartość jest FAŁSZ po wywołaniu DllMain, ponieważ proces używa funkcji LoadLibrary, LoadLibrary zwraca NULL. (System natychmiastowo wywołuje twoją funkcję punktu wejścia za pomocą DLL_PROCESS_DETACH i zwalnia bibliotekę DLL.) wyliczenie: Kod: enum EReturns {SUCCESSFUL_CALL, UNKNOWN_CALL}
Reply
#7
Zacytować: Originally Posted by hftd Wiem, dlaczego to nie działało, miałem właśnie pierdnięcie mózgu podczas dokonywania wyliczenia. naprawiłem to już, kiedy zrobiłem tę odpowiedź. wyliczenie: Kod: enum EReturns {SUCCESSFUL_CALL, UNKNOWN_CALL} Kinda bezużyteczne wyliczenie imo. Po prostu używaj typów specyficznych dla okien podczas pracy z plikami specyficznymi dla Windows (jak DllMain) ERGO ich definicje, TRUE i FALSE ale gj, że to naprawiłeś
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)