keng

Всё проще - за постройку всего отвечает одна и та же функция, её-то и надо найти. Находишь скорость постройки любого юнита\здания, ставишь на адрес брейкпоинт на запись, в отладчике вылезет инструкция, которая и будет частью этой функции. Там будет что-нибудь вроде: inc eax mov ebx,eax По смыслу, это таймер, который увеличивает "прогресс" строительства. Надо будет поменять функцию так, чтобы туда сразу записывалось максимальное значение - т.е. как будто постройка уже готова. Тут есть свои подводные камни - таймер может как увеличиваться, так и уменьшаться, ну и для зданий\юнитов могут быть две разных функции. Плюс, чаще всего эти функции являются общими как для игрока, так и для противников, т.е. надо будет сделать фильтр, чтобы быстрая постройка работала только у нас.

Привет! По первому вопросу навскидку не могу подсказать - артманю последний раз использовал довольно давно. Гляну чуть позже. По второму - во-первых, почему именно поиск по формуле? Насколько я помню, в его случае делается "дамп" памяти игры (сохраняется её состояние на определённый момент). Скажем, сначала у тебя 100 патронов - это A. Потом 50 - это В. А потом 80 - это С. Делаешь три дампа в таких состояниях и затем отсеиваешь по формуле типа: A > C > B Но мне кажется, что это не так эффективно - проще начать с поиска неизвестного значения, т.к. кулдаун - это по сути таймер, который уменьшается или увеличивается до определённого значения, вот его-то искать и надо. Скажем, применил заклинание - таймер начал тикать - ищешь "увеличилось - увеличилось - увеличилось", потом применяешь заклинание опять и уже "уменьшилось", ну и так далее.

На вкус и цвет. :3

Boss, ну я ж серьёзно говорю - я дал тебе уже две отличных книжки для изучения, ты хотя бы дочитай их до конца, а потом уже конкретные вопросы задавай. Не бывает волшебства, благодаря которому кто-то вдруг начинает понимать что-то с нуля - всё приходит с изучением теории на практике, ну и опытом.

А каким-нибудь WinUPack?

Так ещё бы оно работало - все call 123, jmp 456 и так далее сбиваются ведь. Попробуй UPX-ом сжать, должно стать в районе 1кб.

У большинства компиляторов клаустрофобия. Попробуй [UPX] . Без стороннего софта тоже можно - hex-редактор в руки и вперёд - пишешь всё вручную, начиная с заголовка. PS: Ты там троян пишешь, что ли? Чем тебя размер в 2кб не устраивает?

[Добро пожаловать] .

По-секрету скажу, что msg.exe - это обёртка над вот [этим] . Гугл рулит! ;D

ShellExecute!

Ну, если что, msg - это не команда, а [приложение] . Задротный вариант - найти аналог под Linux, взять сорцы, переписать себе. Не очень задротный - искать в папке Windows эту прогу и запускать из своей с нужными аргументами.

А поподробнее можно? Как ты себе это представляешь?

Ну так это WinAPI-функция. Скорее всего, ты её не объявил: import kernel,\ GetModuleHandle,'GetModuleHandleA',\ ExitProcess,'ExitProcess',\ Beep,'Beep' import user,\ DialogBoxParam,'DialogBoxParamA',\ EndDialog,'EndDialog',\ SendMessage,'SendMessageA',\ SetTimer,'SetTimer',\ GetAsyncKeyState, 'GetAsyncKeyState',\ EnumDisplaySettings,'EnumDisplaySettingsA',\ ChangeDisplaySettings,'ChangeDisplaySettingsA'

Дык зачем? Создай пустую DEVMODE, которая у тебя и так объявлена. В initdialog вызываешь одну функцию, которая её заполняет структуру текущими настройками, затем её (уже заполненную) используешь для смены видеорежима. Ничего менять не надо. section '.data' data readable writable devsettings DEVMODE ... .wminitdialog: invoke EnumDisplaySettings,0,-1,devsettings //Читаем текущий видеорежим invoke SetTimer,[hwnddlg],0,100,0 jmp .processed .timer: invoke GetAsyncKeyState,VK_F1 cmp eax,0 jne .f1 jmp .processed .f1: invoke Beep,1000,500 invoke ChangeDisplaySettings,devsettings,0 //При нажатии кнопки - восстанавливаем ранее прочитанный jmp .processed .move: invoke SendMessage,[hwnddlg],0xA1,0x2,0 jmp .processed

Короче, мораль - MSDN решает!

Всё оказалось проще. 1. В секции данных объявляем структуру DEVMODE: devsettings DEVMODE 2. В инициализации диалога делаем: invoke EnumDisplaySettings,0,-1,devsettings 0 - текущий видеоадаптер, к которому подцеплен основной поток вызывающего приложения, -1 - флаг ENUM_CURRENT_SETTINGS. 3. В таймере делаем: invoke ChangeDisplaySettings,devsettings,0 devsettings - заполненная ранее структура, 0 - от балды, не помню что именно этот флаг делает. PS: Мне всё ещё любопытно, зачем ты с этим так мучаешься - уже, вроде, довольно долго.

А, вроде нашёл. mov PelsWidth,dmScreenSettings.dmPelsWidth mov PelsHeight,dmScreenSettings.dmPelsHeight mov DisplayFrequency,dmScreenSettings.dmDisplayFrequency Этими строчками ты копируешь в переменные адреса полей структуры, а тебе надо их содержимое копировать. Попробуй: mov PelsWidth,[dmScreenSettings.dmPelsWidth] Например. На какую строчку компилятор ругается и что пишет?

Так во втором варианте у тебя прога всё равно по таймеру ждёт нажатия клавиши. Вызывай, например, вот [это] (или даже вот [это] ) в wminitdialog, оно тебе с нужным флагом выплюнет текущее разрешение экрана - затем уже заполнишь нужную структуру и второй функцией установишь это разрешение. А так, у тебя что в первом исходнике: .timer: invoke GetAsyncKeyState,VK_NUMPAD1 cmp eax,0 jne .func1ON invoke GetAsyncKeyState,VK_NUMPAD0 cmp eax,0 jne .func1OFF ret Что во втором.

Ну, описание Андрея под требуемое вполне подходит. Штука в том, что ты уже трижды повторил, будто автору до этого аки до луны, но ничего полезного при этом толком не написал. Форум же нужен для обмена информацией, а не для "хааа, у тебя так никогда не получится!".

Жалко конечно, что проблемы автора это не решает. Короче, автор, начни с поиска координат - а потом спрашивай дальше.

Ну так ты подскажи тогда, как надо делать, а то уже два сообщения просто так.

Чего не знаю - того не знаю. Попробуй сделать трейнер с кнопкой вкл\выкл, сохрани как .CT и посмотри сорцы.

[Тык] . Оно?

Как бы, если инструкция работает со многими адресами памяти - можно просто найти указатель на нужный и морозить его. Второй вариант - написать скрипт, ищущий аобсканом нужную инструкцию и прикручивающий к ней фильтр. Типа, если адрес нужный - то с ним ничего не делать.

Ок, вот дамп из Olly: CPU Disasm Address Hex dump Command Comments 00A910B4 |. 6A 38 PUSH 38 ; /Arg3 = 38 00A910B6 |. 8D4424 5C LEA EAX,[ESP+5C] ; | 00A910BA |. 6A 00 PUSH 0 ; |Arg2 = 0 00A910BC |. 50 PUSH EAX ; |Arg1 Это, значит, код программы, загруженный в память. Да - и код, и данные, с которыми код работает - всё хранится в памяти. Ты находишь какой-нибудь адрес поиском в СЕ, например, 0x123456. Типа, скажем, 4 байт целое. Открываешь отладчик и тебе выскакивает инструкция: 00A910B6 |. 8D4424 5C LEA EAX,[ESP+5C] ; | Мол, вот эта инструкция пишет в твой 0x123456, который ты нашёл, насяльнике! Ты открываешь дизассемблер и видишь картинку выше (дамп). Дык вот в момент срабатывания инструкции в [ESP+5C] действительно находится адрес памяти 0x123456, который ты нашёл ранее. Казалось бы, при чём здесь 0x00A910B4, стоящий напротив инструкции? Это - адрес памяти, по которому загружена эта самая инструкция. Вот aobscan нужен для того, чтобы искать местоположение инструкции в памяти, а не адреса данных, с которыми эти инструкции работают. Местоположение у нас в данном случае - 0x00A910B4. Адрес, с которым инструкция работает - 0x123456. Так что как ни пытайся - "заморозить" инструкцию не получится. Зато вполне получится заморозить адрес, с которым она работает - 0x123456. А всё почему? Вот что по-твоему делает заморозка? Она делает вот так: Записать в 0x123456 значение 100 Подождать 100 мсек Записать в 0x123456 значение 100 Подождать 100 мсек Записать в 0x123456 значение 100 Подождать 100 мсек... Поэтому пытаться заморозить код - бесполезно. Само собой, туда тоже можно записаь 100, но толку не будет. Становится понятнее?