Guardship

Апісанне

Guardship разбірае ваш код .NET, а затым кампілюе код MSIL вашага выканальнага файла ў роднае некіраванае прыкладанне шляхам генерацыі двух частак: 1. Запуск модуля [Your_App_Name].com; 2. Бібліятэка [Your_App_Name].lib

Вашы праграмы (WinForms, WPF і г.д.), арыентаваныя на .NET Framework, кампілююцца ў прамежкавую мову (IL). Падчас выканання своечасовы кампілятар (JIT) перакладае IL у ўласны код. Guardship пераводзіць ваш выканальны файл .NET у уласны код, каб зрабіць яго схаваным. Калі вы запускаеце абаронены выканальны файл, ён мае ўсе магчымасці і функцыі кіраванага прыкладання, якое працуе ў памяці ПК. Але браўзеры зборкі .NET і дэкампілятары не змогуць прачытаць вашы абароненыя выкананыя файлы .NET.

Чаму Guardship ператвараецца ў некіравальны выканальны файл? Ёсць некалькі дызассемблераў для дэкампіляцыі некіравальных выкананых файлаў, напісаных на ASM, C або C++. Аднак ніводнаму з іх не ўдасца стварыць дастаткова чытэльны код, які б варты намаганняў. Вы выдаткуеце больш часу на тое, каб прачытаць дэкампіляваны зыходны код з асэмблерам унутры, чым на напісанне таго ж самага функцыянуючага прыкладання з нуля.

Фактычна, любы выканальны модуль можна разабраць і даследаваць. Лёгкасць, з якой дэшыфравальнік можа перарабіць зыходны код вашага прыкладання, залежыць ад таго, наколькі поўныя метаданыя пра зыходны код прыкладання прадстаўлены ў модулі exe. Ці можа расшыфроўшчык высветліць арыгінальныя назвы класаў, метады, працоўныя працэсы, структуры і г.д.? Кампілятар у асноўным ушчыльняе зыходны код прыкладання, пераўтвараючы вывад у фармат, які ў значнай ступені сумяшчальны з машынным выкананнем. Гэта можа быць уласны машынны код або байт-код IL, які апрацоўваецца прамежкавым асяроддзем выканання CLR. Аднак, па вялікім рахунку, шмат інфармацыі аб зыходным кодзе вашага прыкладання (адладка, каментарыі і г.д.) проста можа быць страчана падчас кампактнай кампіляцыі.