GoldenLine
Zaloguj się
Norbert M.

Norbert M. Nobody's perfect.
Call me Nobody ;)

Temat: Dekompilacja kodu

Witam. Chciałbym wystawić komuś kilka napisanych przeze mnie metod w dll’ce. Czy jest jakiś sposób na uniemożliwienie lub znaczne utrudnienie dekompilacji kodu? Nie chciałbym, żeby mój kod został rozszyfrowany np.: za pomocą reflectora.
Dzięki i pozdrawiam.
Link do wypowiedziLink
Sławomir Z

Sławomir Z Starszy Projektant /
Starszy Programista

Temat: Dekompilacja kodu

Jedna z metod jest uzycie programu do zasmiecania kodu - siakiegos Obfuscatora. Zabezpieczenie to tylko utrudnia odczytanie kodu ... ale zawsze to cos.
Link do wypowiedziLink

konto usunięte

Temat: Dekompilacja kodu

Uniemożliwić raczej nie, ale możesz znacznie utrudnić.

Po pierwsze - obfuskacja kodu. Oczywiście da się ją odwrócić, ale zdecydowanie utrudnia ona śledzenie kodu. Zapewne skutecznie zniechęcisz kogoś kto 'od tak' będzie po prostu chciał podejrzeć kod, ale na upartego nie poradzisz.

Po drugie, istnieje kilka trików, które można zastosować, aby wywalić reflektora/ildasma. Niestety nie wszystkie z nich działają na innych narzędziach, których możemy użyć do dekompilacji twoich dll'ek.
Pamiętaj, że jak ktoś jest zdeterminowany choćby miało mu to zająć tydzień to siądzie i ręcznie ci tę dll'kę rozkoduje tak więc te metody to co najwyżej tak zapobiegawczo na 'niedzielnych hakerów'.

BTW. Możesz napisać co chcesz przez to zabezpieczenie osiągnąć? Może nie tędy droga?
Link do wypowiedziLink
Norbert M.

Norbert M. Nobody's perfect.
Call me Nobody ;)

Temat: Dekompilacja kodu

Pamiętaj, że jak ktoś jest zdeterminowany choćby miało mu to zająć tydzień to siądzie i ręcznie ci tę dll'kę

Tak właśnie podejrzewałem, chciałem się jednak upewnić.
BTW. Możesz napisać co chcesz przez to zabezpieczenie osiągnąć? Może nie tędy droga?

Chcę - jak to słusznie ująłeś - zabezpieczyć się na wypadek 'niedzielnych hakerów' :D. Nie jest to nic czego muszę specjalnie chronić, ale nie chcę komuś od tak podać kodu na talerzu.

Wiecie gdzie mogę doczytać coś więcej na temat Obfuscator'ów (oraz trików na Reflectora jeśli można :D)? To dla mnie nowe zagadnienie.

Dzięki i pozdrawiam.
Link do wypowiedziLink

konto usunięte

Temat: Dekompilacja kodu

Podstawowy obfuscator masz dostępny w VS - Dotfuscator Community Editor. Ale lepiej zapytać google o .NET Obfuscator, bo są na pewno oferujące lepsze możliwości.
Co do trików, to powiem szczerze nigdzie nie spotkałem się z artykułem podsumowującym różne techniki (mam w planach post z tym co ja wymyśliłem, ale z braku czasu ciągle odkładam go). Może trochę na OWASP poszperaj.

Niestety będziesz musiał bawić się ILASM'em, żeby to zrobić.
1) Załóżmy, że masz fragment kodu, który wygląda tak
ret

     [instrukcja operująca na stosie]

ret

Oczywiście takiego kodu nie wyprodukujesz za pomocą C#. Musisz posłużyć się MethodBuilder'em (swój kod w postaci IL dostaniesz za pomocą GetMethodBody (na obiekcie MethodInfo). Reflector parsując ten kod do C# będzie próbował wykonać to (stos pusty) i wywali się. Niestety IL pokaże się bez problemu. Wystarczy edycji dll'ki i mamy też C#/VB.NET i inne.
2) Możesz w strumień bajtów wklejać opcody, które nie są przyporządkowane do różnych instrukcji, oczywiście musisz dać BR_S przed tym - czyli musisz mieć 3 bajtowe NOP'y w kodzie.
3) Oba narzędzia mają problem z buffer overload na co wskazał Dinis Cruz na OWASP'ie Buffer_OverFlow_in_ILASM_and_ILDASM.
Wygenerowanie assembly z metodą, która ma 64k znaków w nazwie wywala oba narzędzia. Mankament jest taki, że jedynie możesz zawołać to przez Reflection (i nie sądzę, że to dobry pomysł aby metoda publiczna miała tak długą nazwę :-)).

Przypomniało mi się jeszcze, że możesz dll'kę generować w pamięci user nie będzie miał fizycznie jej na dysku (o ile nie zrobi sobie dump'a pamięci). Jakoś to też zniechęci, jak w kodzie zobaczy IL'a.

Ale tak jak pisałem - wszystko da się obejść. Jeśli miałbyś jakieś pytania to chętnie odpowiem. Jest to ciekawy dla mnie temat.Paweł Łukasik edytował(a) ten post dnia 14.01.09 o godzinie 15:09
Link do wypowiedziLink
Norbert M.

Norbert M. Nobody's perfect.
Call me Nobody ;)

Temat: Dekompilacja kodu

Wielkie dzięki. Myślę że w chwili obecnej zatrzymam się na poziomie jakiegoś Obfuscator'a, ale to naprawdę ciekawe zagadnienie i będę je dalej zgłębiał :D
Link do wypowiedziLink

konto usunięte

Temat: Dekompilacja kodu

Temat jest nadzwyczaj ciekawy (jak też inne związane z bezpieczeństwem (a może niebezpieczeństwem?) .net. I na pewno byłoby wiele ciekawych trików, ale mało osób tym tematem jest zainteresowana. Konkurs na najlepsze .net-owe CrackMe ( Konkurs CrackMe) w ramach KGD.NET miał spopularyzować to zagadnienie, ale widać chętnych nie ma.Paweł Łukasik edytował(a) ten post dnia 14.01.09 o godzinie 15:12
Link do wypowiedziLink
Marcin Pigłowski

Marcin Pigłowski Specjalista ds. baz
danych

Temat: Dekompilacja kodu

Norbert Maziarz:
Wielkie dzięki. Myślę że w chwili obecnej zatrzymam się na poziomie jakiegoś Obfuscator'a, ale to naprawdę ciekawe zagadnienie i będę je dalej zgłębiał :D

jako student słyszałem, że wystarczy dać kod do przepisania/napisania studentowi informatyki i już jest tak zaciemniony, że nikt z niego nic nie odczyta :D
Link do wypowiedziLink
Łukasz Skłodowski

Łukasz Skłodowski SharePoint
Architect, PM,
Właściciel -
Mavsystem

Temat: Dekompilacja kodu

Zerknij sobie na ten obfuscator:
http://www.foss.kharkov.ua/g1/projects/eazfuscator/dot...
Link do wypowiedziLink

konto usunięte

Temat: Dekompilacja kodu

do tej pory uzywalem dotfuscator community edition... nie jest to high tech zaden, bo da sie przesledzic co i jak w kodzie piszczy. Niemniej jak na razie dla mnie jest wystarczajacy. A wiadomo, ze jak ktos sie uprze, to i tak da rade.

BTW - Paweł, dzięki za info o CrackMe :) poki co zalogowalem sie na stronce - znajde chwile to sie pobawie w "krakjera" :p
Link do wypowiedziLink

konto usunięte

Temat: Dekompilacja kodu

Odnośnie zabezpieczeń to wiadomo, że większość da się złamać. Warto po prostu wiedzieć co i jak i podejmować świadomy wybór.

A co do konkursu CrackMe, to troszkę szkoda, że tak mało chętnych i właściwie konkurs upadał zanim wystartował. Żałuję, bo temat sądzę jest ciekawy. Jednakże jeśli ktoś chętny to zachęcam do próby po obu stronach konkursu.
Link do wypowiedziLink

konto usunięte

Temat: Dekompilacja kodu

Są jeszcze inne narzędzia, konwertujące MSIL-a do kodu natywnego, na przykład Salamander .NET protector albo .NET Reactor.
Nie używałem żadnego z nich, ale pewnie niedługo będę musiał. Może ktoś ma jakieś doświadczenia i chciałby się nimi podzielić?
Link do wypowiedziLink
Krzysztof Mierzejewski

Krzysztof Mierzejewski SharePoint
Consultant

Temat: Dekompilacja kodu

A może po prostu NGen?
Link do wypowiedziLink
Arkadiusz Benedykt

Arkadiusz Benedykt programista,
analityk,
poszukiwacz lepszej
drogi

Temat: Dekompilacja kodu

Bolesław Tekielski:
Są jeszcze inne narzędzia, konwertujące MSIL-a do kodu natywnego, na przykład Salamander .NET protector albo .NET Reactor.
Nie używałem żadnego z nich, ale pewnie niedługo będę musiał. Może ktoś ma jakieś doświadczenia i chciałby się nimi podzielić?

Swego czasu Salamander zbierał bardzo wysokie noty, ich obfuscator był tak dobry, że ich własne narzędzia do "deobfuscacji" nie radziły sobie z nim :) no i oczywiście oferowali kompilację do kody natywnego. Nie wiem jak sytuacja wygląda teraz. Może ktoś tutaj używał tego narzędzia i podzieli się opinią
Link do wypowiedziLink

konto usunięte

Temat: Dekompilacja kodu

Ja dodam, że problem staje się coraz ważniejszy jak weźmiemy pod uwagę Silvelighta. Kod łatwo pobrać (XAP), a większość dobrych obfuscatorów (jak Salamander) nie działa z SL. Podobno tylko dotfuscator pro wart uwagi w tym względzie.Sebastian Pienio edytował(a) ten post dnia 18.01.09 o godzinie 13:54
Link do wypowiedziLink
Andrzej Szymczak

Andrzej Szymczak Student, Poznańska
Wyższa Szkoła
Biznesu i Języków
Obcych

Temat: Dekompilacja kodu

Ja powiem tak, miałem doświadczenie z wieloma obfuscatorami, najpierw na xp teraz na viście; na xp bardzo dobry jest codeveil - strasznie mocno zabezpiecza i kombinuje( dodatkowo szyfruje ) - tak bardzo że czasami program może być wykryty jako wirus(!) a w reflectorze nie pokazuje w ogóle że to jest program .net. Dobry jest także smartassembly; dużo opcji konfiguracji. Gdy przesiadłem się na Vistę codeveil i smartassemby przestały działać, ale za to testowałem PreEmptive Dotfuscator i muszę powiedzieć , że obecnie chyba najlepszy; a z tym czy da się coś złamać czy nie - kiedyś programowałem też w c++ i wiadomo każdy cracker użyje idy albo ollydbg i po sprawie, ale według mnie programy w .net( ja piszę w c#) są o wiele trudniejsze do złamania bo niejako kod zaobfuscowany to kod nieczytelny a jeżeli program jest rozbudowany rozszyfrowanie jest prawie niemożliwe, po za tym nie cały program w .net jest kompilowany od razu, a w postaci nieuruchomianej nie jest w ogóle skompilowany i jedyna opcję jest jego deobfuskacaja która czasami jest niemożliwa, oczywiście jak robimy światowej sławy program to jakiś spec "da radę" ale jeżeli robimy własne oprogramowanie nie aż tak popularne to obfuskacja jest dość dobrym zabezpieczeniem.
Link do wypowiedziLink
Stanisław P.

Stanisław P. Software designer

Temat: Dekompilacja kodu

Andrzej Szymczak:
a z tym czy da się coś złamać czy nie - kiedyś programowałem też w c++ i wiadomo każdy cracker użyje idy albo ollydbg i po sprawie, ale według mnie programy w .net( ja piszę w c#) są o wiele trudniejsze do złamania bo niejako kod zaobfuscowany to kod nieczytelny a jeżeli program jest rozbudowany rozszyfrowanie jest prawie niemożliwe, po za tym nie cały program w .net jest kompilowany od razu, a w postaci nieuruchomianej nie jest w ogóle skompilowany i jedyna opcję jest jego deobfuskacaja która

A ja myślę, że jest dokładnie odwrotnie. Próbując obejść dobre zabezpieczenie .net'a nie bawiłbym się wogóle w odszyfrowywanie tego. Dwie drogi są dużo prostsze:
- Jeśli zabezpieczenie nie miesza za bardzo samego systemu ładowania, to wystarczy odinstalować .net2 i dopisać patch do mono, który jeśli już dostanie wersję przeznaczoną do wykonania, w czasie kompilacji -> niech wypisze czysty CIL do jakiegoś pliku
- Jeśli ładowanie jest bardzo zamieszane - spróbować zrobić to samo na binarce .NET'u oryginalnego... tu mogą podpisy binarek trochę namieszać, ale może jest wykonywalne. W końcu wiadomo jakie funkcje kompilują CIL, więc można nawet inject własnego dll'a zrobić w trakcie

Takie podejście nie zależy od systemu szyfrowania / obfuscacji, więc powinno działać na wszystko tak samo dobrze ;)
Link do wypowiedziLink

konto usunięte

Temat: Dekompilacja kodu

Właśnie mniej więcej takie podejście pokazał Dinis Cruz w prezentacji "Rooting The CLR" - http://video.google.com/videoplay?docid=-2492965730809...
Ponieważ biblioteki .NET Frameworka są w tej samej przestrzeni co nasz proces to możemy sobie z nim troszkę porobić za pomocą API windowsowego. Polecam filmik dla ciekawskich.
Link do wypowiedziLink
Andrzej Szymczak

Andrzej Szymczak Student, Poznańska
Wyższa Szkoła
Biznesu i Języków
Obcych

Temat: Dekompilacja kodu

Całkiem trafne spostrzeżenia Panie Stanisławie, aczkolwiek byłem kiedyś na forum crackerów programów .NET i oni nie próbowali takich sposobów, mało tego dla nich priorytetem było zdjęcie zabezpieczenia z programu .NET a potem mając program już "czysty" zmiana czegoś reflectorem, zakładali oni, że gdzieś MUSI być miejsce w którym jest odpakowywany cały IL, aczkolwiek była to dyskusja o CodeVeil który szyfruje plik bin .net, ale nie wiem jak sytuacja wygląda w przypadku samej obfuskacji, aczkolwiek wiem że crackerzy ci mieli problem z którąś wersję CodeVeil - po prostu nie potrafili odwrócić działań tego programu w 100%; taka mała dygresja wracając jeszcze do zabezpieczeń - są tz. kompilatory native( salamander, .net reactor) - strasznie ich nie polecam, bardzo zwiększają rozmiar wynikowy całego produktu i ogólnie są mocno niestabilne.
Link do wypowiedziLink
Norbert M.

Norbert M. Nobody's perfect.
Call me Nobody ;)

Temat: Dekompilacja kodu

Nie wiem czy dokładnie wszystko dobrze rozumiem, ale działanie Obfuscatora polega na tym, że zaciemnia kod przez zamianę nazw. Np. moja metoda "MyMethod(int index)" po przerobieniu będzie wyglądać np tak "a(int b)". Ja chciałbym jednak zrobić coś innego. Zachować nazwy, ale uniemożliwić odczytanie kodu zawartego w metodzie. Powiedzmy, że mam dll’kę z metodami służącymi do jakichś obliczeń i chciałbym zlecić komuś napisanie aplikacji, która cośtam robi, ale z tych metod korzysta, nie chcę jednak, aby wiedział, co dana metoda robi sobie w środku. Jego obchodzi tylko to, co ona(metoda) przyjmuje i co zwraca, ale takie informacje dostanie w specyfikacji.
Czy tak możliwość istnieje? Chodzi mi o sposób w miarę szybki i prosty, choć domyślam się, że tak prosto nie będzie :D.

PS: Jak dotąd korzystałem jedynie z Obfuscatora dostępnego w VS. Czy inne zaciemniają kod w jakiś inny sposób??

Pozdrawiam NNorbert Maziarz edytował(a) ten post dnia 20.01.09 o godzinie 14:49
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy





Wyślij zaproszenie do
Anuluj