| Сейчас на форуме: -Sanchez- (+8 невидимых) |
 |
eXeL@B —› Основной форум —› Взлом dotNET программ |
| << . 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9 . 10 ... 49 . 50 . >> |
| Посл.ответ | Сообщение |
|
|
Создано: 30 августа 2010 22:59 · Поправил: s0l · Личное сообщение · #1 Со времени создания топика много обсудили, во много м разобрались и много осталось за кадром. Решил подшить выкладываемый софт и линки  Инструменты: - бодрый декомпилятор и отладчик - DE-ObfuScatE / Edit IL(Live) / Add payloads / Edit attributes(public/privet) / Copy strong names signing on EXE/DLL - Очень навороченый декомпилер, побробности . Рег-данные: Code:
- платный декомпилятор .NET - думаю все знают - есть много полезных вещей - определение защиты - сигнатурный анализатор - Opensource дизассемблер и дебаггер - профайлер и дизассемблер - что то декриптит, но что не понятно(с) zeppe1in - Assembler, Disassembler, Deobfuscator, IL editor and more... - Дампер .net'овских приложений. - трейсер от известного автора инструментов для .net - Opensource комбайн, на подобие SAE. Подробности - Неплохой трейсер для .Net приложений. Умеет делать трейсы не смешивая потоки как KDT. Умеет сравнивать трейсы двух запусков программы Рег-данные: Code:
- fix dumps after dumping them whit Dotnet Dumper or other similiar tools and will also fix nasty things: multiple assembly/module definitions, wrong extends, etc. - деобфускатор Статьи с хабры: - Субъективная теоретическая муть с хабры, выдаваемая за обзор обфускаторов(только для фанатов) - вот это уже годная статья, в которой рассматривается ручная обфускация в стихах и картинках - ну не знаю...прописные истины, но приятно, что все это есть на русском языке и нормально оформлено - один только заголовок чего стоит. По сути статья информативная Другое: [url=http://lifeinhex.com/string-decryption-with-de4dot/]String decryption with de4dot[/url - Last edit: 2012-02-17, Links fixed. Jupiter]  |
|
|
Создано: 06 апреля 2011 16:59 · Личное сообщение · #2 |
|
|
Создано: 09 апреля 2011 18:30 · Поправил: Модератор · Личное сообщение · #3 Спс. Тема класс!!! спасиб автору! От модератора: спасибо вполне себе кошерно расставляются через специальную кнопку у нужных постов |
|
|
Создано: 10 апреля 2011 15:40 · Личное сообщение · #4 Кто ломанёт .NET Reflector v7.0.1.1????? |
|
|
Создано: 10 апреля 2011 16:15 · Личное сообщение · #5 В запросы с этими вопросами. |
|
|
Создано: 11 апреля 2011 02:05 · Поправил: dx2003 · Личное сообщение · #6 Добрый день. Никак не могу придумать как добавить IL код в реализацию метода. Ситуация следующая: есть сборка, запротекченая .NET Reactor'ом. Обфускацию и шифрование мне удалось снять. Успешно декриптовав ресурсы, я вижу IL код . Как, каким образом, полученый IL код (для каждого метода в отдельности) поместить в саму dll'ку, чтобы можно было видеть исходный код? Сейчас пробую модифицировать класс MethodBodyReader для ручной загрузки.... может быть есть уже какое-то готовое решение, что бы поместить массив byte[] (набор опкодов) в поле Instrections? Спасибо. |
|
|
Создано: 11 апреля 2011 02:25 · Личное сообщение · #7 dx2003 ты сам раскодировал ил код? и успешно деобфусцировал методы реактора? если ил код вместе с хедером, то как вариант можно прилепить всё в новой секции к файлу и исправить RVA методов. Код не только видно, но и запускается успешно) ----- zzz |
|
|
Создано: 11 апреля 2011 02:38 · Поправил: dx2003 · Личное сообщение · #8 zeppe1in да, сам. Но пока до конца не ясно как вставить опкоды в методы.... Сейчас сижу и штудирую Mono.Cecil... вся сложность в том, что у меня есть набор опкодов в виде byte[] с одной стороны и определение метода с ПУСТЫМ (не правильным телом: nop + ret) с другой... а классы Mono.Cecil оперируют понятием Instruction или OpCode и так просто byte не засунешь в класс Instruction.... Не готов пока сказать с хедером он или без. Но что точно, что сам вытащенный из ресурса код ( в разрезе методов ) это то, что мы бы увидели в SAE'е (в разделе Detais) будь он на нужном месте... наверное нужно работать с классом Mono.Cecil.Cil.CodeReader только как-то подсовывать свой набор byte[].... |
|
|
Создано: 11 апреля 2011 03:33 · Поправил: zeppe1in · Личное сообщение · #9 dx2003 пишет: Не готов пока сказать с хедером он или без Без этого никуда. А принадлежность куска кода к методу можете установить? dx2003 пишет: подсовывать свой набор byte[] Не очень разбираюсь в моно. но он по любому читает всё по RVA метода. следовательно подсунув нужный рва или данные будет нужный результат. да кстати, Reactor Decryptor пробовали?) ----- zzz |
|
|
Создано: 11 апреля 2011 03:38 · Поправил: dx2003 · Личное сообщение · #10 А принадлежность куска кода к методу можете установить? Это следующий этап... наверное здесь тоже могут быть сложности.... Reactor Decryptor еще не пробовал. Я почти все сделал, даже код вижу, очень хочется все закончить самому. Никак не ожидал, что будут такие сложности с запихиванием ILкода в DLL'ину.... ( |
|
|
Создано: 11 апреля 2011 03:53 · Личное сообщение · #11 замечательная статья, необходима к добавлению в первое сообщение) http://www.rsdn.ru/article/dotnet/phmetadata.xml dx2003 там есть про заголовки методов, вы сможете определить их наличие или отсутствие. ----- zzz |
|
|
Создано: 11 апреля 2011 03:56 · Поправил: dx2003 · Личное сообщение · #12 zeppe1in Я пока тупо не могу запихнуть уже найденный код в уже определенное место ( Но спасибо за линк! Сейчас немного поигрался с классом CodeReader, и обнаружил на некоторую корреляцию между значением поля body.CodeRVA и начальным "адресом" декодированного мной кода... Может чего и получится... В общем, MethodDefinition::Body.CodeRVA очень похоже на правильное направление. Осталось все же тупо разобраться как byte[] превращять в Instructions и запихивать в метод................... Самое обидное что в принципе понятно как делать, проблема исключительно с кодированием ( |
|
|
Создано: 11 апреля 2011 05:15 · Поправил: dx2003 · Личное сообщение · #13 уф.... кажется все ) результат вроде как есть.... для тех кому интересно: как мне кажется, нужно написать свой метод ReadMethodBody класса CodeReader как показано ниже аргумент ilbody это массив с опкодом мотода, выдранный из недр .NET Reactor'а (в моем случае версии старше 4) Code:
|
|
|
Создано: 11 апреля 2011 06:22 · Личное сообщение · #14 Дайошь, наш Reactor Decryptor!!! 
|
|
|
Создано: 14 апреля 2011 00:36 · Личное сообщение · #15 самое пока сложное, это восстановление убитых локальных переменных и обработчиков исключений.... Реактор оставляет код без проблем обрабатываемый JIT'ингом, но перенося тело методов, удаляет очень важную информацию без которой у декомпилятора сносит крышу. |
|
|
Создано: 14 апреля 2011 13:44 · Личное сообщение · #16 Если методы выполняются значит и локальные переменные и обработчики он откуда-то берет. Вот и собирай все данные метода статически - тип хедера, maxstack, code, exception sections. Потом создай новую секцию и пропиши туда все восстановленные методы согласно их структуре, поправь RVA методов в таблице методов и все. |
|
|
Создано: 14 апреля 2011 14:30 · Личное сообщение · #17 dx2003 эта информация как раз из хедера. и реактор обязан её восстанавливать. ----- zzz |
|
|
Создано: 14 апреля 2011 22:59 · Личное сообщение · #18 эх.... одни общие слова и ни одного примера.... |
|
|
Создано: 15 апреля 2011 00:39 · Личное сообщение · #19 dx2003 какой пример нужен? ты лучше расскажи как ты раскодировал методы, и как реактор их подсовывает фреймворку) ----- zzz |
|
|
Создано: 15 апреля 2011 12:43 · Поправил: dx2003 · Личное сообщение · #20 zeppe1in, обязательно расскажу как мне удалось это сделать. Думаю это поможет разобраться можно ли в принципе сделать то, о чем вы здесь говорите: восстановить локальные переременные и обработчики исключений. Пока, при всем к вам уважении, я не уверен, что это можно сделать.... Почему я так считаю? мои доводы: 1) реакторовский он-лайн загрузчик опкода делает следующее: из ресурса сборки декодирует данные (опкод и еще что-то) и выполняет 2-а цикла по записи полученных данных в сборку. Первый цикл, это запись Int32 по адресу Marshal.GetHINSTANCE( "сборка" ).ToInt64() плюс Int32, полученый из данных. Что здесь происходит я пока не разобрался.... второй, это считывание тела метода из данных, сохранение в коллекции по индексу Body.CodeRVA с последующим восстановлением метода в сборке. Все подробности чуть позднее. 2) если посмотреть на сборку при помощи Researcher .NET'та то видно, что в разделе IMAGE_COR_ILMETHOD_SECT_EH_SMALL для try/catch/finally указываются смещения относительно начала тела метода. Но ведь реактор удаляет тело метода, поэтому, чтобы хедер был валидным, прихордится корректировать и эту секцию, удаляя информацию об расположении кода обработчика... Не вижу я каких-то специальных корректирующих операций.... Кстати, если не считаь первого цикла, то повторение второго (восстановление опкода) приводит к "восстановлению" методов в сборке, правда мне приходится вручную создавать ВСЕ локальные переменные с типом System.Object и пока мириться с отсутствием обработчиков... Любая критика ОЧЕНЬ приветствуется |
|
|
Создано: 15 апреля 2011 13:31 · Личное сообщение · #21 dx2003 пишет: я не уверен, что это можно сделать а вы не думаете что фреймворку необходима эта информация и реактор обязательно должен подать её так как надо? я восстанавливал закодированный код путём перехвата фреймворковских функций. mscorwks.DecoderInit тут происходит парсинг заголовка которого вам так не хватает (но в нём не верный размер). А потом, когда код приходит на компиляцию в compileMethod мы можем получить размер ил кода, и весь ил код. Если у нас есть обработчики исключений, то очевидно, что они там так как надо(в конце тела метода) иначе как они с компилируются. в общем этот заголовок и тело я соединял вместе, лепил в новой секции к фаилу и всё работало. Минусов такова способа предостаточно. Для статической распаковки нужно полностью разобраться что делает реактор. ----- zzz |
|
|
Создано: 15 апреля 2011 14:13 · Поправил: dx2003 · Личное сообщение · #22 zeppe1in пытаюсь разобраться где и что я пропустил.... Судя по: CILJit::compileMethod(class ICorJitInfo *, struct CORINFO_METHOD_INFO *, unsigned int, unsigned char * *, unsigned long *) proc near и struct CORINFO_METHOD_INFO { CORINFO_METHOD_HANDLE ftn; CORINFO_MODULE_HANDLE scope; BYTE * ILCode; unsigned ILCodeSize; unsigned short maxStack; unsigned short EHcount; CorInfoOptions options; CORINFO_SIG_INFO args; CORINFO_SIG_INFO locals; }; информация о локалках и EH нужна...... |
|
|
Создано: 15 апреля 2011 15:18 · Поправил: dx2003 · Личное сообщение · #23 zeppe1in ура! Разобрался! первый цикл как раз и оказался частью кода по восстановлению заголовков!  На картинке момент, когда заголовок уже восстановлен, а опкод в методы еще НЕ загружен (список m_IL содержит только 4-е опкода). Ну усЕ, дальше дело техники +) почикали таки мы .NET Reactor +) PS Спасибо большое, за мысль о НЕ правильном размере +) |
|
|
Создано: 15 апреля 2011 16:56 · Личное сообщение · #24 dx2003 с вас статик анпакаер и расскажите каким образом реактор подсовывает заголовок и тело. я так понял у вас реактор в свой проект собран. было бы интересно посмотреть. ----- zzz |
|
|
Создано: 15 апреля 2011 18:10 · Личное сообщение · #25 dx2003 пишет: Ну усЕ, дольше дело техники +) почикали таки мы .NET Reactor +) Native или Library mode? Просто так то существуют анпакеры работающие, правда не опенсорс. |
|
|
Создано: 19 апреля 2011 00:58 · Личное сообщение · #26 Да.... как обычно 500% времени уходит на "стандартные" операции. Например, на сохранение собранной сборки на диск... Kaimi режим, при котором опкод зашифрован, обфусцирован и находится в сборке (в ресурсах). Я пока не встречал работающих депротекторов для .NET Reactor v4 в режиме шифрации и обфускации кода для сборок на NET 4. PS NET Reactor пройденный этап, впереди протектор: CliSecureRT +) |
|
|
Создано: 19 апреля 2011 01:21 · Личное сообщение · #27 dx2003 пишет: Я пока не встречал работающих депротекторов для .NET Reactor v4 в режиме шифрации и обфускации кода для сборок на NET 4. Дай пример сборки обработанной им? dx2003 пишет: NET Reactor пройденный этап, впереди протектор: CliSecureRT +) Лучше что-нибудь более-менее универсальное, например, для удаления опкодов, препятствующих нормальному отображению метода в рефлекторе. Ещё помню бывали ситуации, когда рефлектор в режиме отображения IL-опкодов не в состоянии разобрать метод и показывает только локальные переменные и всё. |
|
|
Создано: 19 апреля 2011 01:32 · Поправил: dx2003 · Личное сообщение · #28 Kaimi dll: https://rapidshare.com/files/458066219/dll.net.reactor.v4.7z Лучше что-нибудь более-менее универсальное, например, для удаления опкодов, препятствующих нормальному отображению метода в рефлекторе. Ещё помню бывали ситуации, когда рефлектор в режиме отображения IL-опкодов не в состоянии разобрать метод и показывает только локальные переменные и всё. современные обфускаторы ушли, как мне кажется, далеко вперед. не валидные опкоды удаляют даже слабенькие деобфускаторы +) |
|
|
Создано: 19 апреля 2011 01:39 · Личное сообщение · #29 zeppe1in об описании работы реакторы я не забыл. как появится больше свободного времени, набросаю свои мысли ... |
|
|
Создано: 19 апреля 2011 15:52 · Личное сообщение · #30 dx2003 пишет: впереди протектор: CliSecureRT +) нет уж. я его уже забил, разобрал и сделал анпакер
----- zzz |
|
|
Создано: 19 апреля 2011 17:17 · Поправил: HaRpY · Личное сообщение · #31 Здравствуйте Всем! Вот кусок кода из приложения защищенного CodeVeil где-то 2008 года. В коде по адресу 0040242C лежит метод. Как видно у метода должна быть SEH-секция, размер IL кода установлен в ноль. А с адреса 0040243С идет уже следующий метод. Т.е. нет никакого намека на секцию исключений. Code:
Если перехватить jit-компиляцию данного метода, то вместо адреса 00402428 используется другой адрес и там как и положено после IL кода (смещение 98h) идет SEH-обработчик. (к коду приписан старый заголовок с реальным размером метода) Code:
Есть и другое приложение (см. исходники SAE папка TestProjects\Assembly\Assembly008.exe - похоже защита .Net Reactor) Посмотрим на метод по адресу 0040495C. Здесь тоже должна быть SEH-секция, размер IL кода 4 байта. Самого IL кода нет, а есть ID (0205h). Но с адреса 0040496С идет SEH-секция. То-же для метода 0040497C... Code:
Похоже у авторов протекторов нет (или не было) единого мнения по поводу криптовки методов с SEH-секцией. Один убирал их вместе с кодом, другой оставлял на месте после инвалидного тела метода. Но по логике CLR должен обрабатывать только одну из данных ситуаций. Итак вопрос: какой из способов корректен? Возможно приведенные примеры уже не актуальны, но к сожалению у меня нет возможности это проверить. |
| << . 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9 . 10 ... 49 . 50 . >> |
|
eXeL@B —› Основной форум —› Взлом dotNET программ |
| Эта тема закрыта. Ответы больше не принимаются. |
Для печати