У этой функции есть второй аргумент структура COORD,передаю адрес структуры,функция возвращает ошибку,вроде делаю всё правильно Код (ASM): format PE console include 'win32axp.inc' section '.text' code readable executable invoke GetStdHandle,STD_OUTPUT_HANDLE mov word [coord.x],10 mov word [coord.y],10 invoke SetConsoleCursorPosition,eax,coord invoke ExitProcess,0 section '.data' data readable writeable struc coord { .x rw 1 .y rw 1 } coord coord section '.idata' import data readable writeable library kernel32,'kernel32.dll', import kernel32,\ GetStdHandle,'GetStdHandle',\ ExitProcess,'ExitProcess',\ SetConsoleCursorPosition,'SetConsoleCursorPosition',\ GetLargestConsoleWindowSize,'GetLargestConsoleWindowSize'
Структура, состоящая из двух полуслов. Можно было догадаться по МСДНу, где в прототипе нету звездочки. Код (Text): invoke SetConsoleCursorPosition,[hConsoleOutput],DWORD[binScreenBufferInfoCurrent.dwCursorPosition] Код (Text): BOOL WINAPI SetConsoleCursorPosition( _In_ HANDLE hConsoleOutput, _In_ COORD dwCursorPosition ); ЗЫ: снова "возвращает ошибку", анализировать LastError, как майкрософт советует, было видимо незачем.
Код (ASM): format PE console include 'win32ax.inc' ;----------------------- .code start: invoke GetStdHandle,STD_OUTPUT_HANDLE mov [pos.X],40 mov [pos.Y],5 invoke SetConsoleCursorPosition,eax,dword[pos] invoke Sleep,5000 invoke ExitProcess,0 .end start ;----------------------- .data struct COORD X dw ? Y dw ? ends pos COORD
Marylin, спасибо,работает --- Сообщение объединено, 30 сен 2024 --- ЗЫ:вообще команда PUSH работает интересно,ей в качесве операнда можно передать адрес памяти,и она возьмёт значение по этому адресу и переместит по другому адресу(указатель стека),ведь не нужно помещать значение в регистр а после в память --- Сообщение объединено, 30 сен 2024 --- f13nd, я когда в отладчике смотрел,функция возраващает STATUS_INVALID_PARAMETR
..для ленивых имеется и другой вариант - собрать все аргументы по порядку в секции-данных, и просто переместить указатель стека ESP на начало этого блока. (т.е. не Магомед идёт к горе, а гора к Магомеду).
(Вопрос в воздух: и куда же потом будет это значение в esp двигаться...?) Если вы хотите упасть при доступе к не выделенному участку памяти или потереть свои же глобальные переменные, тогда вариант для ленивых идеален.
ну так все нюансы предусмотреть-же нужно примерно так: Код (ASM): .data localVar rb 256 stackFrame rd 64 .code start: mov esp,stackFrame call myFunc ;.... по адресу "stackFrame" кладёшь адрес-возврата, и дальше аргументы..
Если пишите для себя и запускаете только у себя, тогда пойдет. Но вот что делать с другими версиями ОС (НТ - 11)/платформами (wine-vanilla, wine-staging, wine-proton). Там этого кусочка может не хватить. Предлагаете все пересмотреть и выяснить максимальную глубину, которая потребуется?
Да это используется для разового вызова процедуры/функции, после чего указатель esp опять восстанавливается на место. Если функа вызывается много раз с одинаковыми аргументами (например Mbox с сообщением об ошибке), чем постоянно пушить одно и тоже (push - это тормознутая запись в память), проще сместить сам esp.
А много ли вы выиграете для вызова MessageBox, который внутри будет крутить длинный цикл, пока пользователь не нажмет окай? Ничего страшного от тормознутой записи в память при использовании MessageBox не произойдет. А вот программа явно станет работать не корректно (тем более для такой функции как MessageBox т.к. глубину вызовов в стеке вы точно не определите).
какой ещё длинный цикл, когда Mbox синхронный/блокирующий вызов? а впрочем если боитесь, что код будет работать "не корректно", то не трогайте esp - никто не настаивает.
пока мессиджбокс на экране, в винде происходят тонны процессов АКА вызов процедур и передача параметров, разумеется через стек, и никому из них не понравится, если в какой-то момент esp указывает в непонятно что заведомо маленького размера ( переставлять esp куда угодно, в произвольный момент времени, не запретив предварительно прерывания, многозадачность и прочий праздник жизни - это заявка на обрушение как минимум своего приложения а винда это и не даст пользовательскому коду поэтому с точки зрения затрат времени на отладку и поиск котов в черной комнате лучше esp не переставлять на "другой" стек
а ничё, что Win это ос с вытесняющей многозадачностью? Пусть в фоне крутятся не тонны, а хоть мульён процессов - у потоков каждого из них свои стеки и регистры, и к вашему esp они не имеют никакого отношения от слова совсем. О сегменте TSS ничего не слышали? Это во-первых, ..а во-вторых планировщик выделяет кванты времени только тредам активного окна, а остальные переходят в состояние "Wait" и не получают времени. Вытеснить активный поток (забрать его кванты) может только процесс/поток с более высоким приоритетом, и повторюсь у него будет свой стек. В противном случае о никакой безопасности не может быть и речи, т.к. по вашей схеме через стековую память можно было-бы передавать всякое дерьмо буквально всем процессам в системе. Ну вот, уже и до ядра добрались.. При чём вообще тут прерывания? Это абсолютно из другой оперы. Слышать подобного рода высказывания на васме не привычно, а потому если других аргументов нет, лучше зарыть эту тему, пока знающие люди не подняли на смех. Вот почитайте на досуге заметку "Ассемблерные извращения - натягиваем стек" Криса (земля ему пухом). Может что-то прояснится наконец..
Может на хрюше это и катило, но вот на 7 сп1 уже нет Код (Text): format PE GUI 5.0 include 'WIN32A.INC' section '.idat' import data readable writeable library kernel32,"KERNEL32.DLL",user32,"USER32.DLL" include 'API\KERNEL32.INC' include 'API\USER32.INC' section '.data' data readable writeable test_data dd -1, -2, -3, -4, -5 msg_box_param dd 0, 0, msg_text, msg_caption, 0 msg_caption du 'Hello!',0 msg_text du 'Have a nice day.',0 section '.text' code readable executable entry $ mov esp, msg_box_param + 4 call [MessageBoxW] invoke ExitProcess, eax Берем программу использующую ваш способ. И ... получаем До входа https://disk.yandex.ru/d/0XrtZCpzr1FRXg После входа https://disk.yandex.ru/i/0RoDovYzO0aNOQ Бряк.... Как можно видеть вершина стека уперлась в начало образа exe (т.е. стерт даже заголовок PE, не говоря уже о данных в секции). ЗЫ Те. MessageBox использовал больше 8216 байт стека. И вы думаете до сих пор, что ваше rd 64 что-то изменит? --- Сообщение объединено, 3 окт 2024 --- Если так хотите экономить на push'ах, то для вас придумали вот это https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-messageboxindirecta
Перемещать указатель на стек на какой-то свой ограниченный буфер не нужно еще потому, что под windows драйвера режима ядра выполняются в контексте случайного процесса и они используют стек, т.е, указатель esp процесса в том числе. И вы не можете сказать, сколько при этом памяти стековой будет задействовано, поэтому есть хорошая возможность того, что данные в область младших адресов рядом с вашим буфером будут испорчены
Так суть здесь не в ограниченном буфере (ничто не мешает увеличить его до нужных размеров), а чтобы избавиться от многочисленных пушей, когда аргументов много. Другое дело, что в штатном стеке Win помимо свободного пространства лежат и полезные данные, например SEH-фрейм, линк на который прописывается в TEB. Если сменить esp, тогда автоматом отваливаются и обработчики ошибок, которые через esp активно юзает под катом Win32API. Поэтому если и делать стековый фрейм, то только для своих процедур/функций, а не системных.
выше уже за меня ответили на все возражения, поэтому я только замечу, что если ПО спроектировано так, что некий набор параметров передается в вызываемую процедуру в том же порядке и количестве и их прям "много" настолько, что напрягает уже экстра-пуш в стек при вызове, то изначально эта архитектура/проект ущербна т.е. возможно вычленение процедур из большого куска кода сделано неграмотно что касается мыщьа, меня со времен бумажного Хакепа удивлял вопрос "зачем" т.е. практической применимости его изысканий. человек хороший публикатор, набил кучу статей, похайпил ассемблером, вовлек новичков и т.д. но условный софтайс, деде, олли, иду, насм и далее везде - написал не он. статья называется извращения, окей.
Так он и не ставил перед собой цель написать олю или деде. По сути он "воевал" на другой стороне, и делился интересными фишками, которые находил при реверсе всего/этого софта, и особенно малвари, где ставка делается именно на нестандартное решение типичных задач, а кастомный стек как-раз и попадает под эту категорию.
