stringencrypt.com – szukam alternatywy dla Delphi

0

Szukam dla Delphi alternatywy darmowej do: stringencrypt.com
Nawet bym kupił, ale jakieś kredyty itp, nie akceptuję tego typu licencji...

0

Co jest nie tak z AESem czy innymi szyframi?

0

Jak chcesz kupić to jest bardzo dobry TMS Cryptography Pack https://www.tmssoftware.com/site/tmscrypto.asp

0

Potrzebuję ukrywać stringi w kodzie nie szyfrowania typowego.
Np:

xy: string;
xy:='Czytelny';

Chodzi mi o to żeby 'Czytelny' nie był już czytelny w binarce....

0

Ponowię moje pytanie raz jeszcze:

Co jest nie tak z AESem czy innymi szyframi?

0

To, że chociażby klucz szyfrowania nadal będzie stringiem w kodzie łatwym do przeczytania.
Po drugie używanie specjalnie AES'a do ukrywania takich rzeczy wydaje się być co najmniej dziwne.

1

Jeśli string ma nie być stringiem (jak ktoś zdekompiluje binarke i bardzo będzie chciał to i tak wszystko odczyta) to nie pytasz o szyfrowanie tylko zaciemnianie kodu.
Tutaj masz przykład czegoś podobnego do podanej strony
http://reverseengineeringtips.blogspot.com/2015/06/string-xoring-utility-10.html

0

To, że chociażby klucz szyfrowania nadal będzie stringiem w kodzie łatwym do przeczytania.

W przypadku dowolnego szyfrowania wystarczy podpięcie debuggera w odpowiednim miejscu aplikacji tak, aby być w stanie tak czy siak odczytać wszystko - bez zabawy w jakekolwiek ręczne odszyfrowywanie. Koniec końców aplikacja w pewnym momencie i tak musi te dane odszyfrować, by móc je wykorzystać, więc jest to zabezpieczenie najwyżej na kilkanaście minut.

Po drugie używanie specjalnie AES'a do ukrywania takich rzeczy wydaje się być co najmniej dziwne.

Dlaczego wykorzystywanie oprogramowania generującego "dynamiczne" algorytmy szyfrujące nie jest dziwne, a wykorzystanie algorytmu opracowanego w celu szyfrowania, którego siła jest potwierdzona wieloma badaniami, już dziwne jest?

0
Patryk27 napisał(a):

Dlaczego wykorzystywanie oprogramowania generującego "dynamiczne" algorytmy szyfrujące nie jest dziwne, a wykorzystanie algorytmu opracowanego w celu szyfrowania, którego siła jest potwierdzona wieloma badaniami, już dziwne jest?

Dlatego, że nowa biblioteka to nowe potencjalne problemy, nowe licencje oprogramowania itp.
Wiadomo, że można odczytać z pamięci koniec końców, ale przy patchowaniu pliku kiedy chcemy zamienić takiego stringa już kłopot robi się nieco większy.

@Clarc, dokładnie chodzi mi o zaciemnienie (obfuscation)

0

Dlatego, że nowa biblioteka to nowe potencjalne problemy, nowe licencje oprogramowania itp.

Przecież prędzej będziesz miał problemy z licencją takiego autorskiego generatora niż powszechnie uznanego i wykorzystywanego wszędzie AESa czy innego algorytmu szyfrującego. Tak jak zresztą doskonale widać na przykładzie tego wątku.

ale przy patchowaniu pliku kiedy chcemy zamienić takiego stringa już kłopot robi się nieco większy.

Wcale nie - I w jednym, i w drugim przypadku trzeba będzie zamienić w pliku binarnym pewien ciąg znaków na inny - w przypadku wykorzystania generatora trzeba będzie zamienić cały wygenerowany przez niego kod, a w przypadku szyfrowania - szyfrogram. Nie robi to jednak różnicy z punktu twórcy patcha.

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