VB-код для китайского USB-реле

[Хакер]

адреса функции в BAS-модуле под IDE

Адрес чего ты собрался получать?
Под IDE всё компилируется в P-код. То, что возвращает AddressOf — это native-кодный переходник, который вызывает P-кодный код.

Так что дело в том, что там принципиально нет того, что можно патчить. Вернее есть, но патчить придётся не x86-инструкции, а P-кодные инструкции.

[Адская_Капча]

Адрес чего ты собрался получать?

Пропатчить функцию в BAS-модуле (не функцию класса, чей адрес можно извлечь из VTBL и вызов которого медленнее, чем BAS-функции и где EAX еще проверяется на предмет ошибок) ассемблерной вставкой... Которая делает JMP на свой ассемблерный код. Т.е. без использования CallWindowProc... Для этого нужно получить адрес функции и перезаписать по нему переходник.

Мне кажется, сами адреса BAS-процедур должны где-то быть "прописаны"... Или у BAS-функций нигде нет никакого "аналога VTBL" и без JMP не обойтись?

[Хакер]

Ещё раз.

В памяти не существует функций в пригодном дла патчинга виде. Существует только крохотный перехдничок, который возвращается квазиоператором AddressOf — его можешь и патчить.

Ты понимаешь ты разницу между P-кодом и Native-кодом? Или ты не знаешь, что это такое, и неумело пытаешься скрыть этот факт, игнорируя вышеприведённые слова о том, что модульные процедуры (равно как и методы форм, классов и др. объектных модулей) в режиме IDE компилируются в P-код?

[Адская_Капча]

Разницу между P-кодом и Native-кодом понимаю, но мне еще не доводилось заниматься отладкой P-кода... Для P-кода не существует никакого аналога OllyDbg?

Для функций из класса у меня работает в обоих режимах, достаточно подменить адрес в VTBL. А вот для функций из модуля AddressOf работает только для Native-режима, а для IDE приходится использовать TipGetLpfnOfFunctionId.

[Хакер]

Для P-кода не существует никакого аналога OllyDbg?

Нет. Как для него может существовать аналог, если процесс выполнение P-кода это просто процесс выполнения Native-кодных инструкций, построенный вокруг огромной switch-таблицы? Это же не какой-то особый системный режим. Хотя, конечно, при желании такой отладчик можно написать.

а для IDE приходится использовать TipGetLpfnOfFunctionId.

А почему не работает AddressOf? Что мешает? В чём проявляет себя мешающий фактор?
И вообще, зачем тебе это нужно — перезаписывать код процедуры?

[Адская_Капча]

Для IDE получаю адрес BAS-процедуры Proc через AddressOf и по этому адресу пишу

Код: Выделить всё

JMP relAddrASMCode

- вызов Proc не приводит в исполнение мой ASMCode, а происходит словно подмены и небыло.

Для IDE получаю адрес BAS-процедуры Proc через TipGetLpfnOfFunctionId и по этому адресу пишу

Код: Выделить всё

JMP relAddrASMCode

- вызов Proc приводит в исполнение мой ASMCode.

Для IDE получаю адрес BAS-процедуры Proc, вызывая в ней вспомогательную функцию, чтобы посмотреть значение ESP и вычислить адрес Proc, чтобы потом по нему записать переходник. Однако получаю совершенно отличающееся от двух предыдущих значение (причем в Native-режиме вычисляется правильно) ...

Да можно и с классом работать, хоть это и медленнее. Но просто стало интересно - а возможны ли другие пути? И хочется избавиться от TipGetLpfnOfFunctionId... И, по возможности, от JMP relAddrASMCode тоже, чтобы сразу вызов происходил по relAddrASMCode...

[ger_kar]

процесс выполнение P-кода это просто процесс выполнения Native-кодных инструкций, построенный вокруг огромной switch-таблицы? Это же не какой-то особый системный режим. Хотя, конечно, при желании такой отладчик можно написать.

А отладчик VB6 он же по сути и является таким отладчиком? Он же (отладчик vb6) работает не с нативным кодом и отладочными символами, а напрямую с P кодом? без всяких отладочных символов?

[The trick]

Ну если ты отлаживаешь в ольке то наверное видел что возвращает AddresOf. Непосредственно имея это значение можно получить параметр ProcCallEngine, которая вызывает нужный p-код.

Код: Выделить всё

GetMem4 ByVal GetAddr(AddresOf NeedFunc) + &H16, NeedAddr

Для отлаживания р-кода нужна таблица опкодов, которая есть где-то на веб архиве.
viewtopic.php?f=28&t=45598 вот я что-то подобное делал, можешь заменить вызовы из vba6 на данны GetMem будет тоже самое.

[Хакер]

И, по возможности, от JMP relAddrASMCode тоже, чтобы сразу вызов происходил по relAddrASMCode...

Зачем это нужно?

Если тебе нужно вызывать произвольные процедуры, зная их адрес, используй мой кирпич:
viewtopic.php?f=28&t=42929
viewtopic.php?f=15&t=42930

[Адская_Капча]

А отладчик VB6 он же по сути и является таким отладчиком?

Разве в нем можно посмотреть регистры CPU и пошаговую отладку внутренних инструкций, а также ассемблерного кода?

я что-то подобное делал

А причину-то в итоге удалось выяснить, почему происходят вылеты и только по Ctrl+F5 работает? Может, при "просто F5" какая-то инициализация не происходит? У меня при "просто F5" при самом первом запуске строки не выводятся в этом примере, а так вполне замечательный пример!

заменить вызовы из vba6 на данны GetMem

И ведь это работает, круто

вызывать произвольные процедуры, зная их адрес

По адресу вызывать процедуры тоже можно и статью посмотрю, но при использовании ассемблерных вставок, когда в процедуру передаются входные параметры, разве так необходимо передавать и адрес? Это так CallWindowProc работает, но ведь можно и заранее произвести "инициализацию", чтобы потом просто вызывать целевую процедуру, а основную работу будет делать ассемблерный код по обработке входных параметров.
Еще и у GSerg есть статья про указатели... Осталось понять, какой способ вызова является лучшим (с точки зрения быстродействия, например)...

Зачем это нужно?

Здесь была тема (viewtopic.php?t=9286), что и от JMP можно избавиться
В нее еще нужно будет вникнуть более детально...
А разве использование ассемблерных вставок плохо? Это же открывает врата для высокого быстродействия. Простые числа можно получать, к примеру, или строки с массивами обрабатывать, да что угодно.

[The trick]

А причину-то в итоге удалось выяснить, почему происходят вылеты и только по Ctrl+F5 работает? Может, при "просто F5" какая-то инициализация не происходит? У меня при "просто F5" при самом первом запуске строки не выводятся в этом примере, а так вполне замечательный пример

Ну это очевидно, функция не компилируется пока не вызовется. Проблем не вижу в этом чтобы вывести кнопку полной компиляции.

[Хакер]

Разве в нем можно посмотреть регистры CPU и пошаговую отладку внутренних инструкций, а также ассемблерного кода?

Да сколько можно уже говорить. При работе кода под IDE ассемблерного кода, о котором ты привык думать, ВООБЩЕ НЕ ГЕНЕРИРУЕТСЯ.

разве так необходимо передавать и адрес?

Я ничего не понимаю, о чём тут вообще речь. Я тебе дал ссылку на свой кирпич.
Его суть в следуюшем: один раз инициализировал указатель (присвоил указателю адрес своего ассемблерной вставки) — и миллион раз потом просто вызываешь. Вызовы будут крайне быстрыми.
А CallWindowProc не юзайте для вызова произвольных процедур по их адресу. Вы даже не догадываетесь, сколько внутри CallWindowProc всякой сложной логики и лишнего (для данного применения).

И вообще, это какое-то неразумное пацанство — делать так ассемблерные вставки. Хотите ассемблерную вставку — поместите её в DLL и завызывайтесь. Никакой чёрной магии. Либо, с тех пор как я открыл недокументированные ключи, можно даже статически прилинковать ассемблерную вставку (но работать это будет только в скомпилированном виде, понятное дело).

Еще и у GSerg есть статья про указатели...

Насколько я помню, у него есть две статьи — через CallWindowProc и через вызов метода. Оба метода сильно уступают предложенным мною.

Здесь была тема (viewtopic.php?t=9286), что и от JMP можно избавиться Изображение

Это всё устаревшие статьи и методы.

[ger_kar]

А CallWindowProc не юзайте для вызова произвольных процедур по их адресу. Вы даже не догадываетесь, сколько внутри CallWindowProc всякой сложной логики и лишнего (для данного применения).

Да уж, там целый огород. Я думал, что там все элементарно, но посмотрев в отладчике понял, что это не так. Кроме самого кода этой функции, еще и со стороны VB приходится городить целый огород, при том, что вызов по указателю через кирпич Хакера практически ничем не отличается от вызовов Win API функций. И контроль аргументов есть и код вызова прозрачный.

И вообще, это какое-то неразумное пацанство — делать так ассемблерные вставки. Хотите ассемблерную вставку — поместите её в DLL

Ну не любит у нас народ Dll ки. Я сам такой был. Даже не знаю, почему, но у самого было такое предубеждение. Но оно прошло, как только начал делать большие и серьёзные проекты. Вот тогда я и понял насколько это удобно. Да и когда в проекте библиотек и так много, то становится глубоко по фиг, добавится еще несколько библиотек или нет.

[Адская_Капча]

ВООБЩЕ НЕ ГЕНЕРИРУЕТСЯ

Я же про вставки, как тогда в режиме IDE исполняется моя собственная ассемблерная вставка? Как-то ведь исполняется... Или регистров CPU в этом случае совсем нет и их работа как-то эмулируется в режиме IDE? Мои вставки как раз работают с регистрами... Зачастую, бывает необходимо проконтролировать пошагово работу вставки, а также какие-либо моменты до/после нее.

Это всё устаревшие статьи и методы.

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

Хакер, а как вы относитесь к примеру The Trick вызова по указателю?

Про "DLL" - а если вставки небольшие, к примеру, размером в несколько байт?
Я тоже отношусь к тем, кто не любит DLL... их "таскать" нужно, да и программу мою нельзя назвать громадной. Наоборот, я пытаюсь все оптимизировать и минимизировать, чтобы было максимально "быстро", "портативно" и "все в одном".
Ведь в современном мире как программы, так и операционные системы постепенно пухнут и пухнут в размере. А также навязывается .NET, который я не люблю... что может быть лучше старой доброй нативки

Да уж, там целый огород.

В DispCallFunc, тоже ведь какой-то огород есть? Или он еще хуже чем CallWindowProc?

[The trick]

Я же про вставки, как тогда в режиме IDE исполняется моя собственная ассемблерная вставка? Как-то ведь исполняется...

Процессор в любом случае выполняет машинный код. Когда ты передаешь AddressOf-указатель то на самом деле передаётся указатель на специальный переходе чек (назовем его #1) о котором писал Хакер. Этот переходничек проверяет режим работы и что-то ещё. Если p-код находится в режиме выполнения, то выполняется прыжок на др ой переходничек (назовём его #2), который вызывает функцию ProcCallEngine, которая в свою очередь начинает выполнять р-код функции, иначе код вызывает тот злополучный ret как будто у функции 0 аргументов. Когда ты патчишь переходничек #1, то никакого эффекта это не будет иметь при вызове этой функции (если она конечно не крлбэк функция). Если патчит переходе чек #2 то это уже будет вызывать твою вставку при непосредственном вызове функции. Вставка #2 получается посредством функций из vba6, или через GetMem как я писал выше. Эта вставка вызывается всегда, когда вызывается процедура.
Все пишу по памяти и через телефон, возможно в чем то ошибаюсь, Хакер поправит.
Насчёт dispcallfunc это намного быстрее чем callwindowproc, листинг можешь посмотреть в отладчике.

[ger_kar]

Я же про вставки, как тогда в режиме IDE исполняется моя собственная ассемблерная вставка? Как-то ведь исполняется... Или регистров CPU в этом случае совсем нет и их работа как-то эмулируется в режиме IDE? Мои вставки как раз работают с регистрами... Зачастую, бывает необходимо проконтролировать пошагово работу вставки, а также какие-либо моменты до/после нее.

Я например, когда мне нужно что то подобное, то для этих целей использую PowerBasic. Офигительно удобная штука, причем гораздо более удобная чем ассемблер в чистом виде. Потому, что там используются ассемблерные вставки вместе с Basic кодом. И код VB6 в PowerBasic переносится на раз, если он конечно не связан с визуальной частью. Можно конечно и на Си написать, но PowerBasic гораздо ближе к VB во всех отношениях. И там где нужен низкоуровневый подход - он самое то. Ну и что что библиотека будет, это совсем не страшно . Зато отлаживать удобно и не нужны извращенные заморочки.

В DispCallFunc, тоже ведь какой-то огород есть? Или он еще хуже чем CallWindowProc?

Да пес его знает, я смотрел только CallWindowProc

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

По сути та же ассемлерная вставка занимает килобайты и, что исполняемый файл увеличится на этот размер, что рядом появится доп файл с таким же размером особой разницы нет в плане размера. Что касается мобильности, то библиотека будет нативная и ей регистрировать совершенно не надо. Кроме этого если так уж сильно распирает иметь все в одном файле, ассемблерную вставку можно иметь в двух файлах: в виде готовой библиотеки для отладки под IDE, и виде объектного файла, который на стадии сборки можно скомпоновать в один файл. Я так сам не делал, но Хакер говорит, что так можно сделать. Но это уже по идее должна быть совершенно другая тема

[The trick]

Кроме этого если так уж сильно распирает иметь все в одном файле, ассемблерную вставку можно иметь в двух файлах: в виде готовой библиотеки для отладки под IDE, и виде объектного файла, который на стадии сборки можно скомпоновать в один файл. Я так сам не делал, но Хакер говорит, что так можно сделать. Но это уже по идее должна быть совершенно другая тема

viewtopic.php?f=99&t=49733#p6780386[code][/code]

[ger_kar]

Кстати, The trick у тебя же есть блог, было бы неплохо этот момент оформить там отдельной темой.

[ger_kar]

А если для линкования использовать другой метод?
Сделать модуль с двумя типами объявлений для функций. Каждый тип обрамить в теги условной компиляции.
Первую часть сделать на основе Declare и использовать её на стадии отладки в IDE для вызова функций из DLL.
А вторую сделать просто с функциями пустышками. На этапе компиляции этот модуль превратиться в объектный файл и вот тут нужно процесс прервать и подменить этот объектный файл другим подготовленным при помощи того же MASM например. И дальше процесс линковки влинкует его и получится монолитный исполняемый файл.

[The trick]

Просто так не получится, т.к. vb6 использует декорирование имён в стиле c++ с недокументированными символами, а также все функции и методы всех объектов имеют при декорировании прототип как-будто это sub с 0 аргументами. Я для этой цели писал парсер coff с возможностью изменения и пересохранения. Просто заменяем декорированное имя на имя из lib/coff файла и он линкуется. Для целей отладки нужно создавать dll из всех файлов и делать динамическую библиотеку типов для неё чтобы без всяких модулей. С таким подходом можно будет в дополнение делать ассемблерные вставки прямо на асме.

[Адская_Капча]

Проблем не вижу в этом чтобы вывести кнопку полной компиляции.

Не совсем понятно, что значит вывести кнопку полной компиляции... А может, нужно просто снять крыжик в этой (Options > General > Compile > Compile On Demand) опции?
Странно, но у меня ничего не вылетает и нормально работает, если пропатчить процедуру в обычном модуле (у себя в проекте). Может не будет заранее компилироваться в IDE, если процедура находится в другом модуле? В крайнем случае можно просто попробовать ее вызывать перед патчингом...

Все пишу по памяти и через телефон, возможно в чем то ошибаюсь, Хакер поправит.

Откуда вы с Хакером все это знаете... Существует ли какой-то аспект в программировании, где вы что-то не знаете?

использую PowerBasic.

Кстати да, очень неплохая вещь
Где-то писали, что он генерирует очень эффективный и быстрый машинный код. Только ему не хватает хорошего IDE-редактора. Да и антивирус на него реагирует (как packed unknown). А так была бы бомбовая вещь... не понимаю, почему он так малопопулярен...

смотрел только CallWindowProc

DispCallFunc, оказывается, тоже немал) В принципе, можно попробовать сделать свою маленькую и быструю вставку, которая будет джампить по нужному указателю... ведь в стеке уже будут уложены аргументы

ассемлерная вставка занимает килобайты

Это, наверное, когда она прдставлена в виде DLL? А то как-то много для самой вставки... Самая маленькая вставка у меня занимает размер в пределах 8 байт...

и виде объектного файла, который на стадии сборки можно скомпоновать в один файл

Но тогда вставку нельзя будет изменять динамически.

На этапе компиляции этот модуль превратиться в объектный файл и вот тут нужно процесс прервать и подменить этот объектный файл другим подготовленным при помощи того же MASM например. И дальше процесс линковки влинкует его

Какие-то сложные малопонятные манипуляции для всего-лишь какой-то небольшой вставочки, мне так кажется... Можно ведь просто выделить исполняемую память и формировать затем вставку в ней. Или это плохой путь?

Только вот не знаю следующие моменты:
1. Как поступить лучше - через HeapAlloc новый кусок выделять или у байтового массива (Arr() As Byte, созданного в VB) просто изменить атрибуты (чтобы можно было исполнять) через VirtualProtect...
2. Где именно HeapCreate создает кучу, в том адресном пространстве, откуда был вызван, или куча теоретически может появиться где-то еще? Или тогда лучше использовать GetProcessHeap?
3. Если был выделен новый участок через HeapCreate и приложение вдруг обрушилось (в процессе исполнения вставки, например), будет ли этот выделенный участок уничтожен вместе в падением, или так и останется висеть?
4. DEP-Unsafe обрушение происходит только если DEP включен аппаратно? Дело в том, что при программном DEP у меня ничего не обрушается...

[Хакер]

А так была бы бомбовая вещь... не понимаю, почему он так малопопулярен...

Потому что шлак.

1. Как поступить лучше - через HeapAlloc новый кусок выделять или у байтового массива (Arr() As Byte, созданного в VB) просто изменить атрибуты (чтобы можно было исполнять) через VirtualProtect...

Лучше через HeapAlloc.

2. Где именно HeapCreate создает кучу, в том адресном пространстве, откуда был вызван, или куча теоретически может появиться где-то еще? Или тогда лучше использовать GetProcessHeap?

В адресном пространстве процессе, где ещё-то? Не лучше, потому что не у кучи, возвращённой по GetProcessHeap, не будет нужного флага.

3. Если был выделен новый участок через HeapCreate и приложение вдруг обрушилось (в процессе исполнения вставки, например), будет ли этот выделенный участок уничтожен вместе в падением, или так и останется висеть?

Безальтернативно — он не останется висеть.

4. DEP-Unsafe обрушение происходит только если DEP включен аппаратно? Дело в том, что при программном DEP у меня ничего не обрушается...

Не только.

[The trick]

Не совсем понятно, что значит вывести кнопку полной компиляции...

Full_start_example.PNG (2.93 Кб) Просмотров: 9144

А может, нужно просто снять крыжик в этой (Options > General > Compile > Compile On Demand) опции?

Даже не проверял.

DispCallFunc, оказывается, тоже немал)

Так он практически ничего лишнего не делает и отрабатывает быстро. То что размер большой - это не показатель, просто там большой select case, который оптимизирован.

Можно ведь просто выделить исполняемую память и формировать затем вставку в ней. Или это плохой путь?

Как делаю я обычно.

• создаю кучу с разрешением на исполнение и запись;
• полученный описатель кучи сохраняю в переменной-окружения;
• выделяю в этой куче память и пишу туда код.
• если среда была аварийно остановлена то я не пересоздаю кучу, а пользуюсь уже готовой просто получив описатель из переменной окружения;
• также предварительно я могу очистить все вставки если среда была остановлена и предыдущий сеанс отладки завершился аварийно;
• например там же я могу создать счетчик вставок, и если он обнуляется, то удалять кучу.

[sosed213]

Опять, спустя время, доделал проект.
Благодаря The trick, и его Add-in, получилось беспроблемно использовать библиотеку usb_relay_device.dll в IDE.
Это китайское реле встроил в сетевой фильтр (удлинитель) для управления парой розеток, с компьютера (для управления некоторыми устройствами).
Исходник выкладываю, может кому пригодится.