Masm и Syscall

А тут и не нужно шарить в скриптах. То, что так называемый спец не способен прочитать и понять одну страницу мануала - это о многом говорит. Как ты там говорил: "ты не смог, а я смог".

 

У тебя неверно сформирован стек, т.к. нет адреса возврата. Сравни стек при вызове NtProtectVirtualMemory:

и то что ты передаешь:


Оформи правильно вызов по типу (FASM):

Код (ASM):

1. start:
2.  
3. push oldProtect
4. push PAGE_EXECUTE_READWRITE
5. mov [tmp],4096
6. push tmp ;        NumberOfBytesToProtect,
7. push pMem
8. push 0FFFFFFFFh
9. call @f
10.  
11. int3
12.  
13. @@:
14. mov     eax, 4dh ; Номер
15. lea edx,[esp+4]
16. xor ecx,ecx
17. call dword [fs:0C0h]
18. add esp, 4
19. retn 0x14

 

Thetrik, а зачем нужен адрес возврата в данном случае, я же вызвал сискол и все, стек остается тот самый.
И как высчитывать выравнивание стека? Есть 5 параметров, т.е. это ret 0x14, а зачем add esp,4? Это затирает адрес возврата. И у меня тогда на ret идет access_violation.

--- Сообщение объединено, 15 дек 2020 ---

Rel, там ничего сложного нет; просто нужно вырезать рекламу, говноскрипты и прочую ерунду; с этим надо поиграться, с регулярками и хтмл разметкой. Как нибудь сделаю. Или могу залить хтмл файлы, пусть еще кто-то делает, мне сейчас не особо до клаба. Дома ремонт , проблемы с сантехникой. Так то конечно шутки про электриков и ПТУ это весело, но коснись чего - увы, петон с жабоскриптом не умеет чинить проводку и трубы прокладывать. Такие дила.

 

Петон с жабоскриптом заработает тебе денег достаточно, чтобы оплатить работу нужному тебе "спецу".

 

Когда ты вызываешь любую NT-функцию у тебя всегда адрес возврата на вершине стека лежит. Я же скинул скрин со стеком. У тебя не сискол а прыжок на wow64cpu!CpupReturnFromSimulatedCode, можешь в отладчике посмотреть. Сискол вызывается уже внутри WOW64 прослойки, где подготавливаются параметры для 64 битного режима.

В коде стоит [icode]call dword [fs:0C0h][/icode], но возврат из кода происходит по JMP FWORD, т.е. этот адрес так и остается в стеке. add esp, 4 просто удаляет его. Такое поведение по крайней мере в Windows 7 x64.

 

TEB[0xC0] это вызов для оптимизации, называется turbothunk". Там расширяется таблично размер аргументов для ядерных вызовов. Разумеется и переключение режимов.

Я ведь говорил что на кл была обширная тема, была и тут - искалась причина анстаба. Это было решено, можно поискать(тут поиск не рабочий, но гугл отлично находит "wow ss site:wasm.in"), нужно было переключать стековый сегмент https://wasm.in/threads/access-violation-pri-vozvrate-iz-64-bitnogo-rezhima.33604/