Dotpeek как редактировать dll

Get started

dotPeek is available for download in two distributions: as a part of dotUltimate installer and as portable versions for 32-bit and 64-bit processors. Both distributions are functionally equivalent.

The installer-based distribution is a safe bet if you want to use dotPeek on a single computer and take advantage of automatic version management.

The portable distribution is a better fit if you prefer to share dotPeek between multiple machines — for example, using a flash drive or Dropbox folder.

You can start using dotPeek right after installation. dotPeek is free software, you do not need any license.

Basic preferences

In dotPeek, you can control everything with shortcuts. Note that dotPeek provides two keyboard schemes inherited from JetBrains ReSharper. First of all, you may want to study the shortcuts assigned to dotPeek commands in both of these schemes. As soon as you choose, which scheme you prefer to use, select these scheme on the Environment | General page of dotPeek options. As you study these help pages, you can choose your preferred scheme on the top-right corner of the page so that shortcuts from this scheme are displayed to you.

If you want to make dotPeek your default program for browsing .NET assemblies ( *.dll files) and open these files with double-click, enable Windows Explorer integration on the Environment | General page of dotPeek options.

You can quickly configure code viewer preferences — such as whether to wrap long lines or display line numbers — in the View | Outlining and View | Options menu.

Besides decompiling library code, by default, dotPeek automatically finds, fetches, and displays original source files if they are available locally or on a symbol server. If you want to see only decompiled code, clear the Use sources from symbol files when available checkbox on the Decompiler page of dotPeek options.

Open assemblies

To start working with any assembly, you need to open it in the Assembly Explorer. When you launch dotPeek for the first time, you will see that main system assemblies are already loaded into this window. If necessary, you can load more assemblies you want to explore — click Open on the Assembly Explorer toolbar and then select an assembly file, or just drag assembly files to the Assembly Explorer window.

You can also load entire folders, remove assemblies that you are not interested in from the list, keep several sets of assemblies, and more. For supported assembly files and more information, see Explore assemblies.

Browse assemblies

As soon as the desired assembly appears in the Assembly Explorer , you can start studying its contents by successively expanding nodes displayed under the assembly: namespaces, types and delegates, and type members.

You can double-click types and type members to display decompiled code (or code from original source files if they are available) in the code viewer.

Under assembly node, you can also find the References and Resources nodes. Double-clicking a reference loads the referenced assembly, if immediately available; double-clicking an entry under the Resources node opens the source representation of the corresponding resource in the code viewer, or passes it to an external application.

Under type and delegate nodes, you will see the Base types node that can be expanded to show base types and inheritors of the current type. This is a way to browse type inheritance trees that developers with .NET Reflector background usually find appealing.

Assembly Explorer uses the same set of icons that are used in Visual Studio for identification of code symbols.

To filter the content displayed in the Assembly Explorer , start typing the name of an assembly, namespace or a symbol.

View source code

Assembly code is presented as C# in the Code Viewer, which displays source or decompiled code in multiple tabs. Code syntax is highlighted ReSharper-style, with distinctive colors for properties, types, accessors, and methods. When you put the caret at a delimiter, be it a brace or parenthesis, it gets highlighted along with its counterpart, bringing focus to the scope of the particular code block you’re in.

If you need to copy some code, you can select the desired piece with Extend/shrink selection shortcuts Control+W / Control+Shift+W or with the Select containing declaration shortcut Control+Shift+OemOpenBrackets .

To learn more about symbols without opening their declarations, use the quick documentation command Control+Q .

Additionally to assembly code, you can display compiler generated code and metadata tokens right in the code viewer as well as view IL code side by side with source code.

Navigate and search

The scope of navigation and search includes all assemblies currently loaded in the Assembly Explorer window and all assemblies referenced from those assemblies. See Navigate compiled code to learn how the navigation is performed within compiled assemblies.

There are plenty of ways to search code with dotPeek. In most of the cases, you can use the Search Everywhere command Control+N — it will bring you to assemblies, types, and type members from the scope in a few keystrokes. When you specify a symbol to search, use CamelHumps — enter only uppercase letters of compound names.

Among the wealth of navigation commands, the most helpful is Go to Declaration Control+B , which is also available with Ctrl — clicking on symbols. If you invoke this command on a usage of a symbol, you will land on its declaration, if you do this on the declaration itself, you will be able to iterate over all symbol usages in the scope.

To see all navigation commands available for the current caret position, use the Navigate To command .

If these commands do not help you in some situation, you will be able to find a command that helps among other dozens of navigation and search commands.

Another command that you can use after you found the desired symbol — Locate in Assembly Explorer Alt+Shift+L — will help you understand to which assembly, namespace, type, and so on the symbol belongs to.

Advanced features

dotPeek is much more than a decompiler thanks to its advanced features. With dotPeek, you can also:

Explore relation between types with type hierarchy and type dependency diagram.

Как работает декомпиляция в .Net или Java на примере .Net

Сегодня хотелось бы поговорить про декомпиляцию приложений (все применительно к той же Java, да и любому языку с некоторыми допущениями и ограничениями, но поскольку сам я — .Net разработчик, примеры будут совсем немного MSIL’овизированы 🙂 ).

(поддержка R# хоткеев, сервер символов) (также не плохой, множество хоткеев) (аналог dotPeek, но платный. Изначально был основным в мире .Net, но пока был бесплатным) (хороший, opensource. Полезен, когда вы сами пишете код, использующий Mono.Cecil, т.к. Это даст лучшее понимание его работы) с функцией inplace editor

(основной, самый крутой декомпилятор в мире .Net. На выходе получаете объектное «зеркало» содержимого сборки. Т.е. Максимально-упрощенно, без наворотов типа конвертации массива IL в DOM). (надстройка над mono.cecil, переводящая array[MSIL] в DOM, где есть циклы, switches и if’ы. Является частью SharpDevelop/ILSpy) (аналогичное от меня, но сохраняющее информацию о символах. В среднем состоянии, не готова для прода, помощь приветствуется).

А теперь, хотелось бы описать как они работают (вам же интересно, как работает машинка от JetBrains?). Чтобы как минимум понять, насколько это сложно: написать свой декомпилятор .Net сборки обратно в код на C#.

1. Должен принимать на вход любую сборку: от CLR 1.* до 4.*
2. Обязан поддерживать не только C# вывод, но и MSIL, VB.NET и вообще — на что фантазии и потребностей хватит.
3. Возможность выбирать между различными версиями языка (например, C#), при этом не имея дублирования в реализации.

И теперь, когда требования определены, давайте подумаем, как устроена работа MSIL, и как это поможет нам в быстрой декомпиляции приложения.

В отличии от языка процессора, который вносит для нас некоторые сложности в процесс декомпиляции (регистры, оптимизации, возможность сделать одно действие несколькими способами), в MSIL все максимально просто. Если надо записать в локальную переменную нечто, то для этого есть всего одна команда. Другим способом записать в переменную значение не получится. Это свойство наделяет конечный компилятор (JITter) простотой в реализации с одной стороны… А с другой стороны наделяет простотой в реализации декомпилирующую сторону.

Второе свойство, каким обладает MSIL, это вычисления на стеке. Тут нет регистров. И единственная память, через которую идут все вычисления — это стек. Это абсолютно не значит что конечный процессор также все вычисляет через стек. Нет. Это значит что этой моделью для упрощения пользуется описание всех расчетов и вызовов на MSIL. Что это значит для нас? Это значит что сложить два числа можно только одной командой, которая вне зависимости от параметров — одна. Это команда, вытащив данные для сложения из стека, складывает их и сохраняет результат не куда-либо, а обратно в стек. Это важно, потому что для нас, как для людей, пишущих декомпилятор это не породит огромного ветвления кода.

Теперь мы подошли к самому главному: как происходит процесс декомпиляции.

Первая трудность, которая приходит в голову: положение инструкций может быть различным. Т.е., например, чтобы код выполнился, совсем не обязательно что между ldind_i4 и add не будет других инструкций. Например, совершенно валиден следующий код:

Что должно декомпилироваться, например, так:

Во-вторых названия переменных в релизе могут отсутствовать. Т.е. без примесей, код будет таким:

В третьих, что самое сложное, реализации if-else, while, do-while, switch могут отличаться. Этого касаются, в особенности, лямбды, yields, async/awaits и прочие языковые примочки, которые являются опциональными и на самом деле реализуются поверх обычных функций языка. Как все это учесть? На самом деле оба вопроса решаются всего двумя способами.

Стековая модель декомпиляции

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

Т.е. Сначала у нас есть на входе 4 команды. Первые две ничего не берут на вход, а только отдают — число. Соответственно, мы кладем их на стек (ldind_i4 4, ldind_i4 5). После чего мы берем очередную команду — Add. Она принимает на вход два значения со стека. Поэтому мы считываем два узла с нашего стека и, схоранив их как параметры этой команды, сохраняем саму команду- на стек, поскольку у команды есть результат. А любой результат сохраняется на стеке.

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

Соответственно, если бы выражение было бы посложнее:

То процесс создания DOM выглядел бы следующим образом:

После чего осуществляется окончательная сборка дерева:

Таким же образом конструируются вызовы методов. Только в случае методов, со стека будет забираться требуемое под вызов количество параметров и сохраняться в классе ноды вызова метода. Если метод возвращает значение, то нода вызова метода будет сложена в стек. Если нет — добавлена к группе готовых выражений.

Сборка дерева

Это все были подготовительные этапы. Далее, для модульности, создаются классы, которые распознают какую-либо одну конструкцию в дереве и переводят ее в другую. Например, если это if-else, то матчится наличие условного перехода такого, чтобы переход осуществлялся вперед. Тогда узел преобразуется в if-else ноду, код за переходом помечается как else (negative if) нода, а код между условием и else нодой — как positive if нода. Если матчится как условный переход с переходом на прошлые инструкции, то это матчится как while цикл и дерево также перестраивается. Соответственно, в зависимости от чистоты исполнения матчеров, на выходе мы получем преобразованное дерево под конкретный язык программирования. Далее, у каждого из языков программирования мы задаем множество матчеров, которые ему подходят. Например, циклы и условия подойдут всем, потому они будут присутствовать почти во всех пакетах. А вот, например, async/await — он только для C#. Потому, будет присутствовать тольк в его пакете.

Для ясности картины, как собираются if-else и while/do-while, рассмотрим примеры:

Сборка IF-ELSE блока

Сборка WHILE блока

Генерация кода

Последний этап матчинга — генерация кода по дереву. Тут не должно быть каких-то сложностей. Идеально, конечно, было бы круто подсасывать правила от R# или StyleCop. Благо, они в XML. Но в простейшем случае, мы пишем генератор, который принимает на вход дерево описания класса. Он сперва обязан проверить все дерево: содержит ли оно не поддерживаемые типы нод. Если все в порядке, то обходится все дерево и для каждого узла вызывается соответствующий метод по шаблону проектирования Visitor, которому передается StringBuilder и соответствующая нода. Дополнительно, необходимо считать количество пробелов, которые надо отступать с начала каждой строки. На этом этапе все достаточно просто.

Software like DotPeek to decompile and edit DLL's?

I just got DotPeek and I found it is PERFECT for looking into .dll files. However I can’t edit them at all. Is there free software like DotPeek that also lets me edit the DLL instead of just looking at it?

UPDATE: I was able to save all the .cs files in the .dll file separately and edit them in VS (Visual Studio). Now how do I get them back into the .dll file after editing?

4 Answers 4

Simpler method: You can use dnSpy to edit a managed DLL’s bytecode directly using the right click -> «Edit IL instructions» option and save the DLL back from File -> Save Module.

In the latest version of DotPeek you can right click on an assembly in the assembly explorer tree view and click the ‘Export To Project’ option. This will save it as an accessible Visual Studio solution and you can then make changes, debug in run time and recompile to replace the original DLL.

Remember it only provides this option for assemblies and not individual classes within an assembly.

for minor IL code change, use dnSpy to modify the IL code is a easy way. for major .NET code change, use DotPeek to decompile the assembly and export it to a VS project. then you can edit the .cs code and rebuild from the new project.

Статья Хищник среди нас. Учимся реверсить на примере Predator

Введение
Наверное тебе всегда было интересно, как работают современные малвари. Шифровальщики, ратники, стиллеры и другие популярные вирусы это всего лишь разновидность программ заточенные под определенные задачи. Описывать каждый из них я не стану, а лучше расскажу тебе как специалисты по информационной безопасности вскрывают такое. Для примера я взял когда-то знаменитый стиллер Predator. Он имеет обширный арсенал функций и конечно же крякнутую версию по которой будет проще ориентироваться. Давай приступим к делу.

План работы ​

Хуже чем отсутствия плана ничего быть не может. Поэтому давай я введу тебя в курс дела. Сначала мы разберем теоретическую часть, где я опишу основы реверс-инженерии и расскажу как это работает. Также тебе придется познакомиться с матчастью, которая плотно связанна с таким типом деятельности. Ну а какая же теория без практики! Для этого мы настроим среду анализа и попробуем вскрыть нашего хищника при помощи популярных утилит. Не буду задерживать, перейдем к основам.

Основы реверс-инженерии ​

Сейчас, в условиях цифрового мира многие вирусописатели стали прибегать к изощренным способам защиты своего детища от откладки, дизассемблирования и дальнейшего анализа кода. В связи с этим теперь каждый уважающий себя реверс-инженер обязан знать как распаковывать исполняемые файлы. Самые распространенные упаковщики это UPX, VMProtect, FSG и другие. По мимо них создатели вирусов применяют протекторы. Их основная задача это защита исходного кода от посторонних глаз. Как метод защиты применяют обфускацию, шифрование или встраивание функций антиотладки.

Как ты уже догадался, чтобы добраться до заветной частички кода приходится снимать весь обвес, который применял сам разработчик вируса. Такой процесс зависит от запутанности кода. Бывают ситуации, когда вирус имеет стандартный набор защиты, который снимается несколькими утилитами. В других же случаях приходится включать творческий режим и часами колупать защиту, которую придумал автор. Можешь не волноваться, дальше стандартных протекторов в статье я не уйду.

Итак, ты столкнулся с самым стандартным вирусом, который покрыт защитой. Тут есть несколько вариантов развития событий. Ты можешь использовать автоматический распаковщик, которые специально заточены под это. Они основываются уже на известных алгоритмах упаковки и защиты. К примеру, чтобы снять UPX ты можешь использовать UN-PACK. Чтобы вынести защиту ACProtect следует использовать ACKiller, ну а ASProtect ты можешь вынести с ноги используя Stripper.

Второй вариант развития событий это использовать универсальные распаковщики. К примеру QuickUnpack, RL!dePacker или Dr.Web FLY-CODE Unpacker, который основан на движке FLY-CODE антивируса Dr.Web. Отличие от первой ситуации в том, что большую часть работы придется делать самим. В любом случаи такой расклад событий гораздо лучше, чем последний метод о котором я расскажу далее.

Если все же тебе в руки попался профессионал своего дела, то вирус будет покрыть особым типом защиты, который скорее всего будет создан самим разработчиком малвари. Здесь потребуется ручная распаковка с помощью x64dbg или любого другого дизассемблера. Если файл запакован чем-то неизвестным, то это можно распознать по функциям GetProcAddressA, LoadLibraryA или GetModuleHandle из библиотеки kernal.

Как работать с вирусом ​

1. Определение сигнатуры упаковщика;
2. Поиск Original Entry Point (OEP);
3. Дамп вируса на диске;
4. Восстановление кода вируса (таблицы импорта/экспорта);
5. Пересборка.

• Entry Point — адрес, по которому передается управление после загрузки программы в оперативную память.
• Breakpoints — точки останова, их используют для анализа выполняемого кода. Таким образом можно узнать где и что выполняется в вирусе.
• Original Entry Point (OEP) — это адрес, с которого бы начала выполняться программа, если бы не была упакован.

1. Остановка при чтении;
2. Остановка при записи;
3. Выполнение памяти по заданному адресу.

• PE-файл — исполняемый EXE-файл, который содержит в себе исполняемый код и данные необходимые для правильной работы программы в системе.

• Virtual Address (VA) — виртуальный адрес элемента в памяти. Адрес загрузки берется из поля OptionalHeader в том случаи если он равен ImageBase.
• Relative Virtual Address (RVA) — относительный виртуальный адрес, он отсчитывается от адреса загрузки, который либо равен ImageBase, либо нет.

• RVA = VA – адрес загрузки

1. Находим относительный виртуальный адрес у OEP;
2. Дампим полученную малварь;
3. Восстанавливаем таблицу импорта;
4. Подменяем точку входа на оригинальную.

Разбираем малварь на пальцах ​

Из заголовка статьи ты мог узнать с какой малварью мы будем работать. Итак наш подозреваемый носит название Predator, что в переводе с английского означает хищник. Красиво звучит, не так ли? Находится в классе стиллеров, программ нацеленных на кражу и передачу паролей пользователя. Имеет обширный выбор функции и может красть не только из браузеров.

В наличие есть три типа передачи информации: PHP, FTP и E-Mail. Думаю объяснять как это работает не стоит. Заглянем в раздел настроек и посмотрим, как там обстоят дела. Из основных моментов это заметание следов путем очистки журнала, запись в автозапуск и отключения различных функций, к примеру вызов диспетчера задач. Дальше описывать я не буду, а попробую создать вирус. Для этого переходим на последнюю вкладку и собираем PE-файл.

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

Итак, наш подозреваемый построен при помощи библиотеки NET Framework, значит дела обстоят не так плохо и шансы разреверсить программу не прибегая к ручному дизассемблированию у нас есть. Поэтому можешь выдохнуть, так как учить ассемблер в статье мы не будем. Теперь откроем вкладку с энтропией и посмотрим какие же секции спрятал от нас разработчик.

Как ты видишь статус сжатия присутствует только на секции text. Она является одной из главных и порой именно в ней содержится вся необходимая нам информация. По статусу ты также можешь определить, покрыт ли файл упаковщиком или нет. Обычно если автор программы не прибегает к каким либо мерам защиты своего детища, то процесс сжатия не будет переваливать за 80%. Если же он додумался накинуть оберег для своего творения, то твоя шкала уйдет дальше этих несчастных цифр. Еще это все можно увидеть из графика и его скачкообразного движения вниз и вверх.

А теперь давай закрепим знания по теоретической части. Знания относительных виртуальных адресов тебе пригодится для работы с картой памятью. В DiE ты можешь открыть вкладку Карта памяти и посмотреть, что там происходит.

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

А в таблицах импорта у нас все глухо. Лишь одно доказательство того, что вирус использует библиотеку NET. Это ты можешь увидеть если обратишь внимание на библиотеку mscoree.dll. Она отвечает за шаблоны NET Framework.

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

Включаем динамику
Чтобы докопаться до заветной информации воспользуемся ExtremeDumper. Это утилита динамического анализа и с помощью нее мы сможем снять весь обвес по типу обфускатора или криптора. Давай запустим ее попробуем поймать процесс нашего вируса. Заранее предупреждаю, запуск вредоносной программы производить следует только в виртуальной среде. Так ты обезопасишь себя от несанкционированного доступа. После запуска дважды кликаем по нашему вирусу. Далее наведи мышку на окно ExtremeDumper и в выпадающем меню выбери функцию Refresh. Теперь у тебя в поле появился наш вирус. Дампим его и идем по пути готовой работы.

Прежде чем оценить труды дампера закинем сдампленный файл в pestudio. Да, ты сейчас начнешь возмущаться, что мы работаем на динамическом анализе, а не на статическом. Но с помощью этой утилиты ты сможешь посмотреть строки, которые содержит вирус. Выглядит все следующим образом.

Если присмотреться, то наш стиллер создает SQL базу и записывает туда всю собранную информацию. Также в строчках ты можешь найти ссылки и методы подключения по протоколу SMTP (почтовый протокол). Создание, хранение и сохранение — все это ты увидишь в этой утилите.

Повторно запустим наш вирус, но перед этим будем фильтровать трафик при помощи Wireshark. Перед запуском тебе требуется выбрать адаптер. У меня в его роли выступает Беспроводная сеть и поэтому я буду работать именно с ним. Все готово и теперь спустя пару минут перехвата давай попробуем отфильтровать нужные пакеты. Из pestudio мы выяснили, что стиллер делает запросы к определенным сайтам. Начнем копать с протокола HTTP. Для этого в поле фильтрации вводим http. После этого ты увидишь такую картину.

Как ты мог заметить, вирус отправляет уведомления и возвращает ошибку, поскольку я собрал малварь без способов передачи информации. Ты можешь развлечься при помощи фильтров Wireshark и узнать больше информации о нашем подозреваемом. Я этим заниматься не буду, поскольку моя основная задача была убедиться в том, что программа обращается к определенным сайтам для передачи информации. Теперь ты знаешь нужные данные для работы, что же мешает заглянуть под капот и узнать, как написан такой софт?

Для этого я буду использовать достаточно известную утилиту от JetBrains с названием dotPeek. Скачать ты его можешь с

. Загружаем, запускаем и работаем. Перетяни вирус на окно декомпилятора и буквально через пару минут случиться магия. Перед тобой явится исходный код вируса в полном объеме. На деле это выглядит так.

Интерфейс хищника стоит на Windows Forms, а также в части импорта библиотек у нас есть сокеты и почты для работы. Все же какая-то защита данных от несанкционированного доступа у нас есть. Это ты можешь увидеть из следующего скриншота.

Малварь шифрует информацию при помощи AES, это ты можешь увидеть в коде, ну а ключи для декодирования у тебя перед глазами. Передача данных проходит по порту 587. Воспользуйся этим при последующем перехвате трафика через акулу. Дам наводку по фильтру. Используй такую строчку, чтобы найти нужную информацию.

Ну или если тебе лень это делать, то читай статью дальше и я расскажу, что нам даст такой фильтр. Этот порт будет работать в том случаи и только в том случаи если ты не оставлял поля отправки данных пустыми. В моем случаи они ничем не заполнены, поэтому вирус передает информацию по стандартному порту 80. Но в основном здесь ты можешь ознакомиться только с пакетами SYN и ACK. Напомню, для чего они нужны.

Обычно, перед тем, как передать пакеты с информацией серверу твое устройство делает предварительное соединения при помощи отправки TCP-пакета с флагом SYN. Он означает то, что устройство хочет провести подключение. Логично? Как по мне вполне. Если ответ от сервера будет положителен то передача начнется. Ну а флаг ACK в пакете TCP говорят о завершении подключения. Я объяснил все максимально коротко, более подробно о работе с TCP соединениями ты узнаешь в других моих статьях. Повторюсь, в моем случаи нет никакой информации кроме этих флагов так как я не указал место, куда стоит отправлять информацию.

Продолжим наше увлекательное путешествие по строчкам кода хищника. Переключимся на ветку RunPE и посмотрим, что импортировал наш софт. Здесь ты увидишь библиотеку kernal32 и ntdll. Импортированных модулей на горизонте не видно. Вернемся к Form1. Тут продолжаем импортируемые модули и натыкаемся на user32. Обычно, если ты такое видишь, то жди беды. Точка входа у нас это SetWindowsHookExA.

Также вирус регистрирует нажатие клавиш, это можно увидеть если ты пролистаешь код ниже. Записывает информацию наш вирус в файл с названием SysInfo.txt. А теперь я расскажу тебе, что за информацию пытался передать наша малварь в акуле. Файл записывается с именем Predator_Painv13_Notification. К нему добавляется имя компьютера, с которого будет отправлено письмо и имеет расширение TXT. В нем содержится текст такого формата: This is an email notifying you that has ran your logger and emails should be sent to you shortly and at interval choosen.

Далее идут детали подключения, а также несколько адресов. Еще вирус меняет значения реестра по пути: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\\Hidden. На заметку, это еще не автозапуск. Он тут реализуется совершенно иным образом. Для этого создается файл с названием autorun.inf и в него записывается следующие строчки:

Далее все это дело помещается по такому пути: Software\Microsoft\Windows\CurrentVersion\Run. Да, работа автозапуска работает очень странно, но не нам судить творения других людей. Также наш подозреваемый опирается на программу vbc.exe. Поэтому чисто в теории если ты не установишь библиотеку NET Framework, то хищник обойдет тебя стороной. Советы странные. Такие же странные как заставить пользователя выключить интернет. При первом запуске, чтобы сразу не спалиться стиллер использует timesleep. Не забудем про самое главное, где хранятся логи для дальнейшей отправки. Вся информация как не странно хранится в AppData. Для многих это будет очевидно, но все же не указать это при анализе очень не вежливо.

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

и возвращает ответ для записи. Больше в ветке Form1 искать нечего. Все данные по типу хоста, порта, паролей и логинов храниться в ветке Resources.

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

Заключение
Здесь я описал реверс стиллера Хищник, который как и остальные заслуживает должного внимания среди вирусологов. Также мы разобрали основы реверс-инженерии и теперь ты знаешь на базовом уровне то, как работать с малварью. Конечно, это еще не все, что может произойти в реальных условиях. Ты можешь столкнуться с самодельным шифрованием кода и тогда придется прибегать к ручному дизассемблированию. Но об этом я расскажу тебе в другой статье.