Сейчас на форуме: jinoweb (+4 невидимых) |
eXeL@B —› Программирование —› x86 -> x64 on W10 |
Посл.ответ | Сообщение |
|
Создано: 10 сентября 2019 16:07 · Личное сообщение · #1 Всех приветствую. Разбираюсь в реализации перехода к выполнению x64 кода из 32-битного процесса. Постараюсь как можно более конкретно сформулировать возникший вопрос. За основу взял всем известный код https://github.com/dadas190/Heavens-Gate-2.0 В функции X64Call() всё предельно просто - в начале push 0x33 push _next_64bit_block С этого момента (а точнее, после retf сразу за этим кодом) должен выполняться 64-битный код, так как сегмент кода будет изменен на 0x33. До этого в выделенной для куска машинного кода памяти меняются адреса на актуальные, подставляется нужное значение, чтобы исправить стек, и т.д.: *(uint32_t*)(r + 3) = (uint32_t)(r + 8); *(uint8_t*)(r + 20) = stackfix; *(uint8_t*)(r + 27) = (uint8_t)(((n>4) ? (n - 4) : 0)); *(uint32_t*)(r + 34) = (uint32_t)(&args[n - 1]); *(uint64_t*)(r + 83) = proc; *(uint8_t*)(r + 96) = (uint8_t)(32 + ((n > 4) ? ((n - 4) * 8) : 0)); *(uint32_t*)(r + 104) = (uint32_t)(&ret); *(uint32_t*)(r + 115) = (uint32_t)(r + 121); Но как я ни бился, как я ни экспериментировал с выравниванием, с количеством передаваемых параметров вызываемой функции, выполнение вылетает в ntdll .text:77ED1DF0 ntdll.dll:$71DF0 #711F0 <ZwAllocateVirtualMemory>: ACCESS VIOLATION. Работает ли в принципе эта фича в новых виндах, или там что-то поправили, и теперь это невозможно / сложно? Буду благодарен даже не за конкретное решение, а за подсказки. ----- Харе курить веники и нюхать клей, к вам едет из Америки бог Шива, и он еврей. |
|
Создано: 10 сентября 2019 18:03 · Личное сообщение · #2 Crawler на десятке 1809 (предпоследняя это вроде?) работает. Но я юзал чужую либу ( | Сообщение посчитали полезным: Crawler |
|
Создано: 11 сентября 2019 10:05 · Личное сообщение · #3 |
|
Создано: 11 сентября 2019 11:11 · Личное сообщение · #4 странный какой-то код, при желании можно упростить в разы LoadLibrary64 отрабатывает нормально, вызывая 64 битную ntdll._LdrLoadDll GetProcAddress64 тоже отрабатывает, но вызывает при этом 32 битную kernel32 (возможно здесь косяк?) в обоих случаях возвращается значение отличное от нуля после вызова X64Call возвращаемое значение 0 и программа падает на combase._CoIncrementMTAUsage mov rdx,[rax+rcx*8] проверял на Windows 10 х64 1903 |
|
Создано: 11 сентября 2019 11:15 · Личное сообщение · #5 morgot пишет: rewolf wow64ext Может пригодится, инфа от автора: http://blog.rewolf.pl/blog/?p=102 | Сообщение посчитали полезным: Crawler |
|
Создано: 11 сентября 2019 12:31 · Личное сообщение · #6 |
|
Создано: 13 сентября 2019 23:06 · Поправил: difexacaw · Личное сообщение · #7 В 10-ке есть редкая инструкция в торбо wrfsbase, вообще с сегментами какая то мистика, загрузив одинаковый селектор в fs/gs адресация происходит разная.. хз нужно конкретно Интел маны изучать, как это работает. По любому будут траблы с сегментами. Это можно выяснить только отладкой, никак иначе. Там есть есчо фичи в нт планировщике, он как то проверяет сегменты и их фиксит. Это есть даже в сурках в2к, но там обработка совсем иная. Мне тоже пока не ясно что там идёт не так. ----- vx | Сообщение посчитали полезным: Crawler |
|
Создано: 14 февраля 2020 20:27 · Личное сообщение · #8 Потестите кому не лень. Не могу понять что за фигня, толи в железе баг, откуда анстаб на некорых версиях/железе. Таких тем уже много, нужно понять причину. b25b_14.02.2020_EXELAB.rU.tgz - Wow.7z ----- vx |
|
Создано: 16 марта 2020 19:30 · Личное сообщение · #9 О, знакомые штуки. Пользую запчасти из этого и других гейтов, ибо у меня не msvc, а mingw и его не очень умение в инлайл асм, который так обожают почти все авторы гейтов. У меня эта штука написана с год, если не больше, назад, в большом проекте, недавно туда полез - стало крашить на получении PEB64, на мелких прогах-тестах - все норм, хотя ничего не менял, только еще пару функций из х64 добавил. Решил отключением оптимизации кода вокруг memcpy64 и GetPEB64. Судя по отсутствию криков НИЧЕГОНЕРАБОТАЕТ - у остальных проблем нет, разброс винды от семерки и дальше. А вот X64Call у меня выглядит иначе и сейчас я озадачился откуда и почему, ибо с первых разов в гугле подобного не нашел. Code:
Ну и грубо говоря: typedef DWORD64 (*tX64Call)(DWORD64 func, int argC, ...); tX64Call X64Call = (tX64Call)callx64_code; |
|
Создано: 16 марта 2020 21:21 · Личное сообщение · #10 ZLOFENIX Твой код будет работать от фазы луны: Code:
- fs: 53, планировщик пофиксит значение при первом переключении контекста(=> 47.KiSC25) Code:
- можно посчитать переключения. Code:
- 64 код после переключения мода. А куда собственно указывает rsp/rbp.. наверно так совпало что LM_RSP < CM_ESP, поэтому и не падает, а используется чужой стек В этих переключениях есть скрытые нюансы, не зная которые сложно понять в чём нестабильность. ----- vx |
|
Создано: 16 марта 2020 22:50 · Личное сообщение · #11 |
|
Создано: 16 марта 2020 23:35 · Поправил: difexacaw · Личное сообщение · #12 Boostyq Так ведь на 10-ке SwapContext(): mov eax,53h/mov fs,eax(10.0.1). Хотя там есть условие что поток не маркирован, а маркер устанавливается от параметров в KeInitThread(StartContext?). Врядле это как то связано с fg. Без rfg и на 8-ке в частности селектор восстанавливается, а значит это уже анстаб. Добавлено спустя 18 минут Простой пример: Code:
w8, деф. приоритет: ~120переключений/с. На высоком приоритете ~30. ----- vx |
|
Создано: 17 марта 2020 01:15 · Личное сообщение · #13 difexacaw пишет: Без rfg и на 8-ке в частности селектор восстанавливается, а значит это уже анстаб. За что купила, за то продала, референс указала, так что здесь мои полномочия уже все. Возможно в норме селектор должен переписываться, но это происходит не на всех сборках, насколько помню в комите был указан определенный номер. ----- В облачке многоточия |
|
Создано: 17 марта 2020 19:45 · Поправил: difexacaw · Личное сообщение · #14 Boostyq Селекторы трогать нельзя, будет анстаб, на этом был косяк не только у меня ^. А если этот ваш револьф написал кривую реализацию(без переключения стека даже) и все начали копипастить, то это уже проблемы бездумного использования чужих кривых поделок. А как там с fg я посмотрю, наверно сначала нужно этого револьфа почитать, что бы все версии модулей не тянуть. Было бы неплохо номер вспомнить, примерно хоть ----- vx |
|
Создано: 17 марта 2020 21:54 · Личное сообщение · #15 difexacaw пишет: А если этот ваш револьф написал кривую реализацию Этот револьф на несколько порядков > тебя, его либу юзают кучу людей, а твой помет только ты. И никто не пишет про анстаб, потому что он исправил уже кучу багов, а ты только кукареку. Если подставить клавиатуру под твой бескостный вечномолотящий язык, то самая правильная реализация будет готова быстрее, чем я успею сказать надо же. difexacaw пишет: неплохо номер вспомнить, примерно хоть В гугле забанили? На гитхаб зайди да почитай. ----- В облачке многоточия |
|
Создано: 17 марта 2020 22:19 · Поправил: morgot · Личное сообщение · #16 difexacaw , Boostyq насколько я понимаю, речь об этом Хз как оно там правильно, но реализация от револьфа работает на всех 64 битных ОС, что я тестил, вплоть до последней десятки. Инди, напишите свою реализацию, много кто будет благодарен. |
|
Создано: 17 марта 2020 22:27 · Личное сообщение · #17 |
|
Создано: 17 марта 2020 22:42 · Личное сообщение · #18 |
|
Создано: 17 марта 2020 22:51 · Личное сообщение · #19 |
|
Создано: 18 марта 2020 00:32 · Личное сообщение · #20 difexacaw пишет: Не истери, проходи мимо если чота не нравится. Да, мне не нравишься ты и твое тошнотворное поведение, но я не вижу причин следовать совету какого-то гребня. Тебе давно пора заметить, что как бы твое чсв не упорствовало, большинство людей вокруг умнее тебя. И если твой код падает, то наберись мужества, признай что он шваль, и посмотри нормальную реализацию. ----- В облачке многоточия |
eXeL@B —› Программирование —› x86 -> x64 on W10 |