Здесь предлагаю собирать ссылки на статьи/инструменты по разбору и защите от разбора приложений .NET Сгодится любая информация, даже та, которая кажется лично Вам очевидной. https://www.securitylab.ru/analytics/439111.php - http://www.vijaymukhi.com/documents/books/metadata/contents.htm - статьи https://github.com/0xd4d - инструменты https://wasm.in/resources/c-deconstructed.30/ - книга ( надо бы поиск здесь пошерстить, тоже добавить ссылок )
https://wasm.in/threads/issledovanie-net-ispolnjaemyx-fajlov.7243/ https://ntcore.com/files/disasmsil.htm - a free MSIL disasm engine http://83.133.184.251/virensimulation.org/lib/vbe00.html
А почему только .net ? Давайте уже и натив в том числе. https://rutracker.org/forum/viewtopic.php?t=5594952 Это курс по взлому, регулярно сливается с exelab. Но не ждите там ниндзя трюков и приемов. Так же там куча утилит для взлома.
По поводу защиты .net. Лучшее что я видел в защите вот https://bhf.io/threads/258853/ Не реклама. Чел, каким то макаром накрывает фиг пойми чем но взломать очень сложно)
Ненене Дэвид Блейн, в этом топике только Дотнет. О "нативе" (у меня стойкая ассоциация с нейтив-апи, когда слышу это слово) уже писано-переписано лет за 20 дофига и где только можно. Пакеры PE были уже в 1998 ( пусть не пакер, Pe-Crypt32 by Jibz ) Именно и только .Net. Потому что о нем говорят понемногу и редко. А увы, "прогресс" таков, что наступит время, когда только дотнет и будет. Так что давайте подтягивать матчасть. Кто напишет "взлом приложений на .Net framework с нуля", по аналогии с серией Нарвахо, или что-то вроде "win32 приложение голыми руками", только для байткода?
Расскажу все что сам знаю о защите. От множества VM протекторов уже написаны анпакеры и слиты в сеть. Обычная обфускация не спасает, сами понимаете это вопрос времени. Конфузер тоже себя скомпрометировал. Вся защита кроме аппфускатора и иазфускатора снимается de4dot`ом. Забил я на защиту .net и выношу код на VDS. Благо щас они все дешевле и дешевле. В эту тему нужен реверсер, который держит руку на пульсе и следит за реверсингом .net приложений. Но он тут никогда не появится, потому что никто не хочет делиться своими маленькими секретами.
есть забавная идея: эмбедишь себе интерператор WebAssembly в .NET приложение (https://github.com/RyanLamansky/dotnet-webassembly), важную бизнес логику пишешь на любом языке, который компилиться в WebAssembly байт-код... получаешь профит до тех пор пока для WebAssembly не сделают нормальный дизассемблер/декомпилер... даже аббревиатура WebAssembly звучит как WASM, это судьба поцоны...
Очень дальновидно эмбедить опенсурсный интерпретатор в надежде, что никто превозмогая трудности и запершись в квартире на полгода не отреверсит таки этот опенсурс. Особенно учитывая то, что WASM instructions are mapped to their .NET equivalents and converted to native machine language by the .NET JIT compiler.
наверняка это реализовано через System.Reflection.Emit и происходит в рантайме, то есть в статике такое не разберешь, нужно запускать отладчик и отлавливать создаваемые DynamicAssembly...
Ага WebAssembly/compile.cs так и делает. А еще там есть WebAssembly/OpCode.cs. По-моему вопрос неразбираемости в статике к самому компоненту относиться не может. Пришлось недавно рыться в одной большой программулине, которая раньше была в нейтиве и содержала простенький собственный интерпретатор и функции к нему в дико замороченном формате файлов. С недавного времени они перешли на дотнет, большое человеческое им за это спасибо)
Т.е. в .net приложении можно напихать нативных вставок в которых будет какая то проверка? Или я не так это все понимаю?
Библиотека позволяет создавать, открывать, изменять, сохранять и исполнять WebAssembly-файлы из дотнетных приложений. При исполнении не используется интерпретатор. ВАЗМ-инструкции путем тупой замены преобразуются в дотнет-байткод средствами налетукомпилера.
переход к открытому коду неизбежен.. 1. позволяет бороться с воровством. 2. позволяет расширять пул разрабов. 3. для защиты от пираток достаточно привязать его к железкам и продавать аппаратно-программное решение + такой подход может сильно увеличивать производительность. 4. ещё одна схема от пираток == облачка.
Как по Марксу, наступление коммунизма неизбежно. Пингвинятники эту мантру десятилетиями твердят и ютятся в маленькой узконаправленной серверной нише. А бал почему-то правят корпорации со своим закрытым кодом. Есть у опенсурса его особые генетические черты: делается он на голом энтузиазме и с целью поторговать лицом, поэтому часто без напилинга и паялинга толком не работает даже. Самый верный способ защиты - сделать так, чтоб до самой интересной части алгоритма было невозможно дотянуться. Это либо выносить ее на сервер, либо в донгл, всё остальное несерьезно. Разработчики игрушек нашли компромисс - чтоб в оффлайн режиме игра была неполнофункциональна. Скачал школьник репак от РГ ВаськиИнносетупМастера, прошел кампанию, мучаясь с вылетами и пропаданием сейвов, а ачивок и сетевого режима не получил.
MDBG Существует штатный API для отладки .NET, который использует MDBG - отладчик от MS. https://www.microsoft.com/en-us/download/details.aspx?id=2282 Можно ставить брейки на функции. Есть несколько "но": 1.) Отладочный функционал урезан (например, я так и не понял как поставить брейк на перегруженную функцию - это когда две функции с одним именем; а ещё, насколько я помню, брейки можно ставить только на ф-ии и ни на что другое) 2.) Информацию о локальных переменных (и переданных аргументах) можно получить не всегда - возможно, это что-то вроде debug info и нужна debug-сборка 3.) Отладчик и отлаживаемый процесс должны иметь одинаковый Target CPU
