Nie-wkompilowywanie smieci do programu

Witam was serdecznie,

meczy mnie od dluzszego czasu pewien problem, otoz Delphi - 7, XE, XE2, kazda wersja, a takze Free Pascal do skompilowanego programu dodaje roznego rodzaju smieci, ktore moga ulatwic np. zlamanie mojej aplikacji.

Konkretnie chodzi o:

1. Nazwy uzytych unitow - kazdy jeden unit znajduje sie w skompilowanym programie, mozna zobaczyc jakich komponentow program uzywa.
2. Struktury danych (type=record). Skopilowana aplikacja posiada w postaci zwyklego tekstu zapisany kazda nazwe struktury, oraz kazde pole w danej strukturze.
3. Komponenty form oraz ich zdarzenia (np. Button1, Button1Click...) - wszystko podane jak na tacy.

Wylaczajac RTTI oraz wszystko co zwiazane z debugowaniem udalo mi sie wywalic tylko nazwy pol w strukturach danych, natomiast nazwa struktury juz zostala, nie wspominajac o calej reszcie smieci.

Zwracam sie do was zatem z uprzejma prosba o wszelkie informacje mogace pomoc w usunieciu niepotrzebnych danych z programu. Dodam jeszcze, ze nadpisanie ich (winhexem) nie zmienia dzialania programu - nie wystepuja zadne anomalie, typu crash; oraz, ze nie interesuja mnie packery badz cryptery - zjadaja one RAM i spowalniaja aplikacje.

Dobry packer/crypter nie spowolni aż tak Twojej aplikacji. Polecam PESpin by cyberbob.

Dobry packer/crypter nie spowolni aż tak Twojej aplikacji. Polecam PESpin by cyberbob.

Dobry packer/crypter zostanie rozpakowany/rozszyfrowany w 2 minuty bo jest do niego masa narzędzi.

meczy mnie od dluzszego czasu pewien problem, otoz Delphi - 7, XE, XE2, kazda wersja, a takze Free Pascal do skompilowanego programu dodaje roznego rodzaju smieci, ktore moga ulatwic np. zlamanie mojej aplikacji.

To ma ułatwić debuggowanie, w FPC jest program konsolowy strip, którego używasz w tym stylu: 'strip --strip-all program.exe', i już nie masz symboli debuggera.

Ale samo wywalenie symboli debuggowania to słabe zabezpieczenie, ja używam swojego obfuskatora kodu (który zmienia nazwy rekordów/zmiennych/procedur i dodaje śmieci) + do dllek szyfratora sekcji relokacji + pracuję nad szyfrowaniem całych sekcji .

Dobry packer/crypter zostanie rozpakowany/rozszyfrowany w 2 minuty bo jest do niego masa narzędzi.

To znaczy że nie jest dobry. Zazwyczaj co chwilę wychodzi kolejna wersja packera, działająca nieco inaczej i przez to znalezienie odpowiedniego unpackera jest bardzo trudne albo niemożliwe.

Ale samo wywalenie symboli debuggowania to słabe zabezpieczenie, ja używam swojego obfuskatora kodu (który zmienia nazwy rekordów/zmiennych/procedur i dodaje śmieci)

Przecież w pliku .exe - po wywaleniu symboli debuggera - nie ma nigdzie zapisanych informacji o nazwach procedur i rekordów a śmieci przy optymalizacji są wywalane...

To znaczy że nie jest dobry. Zazwyczaj co chwilę wychodzi kolejna wersja packera, działająca nieco inaczej i przez to wymagająca innego unpadkera.

I na pewno codziennie aktualizujesz swój program. Narzędzia wychodzą tak szybko że miesiąc po wypuszczeniu programu będzie on już na przegranej pozycji. Bez sensu, zwłaszcza że większość protektorów dobrych jest płatnych, to jeszcze łamią się jak zapałki. Każdy cracker ma masę narzędzi do łamania protektorów + ich sposoby działania są znane więc są tutki jak to obejść.

Przecież w pliku .exe - po wywaleniu symboli debuggera - nie ma nigdzie zapisanych informacji o nazwach procedur i rekordów a śmieci przy optymalizacji są wywalane...

Też tak myślałem, ale jak przejżałem exek to się zdziwiłem. jest jeszcze RTTI i inne dziwne magiczne rzeczy. poza tym mój obfuskator szyfruje też stringi więc ciężko jest znaleźć punkt zaczepienia (zwłaszcza że połowa kodu po wszystkim jest błędna ze względu na sztuczki z JMP i CALL).

a co byś powiedział na zaszyfrowany zasób który rozpakowujesz w ram'ie i go stamtąd odpalasz to trochę trudno bo nie będziesz mógł przeglądać programu przez takie narzędzia jak ResHacker
(to tylko sugestia)

W sumie dobry pomysl, ~123 ;) Obfucator, to dla Delphi chyba jedyne wyjscie.

polecam aplikację VMProtect jak działa.. z strony vmprotect :

VMProtect protects code by executing it on a virtual machine with non-standard architecture that makes it extremely difficult to analyze and crack the software.