Как взломать net программу

Файл DLL (Библиотека DynamicLink) — это файл библиотеки динамической связи, также известный как «разработка приложений», является типом файла программного обеспечения. В Windows многие приложения не являются полным исполняемым исполняемым, которые разделены на некоторые относительно независимые библиотеки динамической связи, а именно DLL-файлы, помещенные в систему. Когда мы выполняем программу, будет вызываться соответствующий файл DLL. Приложение может использовать несколько файлов DLL, файл DLL также может использоваться различными приложениями, такой файл DLL называется общим файлом DLL.

2.dll Модификация файлов

Многие библиотеки упаковки в реальном использовании могут понадобиться масштабировать или изменять (треснуты). Но нет исходного кода, как изменить файл DLL? Эта статья делает простой расчесывание. Netdll файл.

Так называемые рабочие должны иметь проститутку, прежде чем официально начать, мы подготовим следующие публичные инструменты:

1. .NET Refluer Completed в C #, очень полезно, основной пользователь экспортирует проект VS, а затем просмотреть отношения класса Call.

Простейший взлом через NET Reflector. Получение закрытого ключа шифрования

2. ILDasm Перекомпилируйте файл DLL и отбрасывает файл IL

ILMASM — это программа .NET, в которой предоставлена ​​Microsoft, расположенная в «C: ProgramageFiles Microsoft Sdks Windows v7.0a bin ». Мой компьютер находится в этой папке в этой папке, 64-битные системы могут быть под C: Programfilefiles (x86) Microsoft Sdks Windows v7.0a bin.

3. NodePad ++, используемый для просмотра и редактирования файлов IL, которые для регинировщиков ILDasm.

4. ILASM компилирует файл .il .dll file

ILASM находится в соответствующем каталоге .NETFRAMEWORK, например: C: Windows Microsoft.net framework v2.0.50727 Ilasm.exe

5. Программное обеспечение Visual Studio используется для просмотра файлов проекта C #, которые Refreicle.net Refermeration.

1. Сначала найдите файл DLL, который вам необходимо изменить;

2. Используйте iLDasm.exe, чтобы открыть файл DLL и дамп в файл IL. Здесь есть деталь. Вы должны передавать в формат UTF-8. Вы не можете превратить в ACSII, или какой-то запутанный код потеряет некоторую информацию. При преобразовании в файл IL файл .res, который обычно генерирует одно имен одновременно.

3. Откройте файл DLL, используя ReflicTore.net и выберите элемент в браузере левого объекта. Как показано ниже

Затем нажмите «Файл / экспортировать исходный код» . или использовать клавишу ярлыка CTRL + S непосредственно для всплывающего интерфейса Сохранить интерфейс. Выберите путь, который вы хотите сохранить здесь, нажмите «Пуск».

4. Когда мы приедем сюда, мы можем поставить два инструмента ILDasm.exe и Reflector.net. Используйте NodePad ++, чтобы открыть файл IL, просто нажмите, используйте vs, чтобы открыть файл проекта DLL C #, который только что был преобразован. Используйте файл проекта C # для просмотра классов и ссылок, затем подтвердите, что вам нужно изменить. Затем в файл IL сохраните его после завершения модификации. Ссылка http://www.cnblogs.com/zc22/Archive/2010/02/20/1669550.html)

Как ВЗЛОМАТЬ приложение и получить ИСХОДНЫЙ КОД программы? [Reverse engineering, JetBrains dotPeek]

5. Далее, используйте ярлык Win + R, чтобы открыть командную строку, введите CMD Нажмите, чтобы подтвердить.

Используйте команду: cdc: windows microsoft.net frame v2.0.50727 Переключитесь в папку, в которой каталог находится в папке, где находится Ilasm.

Далее: Ilasmc: mbtcp.il c: mbtcp.res /output=c:/mbtcp.dll / dll (исходный файл iLASM.

Я положил файлы .il и .res, которые я сделали в приводе C, я положил сгенерированный каталог файлов в корневом каталоге C-привода, а выполнение следующее.

Когда вы видите подсказку успеха, вы можете найти файл DLL, который вы выполнили в своем каталоге. Что касается того, как взломать шифрование файла DLL, просто измените соответствующую позицию в файле IL.

Источник: russianblogs.com

Неядерный реактор. Взламываем протектор .NET Reactor

Для защиты при­ложе­ний .NET от отладки и ревер­са сущес­тву­ет мно­жес­тво спо­собов (шиф­рование, ком­прес­сия и дру­гие), а так­же спе­циаль­ных про­тек­торов, таких как, нап­ример, Agile.Net и Enigma. О взло­ме мно­гих из них мы уже пи­сали. Сегод­ня я рас­ска­жу, как побороть еще один популяр­ный про­тек­тор и обфуска­тор — .NET Reactor.

Итак, пред­ста­вим себе такую гипоте­тичес­кую задачу: у нас име­ется некое при­ложе­ние с онлайн‑про­вер­кой лицен­зии при заг­рузке. Его ана­лиз при помощи DIE детек­тит наличие плат­формы .NET. Заг­рузив прог­рамму в отладчик dnSpy, обна­ружи­ваем сра­зу две вещи: пло­хую и хорошую. Нач­ну с пло­хой: при­ложе­ние жес­токо обфусци­рова­но, часть методов пере­име­нова­на в бес­смыс­ленный набор сим­волов, а глав­ное, вмес­то их кода пов­сюду пус­тые заг­лушки.

Для очис­тки совес­ти про­буем сдам­пить при­ложе­ние спо­соба­ми, опи­сан­ным в моей пре­дыду­щей статье, — это час­тень­ко помога­ет вос­ста­новить скры­тый код методов. Увы, не в нашем слу­чае: сдам­плен­ные модули работос­пособ­ны, но несиль­но отли­чают­ся от исходных. Обфуска­ция никуда не делась, тела методов все рав­но пус­тые.

Воз­вра­щаем­ся в отладчик dnSpy и про­буем пот­расси­ровать работа­ющую прог­рамму. А вот и хорошая новость: в при­ложе­нии нет анти­отладчи­ка, при­ложе­ние прек­расно запус­кает­ся и трас­сиру­ется, при­чем при трас­сиров­ке «пус­тых» методов во вклад­ке Call Stack вид­но, что счет­чик команд переме­щает­ся по невиди­мому коду и про­вали­вает­ся в вызовы. Погуляв всле­пую по коду, мы обна­ружи­ваем еще одну хорошую новость: не все методы пере­име­нова­ны, некото­рые наз­вания впол­не осмыслен­ны, и мож­но даже нащупать про­цеду­ру про­вер­ки валид­ности (на скрин­шоте выше — isValid ). Тело дан­ного метода скры­то, но наз­вание и индекс извес­тны, и это уже что‑то.

Поп­робу­ем подой­ти к деоб­фуска­ции по стан­дар­тной схе­ме: для начала нат­равли­ваем на при­ложе­ние de4dot. К сожале­нию, в нашем слу­чае этот метод не работа­ет, de4dot ничего не деоб­фусци­рует. Более ста­рые вер­сии сра­зу валят­ся с ошиб­кой:

Detected .NET Reactor 4.8

Не­обра­ботан­ное исклю­чение: System.Security.Cryptography.CryptographicException: Недопус­тимая дли­на дан­ных для дешиф­рования.
в System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount)
в de4dot.code.deobfuscators.DeobUtils.AesDecrypt(Byte[] data, Byte[] key, Byte[] iv) в D:ade4dot-cexde4dot-cexde4dot.codedeobfuscatorsDeobUtils.cs:стро­ка 87
в de4dot.code.deobfuscators.dotNET_Reactor.v4.EncryptedResource.DecrypterV1.Decrypt(EmbeddedResource resource) в D:ade4dot-cexde4dot-cexde4dot.codedeobfuscatorsdotNET_Reactorv4EncryptedResource.cs:стро­ка 225
в de4dot.code.deobfuscators.dotNET_Reactor.v4.EncryptedResource.Decrypt()
.

Вер­сии пос­вежее фор­мулиру­ют ошиб­ку лаконич­нее:

Latest version and source code: http://www.de4dot.com/
21 deobfuscator modules loaded!

Detected .NET Reactor 4.8

ERROR:
ERROR:
ERROR:
ERROR: Hmmmm. something didn’t work. Try the latest version.

Ну теперь мы хотя бы зна­ем, с чем име­ем дело, — это .NET Reactor вер­сии пред­положи­тель­но 4.8. Вер­сия доволь­но ста­рая, одна­ко с ней не справ­ляет­ся даже спе­циаль­но обу­чен­ный под .NET Reactor de4dot. Ошиб­ка та же, и нам сно­ва пред­лага­ют поис­кать вер­сию пос­вежее.

Труд­ности нас не оста­нав­лива­ют: в кон­це кон­цов, мы уже научи­лись раз­бирать более кру­тые обфуска­торы типа Agile бук­валь­но изнутри на самом низ­ком уров­не. Заг­ружа­ем нашу зло­получ­ную прог­рамму в отладчик x32dbg и вспо­мина­ем все то, о чем я писал в пре­дыду­щей статье. Дабы не тра­тить вре­мя на пов­торение, опус­каю длин­ное опи­сание теоре­тичес­кой час­ти про­цес­са. Вкрат­це: заг­ружа­ем биб­лиоте­ку cljit.dll, отла­доч­ные сим­волы к ней и ста­вим точ­ку оста­нова на вход JIT-ком­пилято­ра CILJit:: compileMethod .

Ука­зан­ный спо­соб работа­ет, то есть при каж­дом вызове ком­пилято­ра в поле ILCode струк­туры CORINFO_METHOD_INFO мы видим рас­шифро­ван­ный IL-код каж­дого метода. В прин­ципе, мож­но ана­лизи­ровать код и даже пат­чить на лету, но это дол­го и уто­митель­но, вдо­бавок нас ждет еще одна лож­ка дег­тя. Напом­ню, что в пре­дыду­щей статье я опи­сывал слег­ка жуль­ничес­кий спо­соб опре­делить индекс ком­пилиро­ван­ной про­цеду­ры. Суть его сос­тоит в том, что хендл ftn (пер­вое двой­ное сло­во в струк­туре CORINFO_METHOD_INFO ), если его исполь­зовать как ука­затель, ука­зыва­ет на оди­нар­ное сло­во — индекс метода в .NET метада­те EXE-модуля.

Присоединяйся к сообществу «Xakep.ru»!

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Источник: xakep.ru

Взлом и анализ приложения на C# созданное в Xamarin

Существует большое количество приложений на С# созданы с помощью платформы Xamarin. В этой статье рассмотрим способы анализа и взлома подобных приложений.

Как взломать приложение на C# созданное в Xamarin

Недавно в мои руки попало интересное мобильное приложение на C# созданное в Xamarin, которое к моему сожалению работало не так, как хотелось бы мне. Хороший повод распотрошить приложение, подумал я.

Статья написана в образовательных целях. Мы не призываем к взлому программ, а пытаемся показать и привлечь внимание разработчиков, к тому, насколько уязвимы могут быть приложения.

Для этого дела отлично подойдет последняя версия GDA.

Итак, открываем APK-файл приложения и видим, что выг­лядит он как‑то очень странно. Все классы activity имеют при­мер­но оди­нако­вый шаб­лонный код:

Это наводит на мыс­ли, что нам попал­ся какой-то некошерный APK. Воз­можно — это фрей­мворк… Попробуем поменять рас­ширение .apk на .zip и тут же в гла­за бро­сает­ся загадочная пап­ка assemblies, которая содержит множество DLL-биб­лиотек. Загадочность заключается в том, что в обыч­ных мобиль­ных при­ложе­ниях такой папки нет.

Пос­коль­ку мно­гие биб­лиоте­ки в наз­вании имеют сло­во Xamarin, все ста­новит­ся ясным — основной код приложения написан на С# и находится в биб­лиоте­ке DLL, а шаблонные части кода написаны на Java, которые пред­назна­чен­ны для свя­зи меж­ду сре­дой выпол­нения Mono и вир­туаль­ной машиной сре­ды выпол­нения Android (ART).

Выбор инструмента

Для работы с .Net на мой взгляд, лучше всего подходят следующие инструменты.

dotPeek от разработчика JetBrains. Утилита может деком­пилиро­вать и анализировать файлы .exe и .dll. Утилита имеет самую удобную навигацию по деком­пилиро­ван­ному коду, так что, если говорить толь­ко об анализе алго­рит­ма, данная тулза самая удоб­ная.

dnSpy — может деком­пилиро­вать, редак­тировать, ком­пилиро­вать и отла­живать сбор­ки .Net. Стоит отме­тить, что весь фун­кционал, кро­ме деком­пиляции, работа­ет далеко не всег­да, все зависит от кон­крет­ной ситу­ации. Лично в моем слу­чае ком­пиляция не хотела работать: dnSpy не смог­ свя­зать прос­транс­тва имен Mono и Android.

Simple-assembly-explorer — это довольно древний но от это­го не утра­тив­ший свою акту­аль­нос­ти инструмент. Утилита умеет деком­пилиро­вать .exe и .dll в код на С# или CIL. Самая важная функция — инс­тру­мент может ком­пилиро­вать код на CIL, что дает возможность без тру­да вно­сить изме­нения в анализируемые фай­лы.

Для рас­паков­ки и сборки файла APK я буду использовать архиватор 7z вмес­то используемого для подобных случаев apktool. Далее я объ­ясню почему.

Распакова APK

В начале я попробовал исполь­зовать для рас­паков­ки APK популярную софтину apktool, но при сборке появилась загвоздка из‑за того, что apktool «не зна­ет» что такое .dll и не счи­тает его стан­дар­тным для файла APK. Стан­дар­тны­ми счи­тают­ся исключительно фай­лы с име­нами из сле­дующе­го мас­сива:

При сбор­ке файла APK все неиз­вес­тные фай­лы сжи­мают­ся (тип сжа­тия DEFLATED), а фреймворк Xamarin желает уви­деть свои DLL нес­жатыми (STORED) и соответственно не может их прочитать.

В начале появилась мысля пофиксить и пересоб­рать apktool, но позже я решил пос­тупить иначе: рас­паковы­вать и собрать фай­лы простым архи­вато­ром, без использования функции сжа­тия. Ведь декоди­рова­ние манифес­та или получе­ние smali-кода мне в дан­ном конкретном случае не нужно, а зачем тог­да искать на попу приключения?

Итак, начинаем рас­паковку:

17z.exe x program.apk -oprogram_apk

Пос­ле рас­паков­ки, кроме при­выч­ных для APK фай­лов, видим папкуassemblies с файлами dll. Из всех этих файлов нас инте­ресу­ет только одна биб­лиоте­ка, название которой сов­пада­ет с названием нашего при­ложе­ния. Ее‑то мы и будем вскрывать и исследовать.

Патчинг .Net

Ана­лиз DLL и поиск мес­та для вне­сения пра­вок выходит за рам­ки сегод­няшней статьи, так как мыс­лям на эту тему будет тес­но даже в кни­ге. Оста­нов­люсь лишь на тех­ничес­ких момен­тах. Как я писал выше, dnSpy отка­зал­ся ком­пилиро­вать исправ­ленную биб­лиоте­ку, поэто­му приш­лось при­бег­нуть к помощи Simple-assembly-explorer (SAE).

До­пус­тим, нам нужно, что­бы дан­ная фун­кция всег­да воз­вра­щала true:

Пос­коль­ку прав­ки мож­но вно­сить толь­ко в IL-код, в окне SAE перек­люча­емся на вклад­ку Details, где видим следующую кар­тину:

123456789101112131415161718190 L_0000: ldarg.01 L_0001: ldstr «connectivity»2 L_0006: callvirt Java.Lang.Object Android.Content.Context::GetSystemService(System.String)3 L_000b: castclass Android.Net.ConnectivityManager4 L_0010: stloc.05 L_0011: ldloc.06 L_0012: brtrue.s 9 -> ldloc.07 L_0014: ldc.i4.08 L_0015: ret9 L_0016: ldloc.010 L_0017: callvirt Android.Net.NetworkInfo Android.Net.ConnectivityManager::get_ActiveNetworkInfo()11 L_001c: stloc.112 L_001d: ldloc.113 L_001e: brfalse.s 17 -> ldc.i4.014 L_0020: ldloc.115 L_0021: callvirt System.Boolean Android.Net.NetworkInfo::get_IsConnected()16 L_0026: ret17 L_0027: ldc.i4.018 L_0028: ret

Тут есть два пути.

Я выб­рал вто­рой вари­ант — это намного быс­трее. Более того, нем­ножко погуг­лив, мож­но обна­ружить очень полез­ный сайт sharplab.io, на котором весь­ма удоб­но кон­верти­ровать код из C# в CIL.

Итак, вво­дим в левой вклад­ке сле­дующее:

и спра­ва сре­ди кучи лиш­него получа­ем:

123456IL_0000: nopIL_0001: ldc.i4.1IL_0002: stloc.0IL_0003: br.s IL_0005IL_0005: ldloc.0IL_0006: ret

Встав­ляем получен­ный код в биб­лиоте­ку с помощью Simple assembly explorer, не забывая при этом сох­ранить изме­нен­ную DLL. Если мы ничего не напута­ли и ниг­де не ошиб­лись, то пора собирать новый APK.

Сборка APK обратно

Для сбор­ки, как я уже писал выше, будем исполь­зовать 7z в режиме без сжа­тия. Получен­ный таким обра­зом APK будет боль­шего раз­мера, чем исходный, ну да раз­мер не глав­ное:

17z.exe a -tzip -mx0 -r0 program_patched_unalign_unsigned.apk .program_apk*.*

• -tzip — фор­мат архи­ва,
• -mx0 — отсутс­твие сжа­тия,
• -r0 — рекур­сивный обход всех под­катало­гов

Да, перед сбор­кой луч­ше уда­лить каталогMETA-INF, содер­жащий ста­рую под­пись. Он не нужен, ведь нам при­дет­ся под­писывать APK самос­тоятель­но. Затем нуж­но соз­дать сер­тификат для под­писи и помес­тить его в хра­нили­ще.

Если у вас уже есть сер­тификат, то этот шаг мож­но про­пус­тить. Соз­даем сер­тификат с помощью ути­литы keytool из сос­тава JDK:

1″c:AndroidAndroid Studiojrebinkeytool.exe» -genkey -v -keystore keys.keystore -alias key -keyalg RSA -keysize 2048 -validity 10000

Она задаст стан­дар­тные воп­росы:

123456789101112131415161718192021Enter keystore password:Re-enter new password:What is your first and last name? [Unknown]: xWhat is the name of your organizational unit? [Unknown]: xWhat is the name of your organization? [Unknown]: xWhat is the name of your City or Locality? [Unknown]: xWhat is the name of your State or Province? [Unknown]: xWhat is the two-letter country code for this unit? [Unknown]: xIs CN=x, OU=x, O=x, L=x, ST=x, C=x correct? [no]: yes Generating 2 048 bit RSA key pair and self-signed certificate (SHA256withRSA) with a validity of 10 000 days for: CN=x, OU=x, O=x, L=x, ST=x, C=x[Storing keys.keystore]

Ну и пос­ле это­го мож­но перехо­дить к под­писыва­нию:

1jarsigner.exe -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore keys.keystore -signedjar program_pathed_unalign.apk program_pathed_unalign_unsigned.apk key

В резуль­тате будет соз­дан поч­ти готовый к уста­нов­ке файл

«Поч­ти» — потому что перед исполь­зовани­ем его сле­дует выров­нять прог­раммой zipalign из сос­тава build-tools SDK Android. Дан­ная про­цеду­ра гаран­тиру­ет, что все нес­жатые фай­лы в архи­ве выров­нены отно­ситель­но начала фай­ла.

Это поз­воля­ет получить дос­туп к фай­лам нап­рямую, без необ­ходимос­ти копиро­вания дан­ных в ОЗУ, что умень­шит исполь­зование памяти вашим при­ложе­нием.

1zipalign.exe -v 4 program_pathed_unalign.apk program_pathed.apk

Пос­ле это­го мож­но сме­ло уста­нав­ливать прог­рамму на телефон или эму­лятор и прис­тупать к ее тес­тирова­нию.

Заключение

Как видите, приложениея C# в сборке Xamarin ничуть не слож­нее для ана­лиза, чем род­ные при­ложе­ния ОС Android, надо лишь учесть некото­рые тон­кости при сбор­ке APK.

Полезные ссылки:

• Фаззинг программ с помощью WinAFL
• Взлом программы macOS с помощью IDA и Hiew

Наши проекты:

Источник: telegra.ph