Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Dlaczego dereferencje działają w RPM, ale nie przez własne?
#1
Dostałem trzy przesunięcia dla Assault Cube   __int32 BaseAdress = 0x400000; __int32 OffsetToLocalPlayer = 0x10F4F4; WORD m_health = 0xF8;   __int32 = pLayer;   Jeśli zrobię RPM dla Baseadress + OffsetToLocalPlayer i wyodrębnię go do pLayer, mogę dodać pLayer + m_Health i mieć poprawny adres dla mojego WPM.   Ale jeśli nie zrobię RPM i po prostu wykonam pLayer = BaseAdress + OffsetToLocalPlayer w mojej klasie, to nie mam odpowiedniego adresu, aby dodać moje przesunięcia i zmienić wartości w WPM. Nie mogę zrozumieć, dlaczego tak się dzieje.   Ponieważ mam BaseAdress i prawidłową OffsetToLocalPlayer, a te nie zmieniają się, czy dodanie ich razem nie zawsze dałoby mi tego samego adresu?   Po prostu nie mogę tego objąć.     Szybka edycja: Używam findWindow, getWindowThreadProcessID, aby uzyskać uchwyt Valid Window, a następnie OpenProcess dla mojego cheata.
Reply
#2
Witaj, spróbuję to wyjaśnić. Nie masz bezpośredniego dostępu do zewnętrznej pamięci gry. Masz BaseAddr i Offset_LocalPlayer Jeśli dodasz te dwie zmienne razem, otrzymasz adres. Nazwijmy ten adres pLocalPlayer Więc wiesz, że pLocalPlayer jest przechowywany w BaseAddr + Offset_LocalPlayer Teraz musisz wyłuskać pLocalPlayer, wywołując RPM na tym adresie. pLocalPlayer = RPM (BaseAddr + Offset_LocalPlayer) Po zakończeniu masz wskaźnik dereferencji przechowywany wewnątrz pLocalPlayer. Jeśli chcesz odczytać / zapisać zdrowie, weź wartość, wykonaj WPM / RPM (pLocalPlayer + Offset_Health) To powinno dać ci podstawowy przegląd tutaj.
Reply
#3
prawie tyle, co powiedział ^ dać ci przykład pozwala założyć, że adresy to 0x100, 0x200 i 0x2, podczas gdy klasa localplayer jest faktycznie (w pamięci pod 0x123123) Po prostu dodanie 0x100 + 0x200 będzie po prostu 0x300, następnie dodaj offset zdrowia, 0x300 + 0x2, kończysz z 0x302 i przeczytaj, co tam jest podczas gdy odczyt (0x100 + 0x200) zwróci 0x123123, doda heatlh, 0x123123 + 0x2, u kończy się 0x123125 i tam jest rzeczywisty adres
Reply
#4
@ Momo5000 Dziękujemy za odpowiedź. Już to zrozumiałem. @ masterlooser18 Dziękuję, tego właśnie szukam. Więc jeśli rozumiem poprawnie, RPM (0x100 + 0x200) zwróci 0x123123, ponieważ w zasadzie robię to na innym adresie rezydującym w aplikacji, w której robię RPM? Wynika to z drogi do adresu, a nie samego adresu? Dobrze? Dodanie ich razem dałoby mi po prostu losowy adres bzdury, który nie ma połączenia z aplikacją? Szybka edycja: Każdy pomysł, dlaczego otrzymuję nieprawidłowy błąd obsługi, gdy przekazuję wskaźnik do mojego uchwytu w funkcji do użycia?
Reply
#5
dobrze u dodaj je razem, niezależnie więc w zasadzie robisz 0x100 + 0x200 = 0x300, a następnie podajesz je do rpm (0x300) rpm następnie "przejdzie" pod ten adres i przeczyta, co tam jest. a jeśli czytasz, powiedzmy dword, a tam jest, jak wskaźnik do czegoś (w tym przypadku do localplayer), zwróci ten adres, który w tym przypadku będzie 0x123123 Oto zrzut ekranu z reclassu, fajne narzędzie, możesz je zdobyć na odwrócenie w przyszłości. Ten obraz został przeskalowany. Kliknij ten pasek, aby wyświetlić pełny obraz. Oryginalny obraz ma rozmiar 653x210. w lewym górnym rogu znajduje się adres u do rpm, 0x10018 o to chodzi (był pierwszym, który znalazłem XD następnie tuż pod, po lewej stronie, możesz zobaczyć "0000" więc w zasadzie 0x10018 + 0x0000 (co jest takie samo) a potem całą drogę po prawej, na tym samym pasie, widzimy czerwoną strzałkę z * wskazującym na 0x10128 co oznacza, że na tym adresie (0x10018 + 0x0000) znajduje się wskaźnik wskazujący adres 0x10128. więc jeśli chcesz odczytać 0x10018 przy pomocy RPM, zwróci to 0x10128. edytuj, to jest to, co robisz z twoim lokalnym odtwarzaczem, właśnie czytasz adres, który zawiera (bardzo dynamiczny) wskaźnik do ur localplayeraddress edit2: just incase isnt not clear, 0x10018 będzie base + localplayeroffset
Reply
#6
Pragnę być w stanie wyjaśnić komuś takie rzeczy jak ty. Dziękuję Ci bardzo. Doceń to bardzo.
Reply




Users browsing this thread: 1 Guest(s)