Сейчас на форуме: (+5 невидимых) |
eXeL@B —› Протекторы —› Crack SecuROM & DENUVO |
<< . 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9 . 10 ... 52 . 53 . >> |
Посл.ответ | Сообщение |
Ранг: 419.0 (мудрец), 647thx Активность: 0.46↗0.51 Статус: Участник "Тибериумный реверсинг" |
Создано: 28 марта 2012 14:24 · Поправил: ELF_7719116 · Личное сообщение · #1 CODEX UNVIRTUALIZE DENUVO/VMProtect Code:
************** В связи со стремительно развивающимися событиями, данный топик будет реформирован. Перечень тем, на которые ведется обсуждение: ░▒▓▓-SecuROM 7/8 common (VM research; disk-check bypass attack; find OEP & dumping; cumulative attack...) ░▒▓▓-- SPR I (profiles; updates) ░▒▓▓-Requests for generation SecuROM PA Unlock code (SecuROM PA Online-activation) WOW! Only on EXELAB.RU ░▒▓▓ ░▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ SPR I - Fight against the virtual machines (VM) of all SecuROM 7-8 versions (Подробности в 80_PA - SecuROM (PA) Online-Activation keygen! Holy shit! [/url] the list of programs (games), which can now be activated using 80_PA: https://pastebin.com/EiMbV3YD or >>>>>>>> (!) Send me more games with SecuROM PA (!) >>>>>>>>>>>> Denuvo Profiler (DProfiler) ------------ 1.04.2012 Собственно я не сказал самого главного. SecuRom_Profiler 7 v1.0(SPR I) - часть большого зеленого пирога, под названием "ТИБЕРИУМНЫЙ РЕВЕРСИНГ" (статья опубликована в 159 номере ][. А позже, ещё одна итоговая статья - 199 ][), включает в себя собственно статью в журнале, ПОЛНУЮ техническую статью, материалы по SecuROM 7.33.0017, исходники X-кода и видео. Технический вариант статьи с приложениями можно брать отсюда: ▒ ▒ ▒ ▒ ▒ Имеет косвенное отношение к статье: ▒ Хроники битвы при DENUVO 19.04.19 https://xakep.ru/2019/04/19/denuvo/ Message for the companies(etc) using this protection: we can buy SecuROM/DENUVO SDK & sources. Сontact me according to the personal message. Сonfidentiality is guaranteed!!! The bought files will be used for private research! ░░░░░░░░░░ См. также: ▓▓ 615d_22.09.2013_EXELAB.rU.tgz - Sony DADC SecuROM vulnerability.zip c177_01.02.2017_EXELAB.rU.tgz - PATENT DENUVO.pdf (притащил v00doo) ▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓ 80_PA new 2.0 hotfix (!!!). Official links (mirrors): https://mega.nz/#!L6gGBYBK!Y9X-6LFBdow6a1_IBlDFbrS6PBF4RRz_n9kuSGiI0UM (или ▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓ DENUVO Leak content обращайтесь в личку - скину. ▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓▒▓ Denuvo Profiler (DProfiler) - test version 0.3 "INSPIRE" https://mega.nz/#!DLwExKya!kCyFXw1roY3MkFaTO56LJAd-amc2yXWVerV2ic38bgs (или | Сообщение посчитали полезным: yanus0, obfuskator, Vovan666, MasterSoft, slick, hlmadip, ClockMan, Nightshade, Dart Raiden, Bronco, BAHEK, SReg, [Nomad], DimitarSerg, verdizela, yagello, OnLyOnE, FrenFolio, daFix, VodoleY, gena-m, m0bscene, Gideon Vi, ff0h, zeppe1in, antipod, huckfuck, kioresk, aRiX, 4kusNick, Ara, d0wn, Smon, audiofeel, zNob, cypherpunk, zzzombie1989, MarcElBichon, v00doo, DenCoder, nick7, Haoose-GP, arnix, Qbik, serilo, s2003r, DICI BF, Kindly, PavelDAS, HandMill, VanHelsing, random, TrueLies, warezhunter_, denfil777, alx30721, omeh2003, asm-jaime, WildGoblin, mushr00m, Flippy1801, KOTwasya, r3n5m388, chegevara, Groul, dnv83, kassane, ==DJ==[ZLO], red0x, HAOSov, rootkid, DirtyHarry, MacTep, kurorolucifer, s0cpy, aire1, ReloadUGunz, tRuNKator, Cherbet, RmK-FreE, Pringell, IHateInventNicknames, go2crck, mak, Dimosz, Creckerhack, zd0x, Mustafa_Dev007, UnnyBolt, Isaev, Astap1516, Voices_of_the_BULG, EHS4N, SnakeByte, KOCMOC42, anarh1st47 |
Ранг: 281.8 (наставник), 272thx Активность: 0.25↘0.01 Статус: Участник Destroyer of protectors |
Создано: 20 ноября 2015 21:35 · Личное сообщение · #2 vden пишет: Могу ошибаться, но, кажется, вмпрот даже не снимали. В кряке codex, похоже, просто эмулируют UPLAY APIs. в большинстве случаев его и снимать не надо, зачем? афтары как правило наркоманы, намазав вм на функцию x, они почему-то наивно полагают, что все вложенные функции тоже будут защищены. Code:
ну и смысл тогда анпачить, но если вдруг всё критичное в вм...то и это не проблема ведь. P.S.: сразу вспомнил фейл компании 1С, которые накрыли старфорсом библу движка, которую можно было слить чистую, этой же версии, с офф. сайта этого же движка. | Сообщение посчитали полезным: hello |
|
Создано: 01 декабря 2015 03:27 · Поправил: Haoose-GP · Личное сообщение · #3 |
|
Создано: 01 декабря 2015 11:49 · Личное сообщение · #4 |
|
Создано: 01 декабря 2015 11:56 · Личное сообщение · #5 |
|
Создано: 01 декабря 2015 13:02 · Личное сообщение · #6 Haoose-GP пишет: Игра вышла полчаса назад. упс.... всё-таки разродились долго делали, хотя.... насрать... я и второго в своё время, процентов на 40 прошёл, потом тупо устал...крошить_освобождать_и_перемещаться... Сука, здоровая локация была. Тут поди ещё больше, в общем нах нах нах... ----- Чтобы юзер в нэте не делал,его всё равно жалко.. |
|
Создано: 01 декабря 2015 18:15 · Личное сообщение · #7 |
Ранг: 419.0 (мудрец), 647thx Активность: 0.46↗0.51 Статус: Участник "Тибериумный реверсинг" |
Создано: 01 декабря 2015 18:28 · Личное сообщение · #8 |
|
Создано: 01 декабря 2015 20:08 · Поправил: Haoose-GP · Личное сообщение · #9 ELF_7719116 На русторке есть стим-рип раздача папкой, скачайте что нужно ) Я игру не качал пока. Ну а под денувой - наверно ж стим ) Хотя Список файлов внутри: bink2w64.dll crashrpt_lang.ini cudart64_55.dll cufft64_55.dll d3dx11_43.dll fmod_studio_F.dll gfsdk_waveworks.win64.dll jc3AudioDSP_MultibandCompressor_SSE_F.dll JustCause3.exe ProfileContext_F.dll sdkencryptedappticket64.dll Shaders_F.shader_bundle steam_api64.dll steam_appid.txt patch_win64\delta_filelist_install.archive | Сообщение посчитали полезным: ELF_7719116 |
Ранг: 419.0 (мудрец), 647thx Активность: 0.46↗0.51 Статус: Участник "Тибериумный реверсинг" |
Создано: 02 декабря 2015 20:00 · Личное сообщение · #10 Just Cause™ 3 - DENUVO (VMProtect) first research report А у нас теперь немного изменена логика работы VM. Естественно из всего смотрим, как теперь декодируются примитивы... А ТУТ ПАЦАНЫ РЕАЛЬНО УДИВЛЯЮТ! Раньше в первых билдах были таблицы типа "Хранилищ №1.5" в секуроме. Расшифровав их можно спокойно получить всю раскладку примитивов...epic win! в Just Cause 3 теперь таблицы убрали и ... фокус, фокус .. стали пихать пошифрованные delta-смещения прямо в ленту pcode. Пошифованное delta-смещение теперь отсчитывается от послденего RVA примитива, на который прыгнула VM: Code:
Если я всё правильно рассчитал, то (сами доагадетесь что за действия теперь можно сделать с лентой) вместо того, чтобы осложнить unvirtualization, они упростили эту задачу ... По мелочи: исчезла вмпротная дебильная обфускация JNE/JE - примитивы стали гораздо чище и читаеме. В немного почищенном виде главные иснтрукции в примитивах выглядят так: Code:
Code:
| Сообщение посчитали полезным: mak, Haoose-GP |
|
Создано: 02 декабря 2015 22:51 · Личное сообщение · #11 |
Ранг: 419.0 (мудрец), 647thx Активность: 0.46↗0.51 Статус: Участник "Тибериумный реверсинг" |
Создано: 03 декабря 2015 17:27 · Личное сообщение · #12 |
|
Создано: 03 декабря 2015 18:30 · Поправил: Bronco · Личное сообщение · #13 |
|
Создано: 04 декабря 2015 07:16 · Личное сообщение · #14 ELF_7719116 пишет: Гарно можна статично розкрутити стрічку p-code Чето я не вижу послаблений для себя. До этого я мог статично проанализировать точку входа в вм, найти таблицу обработчиков примитивов, проанализировать каждый и сопоставить с известными, определить тип и ид, размер примитива в байт-коде и, собственно, расшифровщики байт-кода. А дальше работать только с байт-кодом, опираясь на собранные данные. Теперь же надо проанализировать точку входа, определить ленту байт-кода, расшифровщик дельты, перейти на следующий обработчик, проанализировать его, перейти к следующему и т.д.. Т.е. по сути все тоже самое только подход не шаговый, а комплексный. так и где упростилось то? |
|
Создано: 04 декабря 2015 11:30 · Поправил: vden · Личное сообщение · #15 ELF_7719116 пишет: стали пихать пошифрованные delta-смещения прямо в ленту pcode плавно движется к структуре starforce, остается еще каждый хэндлер инлайнить Убрали dispatch-table, видимо, потому, что ее легко перехватывали и снимали лог состояний вм Даже китайский отладчик, кажется, был на этом построен. Интересно глянуть, что там нового в vmprotect 3 |
|
Создано: 04 декабря 2015 13:16 · Личное сообщение · #16 |
|
Создано: 04 декабря 2015 14:47 · Личное сообщение · #17 |
Ранг: 419.0 (мудрец), 647thx Активность: 0.46↗0.51 Статус: Участник "Тибериумный реверсинг" |
Создано: 04 декабря 2015 18:29 · Личное сообщение · #18 int пишет: Что-то очень похоже на новый VMProtect от VMPSoft. Денуво просто сотрудничает с ними? Я уже на это давно указываю! Причем VMPSoft отказывается комментировать данные факты. ClockMan пишет: Моё предположение что кто то третий продал(подал) идею новой вм Тут определенно есть связь между VMPSoft и DENUVO. Я не верю в такие случайности - практически байт в байт повторяется код (логика вообще одинакова). vden пишет: Убрали dispatch-table, видимо, потому, что ее легко перехватывали и снимали лог состояний вм Psalmopoeus Pulcher пишет: Теперь же надо проанализировать точку входа, определить ленту байт-кода, расшифровщик дельты, перейти на следующий обработчик, проанализировать его, перейти к следующему Друзья! Вообще, я уверен, что DENUVO кто-то (наверняка из окружения Вашего дерматолога) пишет из VMPSoft. Ну не может быть такого, что те же авторы секурома второй раз наступили на одни и те же грабли с dispatch-table (как это было в секуром версии 7). В 8 секуроме они тоже отказались от dispatch-table, но там РЕАЛЬНО ЭТО МНОГОКРАТНО УПРОСТИЛО ЗАДАЧУ ТОЧНОГО ДАМПИНГА примитивов VM. Был т.н. коллектор, под входным примитивом, куда стекалось управление, после каждой выполненной инструкции и безусловного прыжка в любом примитиве. Т.е. step-by-step мы точно собирали весь примитив + обфускации не было вообще. Насчет денувки - разработчики сами недвусмысленно указывают, что всё идет к ленте. Насчет сложности взлома - тут просто нужен коллективный разум, а не так, чтобы один человек всё писал и анализировал. Если уцепиться сейчас за денувий хвост, то вм в любом случае раскрутить более чем реально. Разработчики денуво просто работают на лохов-покупателей, которые верят в то, что игрушка не будет тормозить после навешивания этого говна. Хотя на самом деле, львиная доля тормозов и производительности уходит на вм. И теперь оно ещё больше только будет расти! Sad, but true. Кстати, один я заметил, что все примитивы начинаются с декремента регистра-указателя на ленту (и jmp вверху)?! |
|
Создано: 04 декабря 2015 19:10 · Личное сообщение · #19 |
|
Создано: 04 декабря 2015 20:33 · Поправил: DenCoder · Личное сообщение · #20 ELF_7719116 пишет: Кстати, один я заметил, что все примитивы начинаются с декремента регистра-указателя на ленту (и jmp вверху)?! Бывает декремент, бывает инкремент. Бывают файлы с 2мя вм(обработчиками), у одной инкремент, у другой декремент, но обычно это уже в распакованном файле(со снятым верхним слоем). В файлах с 2мя вм есть примитив перехода на другую вм... Добавлено спустя час Наверное, ты имеешь в виду vm entry? Точка входа в вм (обработчик примитивов, как один сведущий выше человек написал). Абзацем выше я написал, подразумевая это. В обработчике с декрементом сначала декремент указателя на ленту перед тем, как взять индекс примитива, с инкрементом - сначала берётся индекс примитива, потом уже инкремент. Кстати, я заметил 2м примитивом любой ветки, по крайней мере в версиях 2.x, светится константа - ключ для "дешифровки" указателя на некоторую аллоченную область. Одно из 2х - это либо любимое число dermatolog'а, либо - ватермарк. По возможной второй причине здесь не буду светить найденный мной в своих файлах. ----- IZ.RU |
|
Создано: 04 декабря 2015 21:51 · Поправил: vden · Личное сообщение · #21 До ВМ. Секция по адресу 143142000, entry point 143143728 - просто расшифровывает кусок памяти (AES-256), протектит все секции как RWX и выполняет суб-функцию, которая уже ведет в вм. Code:
Пролог и вход в вм для этих двух функций тут Code:
|
|
Создано: 04 декабря 2015 22:37 · Поправил: DenCoder · Личное сообщение · #22 У вас что-то пока мной невиданное, нетроганное Но пока не могу помочь vden пишет: протектит все секции как RWX Это не ново для вмпрота, анпак без этого и невозможен. Но в версиях 2.x VirtualProtect вызывается из виртуализированного кода. Касательно AES - в 2.x не используется, встроенный анпакер проще, но подробно не разбирал. vden пишет: Пролог и вход в вм для этих двух функций тут И это будет 3м признаком, что это отличная от 2.x версия. Видел подобное в pdfLock.dll, где тоже вмпрот. Вот она, версия 3. x? Вход в вм в 2.x: Code:
----- IZ.RU | Сообщение посчитали полезным: ELF_7719116 |
|
Создано: 04 декабря 2015 22:43 · Поправил: vden · Личное сообщение · #23 Я думаю, AES это уже поверх вмпрота, типа сделали свой дополнительный слой, хотя могу и ошибаться. А пролог виден потому, что было наверно так func1() { пролог VMProtectBegin_XXX(); ... VMProtectEnd(); эпилог } Пока основное отличие версии 3 от версии 2 - отсутствие dispatch table. Сама таблица всегда из 256 адресов, с повторяющимися значениями. PS забавно, оказывается код каждого обработчика реально заинлайнен т.е. наверно где-то до сотни примитивов, но скопированы тысячи раз, в итоге секция кода вм = 100 Мб, до защиты игра наверно была 15-20 Мб. Добавлено спустя 17 часов 26 минут Попробовал загрузить точку входа в вм в анализатор, который я пишу для следующей версии vdisasm. Анализатор еще многого не умеет, но вот что он смог мне отследить: Состояние на момент конца первого блока (в точке JMP RDI). Я оставил только значимые выражения. Выражения в определенном внутреннем представлении в префиксной форме, т.е. сначала опкод, потом параметры. RSP ========> and(add(undef(RSP), 0xFFFFFFFFFFFFFE28:64), 0xFFFFFFFFFFFFFFF0:64) RBX ========> xor(0x145CD75A7:64, neg(bswap(add(or(shl(xor(undef([0x145CD75A3:64]:32), 0x45CD75A7:32), 0x1:8), shr(xor(undef([0x145CD75A3:64]:32), 0x45CD75A7:32), 0x1F:8)), 0x34C218C6:32)))) RBP ========> add(undef(RSP), 0xFFFFFFFFFFFFFF68:64) RSI ========> 0x145CD75A3:64 RDI ========> add(0x1495722E8:64, SignExtend(neg(bswap(add(or(shl(xor(undef([0x145CD75A3:64]:32), 0x45CD75A7:32), 0x1:8), shr(xor(undef([0x145CD75A3:64]:32), 0x45CD75A7:32), 0x1F:8)), 0x34C218C6:32))) to 64)) [add(undef(RSP), 0xFFFFFFFFFFFFFFF8:64)] ========> 0xFFFFFFFFC8B9AEB5:64 [add(undef(RSP), 0xFFFFFFFFFFFFFFF0:64)] ========> 0x1495E2024:64 [add(undef(RSP), 0xFFFFFFFFFFFFFFE8:64)] ========> undef(R9) [add(undef(RSP), 0xFFFFFFFFFFFFFFE0:64)] ========> undef(R11) [add(undef(RSP), 0xFFFFFFFFFFFFFFD8:64)] ========> undef(R12) [add(undef(RSP), 0xFFFFFFFFFFFFFFD0:64)] ========> undef(RCX) [add(undef(RSP), 0xFFFFFFFFFFFFFFC8:64)] ========> undef(RDX) [add(undef(RSP), 0xFFFFFFFFFFFFFFC0:64)] ========> undef(RBP) [add(undef(RSP), 0xFFFFFFFFFFFFFFB8:64)] ========> undef(RBX) [add(undef(RSP), 0xFFFFFFFFFFFFFFB0:64)] ========> undef(R8) [add(undef(RSP), 0xFFFFFFFFFFFFFFA8:64)] ========> undef(RSI) [add(undef(RSP), 0xFFFFFFFFFFFFFFA0:64)] ========> undef(RAX) [add(undef(RSP), 0xFFFFFFFFFFFFFF98:64)] ========> undef(RFL) [add(undef(RSP), 0xFFFFFFFFFFFFFF90:64)] ========> undef(R15) [add(undef(RSP), 0xFFFFFFFFFFFFFF88:64)] ========> undef(RDI) [add(undef(RSP), 0xFFFFFFFFFFFFFF80:64)] ========> undef(R10) [add(undef(RSP), 0xFFFFFFFFFFFFFF78:64)] ========> undef(R14) [add(undef(RSP), 0xFFFFFFFFFFFFFF70:64)] ========> undef(R13) [add(undef(RSP), 0xFFFFFFFFFFFFFF68:64)] ========> 0x0:64 Тут мы видим основные регистры и стек. Виден весь начальный контекст вм. Можно заметить, что RBP (указатель вм-стека) указывает на самое нижнее выражение, вм будет их один за другим переносить в свои регистры (VM_POP). А память вм-регистров находится ниже - от RBP до RSP. Можно посчитать размер, но в любом случае, вм может увеличивать размер своего контекста, при необходимости. Выражения RDI и RBX в виде графа, потому что текстовый вид сложно читать: Тут мы видим внизу есть MemRef - здесь чтение из памяти по адресу 0x145CD75A3. Это первый адрес байт-кода из которого читается DWORD. Далее по графу это значение попадает в XOR на константу, потом ROL 1 (который тут в виде SHL и SHR), потом плюс еще одна константа, потом меняем байты местами, потом меняем знак, расширяем со знаком до 64 бит и прибавляем к константе слева. В итоге получаем адрес следующего блока. Немного автоматизировав, посчитались следующие значения Byte-code data address for next jump: 145CD75A3 // первый адрес читаемый в байт-коде Byte-code data for next jump: 66C6063A // DWORD прочитанный из 145CD75A3 Next jump: 0x14956496E:64 Expected RBX: 0x1BA325321:64 Действительно, JMP RDI идет по адресу 0x14956496E и RBX = 0x1BA325321. Вот такой небольшой fun | Сообщение посчитали полезным: ELF_7719116, DenCoder, 4kusNick, mak, v00doo |
|
Создано: 05 декабря 2015 17:33 · Поправил: DenCoder · Личное сообщение · #24 vden пишет: Далее по графу это значение попадает в XOR на константу, потом ROL 1 (который тут в виде SHL и SHR), потом плюс еще одна константа, потом меняем байты местами, потом меняем знак, расширяем со знаком до 64 бит и прибавляем к константе слева Аналогично, как и в 2.x. Приведённый алгоритм меняется рандомно для каждой новой протекции или каждого нового файла. Также внутри одного файла, если есть 2 вм, то для каждой свой такой алго. В обработчиках с декрементом меняются местами байты, с инкрементом - нет. Также в примитивах, использующих какую-либо константу из ленты, свой алго декодинга этих констант, зависит от размера данных, вводимых в стек/извлекаемых из стека, и типа обработчика - декремент/инкремент. <- тебе потребуется разобрать всего где-то 4 + 4 + 1(уже есть) = 9 различных алго декодинга для одной вм. Так было в 2.x. vden пишет: [add(undef(RSP), 0xFFFFFFFFFFFFFFF8:64)] ========> 0xFFFFFFFFC8B9AEB5:64 [add(undef(RSP), 0xFFFFFFFFFFFFFFF0:64)] ========> 0x1495E2024:64 [add(undef(RSP), 0xFFFFFFFFFFFFFFE8:64)] ========> undef(R9) [add(undef(RSP), 0xFFFFFFFFFFFFFFE0:64)] ========> undef(R11) [add(undef(RSP), 0xFFFFFFFFFFFFFFD8:64)] ========> undef(R12) [add(undef(RSP), 0xFFFFFFFFFFFFFFD0:64)] ========> undef(RCX) [add(undef(RSP), 0xFFFFFFFFFFFFFFC8:64)] ========> undef(RDX) [add(undef(RSP), 0xFFFFFFFFFFFFFFC0:64)] ========> undef(RBP) [add(undef(RSP), 0xFFFFFFFFFFFFFFB8:64)] ========> undef(RBX) [add(undef(RSP), 0xFFFFFFFFFFFFFFB0:64)] ========> undef(R8) [add(undef(RSP), 0xFFFFFFFFFFFFFFA8:64)] ========> undef(RSI) [add(undef(RSP), 0xFFFFFFFFFFFFFFA0:64)] ========> undef(RAX) [add(undef(RSP), 0xFFFFFFFFFFFFFF98:64)] ========> undef(RFL) [add(undef(RSP), 0xFFFFFFFFFFFFFF90:64)] ========> undef(R15) [add(undef(RSP), 0xFFFFFFFFFFFFFF88:64)] ========> undef(RDI) [add(undef(RSP), 0xFFFFFFFFFFFFFF80:64)] ========> undef(R10) [add(undef(RSP), 0xFFFFFFFFFFFFFF78:64)] ========> undef(R14) [add(undef(RSP), 0xFFFFFFFFFFFFFF70:64)] ========> undef(R13) [add(undef(RSP), 0xFFFFFFFFFFFFFF68:64)] ========> 0x0:64 На 2 меньше, чем в 2.x! Кстати, порядок ввода в стек регистров процессора также меняется для каждой новой протекции. Самый верхний адрес тут - шифрованный адрес ленты. Второй - (теоретически)шифрованный адрес перехода после окончания работы одной ленты, но не замечено, чтоб он использовался. Последний - дельта-смещение(для exe-файлов = 0, для неперебазированных dll тоже). В 2.x предпоследним был шифрованный указатель аллоченной области, бравшийся из ячейки по адресу. Какое кол-во примитивов? 79? 78? или другое какое-то? Размер области вм-регистров = 0xC0? vden пишет: Пока основное отличие версии 3 от версии 2 - отсутствие dispatch table. Не понял, что ты имеешь в виду. ----- IZ.RU | Сообщение посчитали полезным: vden |
|
Создано: 05 декабря 2015 18:22 · Поправил: vden · Личное сообщение · #25 DenCoder пишет: vden пишет: Пока основное отличие версии 3 от версии 2 - отсутствие dispatch table. Не понял, что ты имеешь в виду. В 2.х там всегда есть dispatcher, который вызывает каждый примитив (или handler, дело терминологии ) В принципе, все то же что ты описал выше. Заканчивается он таким кодом JMP [TABLE_ADDRESS + EAX * 4] или JMP [TABLE_ADDRESS + EAX * 8] EAX - индекс, а TABLE_ADDRESS - это то что я называю dispatch table. И в 3.x этой таблицы нет, а переходы считаются сразу в каждом примитиве/хэндлере. В 2.х по таблице было легко посчитать количество уникальных примитивов (хотя и не все из них могли использоваться). В новой версии уже так не получится. Можно трейсить исполнение и определять примитивы по тому, что они делают. Когда весь код будет отслежен (после VM_EXIT примитива), тогда можно понять сколько было уникальных примитивов. Я думаю что их около 100, потому что редко используется больше. Хотя может быть, конечно и больше. Но это не принципиально. В графе, могут отсутствовать какие-то промежуточные значения, потому что много мусора просто оптимизируется, например, константы вычисляются сразу. Добавлено спустя 12 минут DenCoder пишет: тебе потребуется разобрать всего где-то 4 + 4 + 1(уже есть) = 9 различных алго декодинга для одной вм Зачем? Самое забавное то, что я задаю известные данные, и вычисляю выражение автоматически. Просто нужно следить за RBX, RSI, RBP, а в 2.х еще и за RDI (там RDI, кажется, указыает на RSP). RSI - vm ip RBX - производная от операций с байт-кодом (vm-ip, константы на ленте) RBP - vm sp В примере выше, вручную я только прочитал DWORD c ленты и подставил в выражение и сделал "типа-evaluate". Добавлено спустя 31 минуту DenCoder пишет: На 2 меньше, чем в 2.x! Похоже на то. Недавно тут был Asassin's Creed новый, под vmp2. Если ошибки нет, то RSP ========> and(add(undef(RSP), 0xFFFFFFFFFFFFFE18:64), 0xFFFFFFFFFFFFFFF0:64) RBP ========> add(undef(RSP), 0xFFFFFFFFFFFFFF58:64) [add(undef(RSP), 0xFFFFFFFFFFFFFFF8:64)]:8 ========> 0xFFFFFFFFB5B538DF:64 [add(undef(RSP), 0xFFFFFFFFFFFFFFF0:64)]:8 ========> 0xFFFFFFFFA64D9438:64 [add(undef(RSP), 0xFFFFFFFFFFFFFFE8:64)]:8 ========> undef(RBX) [add(undef(RSP), 0xFFFFFFFFFFFFFFE0:64)]:8 ========> undef(R9) [add(undef(RSP), 0xFFFFFFFFFFFFFFD8:64)]:8 ========> undef(RSI) [add(undef(RSP), 0xFFFFFFFFFFFFFFD0:64)]:8 ========> undef(RFL) [add(undef(RSP), 0xFFFFFFFFFFFFFFC8:64)]:8 ========> undef(RDI) [add(undef(RSP), 0xFFFFFFFFFFFFFFC0:64)]:8 ========> undef(RCX) [add(undef(RSP), 0xFFFFFFFFFFFFFFB8:64)]:8 ========> undef(RBP) [add(undef(RSP), 0xFFFFFFFFFFFFFFB0:64)]:8 ========> undef(RDX) [add(undef(RSP), 0xFFFFFFFFFFFFFFA8:64)]:8 ========> undef(R15) [add(undef(RSP), 0xFFFFFFFFFFFFFFA0:64)]:8 ========> undef(R10) [add(undef(RSP), 0xFFFFFFFFFFFFFF98:64)]:8 ========> undef(RDX) [add(undef(RSP), 0xFFFFFFFFFFFFFF90:64)]:8 ========> undef(R12) [add(undef(RSP), 0xFFFFFFFFFFFFFF88:64)]:8 ========> undef(RAX) [add(undef(RSP), 0xFFFFFFFFFFFFFF80:64)]:8 ========> undef(R11) [add(undef(RSP), 0xFFFFFFFFFFFFFF78:64)]:8 ========> undef(R8) [add(undef(RSP), 0xFFFFFFFFFFFFFF70:64)]:8 ========> undef(R13) [add(undef(RSP), 0xFFFFFFFFFFFFFF68:64)]:8 ========> undef(R14) [add(undef(RSP), 0xFFFFFFFFFFFFFF60:64)]:8 ========> undef([0x1498A06D6:64]:64) [add(undef(RSP), 0xFFFFFFFFFFFFFF58:64)]:8 ========> 0x0:64 |
|
Создано: 05 декабря 2015 18:58 · Личное сообщение · #26 vden пишет: Просто нужно следить за RBX, RSI, RBP, а в 2.х еще и за RDI (там RDI, кажется, указыает на RSP). Rdi там указатель на область регистров. Хорошо, если при трейсе или после трейса инструкций мусор автоматически удаляется. Но всё равно читать больше кода, чем если из трейса байт-кода. ----- IZ.RU |
|
Создано: 05 декабря 2015 18:58 · Поправил: vden · Личное сообщение · #27 И небольшой лог (Asassin's Creed) Code:
| Сообщение посчитали полезным: ELF_7719116 |
|
Создано: 06 декабря 2015 15:09 · Личное сообщение · #28 |
Ранг: 419.0 (мудрец), 647thx Активность: 0.46↗0.51 Статус: Участник "Тибериумный реверсинг" |
Создано: 06 декабря 2015 19:01 · Поправил: ELF_7719116 · Личное сообщение · #29 WOW! WOW! WOW! Я дописал, наконец-то, декодер для request unlock code (код-запрос на сервер активации) для SecuROM PA! Ну ещё добавил несколько распотрошенных новых игрушек. Теперь кроме native-метода (primary HWID input), я могу декодировать любой (при условии наличия игрушки у меня в библиотеке) request unlock code, как это делает https://support.securom.com/PAunlock/ Так что - смело постите сюда свои request unlock code! На радостях, я решил декодировать request unlock code, который засвечен на сайте SecuROM PA: Code:
Вот такого только набора ключей в моей библиотеке 80_PA не оказалось Удалось расшифровать следующие данные: Code:
Что-то я сомневаюсь, что индивидуальный набор ключей будет в одной из защищенных секуромом игрушек. Скорее всего, это набор самой Sony DADC AG. В связи с чем, просто так получить набор не получится. Ситуация такова: у меня есть CRC_of_MD5_digest_DES_INDIVIDUAL_KEY_prep - CRC от MD5 дайджеста заготовки индивидуального DES ключа. Заготовка имеет длину 48 байт (10 байт та всегда одинаковы). Я так мыслю - связка MD5 (48 байт) + CRC (6 байт) брутиться будет невероятно долго. Есть конечно вариант - плюнуть на процедуру сверки связи и напрямую брутануть индивидуальный DES ключ, которым закрыты 19 байт остальной структуры request unlock code. Можно ли за приемлемое время брутануть обычный DES?? |
|
Создано: 07 декабря 2015 17:06 · Личное сообщение · #30 ELF_7719116 Обычный DES на обыкновенной машине или паре таких машин брутануть без дополнительных данных не удастся. Я не изучал статью, как устроен механизм гена я не знаю. Но если это реально крк от ключа, тогда ты можешь построить свой вектор атаки и сделать атаку - Встреча посередине. Такая атака возможна только если сам алгоритм реализован ошибочно. Добавив к этому некоторые ошибки или лозейки в коде, можно сгенерировать дополнительные таблицы валидации, используя десяток машин теоретически это можно сделать за 15 - 20 дней. Но если это режим кбк с мд5, тогда это маловероятно. Ты уверен, что мд5 именно от ключа ДЕС? Добавляется ли мд5 к началу шифротекста? Какой режим ДЕС? Используется ли дополнительный ключ для мд5 в шифротексте? Все эти моменты крайне важны для построения метода атаки, другими словами все зависит от реализации. Для этого нужно только правильно расписать все известные данные, а потом оценить метод подбора и его математическое качество, возможность брутануть за приемлемое время. Ты можешь проанализировать длину ключа и стойкость в других парах, если они у тебя имеются. В итоге на твой вопрос нет прямого ответа, пока ты сам не проанализируешь стойкость. ----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube | Сообщение посчитали полезным: ELF_7719116, DenCoder |
|
Создано: 08 декабря 2015 02:48 · Личное сообщение · #31 |
<< . 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9 . 10 ... 52 . 53 . >> |
eXeL@B —› Протекторы —› Crack SecuROM & DENUVO |