eXeLab
eXeL@B ВИДЕОКУРС !

ВИДЕОКУРС ВЗЛОМ
обновлён 2 декабря!


УЗНАТЬ БОЛЬШЕ >>
Домой | Статьи | RAR-cтатьи | FAQ | Форум | Скачать | Видеокурс
Новичку | Ссылки | Программирование | Интервью | Архив | Связь

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

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

 eXeL@B —› Софт, инструменты —› Unicorn - The ultimate CPU emulator
. 1 . 2 . 3 . 4 . >>
Посл.ответ Сообщение


Ранг: 657.3 (! !)
Статус: Участник
CyberMonk

Создано: 19 октября 2017 13:52 · Поправил: mak New!
Цитата · Личное сообщение · #1



Unicorn is a lightweight, multi-platform, multi-architecture CPU emulator framework based on QEMU.

Unicorn offers some unparalleled features:

Multi-architecture: ARM, ARM64 (ARMv8), M68K, MIPS, SPARC, and X86 (16, 32, 64-bit)
Clean/simple/lightweight/intuitive architecture-neutral API
Implemented in pure C language, with bindings for Crystal, Clojure, Visual Basic, Perl, Rust, Ruby, Python, Java, .NET, Go, Delphi/Free Pascal, Haskell and Pharo.
Native support for Windows & *nix (with Mac OSX, Linux, *BSD & Solaris confirmed)
High performance via Just-In-Time compilation
Support for fine-grained instrumentation at various levels
Thread-safety by design
Distributed under free software license GPLv2


Последний мастер - --> Link <--
Последний релиз Version 1.0.2-rc1 - --> Link <--

Сборка - следуем указанию в --> Link <--

Code:
  1.  MINGW64 /n
  2. $ cd msys64/unicorn
  3.  
  4. @PC MINGW64 /n/msys64/unicorn
  5. $ ./make.sh cross-win64
  6. cd qemu && \
  7. ./configure --cc="x86_64-w64-mingw32-gcc" --extra-cflags="-DUNICORN_HAS_X86 -DUNICORN_HAS_ARM -DUNICORN_HAS_M68K -DUNICORN_HAS_ARM64 -DUNICORN_HAS_MIPS -DUNICORN_HAS_MIPSEL -DUNICORN_HAS_MIPS64 -DUNICORN_HAS_MIPS64EL -DUNICORN_HAS_SPARC " --target-list="x86_64-softmmu, arm-softmmu, m68k-softmmu, aarch64-softmmu, mips-softmmu, mipsel-softmmu, mips64-softmmu, mips64el-softmmu, sparc-softmmu,sparc64-softmmu," --disable-stack-protector

*Если MINGW64 Портабельный то здесь нужно указать полный путь с названием диска $ cd c:/msys64/unicorn

| Сообщение посчитали полезным: plutos, Isaev



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

Создано: 19 октября 2017 17:23 New!
Цитата · Личное сообщение · #2

Не трогайте реестр.

Здесь необходимо просто отредактировать unicorn/windows_export.bat

| Сообщение посчитали полезным: Bronco


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

Создано: 19 октября 2017 21:07 New!
Цитата · Личное сообщение · #3

А нельзя картинки поменьше сделать? А то даже с монитора на соседнюю стенку залазят!!!


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

Создано: 19 октября 2017 22:49 · Поправил: Bronco New!
Цитата · Личное сообщение · #4

просмотрел хидер с примерами, интересовали мем_рид_врайт для х64, вывод: код в дифайнах зависим от базового адреса в тех же дифайнах. на практике любой адрес для мапа и записи должен быть округлён, как при выделении страницы, с адреса инстр ус_мем_врайт егорит, хотя страница замаплена по размеру. выделенный байт код из страницы, пишет в начало страницы, новый рип не релочат, в итоге указатель "сломан" и с памяти не читает.
из хуков полезен по ходу только комби UC_HOOK_MEM_INVALID, как раз для "ломанных указателей"
независимые куски кода эмулит на ура.


Ранг: 657.3 (! !)
Статус: Участник
CyberMonk

Создано: 20 октября 2017 13:18 · Поправил: mak New!
Цитата · Личное сообщение · #5

в Visual Studio 2017 собралось отлично, все либы и длл, моя ошибка была в том, что хидеры не обновились под 2017, после повторного апдейта для 141xp не было ни одной ошибки. Теперь осталось проверить совместимость со старым проектом и актуального мастера и потом проверить указатели


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

Создано: 21 октября 2017 18:51 · Поправил: Bronco New!
Цитата · Личное сообщение · #6

mak пишет:
и потом проверить указатели

упс...одно горе на двоих..
хз как ты собираешь буфер, для записи байткода перед эмулем, но со списком инструкций, пока лучшим решением брать для uc_mem_map базу образа, и к ебеням весь размер образа. А при сборке буффера перехватывать инстр зависимые от RIP, и пересчитывать дистанцию в байткоде инструкции.
Code:
  1. temp = ListEmul->first;
  2. uint64_t assembly_size = 0;
  3. while (temp != NULL) {
  4. cs_x86 *x86temp = &(temp->instruction->detail->x86);
  5. if (x86temp->operands[0].mem.base == X86_REG_RIP || x86temp->operands[1].mem.base == X86_REG_RIP)
  6. { uint32_t disp = DecodeRipForAddr(false, temp) - TEXT_ADDRESS - temp->instruction->size - assembly_size;
  7. int pos = temp->instruction->size - 5;
  8. for (int i = 0; i < temp->instruction->size; i++)
  9. {
  10. if (> pos)
  11. { temp->instruction->bytes[i] = disp;
  12.    disp = disp >> 8;
  13. }
  14. }
  15. assembly_size += temp->instruction->size;
  16. temp = temp->next;
  17. }

в итоге указатели под мап валидные, но читать_писать этот "хер с рогом" не желает. отписали исузу, пока игнор.
Bronco пишет:
читать_писать этот "хер с рогом" не желает

он то хочет , но с uc_mem_map может только мапить пустые страницы..
Code:
  1. BYTE *ptrtest = new BYTE[Module::GetMainModuleSize()];
  2. DbgMemRead(Module::GetMainModuleBase(), (void*)ptrtest, Module::GetMainModuleSize());
  3. err = uc_mem_map_ptr(uc, (uint64_t)Module::GetMainModuleBase(), (size_t)Module::GetMainModuleSize(),UC_PROT_ALL, (void*)ptrtest);
  4. if (err != UC_ERR_OK)
  5. {
  6. _plugin_logprintf("[" PLUGIN_NAME PLUGIN_BIT"] Error: uc_mem_map_ptr, %s\n", uc_strerror(err));
  7. return;
  8. }

в итоге всё читаем, куда угодно пишем:
Code:
  1. - UC_MEM_WRITE  in address: 0x8fb7f8; size = 8; value = 0x14c35e33e
  2.    - UC_MEM_READ from address: 0x14931ab00; size = 4; value = 0xfffd19f2
  3.    - UC_MEM_READ from address: 0x8fb7f8; size = 8; value = 0x14c35e33e
  4.    - UC_MEM_WRITE  in address: 0x8fb7f8; size = 8; value = 0x14c32fd30
  5.    - UC_MEM_READ from address: 0x8fb7f8; size = 8; value = 0x14c32fd30
  6.    - UC_MEM_READ from address: 0x14168b588; size = 4; value = 0x18
  7.    - UC_MEM_WRITE  in address: 0x8fb7f8; size = 8; value = 0x14c32fd30
  8.    - UC_MEM_READ from address: 0x147c51f51; size = 4; value = 0x66972e
  9.    - UC_MEM_READ from address: 0x8fb7f8; size = 8; value = 0x14c32fd30
  10.    - UC_MEM_WRITE  in address: 0x8fb7f8; size = 8; value = 0x14c99945e
  11.    - UC_MEM_READ from address: 0x8fb7f8; size = 8; value = 0x14c99945e


Ранг: 657.3 (! !)
Статус: Участник
CyberMonk

Создано: 22 октября 2017 13:04 · Поправил: mak New!
Цитата · Личное сообщение · #7

Господа специалисты С++ выручайте!

Оригинальный релиз апрельский от разработчиков, функция uc_open, начало

Code:
  1. PUSH    RBP
  2. MOV     RBP, RSP
  3. SUB     RSP, 30
  4. MOV     DWORD PTR SS:[RBP + 10], ECX
  5. MOV     DWORD PTR SS:[RBP + 18], EDX
  6. MOV     QWORD PTR SS:[RBP + 20], R8
  7. CMP     DWORD PTR SS:[RBP + 10], 7
  8. JA      unicorn.6B6B9802

То что выдаёт мне студия 2017
Code:
  1. MOV     QWORD PTR SS:[RSP + 10], RSI
  2. MOV     QWORD PTR SS:[RSP + 18], RDI
  3. PUSH    R14
  4. SUB     RSP, 20
  5. MOV     R14, R8
  6. MOV     EDI, EDX
  7. MOV     ESI, ECX
  8. CMP     ECX, 8
  9. JGE     unicorn.7FFE3ADE9498

Вопрос - как разработчики собирают подобный код с RBP фреймом?! Судя по этому документу /Oy (Frame-Pointer Omission) --> Link <-- я не могу напрямую в Студии использовать RBP фрейм?! Я уже испытал все возможные варианты, которые пришли в голову, включая без оптимизации.
Вот начало функции в msys64
Code:
  1. PUSH    RBP
  2. PUSH    RDI
  3. PUSH    RSI
  4. PUSH    RBX
  5. SUB     RSP, 28
  6. CMP     ECX, 7
  7. MOV     ESI, ECX
  8. MOV     EDI, EDX
  9. MOV     RBP, R8
  10. JA      unicorn.6B08B8D1
  11. MOV     EDX, 7A0
  12. MOV     ECX, 1

В обоих случаях у меня ломается стэк при вызове любой процедуры уникорна, конечно я могу перед каждым call сделать пролог и потом епилог, но это не нормально, учитывая, что версия от разработчиков работает так как должна. Какие опции они используют?

Актуальный мастер - --> Link <--


Ранг: 1014.5 (!!!!)
Статус: Участник

Создано: 22 октября 2017 13:22 New!
Цитата · Личное сообщение · #8

mak пишет:
Вопрос - как разработчики собирают подобный код с RBP фреймом?!

достаточно в фаре открыть длл по ф3 и все становится понятно


Ранг: 540.1 (!)
Статус: Участник
_Вечный_Студент_

Создано: 22 октября 2017 23:31 New!
Цитата · Личное сообщение · #9

reversecode пишет:
достаточно в фаре открыть длл по ф3 и все становится понятно


Пожалуйста, можно немного подробнее?


Ранг: 1014.5 (!!!!)
Статус: Участник

Создано: 22 октября 2017 23:40 New!
Цитата · Личное сообщение · #10

очевидно что unicorn.dll разработчики собирают через mingw
такой пролог только гцц генерит
или о чем вопрос ?

| Сообщение посчитали полезным: plutos



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

Создано: 23 октября 2017 00:06 · Поправил: Bronco New!
Цитата · Личное сообщение · #11

reversecode пишет:
очевидно что unicorn.dll разработчики собирают через mingw

MinGW(GCC: (Rev2, Built by MSYS2 project) 6.2.0)
хз как они собирают такую большую длл в релизных билдах, с мастера в студии линкуются очень не большие либы, как статик так и динамик.+ к к этому, слинкованное егорит все проекты.

| Сообщение посчитали полезным: plutos


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

Создано: 23 октября 2017 01:05 New!
Цитата · Личное сообщение · #12

Bronco пишет: хз как они собирают такую большую длл в релизных билдах, с мастера в студии линкуются очень не большие либы, как статик так и динамик.+ к к этому, слинкованное егорит все проекты.

Размер зависит от количества поддерживаемых камней, если x86-x64 онли, без всяких arm и mips оно собственно маленьким и получается, плюс студийный компилятор не пихает шлак с msys.


Ранг: 657.3 (! !)
Статус: Участник
CyberMonk

Создано: 23 октября 2017 12:32 New!
Цитата · Личное сообщение · #13

Это говорит о том, как бывает случайно тут и у многих reversecode даже не прочитал пост) Если бы он его прочитал, то такого ответа не было бы. Тут даже ответить то нечего


Ранг: 1014.5 (!!!!)
Статус: Участник

Создано: 23 октября 2017 12:36 New!
Цитата · Личное сообщение · #14

нука нука что там reversecode не прочитал ? уточните
может у него еще туз в рукаве


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

Создано: 24 октября 2017 07:11 New!
Цитата · Личное сообщение · #15

shellstorm пишет:
оно собственно маленьким и получается

так это слинкованное егорит все проекты. , возможно из-за экспорта.

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

Создано: 24 октября 2017 09:10 New!
Цитата · Личное сообщение · #16

Bronco пишет: так это слинкованное егорит все проекты. , возможно из-за экспорта.

Хз, линковал со статической либой собранной TDM GCC (msys днище для совсем уж специфических вещей) и собирал студийным компилем тоже со статик линковкой, проблем не было, если не считать баги реализации.


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

Создано: 24 октября 2017 21:15 · Поправил: Bronco New!
Цитата · Личное сообщение · #17

shellstorm пишет:
линковал со статической либой собранной TDM GCC

я за мастер сорцы. в апрельском релизе в хидерах не было "platform.h". а он тянет за собой в инклудах
<winsock2.h>
у меня пятнашка , в моём проекте, ещё до сборки начинает егорит на свой же файл.
если закоментить инклуд, то слинкованая в студии статик либа с мастер сорцов, подходит. а вот с динамической не всё так гуд, по ходу всё таки экспорт ломается.
"Порядковый номер 10694 не найден в библиотеке DLL.."
===добавил.
упс...
закоментил "platform.h" в хидерах "unicorn.h" и "x86.h", переименовал "unicorn_static.lib" в "unicorn.lib", подкинул собранную в пятнашке unicorn.dll на 5 мег завелось_работает..


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

Создано: 18 июня 2018 23:59 New!
Цитата · Личное сообщение · #18

при записи трассы в бинарь, по опкодам или адресам инстр, на хуках что то можно фильтровать, но если код трассы лапша, то большие участки, которые повторяются хз как пропускать.
кто юзал сабж как трассер, по типу pin или dinamorio, плезир отпишитесь, если шара бряки ставить?
пока по таймингам такое:
Code:
  1. 1.Unicorn
  2. - Total Time: 00:00:01.609 - 1.Write instr->928 | 2.Instr size->-0xd8d
  3. 2.x64dbg //странно но с вкл медиа плеером трассирует в 10 раз быстрее, и всё равно рог шустрее...))
  4.  - Total Time: 00:00:05.781 - 1.Write instr->887 | 2.Instr size->-0xd54


Ранг: 316.3 (мудрец)
Статус: Участник

Создано: 19 июня 2018 01:06 New!
Цитата · Личное сообщение · #19

Bronco

1к инструкций за полторы секунды - это не тайминг, это ппц. Тем более что от сырой трассы толку нет, она должна быть связана в cfg/dfg. Почему оно столь медленное ?


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

Создано: 19 июня 2018 01:50 New!
Цитата · Личное сообщение · #20

difexacaw пишет:
Почему оно столь медленное ?

млять, опять ты, перечитай последнее предложение


Ранг: 316.3 (мудрец)
Статус: Участник

Создано: 19 июня 2018 02:21 · Поправил: difexacaw New!
Цитата · Личное сообщение · #21

Bronco

По вашей ссылке ответ по декодеру, который никакого не имеет отношения к профайлу. 1к инструкций/сек таких тормозов я за всё время что в теме никогда не видел. Даже тормозное определение длины системным путём(TF) обеспечивает на порядки выше профайл(1/3М если верно помню). Что вы там курите ?)

А учитывая что тема про эмулятор, то такие просадки профайла вообще уму не постижимы..

На счёт капстонов и прочего говна я же говорил - лишь один есть годный декодер это ксед. Остальное всё - мусор.

Ваш ответ в такой манере.. вы должны знать что ваше мнение значения не имеет.

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

Создано: 19 июня 2018 02:36 New!
Цитата · Личное сообщение · #22

difexacaw пишет: Что вы там курите ?

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


Ранг: 316.3 (мудрец)
Статус: Участник

Создано: 19 июня 2018 02:51 · Поправил: difexacaw New!
Цитата · Личное сообщение · #23

shellstorm

Разницы между модами 86-64 нет, незначительная которая резолвится общим декодером. Обкатывать новые алгоритмы проще на 86, это во первых простая отладка и набор инструкций. Фактически разница лишь в RIP-адресации. Это всё столь не существенно, что не вижу смысла даже это обсуждать.

Графы - нет смысла строить какие то трассы без их свёртки. А имплементация по числу строк, вы удивитесь какого малого размера может быть встраиваемый визор. Просто это нэйтивное обычно, а не собирается какой то поганью. В противном случае и получается такое глючное - 1к/сек это походу прикол какой то, это вообще невозможно так косячно реализовать. Можно допустить что время уходит на какой то анализ, но в данном случае его нет.

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

Создано: 19 июня 2018 03:20 New!
Цитата · Личное сообщение · #24

difexacaw пишет: Обкатывать новые алгоритмы проще на 86, это во первых простая отладка и набор инструкций

для x86 старого полно, в крайнем случае можно на коленке разобрать в IDA, даже vmprot, а проблема как раз с x64 нет нормальных инструментов, IDA и та в этом случае не помощник, анализа можно дожидаться очень долго из за пары vm, какой нэйтив, он в IDA отбивается в компилируемые исходники.
на счет времени не знаю почему так долго, хотя qemu никогда не отличался скоростью, но вариант с рекомпиляторами не подходит Bronco из-за сопутствующей инфраструктуры, слишком много кода писать. остальное всё это пиар "мотора" теоретиком, нечего даже обсуждать, тем более здесь никто не требует каких-то феноменальных скоростей.


Ранг: 316.3 (мудрец)
Статус: Участник

Создано: 19 июня 2018 03:50 New!
Цитата · Личное сообщение · #25

shellstorm

Инструменты - они нужны для автоматизации. Но прежде нужны какие то знания и опыт. Я забыл когда последний раз открывал отладчик - вы не сможете на должном уровне листаль код как я, на это нужны десятилетия. Вы врядле можите просто листать код какого то криптора и свернуть его, у вас во первых нет инструмента

Bronco странный, тут конечно же не васм, где можно взять человека на анализ, но всё равно у человека должна не прекращаться логика.


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

Создано: 19 июня 2018 07:22 New!
Цитата · Личное сообщение · #26

У меня только один вопрос: зачем? Зачем такая странная форма выпуска этой штуки, зачем так мало архитектур, зачем эмулировать х86? Есть старый добрый TRACE32, который знает больше архитектур, чем человек способен запомнить, и эмулирует и трассирует и скрипты поддерживает и годится для программ, написанных не тобой и наконец можно достать полнофункциональный дистрибутив и ломается он левой пяткой. А что до х86, то для него инструментарий существует богатейший. Поэтому зачем?

| Сообщение посчитали полезным: SDK, plutos



Ранг: 540.1 (!)
Статус: Участник
_Вечный_Студент_

Создано: 19 июня 2018 07:57 New!
Цитата · Личное сообщение · #27

difexacaw пишет:
вы не сможете на должном уровне листаль код как я


Понятно, что это просто опечатка, но звучит смешно: так в советских фильмах разговаривали фашисты.

Sorry about OFFTOP!


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

Создано: 19 июня 2018 09:45 · Поправил: hors New!
Цитата · Личное сообщение · #28

Bronco пишет:
если шара бряки ставить?


Есть два способа.

Быстрый по производительности:

1) Анализируется код.
2) Выбирается место где ставить брекпойнт.
3) Останавливается эмулятор(если он ещё не был остановлен), запоминается адрес остановки.
4) Запускается uc_emu_start с параметрами откуда стартуем(адрес с пункта номер 3), когда останавливаемся(наш брекпойнт)

Медленный, но более гибкий.

Ставим хук на всё адресное пространство, останавливаемся на каждой инструкции и сравниваем адреса.


f13nd пишет:
У меня только один вопрос: зачем? Зачем такая странная форма выпуска этой штуки, зачем так мало архитектур, зачем эмулировать х86? Есть старый добрый TRACE32, который знает больше архитектур, чем человек способен запомнить, и эмулирует и трассирует и скрипты поддерживает и годится для программ, написанных не тобой и наконец можно достать полнофункциональный дистрибутив и ломается он левой пяткой. А что до х86, то для него инструментарий существует богатейший. Поэтому зачем?


Очевидно затем, чтобы выявлять на этом форуме психически неурaвновешанных людей, которые свои личные комплексы сублимируют в агрессивное навязывание своего мнения. Например в теме про Unicorn рассказывают про trace32.

| Сообщение посчитали полезным: Bronco



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

Создано: 19 июня 2018 10:13 New!
Цитата · Личное сообщение · #29

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


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

Создано: 19 июня 2018 10:15 New!
Цитата · Личное сообщение · #30

hors вы f13nd не так поняли
Он хотел сказать -Кому это надо?Никому не надо! Кому это нужно? Никому не нужно!
А потому что 90% посетителей форума незнают как получить пользу от инструмента которым неумеют пользоваться.
Нужна информация по работе с инструментом на примерах тогда его не будут сравнивать с другим инструментарием с которым уже приходилось успешно работать
. 1 . 2 . 3 . 4 . >>
 eXeL@B —› Софт, инструменты —› Unicorn - The ultimate CPU emulator

Оригинальный DVD-ROM: eXeL@B DVD !

Вы находитесь на форуме сайта EXELAB.RU
Проект ReactOS