CHBS

Спасибо за информацию, а [C6 /0 ib] - [MOV r/m8, imm8] из этой инструкции, /0 ib чем является? О, как, спасибо большое, я просто голову ломал из-за порядка байт, разворачивал но получалось 87 C6 D0 00 00 00 01, стало намного яснее. По поводу не загоняйся - мне просто стало интересно из чего сигнатура строится, еще нужно бы понимать, какие аргументы меняются и как их определять, понятное дело что mov это опкод и он будет неизменным в сигнатуре, но вот может ли сменится регистр в блоке инструкций или он уже назначен на rdi? Просто у него сигнатуру кончилась до этого опкода, если же посмотреть на предыдущую инструкцию // 4C 8B 35 F3 A8 2A 02 mov r14, cs:_g_pGameEntitySystem 35 тут к чему будет относится? Спасибо, она? [CENSORED]

Всё равно не ясно, ведь 41 опкод зарезервирован для инструкции INC, та же кстати история с // C6 87 D0 00 00 00 01 mov byte ptr [rdi+0D0h], 1 // 49 8B 3E mov rdi, [r14] Даже если документацию открыть на 1169 странице, https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf, То опкоды MOV начинаются с 88+, что там делает в первой строке 87 мне не понятно, а еще более не понятен порядок байт, должно быть либо с лева, либо с права на лево, а опкоды по середине почему-то.

Да там же 5 тысяч страниц, https://en.wikipedia.org/wiki/X86_instruction_listings Даже тут не указано про что инструкция push может иметь назначение опкода 41. // 41 55 push r13 Если я все правильно понял, то r13 это регистр общего назначения, и push у него должен быть соответственно в диапазоне 0x50-0x57, в чём подвох?

// 41 55 push r13 Тогда почему тут 41?

Я заранее извиняюсь если создал тему не в том разделе, но посчитал что это будет ближе к ассемблеру. Вопрос возник при изучении исходного кода одного из сканнеров сигнатур https://github.com/LWSS/McDota/blob/master/src/Scanner.cpp Если мы допустим откроем что нибудь в отладчике, увидим набор инструкций и их опкодов с аргументами, вопрос вот в этом моменте // 55 push rbp // 48 89 E5 mov rbp, rsp // 41 56 push r14 // 4C 8B 35 F3 A8 2A 02 mov r14, cs:_g_pGameEntitySystem // 41 55 push r13 // 49 89 FD mov r13, rdi // 41 54 push r12 // 53 push rbx // 31 DB xor ebx, ebx // C6 87 D0 00 00 00 01 mov byte ptr [rdi+0D0h], 1 // 49 8B 3E mov rdi, [r14] // E8 EA 4B E2 FF call CGameEntitySystem__GetHighestEntityIndex PatternFinder::FindPatternInModule("libclient.so", "55 48 89 E5 41 56 4C 8B 35 ?? ?? ?? ?? 41 55 49 89 FD 41 54 53 31", "reinitPredictables"); Не могу понять какой байт имеет опкод push? если посмотреть на первую строку из кода то мы видим 55, но почему не указан аргумент rbp? Т.е я предполагал что если идет опкод с аргументом, то должно быть его байтовое обозначение, т.е например из первой строки 55[push] 89[rbp] например. В следующей же строке это все присутствует 48[mov] 89[rbp] e5[rsp] Так почему же в первой строке где у нас push rbp, не указан байт-аргумент? Так-же почему 3-ья строка имеет другой опкод отличный от первого? 41[push] 56[r14], если push вроде как должен быть 55? Я знаю что я как-то не так интерпретирую информацию, что очень скажется на конечном результате изучения, поэтому и задал вопрос, поставьте сразу на правильный путь, почему отладчик так выводит назначение опкодов и аргументов?

На счёт key, value in pairs(editLine) там может быть ошибка, так что глаза в оба, протестить не могу, ибо не знаю как, где находятся UDF1 элемент и его панели?

А зачем ты используешь табличные индексы, а не table.insert?

Хотелось бы узнать, а адрес 0x74c37990 откуда был взят? Он статический во всей памяти, или конкретно вопрос как собственно найти адрес у этой функции непосредственно в CE?

Ну юмористы xDDD Что-то типо того, я же в координаты должен засунуть еще и углы поворота машины, а потом восстановить как было)) Вопросов по телепорту не осталось, спасибо @ReWanet за оказанную помощь. объяснил что и как и к чему))

@ReWanetТак должно быть?

Рабочий Не рабочий

Не могу редактировать. Вообщем проблема странная, будто pos обнуляется, т.е первые раз я сохраняю позицию, выполняя метку store: далее я проезжаю сколько то метров, выполняю метку restore: меня телепортирует, а если проехать например пару сотен метров, то pos вовсе будет держать в себе значения рандомного флоата, например моя настоящая позиция x = 3000, y = -2000, z = 200 в posX = 1.3141431413E+4, posY = 2.13123123123E+4, posZ = 0.31413413413 Не могу понять почему так происходит, вроде pos не должен записываться пока я не выполню метку store, все выполняется по клавишам

@ReWanet, спасибо большое, проблема решена, нужно было сместить restore, store вниз, непонятно почему так Код

Когда я писал, ее не было просто, сообщение отредактировано ведь Вылета как такового вроде бы и нет, я не могу это проверить, потому что скрипт работает явно не стабильно, дело в том что когда я включаю скрипт, на нем вешается крестик, но в моем случае крестика нету, и я получается не могу обратно восстановить инструкцию, и немогу понять почему крест не вешается и инструкция не восстанавливается

О_о а где оно повторяется то? убрал, кстати почему? как вообще происходит выполнение кода, ведь нет нигде указания что нужно зайти в метку pflag, и выполнить db 0 Прописал Вот да, я в это и впоролся, и приходится пока ручками восстанавливать инструкцию, не понимаю почему после выполнения своих действий, он не восстанавливает по нажатию мои собственные инструкции Имена меток попутал restore -> store, store -> restore Посмотрел в бряке регистры, был занят, сделал через fld, fstp, хоть понял как это теперь работает Инструкция пересчитывает на самом деле много адресов Привожу ниже текущий код.