Launcher i główny exec.

0

Witam
Piszę właśnie teraz launchera który odpala właściwy program po zalogowaniu się do serwera.
Nie chcę żeby mój główny program był odpalany bez zalogowania się. Jak to profesjonalnie zabezpieczyć ? (bez zapisów do pliku np);
Np żeby główny program wiedział ze został odpalony przez launchera a nie bezpośrednio z execa ?

Pozdrawiam
//Mienio

0

Może twórz Mutex z oryginalną nazwa przez CreateMutex w Launcherze. I jeżeli wywołany program przy sprawdzaniu GetLastError zwróci ERROR_ALREADY_EXISTS, to znaczy że uruchomiono go z Launchera, a jeżeli nie to zamyka się uruchamiany program. Oczywiście takie zabezpieczenie można łatwo ominąć, znając podstawy inżynierii wstecznej. Jeżeli exek nie jest spakowany i zabezpieczony jakimś protectorem, a kod nie jest obfuscowany. Ale na pospolitych użytkowników wedlug mnie powinno wystarczyć. Może ktoś jeszcze coś tutaj Tobie doradzi lepszego. Więcej informacji o wspomnianych funkcjach API masz na MSDN.

1

Możesz uruchamiać program z parametrem zawierającym klucz.

Klucz możesz zbudować na podstawie własnego algorytmu w połączeniu z aktualną datą (rok + miesiąc + dzień + godzina + minuta + sekunda).
Tak wygenerowany klucz zahaszuj np: w SHA1.
Następnie potnij go na części i poodwracaj w sobie tylko znany sposób.
Otrzymany gotowy klucz wyślij parametrem do drugiego programu.

Teraz, drugi program natychmiast pobiera aktualną datę i tak samo generuje sobie klucz jak pierwszy program.
Jeśli klucz zgadza się z tym, który otrzymał w parametrze, to znaczy, że aplikacja została uruchomiona przez launchera. Dodatkowo możesz sprawdzać, czy proces launchera istnieje i czy np.: zawiera się w określonym rozmiarze + ewentualne sprawdzenie daty utworzenia launchera (takie proste metody często są najlepsze).

Haszowanie klucza z aktualną datą, pomoże w tym, aby klucze za każdym razem były inne.
Możesz zabezpieczyć się też przed niezsynchronizowanym generowaniem kluczy, tj. w momencie wygenerowania klucza i wysłania parametru do drugiego programu, minie kilka sekund, za nim ten drugi sobie wygeneruje klucz do porównania.
Dlatego musisz zastosować pole manewru w odstępie 5-10 sekund dla generowanego klucza, albo usunąć z generowania klucza sekundy w dacie - ale wtedy twój generowany klucz "będzie ważny" przez minutę (max założenie).

Jeśli natomiast chcesz skorzystać z "sekundowej" ważności klucza, wygeneruj klucz w pierwszym programie z 5-10 sekundowym wyprzedzeniem od aktualnej daty.
Następnie drugi program generuje co sekundę nowy klucz i porównuje z tym otrzymany. Po <10 sekundach dotrze do tego poprawnego.
Jeśli przez te <10 sekund żaden z 9 kluczy się nie zgadza to po prostu zamykasz aplikację z komunikatem o błędzie autoryzacji.

0

Dziękuję wam za fajne pomysły
od zaraz biorę się do roboty
Najlepiej będzie jak oba naraz zastosuje :D
Macie po piwku panowie :)

0

Sam pomysł wykorzystania dodatkowych parametrów uruchomieniowych nie jest zły, przekazywanie klucza w parametrze także nie, jednak ważność klucza przez tylko jedną sekundę jest bardzo ryzykowne; W ogóle wykorzystanie daty i czasu jest ryzykowne, bo zawsze można trafić na moment, gdzie milisekundy zaważą na poprawnym zalogowaniu;

Bez względu na to, czy do budowy klucza bierze się pod uwagę sekundę, minutę, godzinę, czy nawet dzień, miesiąc, rok - ryzyko błędu jest niemałe; Wystarczy, że próba logowania odbędzie się w ostatniej sekundzie danej minuty, a właściwa aplikacja uruchomi się w kolejnej sekundzie - zmieni się minuta, zmienić się może także godzina, dzień, miesiąc, rok;

A co jeśli pliki są pofragmentowane, procesor zbyt obciążony, właściwy plik aplikacji dość duży? Szansa na nierozpoznanie klucza jest zbyt duża; Wykorzystanie czasu jest dość ryzykowne, daty już mniej, jednak tego typu algorytmy powinny być niezawodne;

Parametr można przekazać i raczej bym tego próbował, jednak nie brałbym pod uwagę czasu, a inne sensowniejsze dane.

0

IMO nie ma sensu takie zabezpieczenie bo można je ominąć jednym jumpem do właściwego startu programu.
Napisz dlaczego ten launcher musi być akurat twój. Jeśli ktoś napisze alternatywny, który będzie robił to samo to nie ma się co upierać.
Napisałeś coś o logowaniu do gry - rozumiem, że to aplikacja sieciowa a launcher to updater plików tak? W takim razie niech updater łączy się z serwerem aktualizacji, pobiera "token" oraz sumy kontrolne plików, które przekażesz do właściwej aplikacji. W niej sprawdzisz czy otrzymane CRC są dobre oraz token jest poprawny (tzn. pobrany uprzednio przez launcher). Jeśli nie będą się zgadzać zamknij po prostu połączenie i ew. klienta gry.
Oczywiście to zabezpieczenie nie jest też 100%, ale sprawdzenie sumy kontrolnej przez serwer wymusza pobranie tokenu przez launcher i jest to na pewno więcej zabawy dla osoby która chce takie zabezpieczenie ominąć.

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