[C++ Help] Uruchamianie funkcji z innego procesu.

0

Witam.

Zalozmy ze mamy 2 procesy :
Proces A
Proces B

jak wiadomo proces A moze odczytywac / zapisywac dane z/do procesu B.
poprzez ReadProcessMemory / WriteProcessMemory tak samo B moze A.

teraz wynika pytanie :
Proces A - callujacy
Proces B - na offsecie 0x12345 posiada funkcje CallMe() zwracajaca string 'Called'.

czy da sie zrobic CALL z procesu A do funkcji CallMe() w procesie B zwracajac wynik tej funkcji do procesu A ?

0

używając asemblera,możesz zastosować instrukcję call <adres>,gdzie adres jest adresem funkcji jaką chcesz wywołać.Problem może wyniknąć jedynie z powodów ochrony pamięci przez Windows-oże się OS burzyć.Rozwiązaniem jest zmiana poziomu uprzywilejowania aplikacji(szczegóły w SDK).
co do zwracania wartośći-w C oraz WinAPI funkcje zwracają wartości stałopozycyjne do eax(od 8 do 32bit),EDX:EAX(64bit),natomiast wartości zmiennopozycyjne w ST(0).Wiedząc to,możesz z łatwością załadować jakąś zmienną zwróconą wartością,i użyć Read/WriteProcessMemory

0

z tego co wiem

asm
{
MOV DWORD PTR [adres] , EAX
}

raczej nie przyniesie zadanego efektu
poniewaz zanim ten kod sie wykona to proces B juz uzyje EAX do czegos innego.

moglbys dac namiar na tego SDK ?

0

otóż Bracie,proces B NIE MOŻE użyć do czegokolwiek rejestru,skoro Ty wciąż jesteś w procesie A ;] Windows zapamiętuje stan procesora przed przełączeniem na inne zadanie,stąd wartość EAX dla procesu A będzie taka jak ją zostawisz.
Twój kod nie wykona się z innego powodu-po prostu nie zostanie użyta WARTOŚĆ zmiennej adres,a jej offset ;]Trzeba by to tak zapisać:
asm{
mov ebx,adres//wieeeelokrotnie to przerabiałem w swej karierze
mov dword ptr[ebx],eax
}
a wywołać funkcję trzeba w ten sposób:
asm{
call adres//adres jest adresem twojej procedury
}
pytanie brzmi,jak otrzymać adres owej procedury?Otóż jest to prościutkie,z pomocą przychodzi instrukcja LEA
void test(void)
{MessageBox(hWnd,"Test pomyslny!","Test",MB_OK);}

_asm{
	lea eax,test
	call eax
	}//ten kod wklejam prosto po teście z kompilatora ;]

Pozostaje tutaj problem ręcznego odłożenia parametrów na stos,w zalezności od przyjętej konwencji wywołań.
u Ciebie Bracie,wartość eax zapamiętaj w jakiejś zmiennej DWORD,a następnie z 2 procesu weź przy użyciu ReadProcessMemory weź pobierz jej wartość.
SDK to na stronie microsoftu,wejdź do MSDN i wpisz privledge(or sth) level

0

widac nie rozumiesz o co biega
anyway znajomy wytlumaczyl mi jak to zrobic.

czyli :
nalezy zrobic sobie jakas funkcje ktora sie zapisze do procesu B w miejsce zaalokowane przez
VirtualAllocEx
poprzez WriteProcessmemory

i nalezalo by zrobic z tego CreateRemoteThread przekazujac jako parametr adres funkcji ktora chcemy zcallowac.

funkcja ktora zainfekujemy proces B bedzie tak jak by przekaznikiem miedzyprocesowym

a w funkcji np.
mov edx , [esp+4]
call edx

i ten sposob spisuje sie elegancko.

0
MasterBLB napisał(a)

używając asemblera,możesz zastosować instrukcję call <adres>,gdzie adres jest adresem funkcji jaką chcesz wywołać.Problem może wyniknąć jedynie z powodów ochrony pamięci przez Windows-oże się OS burzyć.Rozwiązaniem jest zmiana poziomu uprzywilejowania aplikacji(szczegóły w SDK).

MasterBLB napisał(a)

//wieeeelokrotnie to przerabiałem w swej karierze

Niby problem został juz rozwiązany jak trzeba, ale jak widzę takie herezje to nie mogę powstrzymać się od komentarza. MasterBLB, z tą Twoją karierą i znajomością asma jest jak z obietnicami polityków... Po pierwsze zmiana poziomu uprzywilejowania? A co to niby da jeżeli nawet uzyskasz ring0 /w sumie na 9x jest to dziecinnie proste - np. podmiana cs w context poprzez seh'a/ ? Next - wiesz może czym jest tryb chroniony i stronnicowanie? Pozwolisz, że Ciebie uświadomię:

  • Windows przacuje w trybie chronionym ze stronnicowaniem
  • każdy proces ma całkowicie oddzielną przestrzeń adresową - 'widzi' 4GB pamięci /nie widzi innych programów oraz bibliotek innych niż własne bądź kilka systemowych, które są zawsze mapowane/
  • wyjątkami od tej 'oddzielności' są kopie tego samego programu a konkretnie ich sekcje posiadające atrybut shareable
  • Niezależne od przestrzeni adresowej są tylko sterowniki... a i to nie zawsze - na 9x np. uchwyty plików w R0 działały tylko w obrębie danego procesu, na NT chyba też tak jest, ale głowy nie dam - ostatni raz jakiś driver operujący intensywnie na plikach pisałem z rok temu jak nie lepiej,
  • dobieranie się do innych procesów polega na operacjach na pamięci procesu poprzez funkcje o jakich wspomniał autor tematu.
    W sumie mogę tak jeszcze długo... ale przejdę do ostatniej rzeczy:
sobieh napisał(a)

i ten sposob spisuje sie elegancko.

Nie do końca elegancko - przy większych operacjach po utworzeniu wątku warto wywołać WaitForSingleObject i odczekać w ten sposób na koniec. Następnie GetExitCodeThread - w końcu w wątku można zwrócić jakieś ciekawe wartości - adres czy rozmiar danych w poprzednio przygotowanym buforze. Na nowszych procesorach trzeba pamiętać o fladze wykonywalności dla zaalokowanej pamięci - inaczej posypie się na dep'ie. Ciekawym pomysłem wysłanie message'a do okna naszej aplikacji z naszego zdalnego wątku - możemy przekazać 2 wartości typu dword wiec adres i rozmiar danych do przeniesienia do 'właściwego programu'. Przy jakichś większych operacjach trzeba zadbać o obsługę wyjątków w zdalnym wątku - inaczej posypie się cały program. Oczywiście wypadałoby zwolnić po wszystkim zaalokowaną pamięć... Ciekawą sztuczką jeżeli wywoływana funkcja ma otrzymywać jeden parametr jest utworzenie z niej zdalnego wątku i pobranie potem ExitCode - znacznie ułatwia zabawę.

p.s. temat raczej do działu [Inne] niż [C/C++].

0

ok dzieki za rade

waitforsingleobject jest tak samo VirtualFreeEx na koncu
i przy niepowodzeniu
GetExitCodeThread
TerminateThread

mysle ze temat zakonczony ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1