Русский / Russian English / Английский

Сейчас на форуме: Astap1516, amanimm, forever_, Zer0, Sorry, cppasm (+2 невидимых)
 · Начало · Статистика · Регистрация · Поиск · ПРАВИЛА ФОРУМА · Язык · RSS ·

 eXeL@B —› Основной форум —› Опять .net
<< . 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9 . 10 ... 49 . 50 . >>
Посл.ответ Сообщение

Ранг: 60.6 (постоянный)
Статус: Участник

Создано: 30 августа 2010 22:59 · Поправил: 2 сентября 2016 10:10 s0l New!
Цитата · Личное сообщение · #1

Со времени создания топика много обсудили, во много м разобрались и много осталось за кадром. Решил подшить выкладываемый софт и линки

Инструменты:

dnSpy - бодрый декомпилятор и отладчик тут беты

Gray Wolf - DE-ObfuScatE / Edit IL(Live) / Add payloads / Edit attributes(public/privet) / Copy strong names signing on EXE/DLL
ReSharper 6.0 Build 2093 Pre-Release - Очень навороченый декомпилер, побробности --> ТУТ <--.
Рег-данные:
Code:
  1. User Name: ReSharper EAP User
  2. License Key: 0-A60kqsqDMPkvPrLC3bz1/jmns4/DAUV6
  3. which is valid until 31 March 2010

Reflector 8.3.3.115 - платный декомпилятор .NET 8.3.0.95 + (дополнение к нему)
Седьмая версия рефлектора - думаю все знают
Сборка Add-in'ов для Reflector - есть много полезных вещей
.Net ID 1.0.0.3 - определение защиты
DNiD by Rue - сигнатурный анализатор
Dotnet IL Editor (DILE)- Opensource дизассемблер и дебаггер
Xenocode Fox Code Analyzer- профайлер и дизассемблер
Reactor Decryptor 1.7 - что то декриптит, но что не понятно(с) zeppe1in
Simple Assembly Explor (SAE) - Assembler, Disassembler, Deobfuscator, IL editor and more...
DotNet Dumper 1.0 - Дампер .net'овских приложений. Подробное описание
Kurapica dotNET Tracer 1.1 - трейсер от известного автора инструментов для .net
ILSpy 1.0.0.481 - Opensource комбайн, на подобие SAE. Подробности тут
dotTrace Performance 4.0.665.4 - Неплохой трейсер для .Net приложений. Умеет делать трейсы не смешивая потоки как KDT. Умеет сравнивать трейсы двух запусков программы
Рег-данные:
Code:
  1. Name: exelab
  2. Serial: OLgDSHG0hJghkLdXYJh1IjM3ytMrqKcn

Universal Fixer 1.0 - 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.
iMPROVE .NET Deobfuscator - деобфускатор


ConfuserDumper
ConfuserDelegateKiller
CodeCrackerTools: ConfuserMethodsDecryptor, ConfuserDelegateKiller, ConfuserStringDecryptor, MegaDumper, etc.

Статьи с хабры:
Защита .NET приложений - Субъективная теоретическая муть с хабры, выдаваемая за обзор обфускаторов(только для фанатов)
Как обмануть NET.Reflector - вот это уже годная статья, в которой рассматривается ручная обфускация в стихах и картинках
Взлом программ для чайников - ну не знаю...прописные истины, но приятно, что все это есть на русском языке и нормально оформлено
Реверс-инжиниринг обфусцированной сборки .NET - один только заголовок чего стоит. По сути статья информативная
Инъекции MSIL кода в стороннюю сборку при помощи Mono.Cecil. Реализация принципов АОП в NET
Избавление .NET программы от регистрации на примере BEM
Снимаем дамп объектов с памяти .Net приложения

Другое:
.NET Reflector v7.0.0.198 (C# Source by wangshy)
[url=http://lifeinhex.com/string-decryption-with-de4dot/]String decryption with de4dot[/url

-

Last edit: 2012-02-17, Links fixed. Jupiter]

Ранг: 80.6 (постоянный)
Статус: Участник

Создано: 6 апреля 2011 16:59 New!
Цитата · Личное сообщение · #2

Ранг: 20.3 (новичок)
Статус: Участник

Создано: 9 апреля 2011 18:30 · Поправил: Модератор New!
Цитата · Личное сообщение · #3

Спс. Тема класс!!! спасиб автору!

От модератора: спасибо вполне себе кошерно расставляются через специальную кнопку у нужных постов

Ранг: 20.3 (новичок)
Статус: Участник

Создано: 10 апреля 2011 15:40 New!
Цитата · Личное сообщение · #4

Кто ломанёт .NET Reflector v7.0.1.1?????


Ранг: 2006.1 (!!!!)
Статус: Модератор
retired

Создано: 10 апреля 2011 16:15 New!
Цитата · Личное сообщение · #5

В запросы с этими вопросами.

Ранг: 11.0 (новичок)
Статус: Участник

Создано: 11 апреля 2011 02:05 · Поправил: dx2003 New!
Цитата · Личное сообщение · #6

Добрый день.

Никак не могу придумать как добавить IL код в реализацию метода.
Ситуация следующая:
есть сборка, запротекченая .NET Reactor'ом.
Обфускацию и шифрование мне удалось снять.
Успешно декриптовав ресурсы, я вижу IL код .

Как, каким образом, полученый IL код (для каждого метода в отдельности) поместить в саму dll'ку, чтобы можно было видеть исходный код?
Сейчас пробую модифицировать класс MethodBodyReader для ручной загрузки....
может быть есть уже какое-то готовое решение, что бы поместить массив byte[] (набор опкодов) в поле Instrections?

Спасибо.


Ранг: 127.3 (ветеран)
Статус: Участник

Создано: 11 апреля 2011 02:25 New!
Цитата · Личное сообщение · #7

dx2003
ты сам раскодировал ил код? и успешно деобфусцировал методы реактора?
если ил код вместе с хедером, то как вариант можно прилепить всё в новой секции к файлу и исправить RVA методов. Код не только видно, но и запускается успешно)

Ранг: 11.0 (новичок)
Статус: Участник

Создано: 11 апреля 2011 02:38 · Поправил: dx2003 New!
Цитата · Личное сообщение · #8

zeppe1in

да, сам.

Но пока до конца не ясно как вставить опкоды в методы....
Сейчас сижу и штудирую Mono.Cecil...

вся сложность в том, что у меня есть набор опкодов в виде byte[] с одной стороны и определение метода с ПУСТЫМ (не правильным телом: nop + ret) с другой...
а классы Mono.Cecil оперируют понятием Instruction или OpCode и так просто byte не засунешь в класс Instruction....

Не готов пока сказать с хедером он или без.
Но что точно, что сам вытащенный из ресурса код ( в разрезе методов ) это то, что мы бы увидели в SAE'е (в разделе Detais) будь он на нужном месте...

наверное нужно работать с классом Mono.Cecil.Cil.CodeReader только как-то подсовывать свой набор byte[]....


Ранг: 127.3 (ветеран)
Статус: Участник

Создано: 11 апреля 2011 03:33 · Поправил: zeppe1in New!
Цитата · Личное сообщение · #9

dx2003 пишет:
Не готов пока сказать с хедером он или без

Без этого никуда.
А принадлежность куска кода к методу можете установить?

dx2003 пишет:
подсовывать свой набор byte[]


Не очень разбираюсь в моно. но он по любому читает всё по RVA метода. следовательно подсунув нужный рва или данные будет нужный результат.

да кстати, Reactor Decryptor пробовали?)

Ранг: 11.0 (новичок)
Статус: Участник

Создано: 11 апреля 2011 03:38 · Поправил: dx2003 New!
Цитата · Личное сообщение · #10

А принадлежность куска кода к методу можете установить?

Это следующий этап... наверное здесь тоже могут быть сложности....

Reactor Decryptor еще не пробовал.
Я почти все сделал, даже код вижу, очень хочется все закончить самому.
Никак не ожидал, что будут такие сложности с запихиванием ILкода в DLL'ину.... (


Ранг: 127.3 (ветеран)
Статус: Участник

Создано: 11 апреля 2011 03:53 New!
Цитата · Личное сообщение · #11

замечательная статья, необходима к добавлению в первое сообщение)
http://www.rsdn.ru/article/dotnet/phmetadata.xml

dx2003
там есть про заголовки методов, вы сможете определить их наличие или отсутствие.

Ранг: 11.0 (новичок)
Статус: Участник

Создано: 11 апреля 2011 03:56 · Поправил: dx2003 New!
Цитата · Личное сообщение · #12

zeppe1in

Я пока тупо не могу запихнуть уже найденный код в уже определенное место (
Но спасибо за линк!

Сейчас немного поигрался с классом CodeReader, и обнаружил на некоторую корреляцию между значением поля body.CodeRVA и начальным "адресом" декодированного мной кода...

Может чего и получится...

В общем, MethodDefinition::Body.CodeRVA очень похоже на правильное направление.
Осталось все же тупо разобраться как byte[] превращять в Instructions и запихивать в метод...................
Самое обидное что в принципе понятно как делать, проблема исключительно с кодированием (

Ранг: 11.0 (новичок)
Статус: Участник

Создано: 11 апреля 2011 05:15 · Поправил: dx2003 New!
Цитата · Личное сообщение · #13

уф.... кажется все )

результат вроде как есть.... для тех кому интересно:
как мне кажется, нужно написать свой метод ReadMethodBody класса CodeReader как показано ниже
аргумент ilbody это массив с опкодом мотода, выдранный из недр .NET Reactor'а (в моем случае версии старше 4)

Code:
  1. public MethodBody ReadMethodBody(MethodDefinition method, byte[] ilbody)
  2. {
  3.   this.method = method;
  4.   this.body = new MethodBody( method );
  5.  
  6.   reader.context = method;
  7.  
  8.   //ReadMethodBody();
  9.   //MoveTo( method.RVA );
  10.   for( int i= 0; i < ilbody.Length; ++i ) {
  11.     base.buffer[i] = ilbody[i];
  12.   }
  13.   base.position = 0;
  14.  
  15.       //wicky.patch.start: set codeRva
  16.       body.codeRva = method.rva + 1;
  17.       //wicky.patch.end
  18.       body.code_size = ilbody.Length; // flags >> 2;
  19.       body.MaxStackSize = 8;
  20.       ReadCode();
  21.  
  22.   var symbol_reader = reader.module.SymbolReader;
  23.  
  24.   if( symbol_reader != null ) {
  25.     var instructions = body.Instructions;
  26.     symbol_reader.Read( body, offset => GetInstruction( instructions, offset ) );
  27.   }
  28.  
  29.   return this.body;
  30. }


Ранг: 86.2 (постоянный)
Статус: Участник

Создано: 11 апреля 2011 06:22 New!
Цитата · Личное сообщение · #14

Дайошь, наш Reactor Decryptor!!!

Ранг: 11.0 (новичок)
Статус: Участник

Создано: 14 апреля 2011 00:36 New!
Цитата · Личное сообщение · #15

самое пока сложное, это восстановление убитых локальных переменных и обработчиков исключений....
Реактор оставляет код без проблем обрабатываемый JIT'ингом, но перенося тело методов, удаляет очень важную информацию без которой у декомпилятора сносит крышу.

Ранг: 45.8 (посетитель)
Статус: Участник

Создано: 14 апреля 2011 13:44 New!
Цитата · Личное сообщение · #16

Если методы выполняются значит и локальные переменные и обработчики он откуда-то берет. Вот и собирай все данные метода статически - тип хедера, maxstack, code, exception sections. Потом создай новую секцию и пропиши туда все восстановленные методы согласно их структуре, поправь RVA методов в таблице методов и все.


Ранг: 127.3 (ветеран)
Статус: Участник

Создано: 14 апреля 2011 14:30 New!
Цитата · Личное сообщение · #17

dx2003 эта информация как раз из хедера. и реактор обязан её восстанавливать.

Ранг: 11.0 (новичок)
Статус: Участник

Создано: 14 апреля 2011 22:59 New!
Цитата · Личное сообщение · #18

эх....
одни общие слова и ни одного примера....


Ранг: 127.3 (ветеран)
Статус: Участник

Создано: 15 апреля 2011 00:39 New!
Цитата · Личное сообщение · #19

dx2003 какой пример нужен? ты лучше расскажи как ты раскодировал методы, и как реактор их подсовывает фреймворку)

Ранг: 11.0 (новичок)
Статус: Участник

Создано: 15 апреля 2011 12:43 · Поправил: dx2003 New!
Цитата · Личное сообщение · #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 и пока мириться с отсутствием обработчиков...

Любая критика ОЧЕНЬ приветствуется


Ранг: 127.3 (ветеран)
Статус: Участник

Создано: 15 апреля 2011 13:31 New!
Цитата · Личное сообщение · #21

dx2003 пишет:
я не уверен, что это можно сделать

а вы не думаете что фреймворку необходима эта информация и реактор обязательно должен подать её так как надо?
я восстанавливал закодированный код путём перехвата фреймворковских функций.

mscorwks.DecoderInit
тут происходит парсинг заголовка которого вам так не хватает (но в нём не верный размер).
А потом, когда код приходит на компиляцию в compileMethod мы можем получить размер ил кода, и весь ил код. Если у нас есть обработчики исключений, то очевидно, что они там так как надо(в конце тела метода) иначе как они с компилируются.

в общем этот заголовок и тело я соединял вместе, лепил в новой секции к фаилу и всё работало.
Минусов такова способа предостаточно.
Для статической распаковки нужно полностью разобраться что делает реактор.

Ранг: 11.0 (новичок)
Статус: Участник

Создано: 15 апреля 2011 14:13 · Поправил: dx2003 New!
Цитата · Личное сообщение · #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 нужна......

Ранг: 11.0 (новичок)
Статус: Участник

Создано: 15 апреля 2011 15:18 · Поправил: dx2003 New!
Цитата · Личное сообщение · #23

zeppe1in

ура! Разобрался!
первый цикл как раз и оказался частью кода по восстановлению заголовков!


На картинке момент, когда заголовок уже восстановлен, а опкод в методы еще НЕ загружен (список m_IL содержит только 4-е опкода).
Ну усЕ, дальше дело техники +)
почикали таки мы .NET Reactor +)

PS
Спасибо большое, за мысль о НЕ правильном размере +)


Ранг: 127.3 (ветеран)
Статус: Участник

Создано: 15 апреля 2011 16:56 New!
Цитата · Личное сообщение · #24

dx2003
с вас статик анпакаер
и расскажите каким образом реактор подсовывает заголовок и тело.
я так понял у вас реактор в свой проект собран. было бы интересно посмотреть.

Ранг: 60.6 (постоянный)
Статус: Участник

Создано: 15 апреля 2011 18:10 New!
Цитата · Личное сообщение · #25

dx2003 пишет:
Ну усЕ, дольше дело техники +)
почикали таки мы .NET Reactor +)

Native или Library mode? Просто так то существуют анпакеры работающие, правда не опенсорс.

Ранг: 11.0 (новичок)
Статус: Участник

Создано: 19 апреля 2011 00:58 New!
Цитата · Личное сообщение · #26

Да.... как обычно 500% времени уходит на "стандартные" операции. Например, на сохранение собранной сборки на диск...

Kaimi
режим, при котором опкод зашифрован, обфусцирован и находится в сборке (в ресурсах).

Я пока не встречал работающих депротекторов для .NET Reactor v4 в режиме шифрации и обфускации кода для сборок на NET 4.

PS
NET Reactor пройденный этап, впереди протектор: CliSecureRT +)

Ранг: 60.6 (постоянный)
Статус: Участник

Создано: 19 апреля 2011 01:21 New!
Цитата · Личное сообщение · #27

dx2003 пишет:
Я пока не встречал работающих депротекторов для .NET Reactor v4 в режиме шифрации и обфускации кода для сборок на NET 4.

Дай пример сборки обработанной им?

dx2003 пишет:
NET Reactor пройденный этап, впереди протектор: CliSecureRT +)

Лучше что-нибудь более-менее универсальное, например, для удаления опкодов, препятствующих нормальному отображению метода в рефлекторе. Ещё помню бывали ситуации, когда рефлектор в режиме отображения IL-опкодов не в состоянии разобрать метод и показывает только локальные переменные и всё.

Ранг: 11.0 (новичок)
Статус: Участник

Создано: 19 апреля 2011 01:32 · Поправил: dx2003 New!
Цитата · Личное сообщение · #28

Kaimi

dll: https://rapidshare.com/files/458066219/dll.net.reactor.v4.7z

Лучше что-нибудь более-менее универсальное, например, для удаления опкодов, препятствующих нормальному отображению метода в рефлекторе. Ещё помню бывали ситуации, когда рефлектор в режиме отображения IL-опкодов не в состоянии разобрать метод и показывает только локальные переменные и всё.


современные обфускаторы ушли, как мне кажется, далеко вперед.
не валидные опкоды удаляют даже слабенькие деобфускаторы +)

Ранг: 11.0 (новичок)
Статус: Участник

Создано: 19 апреля 2011 01:39 New!
Цитата · Личное сообщение · #29

zeppe1in

об описании работы реакторы я не забыл.
как появится больше свободного времени, набросаю свои мысли ...


Ранг: 127.3 (ветеран)
Статус: Участник

Создано: 19 апреля 2011 15:52 New!
Цитата · Личное сообщение · #30

dx2003 пишет:
впереди протектор: CliSecureRT +)

нет уж. я его уже забил, разобрал и сделал анпакер

Ранг: 8.5 (гость)
Статус: Участник

Создано: 19 апреля 2011 17:17 · Поправил: HaRpY New!
Цитата · Личное сообщение · #31

Здравствуйте Всем!

Вот кусок кода из приложения защищенного CodeVeil где-то 2008 года.
В коде по адресу 0040242C лежит метод. Как видно у метода должна быть SEH-секция, размер IL кода установлен в ноль.
А с адреса 0040243С идет уже следующий метод. Т.е. нет никакого намека на секцию исключений.
Code:
  1. 00402420:  04 D0 4B 00-00 04 28 9F-00 00 0A 2A-1B 30 04 00
  2. 00402430:  00 00 00 00-18 00 00 11-2A 96 2C 00-1B 30 06 00
  3. 00402440:  00 00 00 00-19 00 00 11-2A 96 D4 00-13 30 08 00

Если перехватить jit-компиляцию данного метода, то вместо адреса 00402428 используется другой адрес и там как и положено после IL кода (смещение 98h) идет SEH-обработчик.
(к коду приписан старый заголовок с реальным размером метода)
Code:
  1. 00000000:  1B 30 04 00-89 00 00 00-18 00 00 11-7E 45 00 00
  2. 00000010:  04 2D 09 02-17 FE 01 28-4D 00 00 06-02 16 32 0A
  3. 00000020:  02 7E 45 00-00 04 8E 69-31 06 72 77-02 00 70 2A
  4. 00000030:  7E 45 00 00-04 02 9A 0A-06 2C 02 06-2A 7E 47 00
  5. 00000040:  00 04 02 94-0B 7E 46 00-00 04 73 3F-00 00 0A 0C
  6. 00000050:  08 73 A0 00-00 0A 0D 08-07 7E 48 00-00 04 58 6A
  7. 00000060:  6F 9C 00 00-0A 09 6F 36-00 00 0A 0A-DE 0A 09 2C
  8. 00000070:  06 09 6F 34-00 00 0A DC-DE 0A 08 2C-06 08 6F 34
  9. 00000080:  00 00 0A DC-06 28 A1 00-00 0A 0A 7E-45 00 00 04
  10. 00000090:  02 06 A2 06-2A 00 00 00-01 1C 00 00-02 00 4B 00
  11. 000000A0:  17 62 00 0A-00 00 00 00-02 00 44 00-2A 6E 00 0A
  12. 000000B0:  00 00 00 00-           -           -

Есть и другое приложение (см. исходники SAE папка TestProjects\Assembly\Assembly008.exe - похоже защита .Net Reactor)
Посмотрим на метод по адресу 0040495C. Здесь тоже должна быть SEH-секция, размер IL кода 4 байта.
Самого IL кода нет, а есть ID (0205h). Но с адреса 0040496С идет SEH-секция.
То-же для метода 0040497C...
Code:
  1. 00404950:  04 00 00 00-55 00 00 11-04 02 00 00-1B 30 05 00
  2. 00404960:  04 00 00 00-56 00 00 11-05 02 00 00-01 10 00 00
  3. 00404970:  02 00 24 00-7B 9F 00 17-00 00 00 00-1B 30 07 00
  4. 00404980:  04 00 00 00-57 00 00 11-06 02 00 00-41 34 00 00
  5. 00404990:  02 00 00 00-1C 01 00 00-51 00 00 00-6D 01 00 00
  6. 004049A0:  18 00 00 00-00 00 00 00-02 00 00 00-79 00 00 00
  7. 004049B0:  A2 01 00 00-1B 02 00 00-18 00 00 00-00 00 00 00
  8. 004049C0:  12 07 02 00-00 00 00 00-12 08 02 00-00 00 00 00
  9. 004049D0:  12 09 02 00-00 00 00 00-12 0A 02 00-00 00 00 00
  10. 004049E0:  13 30 06 00-08 00 00 00-58 00 00 11-0B 02 00 00


Похоже у авторов протекторов нет (или не было) единого мнения по поводу криптовки методов с SEH-секцией. Один убирал их вместе с кодом, другой оставлял на месте после инвалидного тела метода.
Но по логике CLR должен обрабатывать только одну из данных ситуаций.

Итак вопрос: какой из способов корректен?

Возможно приведенные примеры уже не актуальны, но к сожалению у меня нет возможности это проверить.
<< . 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9 . 10 ... 49 . 50 . >>
 eXeL@B —› Основной форум —› Опять .net
Эта тема закрыта. Ответы больше не принимаются.

Видеокурс ВЗЛОМ