Ochrona pliku przed edycją, lub zakodowanie binarnie

Jak są laikami to po prostu zxoruj plik. Po co angażować w to serwer?

Zrób taki myk, gdzieś w dysk:/windows/system32 albo innym katalogu wsadź plik z datą, nawet szyfrowana nie musi być (chociaż wiesz no...), palnij rozszerzenie dll, takich plików przeciętny użytkownik nie tyka. Mogą być potrzebne prawa administratora żeby zapisywać w takich lokalizacjach.

Zamysł generalnie taki, żeby nie trzymać tablicy bajtów w jednym miejscu w pliku exe.

Ścieżkę do pliku dll potraktuj jako std::string, zaszyfruj ją choćby głupim xor'em. Ok - masz zaszyfrowaną ścieżkę, skopiuj sobie ją gdzieś w notatnik. Będziesz potrzebował znać każdy jeden kod ASCII zaszyfrowanej lokalizacji.

Teraz robisz taki myk, że tworzysz kilka klas (być może) dziedziczących po sobie i jak stworzysz ich obiekty, wywołujesz różnej maści ich metody, które po troszkę zwracają zaszyfrowaną ścieżkę. Ścieżkę dodajesz operatorem += na koniec std::string'a, robisz xora albo w momencie pobierania wyniku metod, albo pod koniec, kiedy cały zaszyfrowany string jest już prawie gotowy do użycia. Zaraz po użyciu (czyli odczytaniu pliku z datą) dany string wypełnij bzdurami, żeby w pamięci nie siedział sekret ;)

Trochę cudaczny sposób, zamiast klas po sobie dziedziczących możesz robić klasy wewnętrzne. To też rozrzuca wbrew pozorom po pliku exe dane. Generalnie w programie zapisałbym datę ostatniej kompilacji (w postaci zaszyfrowanej) gdyby jakiemuś zawodnikowi przyszło do głowy przestawić zegar w kompie jeszcze przed instalacją. Na jednej z maszyn wirtualnych tak mam ze względu na pewien program.

W razie jak się program zorientuje, że ktoś czy coś gmerało przy dacie, otwórz plik exe i go drania uszkodź usuwając losowe bajty, dodaj gdzieś info na dysku, że użyszkodnik próbował cudować ;]

Do zapisu w lokalizacjach systemowych potrzeba praw administratora, których program na 99.9% mieć nie będzie.

Po co dzielić zaszyfrowaną ścieżkę? I to klasami. To zajmie dużo kodu, a efekt będzie mizerny, bo i tak kompilator poukłada stringi obok siebie.

Zaraz po użyciu (czyli odczytaniu pliku z datą) dany string wypełnij bzdurami, żeby w pamięci nie siedział sekret

W pamięci i tak będzie dużo ścieżek do dysk:\windows\system32.. A poza tym, kto by grzebał w kilo/megabajtach pamięci prywatnej programu?

otwórz plik exe i go drania uszkodź

Program nie może sam siebie uszkodzić. (A przynajmniej nie bezpośrednio ;)) Poza tym bardzo łatwo to obejść.

Nie czytałem wszystkich postów, ale z tego co widzę to można zrobić kilka prostych myków, które na proste aplikacje powinny wystarczyć.

Po pierwsze szyfrowanie możesz zrobić różnymi algorytmami w co wliczam też XOR'owanie ;)
Po drugie aby uchronić plik przed zapisem możesz zrobić tak, by jakiś program cały czas działał w tle i tworzył uchwyt do pliku, wówczas pliku nie można zmodyfikować bez "odczepienia", czyli zamknięcia takiego procesu. Paru nieco bardziej ogarniętych użytkowników komputera to ominie, ale mówiłem, że jest to najprostsza metoda chyba.

Pekfos@ wystarczy drobna modyfikacja, zmienne zamiast trzymać w char* można przecież trzymać w wektorach, które to z kolei mogą przyjmować różne typy wejściowe :) Nie byłbym taki pewien, czy kompilator poukłada koło siebie dane, tzn czy będzie odpowiednio kolejność zachowana, a to kluczowe jest. Jeśli coś ma być zaszyfrowane wewnątrz programu to powinno być porozrzucane a nie zbitę np. w tablicę. System klas, o którym wspomniałem to jedynie sposób do rozważenia, nie jako jeden słuszny model.

Inna sprawa, program instalujący może wymagać praw administratora, a to furtka to systemowego katalogu Windows

Jeśli coś ma być zaszyfrowane wewnątrz programu to powinno być porozrzucane a nie zbitę np. w tablicę.

Mylisz się. W tym przypadku nie ma żadnego znaczenia, jak bardzo zaszyfrujesz dane. Program dla laika to ciąg krzaków, a zaszyfrowana ścieżka również będzie krzakami.

Poza tym, nawet gdybyś zaszyfrował ścieżkę AESem, podzielił ją na bity i porozsiewał je po całym pliku, ktoś bardziej ogarnięty odczyta ją bez problemu.