Tajne dane (np. hasła aplikacji) w kodzie programistycznym .NET – zagrożenia

Nowe technologie mają wiele plusów i wiele „minusów”. Przyglądając się dokładniej często minusami nazywamy to co w koncepcji miało być wyróżnikiem. Dziś chciałbym powiedzieć o czymś co nazywa się dekompilacją kodu i zagrożeniami z tego płynącymi. Na początek krótka teoria. .NET Framework, poprzez środowisko uruchomieniowe .NET przekształca kod źródłowy (zgodny z CLS – Common Language Specyfication) w kod pośredni IL – Intermediate Language (nazywany też MSIL – Microsoft Intermediate Language czy CIL –Common Intermediate Language). Następnie, już podczas uruchamiania na konkretnej maszynie CLR (Common Language Runtime) poprzez kompilator JIT (Just In Time) przekształca kod IL w kod maszynowy. Ciekawy jest kod pośredni IL. To właśnie ten kod przechowywany jest w kontenerach nazywanych podzespołami. Podzespoły te mają ogólnie znane rozszerzenia .exe i .dll, (w rzeczywistości są w nich spore różnice w stosunku do „dawnych” .exe czy .dll, ale dziś nie o tym chcę napisać). I teraz sedno tematu. Otóż z plików tych można w dość prosty sposób uzyskać kod programistyczny (pierwotny) poprzez dekompilacje (np. programem ILDasm.exe). Co to oznacza? Ujawniany jest nasz know-how programistyczny, dostępne są np, często innowacyjne, algorytmy. Ponadto jeżeli użylibyśmy w kodzie jakichkolwiek haseł czy innych danych, które stanowią naszą tajemnicę, wszystko to będzie widoczne. Można się przed tym częściowo zabezpieczyć stosując „zaciemniacze” (jest dostępnych trochę komercyjnych rozwiązań, a w Visual Studio 2005 jest dostarczony Dotfuscatro Community Edition). Powodują one, że jest znacznie trudniej pozyskać kod źródłowy, ale nadal będzie to możliwe.