ognacy napisał(a):
Mouse_event oraz SendInput są komunikatami windowsowymi, do których doczepiony jest kontekst, m.in. HWND nadawcy. Jeśli wykryję w systemie latające komunikaty symulujące ruchy myszki pochodzące od nieznanej aplikacji, lub od dwóch dowolnych, ale różnych aplikacji, to mam pewność, że ktoś coś kombinuje. To jedna metoda, ale nie jedyna z uwagi na zunifokowaną architekturę przetwarzania wejścia przez DInput - jeśli event pojawia się z zewnątrz, wskakuje do chaina później. Wystarczy wsadzić hooka niżej i na końcu i porównywać czy coś nie wpada. W ogóle można założyć objazd na sendinput i moseevent, a następnie sprawdzać czy ktoś z tym hookiem nie kombinuje. Oczywiście, wszystko da się obejść, ale obejścia można również wykrywać i tak dalej, zgodnie z zasadami rywalizacji tarczy i włóczni

Nie twierdzę, że ta metoda pomoże na 1337arnego hackera, których tak wielu nie ma, ale pomoże na tych co sobie sklejają tutoriale, którzy produkują komercyjne cheaty (bo im więcej trzeba przechwycić, tym trudniej zrobić to komercyjne i dostatecznie polimorficzne zarazem). I tak dalej. Nie mówię, żeby od razu wygrać, tylko żeby poważnie utrudnić i ograniczyć dostęp dla znakomitej większości programistów. Zwiększyć poważnie ryzyko wykrycia.
Evenbalance już dawno "filtruje" aplikacje uruchomione razem z BF2.exe, ogólna zasada ich sprawdzania polega na sprawdzeniu czy w BF2.exe lub RendDX9.dll nie jest "wstrzyknięte" DLL z obcym kodem. Problem w tym,że uruchom BF2.exe i zobacz jakie moduły są powiązane z tym procesem... a mianowicie systemowe, drivery od mychy itp. System sam wstrzykuje DLL do procesu. I się pojawia problem,że nie zawsze da się wykryć co jest obce a co nie. Częściowo odnoszą sukcesy i łapią niektórych, bo sprawdzaja czy w danym DLL nie ma JMP'a do procesu macierzystego(a jak wiadomo procedury zewn. i wewn. robi się przez CALL) z krótkim kodem poprzedzającym JMP'a. Co do publicznych,oficjalnych AIMBOT'ów masz rację, ukręcą im łba. Ale prywatne przetrwają. Sławetny MSX AIMBOT jest już wykrywalny przez PB jako AIMBOT i kickują.
ognacy napisał(a):
Bynajmniej! Engine BF2 wie, czy gracze się nawzajem widzą, czy nie - więc już to jest wyliczane. A algorytm przecięcia sfery z prostą wyznaczoną przez wektor to 3 funkcje trygonometczyne (obrót; 2 cosinusy 1 sinus), 1 dzielenie, 1 pierwiastkowanie. To jest kompletnie pomijalne wobec ilości tego samego rodzaju wyliczeń wykonywanych co klatkę przez serwer dla każdego projectile'a, gracza i tego co robi klient.
Tylko,że by to zrealizować EA/DICE musiałaby dać pełną dokumentację struktury engine'u, co chyba chłopakom z Evenbalance by pomieszało w głowach bo idea PB nie opiera sie na wykrywaniu oszustw w sferze 3D ale w kodzie programu,bibliotek.
ognacy napisał(a):
Ok, czyli godzisz się na totalną bylejakość bo programiscie nie chce się ruszyć dupy i posiedzieć nad algorytmem 2 tygodnie?... Nie każdy rozumie algebrę wektorową, to fakt, ale nie każdy powinien być programistą zatrudnionym w evenbalance...
Jeżeli masz na myśli programistów z EA/DICE to godzę się, bo oni mają to w tyłku. Jeżeli by im zależało na zabezpieczeniach przed cheaterami to by sami zrobili wewnętrzy system zapobiegania. Czy chłopakow z Evenbalance także zależy na szybkim "wybiciu" cheaterów? Nie sądzę, zobacz ile dali banów,co zmusza do kupienia nowego CD-KEY'a który odziwo EA sprzedaje za 10usd pod pretekstem sprzedaży gdy ktoś zgubił!! Kto gubi CD-KEY'e??

Tu się biznes sam nakręca, więc chłopaki z EB nie chcą robić skutecznych metod...?
ognacy napisał(a):
Oczywiscie. Podobnie jak serwer może ile chce raportować, że gracz A statystycznie 1/25 czasu gry patrzy się na jakiegoś gracza poza zasięgiem widoku. A prawdopodobieństwo przypadkowego spojrzeia na niewidocznego gracza jest totalnie marginalna (ok, przez 1 klatkę to się zdarzy raz na pare minut, ale przez 200 klatek - zerowa).
Zgadzam się, to prawda, ale problem jest w czasochłonności. PB i tak już mocno obciąża grę. A co dopiero próbkowanie danych 3D...
ognacy napisał(a):
Tak by było, gdyby użytkownicy aimbotów celowali wyłącznie w widoczne cele i używali ich jako wspomaganie celowania. Ale najwięcej cheaterów łapie się po tym, że gapią się ustawicznie w różne ściany żeby się zorientować, co się dzieje na mapie.
Kod PB musiałby zupełnie być napisany pod kątem grafiki 3D by oszacować który gracz jest widoczny a który nie(chodzi mi o sciany).
Ale jak już pisałem "cameleon skin" AIMBOT'y odchodzą do lamusa i są które bazują na współrzędnych graczy. Więc cheater celuje tylko w widoczny cel. Nadal jest ryzyko zrobienia SS graczowi, więc dlatego wektorowe AIMBOT'y są wizualnie niewykrywalne na SS. Druga sprawa to to,że MSX ingeruje w kod PB by zapobiedz wysłania SS. Evenbalance nie gwarantuje,że gry admin wyśle żądanie o SS to, że dostanie SS. Po prostu traktują to jako pakiet lost, nawet przy 5 kolejnych próbach(Porażka EV). Inna kwestia jak dotrze czarny SS(to już BAN). Mało kto z ma jaja by ingerować w kod PB, bo byle potknięcie i HARDWARE BAN i grożą konsekwencje prawne.
ognacy napisał(a):
Jeśli by tak było to już byłby to wielki sukces walki z cheaterstwem. Co więcej, połączenie tego z lepszą detekcją innych nadużyć dosłownie starłoby przewagę jaką dają cheaty nad wyskillowanymi, myślącymi graczami. Dodam jeszcze, że takie obcięcie listy wrogów jest bardziej ryzywkowne dla autora cheata, ponieważ wymaga ścisłej integracji z enginem, a im więcej interakcji, tym łatwiej wykryć...
Zauważ,że natłok informacji jaką dają cheaty które pokazują graczy przez ściany, nie pomaga ale utrudnia granie, bo nie można oszacować odległości od gracza, nie wiadomo czy jest za 1,2 czy 3 scianami. Ten AIMBOT jest przestarzałym AIMBOT'em bazującym na skanowaniu zadanego kwadratowego lub prostokątnego obszaru w rejonie kursora. Algorytm bazujący na takiej zasadzie nie potrafi wyszukać gdzie jest głowa gracza. Ba jeżeli by potrafił to byłby super algorytm nad którym pracuje NASA i nie tylko, czyli na rozpoznawaniu przedmiotów po konturach z bitmapy, w tym przypadku było by rozpoznanie pozycji przeciwnika i oszacowanie gdzie jest głowa. Więc takie AIBOT'y odchodzą do lamusa. A jak pisałem, ostatnio często dostaję prosto w makówke z AK-101. Więc na pewno nie jest to AIMBOT bazujący na camelon skin.
ognacy napisał(a):
Znowu - będzie to sukces, bo taki aimbote będzie mniej efektywny. W walce z dobrym klanowiczem zawodnik ma mniej niż sekundę, żeby wpakować heada. W przeciwnym wypadku taki wyskillowany koleś z przysłowiowej Wildy (powinni tego zabronić

) sam pakuje heada i podskakuje wesoło dalej. Aimbot który wymagałby korekty byłby bez porównania mniej efektywny wobec refleksu, jaki jest wymagany w fpp. Już nie mówię o tym, że tego rodzaju zabawę też można algorytmicznie wykryć, ale nie chce mi się robić z tego wątku forum programistycznego

Już i tak czuję, że zaśmiecam.
Tu nie ma co odpowiadać bo częściowo odpowiedzi udzieliłem wcześniej. Dodam,że prędkość namierzania na podstawie współrzędnych przeciwnika przez AIMBOT'a zdecydowanie będzie szybsza niż jakiegokolwiek gracza. Oczywiście w walce 1 na 1 a nie 1 na 3-5.
ognacy napisał(a):
Proste to nie jest, ale podałem to jako trzecią metodę, i wymagającą dodatkowych usprawnień. Można np. zastosować pętlę histerezy. Jeśli wektor celującego wpada w sferę powiezmy fi 85 cm opinającą cel, następnie zatrzymuje się w sferze o fi, powiedzmy, 30 cm wewnątrz tej pierwszej i nie opuszcza wewnętrznej sfery przez dłuższy czas przy założeniu określonego minimalnego dystansu między celami i minimalnej prędkości względnej - to mamy warning. Bo mało który człowiek jest w stanie utrzymać celownik w dokładnie tym samym miejscu wroga - a aimbot celuje w głowę, brzch, cokolwiek - ale generalnie w te samo miejsce, z dokładnością do wahań latency itp. Rocket science to to nie jest.
Więc można dodać wartość losową dodawaną do każdej próby namierzania i zależną od odległości celu. Powiedzmy przeciwnik jest oddalony o 5m więc cel(głowa) ma większą średnicę, więc wartośc losowa dla X,Y od centrum będzie większa by zapobiedz wykryciu, ale będzie się zawsze mieścić w sferze. Wartości te będą się zmiejszać wraz z dystansem.
ognacy napisał(a):
To o czym rozmawiamy to na razie uniwersalna algebra wektorowa i zdrowy rozsądek. Wyciągnięcie koordynatów z engine'u to nie jest wielki problem dla narzędzia AC (EA endorsed lub i nie). Co się tyczy edycji pakietów i cheatów bazujących na tej ściśle elitarnej zabawie to oczywiście zaczynaja się schody, ale na razie nie z tym są problemy, tylko z aimbotami prymitywniejszymi.
Czytałem, że już edytują pakiety i nawet publicznie podane jest jak rozpoznać pakiet PB i aplikacji BF2...
Ostanimi słowami, ogólnie o zabezpieczeniach przed cheaterami: Z Twoich wypowiedzi wnioskuję,że jesteś programistą i być może liznąłeś reverse engineering(albo jesteś PRO),wieć to co napiszę możesz sprawdzić. EA/DICE WOGÓLE nie starała się w jakimkolwiek stopniu zminimalizować to zjawisko(cheating). Zostawiając w kodzie programu MNUSTWO udogodnień dla hackera/cheatera itp. Sama gra opiera się na skryptach i zmiennych i stałych które można elastycznie i każdym momencie zmieniać edytować(poza pewnymi wyjątkami). Przykładem jest mój post "Tajemnice Strike of Karkand" i przykład drabinek... Większość cheaterów bazuje na publicznych cheatach i PB zbiera żniwo. Z tego co wyczytałem Ci bardziej PRO stosują metody alternatywne, właśnie podane na talerzu przez EA i w 100% niewykrywalne przez PB(być może na razie). Wystarczy zerknąc w kod BF2 i włos się jeży i człowiek zaczyna sie zastanawiać czy EA tak bardzo na tym zależy...
Proste pytanie: dlaczego PB sprawdza cały BF2.exe a RendDX9.dll tylko częściowo

Ostatnio się wzieli za sprawdzanie niektórych procedur z Kernel32.dll czy nie ma tam code cave... Smieszne, bo więcej czasu się traci nad odczytem obszarów pamięci z oddzielnego procesu niż zrobienie snapshota całego RendDX9.dll i sprawdzeniu całego. To kolejny dowód.
Trzeba sobie powiedzieć prosto w oczy PB to lekko złudne poczucie bezpieczeństwa. Moim zdaniem nie chodzi tu o ukrócenie zjawiska cheatowania a jedynie nabijanie kasy dla gigantów takich jak EA/DICE.
Pzdr.
Ps. Ja poproszę jakiś medalik i unlocka
