Unicorn - The ultimate CPU emulator

Сейчас на форуме: bartolomeo, -Sanchez-, morgot, sashalogout (+5 невидимых)

. 1 . 2 . 3 . 4 . 5 . >>

Посл.ответ	Сообщение
mak Ранг: 673.3 (! !), 400thx Активность: 0.4↘0.31 Статус: Участник CyberMonk	Создано: 19 октября 2017 13:52 · Поправил: mak · Личное сообщение · #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-rc4 (30.06.2020) - --> Link <-- Code: Version 1.0.2-rc4 This version fixes some issues and improves over v1.0.2-rc3. No longer require Python to build Fix recursive UC_HOOK_MEM callbacks for cross pages access Remove UC_ERR_TIMEOUT, so timeout on uc_emu_start() is not considered error Added UC_QUERY_TIMEOUT to query exit reason Fix UAF when deleting hook while in hook callback Ensure that hooks are unaffected by a request to stop emulation. Fix block hooks being called twice after an early exit from execution. Fix binding install on python2 (MacOS) X86: Support read/write STn registers Support read/write X64 base regs ARM64: Support some new registers Сборка - следуем указанию в --> Link <-- Code: MINGW64 /n $ cd msys64/unicorn @PC MINGW64 /n/msys64/unicorn $ ./make.sh cross-win64 cd qemu && \ ./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 ----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube \| Сообщение посчитали полезным: plutos, Isaev

hors Ранг: 136.0 (ветеран), 360thx Активность: 0.27↘0.14 Статус: Участник Qt Developer	Создано: 19 октября 2017 17:23 · Личное сообщение · #2 Не трогайте реестр. Здесь необходимо просто отредактировать unicorn/windows_export.bat ----- http://ntinfo.biz \| Сообщение посчитали полезным: Bronco
DrVB_5_6 Ранг: 58.3 (постоянный), 50thx Активность: 0.04↗0.08 Статус: Участник	Создано: 19 октября 2017 21:07 · Личное сообщение · #3 А нельзя картинки поменьше сделать? А то даже с монитора на соседнюю стенку залазят!!!
Bronco Ранг: 312.0 (мудрец), 349thx Активность: 0.46↗0.65 Статус: Участник Advisor	Создано: 19 октября 2017 22:49 · Поправил: Bronco · Личное сообщение · #4 просмотрел хидер с примерами, интересовали мем_рид_врайт для х64, вывод: код в дифайнах зависим от базового адреса в тех же дифайнах. на практике любой адрес для мапа и записи должен быть округлён, как при выделении страницы, с адреса инстр ус_мем_врайт егорит, хотя страница замаплена по размеру. выделенный байт код из страницы, пишет в начало страницы, новый рип не релочат, в итоге указатель "сломан" и с памяти не читает. из хуков полезен по ходу только комби UC_HOOK_MEM_INVALID, как раз для "ломанных указателей" независимые куски кода эмулит на ура. ----- Чтобы юзер в нэте не делал,его всё равно жалко..
mak Ранг: 673.3 (! !), 400thx Активность: 0.4↘0.31 Статус: Участник CyberMonk	Создано: 20 октября 2017 13:18 · Поправил: mak · Личное сообщение · #5 в Visual Studio 2017 собралось отлично, все либы и длл, моя ошибка была в том, что хидеры не обновились под 2017, после повторного апдейта для 141xp не было ни одной ошибки. Теперь осталось проверить совместимость со старым проектом и актуального мастера и потом проверить указатели ----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube
Bronco Ранг: 312.0 (мудрец), 349thx Активность: 0.46↗0.65 Статус: Участник Advisor	Создано: 21 октября 2017 18:51 · Поправил: Bronco · Личное сообщение · #6 mak пишет: и потом проверить указатели упс...одно горе на двоих.. хз как ты собираешь буфер, для записи байткода перед эмулем, но со списком инструкций, пока лучшим решением брать для uc_mem_map базу образа, и к ебеням весь размер образа. А при сборке буффера перехватывать инстр зависимые от RIP, и пересчитывать дистанцию в байткоде инструкции. Code: temp = ListEmul->first; uint64_t assembly_size = 0; while (temp != NULL) { cs_x86 x86temp = &(temp->instruction->detail->x86); if (x86temp->operands[0].mem.base == X86_REG_RIP \|\| x86temp->operands[1].mem.base == X86_REG_RIP) { uint32_t disp = DecodeRipForAddr(false, temp) - TEXT_ADDRESS - temp->instruction->size - assembly_size; int* pos = temp->instruction->size - 5; for (int i = 0; i < temp->instruction->size; i++) { if (i > pos) { temp->instruction->bytes[i] = disp; disp = disp >> 8; } } } assembly_size += temp->instruction->size; temp = temp->next; } в итоге указатели под мап валидные, но читать_писать этот "хер с рогом" не желает. отписали исузу, пока игнор. Bronco пишет: читать_писать этот "хер с рогом" не желает он то хочет , но с uc_mem_map может только мапить пустые страницы.. Code: BYTE ptrtest = new* BYTE[Module::GetMainModuleSize()]; DbgMemRead(Module::GetMainModuleBase(), (void)ptrtest, Module::GetMainModuleSize()); err = uc_mem_map_ptr(uc, (uint64_t)Module::GetMainModuleBase(), (size_t)Module::GetMainModuleSize(),UC_PROT_ALL, (void)ptrtest); if (err != UC_ERR_OK) { _plugin_logprintf("[" PLUGIN_NAME PLUGIN_BIT"] Error: uc_mem_map_ptr, %s\n", uc_strerror(err)); return; } в итоге всё читаем, куда угодно пишем: Code: - UC_MEM_WRITE in address: 0x8fb7f8; size = 8; value = 0x14c35e33e - UC_MEM_READ from address: 0x14931ab00; size = 4; value = 0xfffd19f2 - UC_MEM_READ from address: 0x8fb7f8; size = 8; value = 0x14c35e33e - UC_MEM_WRITE in address: 0x8fb7f8; size = 8; value = 0x14c32fd30 - UC_MEM_READ from address: 0x8fb7f8; size = 8; value = 0x14c32fd30 - UC_MEM_READ from address: 0x14168b588; size = 4; value = 0x18 - UC_MEM_WRITE in address: 0x8fb7f8; size = 8; value = 0x14c32fd30 - UC_MEM_READ from address: 0x147c51f51; size = 4; value = 0x66972e - UC_MEM_READ from address: 0x8fb7f8; size = 8; value = 0x14c32fd30 - UC_MEM_WRITE in address: 0x8fb7f8; size = 8; value = 0x14c99945e - UC_MEM_READ from address: 0x8fb7f8; size = 8; value = 0x14c99945e ----- Чтобы юзер в нэте не делал,его всё равно жалко..
mak Ранг: 673.3 (! !), 400thx Активность: 0.4↘0.31 Статус: Участник CyberMonk	Создано: 22 октября 2017 13:04 · Поправил: mak · Личное сообщение · #7 Господа специалисты С++ выручайте! Оригинальный релиз апрельский от разработчиков, функция uc_open, начало Code: PUSH RBP MOV RBP, RSP SUB RSP, 30 MOV DWORD PTR SS:[RBP + 10], ECX MOV DWORD PTR SS:[RBP + 18], EDX MOV QWORD PTR SS:[RBP + 20], R8 CMP DWORD PTR SS:[RBP + 10], 7 JA unicorn.6B6B9802 То что выдаёт мне студия 2017 Code: MOV QWORD PTR SS:[RSP + 10], RSI MOV QWORD PTR SS:[RSP + 18], RDI PUSH R14 SUB RSP, 20 MOV R14, R8 MOV EDI, EDX MOV ESI, ECX CMP ECX, 8 JGE unicorn.7FFE3ADE9498 Вопрос - как разработчики собирают подобный код с RBP фреймом?! Судя по этому документу /Oy (Frame-Pointer Omission) --> Link <-- я не могу напрямую в Студии использовать RBP фрейм?! Я уже испытал все возможные варианты, которые пришли в голову, включая без оптимизации. Вот начало функции в msys64 Code: PUSH RBP PUSH RDI PUSH RSI PUSH RBX SUB RSP, 28 CMP ECX, 7 MOV ESI, ECX MOV EDI, EDX MOV RBP, R8 JA unicorn.6B08B8D1 MOV EDX, 7A0 MOV ECX, 1 В обоих случаях у меня ломается стэк при вызове любой процедуры уникорна, конечно я могу перед каждым call сделать пролог и потом епилог, но это не нормально, учитывая, что версия от разработчиков работает так как должна. Какие опции они используют? Актуальный мастер - --> Link <-- ----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube
reversecode Ранг: 1053.6 (!!!!), 1078thx Активность: 1.06↘0.81 Статус: Участник	Создано: 22 октября 2017 13:22 · Личное сообщение · #8 mak пишет: Вопрос - как разработчики собирают подобный код с RBP фреймом?! достаточно в фаре открыть длл по ф3 и все становится понятно
plutos Ранг: 622.6 (!), 521thx Активность: 0.33↗0.89 Статус: Участник _Вечный_Студент_	Создано: 22 октября 2017 23:31 · Личное сообщение · #9 reversecode пишет: достаточно в фаре открыть длл по ф3 и все становится понятно Пожалуйста, можно немного подробнее? ----- Give me a HANDLE and I will move the Earth.
reversecode Ранг: 1053.6 (!!!!), 1078thx Активность: 1.06↘0.81 Статус: Участник	Создано: 22 октября 2017 23:40 · Личное сообщение · #10 очевидно что unicorn.dll разработчики собирают через mingw такой пролог только гцц генерит или о чем вопрос ? \| Сообщение посчитали полезным: plutos
Bronco Ранг: 312.0 (мудрец), 349thx Активность: 0.46↗0.65 Статус: Участник Advisor	Создано: 23 октября 2017 00:06 · Поправил: Bronco · Личное сообщение · #11 reversecode пишет: очевидно что unicorn.dll разработчики собирают через mingw MinGW(GCC: (Rev2, Built by MSYS2 project) 6.2.0) хз как они собирают такую большую длл в релизных билдах, с мастера в студии линкуются очень не большие либы, как статик так и динамик.+ к к этому, слинкованное егорит все проекты. ----- Чтобы юзер в нэте не делал,его всё равно жалко.. \| Сообщение посчитали полезным: plutos
shellstorm Ранг: -0.7 (гость), 170thx Активность: 0.54↘0 Статус: Участник	Создано: 23 октября 2017 01:05 · Личное сообщение · #12 Bronco пишет: хз как они собирают такую большую длл в релизных билдах, с мастера в студии линкуются очень не большие либы, как статик так и динамик.+ к к этому, слинкованное егорит все проекты. Размер зависит от количества поддерживаемых камней, если x86-x64 онли, без всяких arm и mips оно собственно маленьким и получается, плюс студийный компилятор не пихает шлак с msys.
mak Ранг: 673.3 (! !), 400thx Активность: 0.4↘0.31 Статус: Участник CyberMonk	Создано: 23 октября 2017 12:32 · Личное сообщение · #13 Это говорит о том, как бывает случайно тут и у многих reversecode даже не прочитал пост) Если бы он его прочитал, то такого ответа не было бы. Тут даже ответить то нечего ----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube
reversecode Ранг: 1053.6 (!!!!), 1078thx Активность: 1.06↘0.81 Статус: Участник	Создано: 23 октября 2017 12:36 · Личное сообщение · #14 нука нука что там reversecode не прочитал ? уточните может у него еще туз в рукаве
Bronco Ранг: 312.0 (мудрец), 349thx Активность: 0.46↗0.65 Статус: Участник Advisor	Создано: 24 октября 2017 07:11 · Личное сообщение · #15 shellstorm пишет: оно собственно маленьким и получается так это слинкованное егорит все проекты. , возможно из-за экспорта. ----- Чтобы юзер в нэте не делал,его всё равно жалко..
shellstorm Ранг: -0.7 (гость), 170thx Активность: 0.54↘0 Статус: Участник	Создано: 24 октября 2017 09:10 · Личное сообщение · #16 Bronco пишет: так это слинкованное егорит все проекты. , возможно из-за экспорта. Хз, линковал со статической либой собранной TDM GCC (msys днище для совсем уж специфических вещей) и собирал студийным компилем тоже со статик линковкой, проблем не было, если не считать баги реализации.
Bronco Ранг: 312.0 (мудрец), 349thx Активность: 0.46↗0.65 Статус: Участник Advisor	Создано: 24 октября 2017 21:15 · Поправил: Bronco · Личное сообщение · #17 shellstorm пишет: линковал со статической либой собранной TDM GCC я за мастер сорцы. в апрельском релизе в хидерах не было "platform.h". а он тянет за собой в инклудах <winsock2.h> у меня пятнашка , в моём проекте, ещё до сборки начинает егорит на свой же файл. если закоментить инклуд, то слинкованая в студии статик либа с мастер сорцов, подходит. а вот с динамической не всё так гуд, по ходу всё таки экспорт ломается. "Порядковый номер 10694 не найден в библиотеке DLL.." ===добавил. упс... закоментил "platform.h" в хидерах "unicorn.h" и "x86.h", переименовал "unicorn_static.lib" в "unicorn.lib", подкинул собранную в пятнашке unicorn.dll на 5 мег завелось_работает.. ----- Чтобы юзер в нэте не делал,его всё равно жалко..
Bronco Ранг: 312.0 (мудрец), 349thx Активность: 0.46↗0.65 Статус: Участник Advisor	Создано: 18 июня 2018 23:59 · Личное сообщение · #18 при записи трассы в бинарь, по опкодам или адресам инстр, на хуках что то можно фильтровать, но если код трассы лапша, то большие участки, которые повторяются хз как пропускать. кто юзал сабж как трассер, по типу pin или dinamorio, плезир отпишитесь, если шара бряки ставить? пока по таймингам такое: Code: 1.Unicorn - Total Time: 00:00:01.609 - 1.Write instr->928 \| 2.Instr size->-0xd8d 2.x64dbg //странно но с вкл медиа плеером трассирует в 10 раз быстрее, и всё равно рог шустрее...)) - Total Time: 00:00:05.781 - 1.Write instr->887 \| 2.Instr size->-0xd54 ----- Чтобы юзер в нэте не делал,его всё равно жалко..
difexacaw Ранг: 337.5 (мудрец), 348thx Активность: 2.11↗2.42 Статус: Участник	Создано: 19 июня 2018 01:06 · Личное сообщение · #19 Bronco 1к инструкций за полторы секунды - это не тайминг, это ппц. Тем более что от сырой трассы толку нет, она должна быть связана в cfg/dfg. Почему оно столь медленное ? ----- vx
Bronco Ранг: 312.0 (мудрец), 349thx Активность: 0.46↗0.65 Статус: Участник Advisor	Создано: 19 июня 2018 01:50 · Личное сообщение · #20 difexacaw пишет: Почему оно столь медленное ? млять, опять ты, перечитай последнее предложение ----- Чтобы юзер в нэте не делал,его всё равно жалко..
difexacaw Ранг: 337.5 (мудрец), 348thx Активность: 2.11↗2.42 Статус: Участник	Создано: 19 июня 2018 02:21 · Поправил: difexacaw · Личное сообщение · #21 Bronco По вашей ссылке ответ по декодеру, который никакого не имеет отношения к профайлу. 1к инструкций/сек таких тормозов я за всё время что в теме никогда не видел. Даже тормозное определение длины системным путём(TF) обеспечивает на порядки выше профайл(1/3М если верно помню). Что вы там курите ?) А учитывая что тема про эмулятор, то такие просадки профайла вообще уму не постижимы.. На счёт капстонов и прочего говна я же говорил - лишь один есть годный декодер это ксед. Остальное всё - мусор. Ваш ответ в такой манере.. вы должны знать что ваше мнение значения не имеет. ----- vx
shellstorm Ранг: -0.7 (гость), 170thx Активность: 0.54↘0 Статус: Участник	Создано: 19 июня 2018 02:36 · Личное сообщение · #22 difexacaw пишет: Что вы там курите ? повторяй: я буду внимательно читать посты. есть там графы и разрывы трассы, и код загажен протами, которые вдобавок ломают граф, для построения доминатора, анализа связей, etc или упрощения временных переменных на стеке, неплохо сначала склеить трассу, желательно за малое количество человекочасов, следовательно по пути наименьшего сопротивления, а не отливать код в граните, тем более для x64 такого кода на шару нет, есть только варианты в которых инструменты начинаются с примерно 10K тяжелых плюсовых строк или вариант проще, собрать на коленке инструмент проще, тем более когда это просто хобби, а не работа или багхантинг.
difexacaw Ранг: 337.5 (мудрец), 348thx Активность: 2.11↗2.42 Статус: Участник	Создано: 19 июня 2018 02:51 · Поправил: difexacaw · Личное сообщение · #23 shellstorm Разницы между модами 86-64 нет, незначительная которая резолвится общим декодером. Обкатывать новые алгоритмы проще на 86, это во первых простая отладка и набор инструкций. Фактически разница лишь в RIP-адресации. Это всё столь не существенно, что не вижу смысла даже это обсуждать. Графы - нет смысла строить какие то трассы без их свёртки. А имплементация по числу строк, вы удивитесь какого малого размера может быть встраиваемый визор. Просто это нэйтивное обычно, а не собирается какой то поганью. В противном случае и получается такое глючное - 1к/сек это походу прикол какой то, это вообще невозможно так косячно реализовать. Можно допустить что время уходит на какой то анализ, но в данном случае его нет. ----- vx
shellstorm Ранг: -0.7 (гость), 170thx Активность: 0.54↘0 Статус: Участник	Создано: 19 июня 2018 03:20 · Личное сообщение · #24 difexacaw пишет: Обкатывать новые алгоритмы проще на 86, это во первых простая отладка и набор инструкций для x86 старого полно, в крайнем случае можно на коленке разобрать в IDA, даже vmprot, а проблема как раз с x64 нет нормальных инструментов, IDA и та в этом случае не помощник, анализа можно дожидаться очень долго из за пары vm, какой нэйтив, он в IDA отбивается в компилируемые исходники. на счет времени не знаю почему так долго, хотя qemu никогда не отличался скоростью, но вариант с рекомпиляторами не подходит Bronco из-за сопутствующей инфраструктуры, слишком много кода писать. остальное всё это пиар "мотора" теоретиком, нечего даже обсуждать, тем более здесь никто не требует каких-то феноменальных скоростей.
difexacaw Ранг: 337.5 (мудрец), 348thx Активность: 2.11↗2.42 Статус: Участник	Создано: 19 июня 2018 03:50 · Личное сообщение · #25 shellstorm Инструменты - они нужны для автоматизации. Но прежде нужны какие то знания и опыт. Я забыл когда последний раз открывал отладчик - вы не сможете на должном уровне листаль код как я, на это нужны десятилетия. Вы врядле можите просто листать код какого то криптора и свернуть его, у вас во первых нет инструмента Bronco странный, тут конечно же не васм, где можно взять человека на анализ, но всё равно у человека должна не прекращаться логика. ----- vx
f13nd Ранг: 271.2 (наставник), 331thx Активность: 0.32↗1.49 Статус: Участник	Создано: 19 июня 2018 07:22 · Личное сообщение · #26 У меня только один вопрос: зачем? Зачем такая странная форма выпуска этой штуки, зачем так мало архитектур, зачем эмулировать х86? Есть старый добрый TRACE32, который знает больше архитектур, чем человек способен запомнить, и эмулирует и трассирует и скрипты поддерживает и годится для программ, написанных не тобой и наконец можно достать полнофункциональный дистрибутив и ломается он левой пяткой. А что до х86, то для него инструментарий существует богатейший. Поэтому зачем? ----- 2 оттенка серого \| Сообщение посчитали полезным: SDK, plutos
plutos Ранг: 622.6 (!), 521thx Активность: 0.33↗0.89 Статус: Участник _Вечный_Студент_	Создано: 19 июня 2018 07:57 · Личное сообщение · #27 difexacaw пишет: вы не сможете на должном уровне листаль код как я Понятно, что это просто опечатка, но звучит смешно: так в советских фильмах разговаривали фашисты. Sorry about OFFTOP! ----- Give me a HANDLE and I will move the Earth.
hors Ранг: 136.0 (ветеран), 360thx Активность: 0.27↘0.14 Статус: Участник Qt Developer	Создано: 19 июня 2018 09:45 · Поправил: hors · Личное сообщение · #28 Bronco пишет: если шара бряки ставить? Есть два способа. Быстрый по производительности: 1) Анализируется код. 2) Выбирается место где ставить брекпойнт. 3) Останавливается эмулятор(если он ещё не был остановлен), запоминается адрес остановки. 4) Запускается uc_emu_start с параметрами откуда стартуем(адрес с пункта номер 3), когда останавливаемся(наш брекпойнт) Медленный, но более гибкий. Ставим хук на всё адресное пространство, останавливаемся на каждой инструкции и сравниваем адреса. f13nd пишет: У меня только один вопрос: зачем? Зачем такая странная форма выпуска этой штуки, зачем так мало архитектур, зачем эмулировать х86? Есть старый добрый TRACE32, который знает больше архитектур, чем человек способен запомнить, и эмулирует и трассирует и скрипты поддерживает и годится для программ, написанных не тобой и наконец можно достать полнофункциональный дистрибутив и ломается он левой пяткой. А что до х86, то для него инструментарий существует богатейший. Поэтому зачем? Очевидно затем, чтобы выявлять на этом форуме психически неурaвновешанных людей, которые свои личные комплексы сублимируют в агрессивное навязывание своего мнения. Например в теме про Unicorn рассказывают про trace32. ----- http://ntinfo.biz \| Сообщение посчитали полезным: Bronco
Bronco Ранг: 312.0 (мудрец), 349thx Активность: 0.46↗0.65 Статус: Участник Advisor	Создано: 19 июня 2018 10:13 · Личное сообщение · #29 кто о чём, а вшивый о блохах.. на вопрос, по сути о фильтрации трассы, а именно с ним поднял топ, только один ответ, и то приватный. почему сабж? да было интересно, может ли он быть трассером. поэтому и тайминги скинул. может у кого то быстрее, тогда и предмет дискуссии будет. да, пин или рио на порядок быстрее, но с любого места не стартуют, да и выхлоп идёт не в бинарь. с фильтрами у них то же борода, фейсов для этого нет, лезть под капот пока не охота. ----- Чтобы юзер в нэте не делал,его всё равно жалко..
SDK Ранг: 54.0 (постоянный), 49thx Активность: 0.72↗1.1 Статус: Участник	Создано: 19 июня 2018 10:15 · Личное сообщение · #30 hors вы f13nd не так поняли Он хотел сказать -Кому это надо?Никому не надо! Кому это нужно? Никому не нужно! А потому что 90% посетителей форума незнают как получить пользу от инструмента которым неумеют пользоваться. Нужна информация по работе с инструментом на примерах тогда его не будут сравнивать с другим инструментарием с которым уже приходилось успешно работать

. 1 . 2 . 3 . 4 . 5 . >>

Для печати