Здравсвуйте всем.

У нас следующая проблема, необходимо под Windows (в принципе в любой, а желательно разобраться как в какой) считывать регистр LPT порта или перехватывать прерывания от него

Как это сделать под Windows, заранее благодарен, Алексей.

Здравствуйте Аноним, вы писали:

А> Здравсвуйте всем.

А> У нас следующая проблема, необходимо под Windows (в принципе в любой, а желательно разобраться как в какой) считывать регистр LPT порта или перехватывать прерывания от него

А> Как это сделать под Windows, заранее благодарен, Алексей.

Под NT — писать parallel port class driver, пример есть в DDK, под 9х — в принципе, и так (in/out) сойдет. По крайней мере, в некоторых версиях 95 работало.

S> Под NT — писать parallel port class driver, пример есть в DDK, под 9х — в принципе, и так (in/out) сойдет. По крайней мере, в некоторых версиях 95 работало.

Да ну!
Обычный Legasy драйвер сойдет , многое зависит от того какой контроллер прерываний используется APIC или PIC.
Если PIC то понятно какое софтверное прерывание будет соответствовать IRQ принтера,
если APIC все несколько сложнее.
Для PIC контроллера , соответствие SOftware Interrupt и IRQ расчитываются следующим образом:
SoftInt = IrqN + 0x30h — для NT подобных операционок , к примеру прерывание таймера IRQ0
SoftInt = 0 + 0x30h = > int 0x30h в таблице idt соответственно находится адресс обработчика прерывания таймеры по вектору 0x30.
Для машин с hypertrading или просто многопроццесорных машин обладающих APIC контроллерами все сложнее те могут индивидуальным IQR присвоить индивидуальные int x .
Соответственно расчитаем int для LPT (для PIC контроллера):
для LPT1 — IRQ7
int 0x37
lkz ДЗЕ2 — IRQ5
int 0x35
Подключить свой обработчик к прерыванию можно с помощью системного вызова
IoConnectInterrupt или както так, точно непомню, самостоятельно корректировать IDT
не рекомендую можно такой херни накрутить.

status = IoConnectInterrupt(&DeviceExtension->InterruptObject, // InterruptObject
InterruptIsr, // ServiceRoutine
DeviceObject, // ServiceContext
NULL, // SpinLock
MappedVector, // Vector
Irql, // Irql
Irql, // SynchronizeIrql
Latched, // InterruptMode
FALSE, // ShareVector
DeviceExtension->Affinity, // ProcessorEnableMask
FALSE);

Здравствуйте, Аноним, Вы писали:

S>> Под NT — писать parallel port class driver, пример есть в DDK, под 9х — в принципе, и так (in/out) сойдет. По крайней мере, в некоторых версиях 95 работало.

А>Да ну!
А>Обычный Legasy драйвер сойдет , многое зависит от того какой контроллер прерываний используется APIC или PIC.
А>Если PIC то понятно какое софтверное прерывание будет соответствовать IRQ принтера,
А>если APIC все несколько сложнее.
А>Для PIC контроллера , соответствие SOftware Interrupt и IRQ расчитываются следующим образом:
А>SoftInt = IrqN + 0x30h — для NT подобных операционок , к примеру прерывание таймера IRQ0
А>SoftInt = 0 + 0x30h = > int 0x30h в таблице idt соответственно находится адресс обработчика прерывания таймеры по вектору 0x30.
А>Для машин с hypertrading или просто многопроццесорных машин обладающих APIC контроллерами все сложнее те могут индивидуальным IQR присвоить индивидуальные int x .
А>Соответственно расчитаем int для LPT (для PIC контроллера):
А>для LPT1 — IRQ7
А>int 0x37
А>lkz ДЗЕ2 — IRQ5
А>int 0x35
А>Подключить свой обработчик к прерыванию можно с помощью системного вызова
А>IoConnectInterrupt или както так, точно непомню, самостоятельно корректировать IDT
А>не рекомендую можно такой херни накрутить.

А>status = IoConnectInterrupt(&DeviceExtension->InterruptObject, // InterruptObject
А> InterruptIsr, // ServiceRoutine
А> DeviceObject, // ServiceContext
А> NULL, // SpinLock
А> MappedVector, // Vector
А> Irql, // Irql
А> Irql, // SynchronizeIrql
А> Latched, // InterruptMode
А> FALSE, // ShareVector
А> DeviceExtension->Affinity, // ProcessorEnableMask
А> FALSE);


Многое так-же зависит от типа прерывания , как известно они (прерывания бывают Latched и не лэтчед), разница лишь в том что считать прерыванием , изменение фронта сигнала на соответствующей ножке процессора/контроллера , или извменение уровня.
К примеру прерывания от COM портов меняются по фронту , это неизбежно приводит к неправильной работе мыши на com1 и модема на com3.
Напоминаю что устройства впринципе вполне спокойной могут бесконфликтно работать на одном irq вместе если драйвер написан правильно(исключение COM порты).

Здравствуйте, Аноним, Вы писали:

А> Здравсвуйте всем.

А> У нас следующая проблема, необходимо под Windows (в принципе в любой, а желательно разобраться как в какой) считывать регистр LPT порта или перехватывать прерывания от него

А> Как это сделать под Windows, заранее благодарен, Алексей.

Можно так-же модифицировать карту ввода вывода , так называемый IOPM,
которы отображается из TSS всем процессам в виндах и получить доступ
к портам в NT/2000/XP из пользовательского режима.
Вобщем гугли по слову "gwiopm" .Гдето на www.torry.net или както так лежал пример как это делать .
А на www.void.ru лежала статья и исходники для работы с портами , т.е. можно при помощи маленького драйвера , спокойно обеспечивать доступ к портам из USER_MODE:
только дрова нада будет скомпилить и все.

Здравствуйте, Аноним, Вы писали:

А> Здравсвуйте всем.

А> У нас следующая проблема, необходимо под Windows (в принципе в любой, а желательно разобраться как в какой) считывать регистр LPT порта или перехватывать прерывания от него

А> Как это сделать под Windows, заранее благодарен, Алексей.

Под NT можно работать с портами ввода-вывода из 3 кольца. Правда это требует специфичных привилегий, которые обычно отключены во всех аккаунтах и группах ( кроме SYSTEM )
http://borland.xportal.ru/forum/viewtopic.php?t=12828&start=3

TC>Под NT можно работать с портами ввода-вывода из 3 кольца. Правда это требует специфичных привилегий, которые обычно отключены во всех аккаунтах и группах ( кроме SYSTEM )
TC>http://borland.xportal.ru/forum/viewtopic.php?t=12828&start=3

Да не привелегий а установки соответствующих битов в IOPM, можно просто модифицировать
располеженный в TSS IOPM который копируется оттуда в контекст каждого процесса и все .

Здравствуйте, Аноним, Вы писали:

TC>>Под NT можно работать с портами ввода-вывода из 3 кольца. Правда это требует специфичных привилегий, которые обычно отключены во всех аккаунтах и группах ( кроме SYSTEM )
TC>>http://borland.xportal.ru/forum/viewtopic.php?t=12828&start=3

А>Да не привелегий а установки соответствующих битов в IOPM, можно просто модифицировать
А>располеженный в TSS IOPM который копируется оттуда в контекст каждого процесса и все .
Читать вот тут:
http://www.torry.ru/comments/gwiopm/gwiopm_code.htm
без всяких try,except можно обойтись и без исключений , все можно сделать красиво.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

TC>>>Под NT можно работать с портами ввода-вывода из 3 кольца. Правда это требует специфичных привилегий, которые обычно отключены во всех аккаунтах и группах ( кроме SYSTEM )
TC>>>http://borland.xportal.ru/forum/viewtopic.php?t=12828&start=3

А>>Да не привелегий а установки соответствующих битов в IOPM, можно просто модифицировать
А>>располеженный в TSS IOPM который копируется оттуда в контекст каждого процесса и все .
А>Читать вот тут:
А>http://www.torry.ru/comments/gwiopm/gwiopm_code.htm
А>без всяких try,except можно обойтись и без исключений , все можно сделать красиво.

Вот это как раз ни хера некарсиво — требуется устанавливать какой то левый драйвер в системе. В то время как NT сама позволяет для любого процесса менять привелегию инструкций in/out ( по умолчанию они привелигированные и могут выполнятся только в 0 кольце ) — меняется значение IOPL в регистре флагов для указанного процесса . Код, приведенный мной, не требует установки драйверов. При наличии драйвера лучше работать прямо в ядре — написать свой фильтр к parport.sys или yfghzve.

TC>Вот это как раз ни хера некарсиво — требуется устанавливать какой то левый драйвер в системе. В то время как NT сама позволяет для любого процесса менять привелегию инструкций in/out ( по умолчанию они привелигированные и могут выполнятся только в 0 кольце ) — меняется значение IOPL в регистре флагов для указанного процесса . Код, приведенный мной, не требует установки драйверов. При наличии драйвера лучше работать прямо в ядре — написать свой фильтр к parport.sys или yfghzve.

Да с помощью тех недокументированых функций (которые в gwiopm описаны) , можно спокойно определять права в карте IOPL для конкретно заданного процесса-это красиво ,удобно , не напрягает SEH, в отличие от твоего примера, к томуже это просто напросто правольно.
И еще откуда ты знаешь как часто обновляется IOPL для процесса из TSS??? И при каких условиях? Случится событие :


/* Этот код демонстрирует подход к модификации базы IOPM методом “грубой силы”.

* база IOPM хранится в 2-байтном числе по смещению 0x66 в TSS,

* как документировано в описании процессора. В Windows NT IOPM хранится

* внутри TSS по смещениб 0x88, и занимает 0x2004 байта.

* Это нигде не документировано, и выяснено непосредственным просмотром.

* код здесь помещает несколько нулей в IOPM после чего мы можем попытаться

* обратиться к некоторым портам в/в, после чего изменяет базовый адрес IOPM.

* Этот код нерабочий потому что NT перезаписывает базу IOPM при переключении

* процессов. */
Случится в момент работы твоей проги task switch и досвидание.
Ты это проверял? Почему тогда так однозначно заявляешь??

http://www.void.ru/?do=printable&id=701

Здравствуйте, Аноним, Вы писали:

TC>>Вот это как раз ни хера некарсиво — требуется устанавливать какой то левый драйвер в системе. В то время как NT сама позволяет для любого процесса менять привелегию инструкций in/out ( по умолчанию они привелигированные и могут выполнятся только в 0 кольце ) — меняется значение IOPL в регистре флагов для указанного процесса . Код, приведенный мной, не требует установки драйверов. При наличии драйвера лучше работать прямо в ядре — написать свой фильтр к parport.sys или yfghzve.

А>Да с помощью тех недокументированых функций (которые в gwiopm описаны) , можно спокойно определять права в карте IOPL для конкретно заданного процесса-это красиво ,удобно , не напрягает SEH, в отличие от твоего примера, к томуже это просто напросто правольно.
А>И еще откуда ты знаешь как часто обновляется IOPL для процесса из TSS??? И при каких условиях? Случится событие :


А>/* Этот код демонстрирует подход к модификации базы IOPM методом “грубой силы”.

А>* база IOPM хранится в 2-байтном числе по смещению 0x66 в TSS,

А>* как документировано в описании процессора. В Windows NT IOPM хранится

А>* внутри TSS по смещениб 0x88, и занимает 0x2004 байта.

А>* Это нигде не документировано, и выяснено непосредственным просмотром.

А>* код здесь помещает несколько нулей в IOPM после чего мы можем попытаться

А>* обратиться к некоторым портам в/в, после чего изменяет базовый адрес IOPM.

А>* Этот код нерабочий потому что NT перезаписывает базу IOPM при переключении

А>* процессов. */
А>Случится в момент работы твоей проги task switch и досвидание.
А>Ты это проверял? Почему тогда так однозначно заявляешь??

А>http://www.void.ru/?do=printable&id=701

Сдается мне, что Вы не смотрели на код ( он кстати не мой ) который я привел. А если смотрели то не поняли в чем дело; рассуждения по поводу task switch и обнновления IOPL из TSS — полный бред. Не нужно никакого драйвера, не нужно кода 0 кольца, никаких "грубых сил" — процессу можно вполне легально ( средствами ОС ) установить IOPL = 3.

> располеженный в TSS
>
А откуда такая информация, что винда использует TSS?
Я всю жизнь думал, что она брезгует этим аппаратным механизмом!!!

Здравствуйте, Stanky, Вы писали:

S>А откуда такая информация, что винда использует TSS?
S>Я всю жизнь думал, что она брезгует этим аппаратным механизмом!!!

Могу ошибаться... Насколько я знаю, с точки зрени я "аппаратного механизма" в Windows ровно один процесс. Или что-то около того. Как минимум один необходим, т.к. TSS используется при переключении процессора из 3 в 0 кольцо и обратно.

А>>* процессов. */
А>>Случится в момент работы твоей проги task switch и досвидание.
А>>Ты это проверял? Почему тогда так однозначно заявляешь??

А>>http://www.void.ru/?do=printable&id=701

TC>Сдается мне, что Вы не смотрели на код ( он кстати не мой ) который я привел. А если смотрели то не поняли в чем дело; рассуждения по поводу task switch и обнновления IOPL из TSS — полный бред. Не нужно никакого драйвера, не нужно кода 0 кольца, никаких "грубых сил" — процессу можно вполне легально ( средствами ОС ) установить IOPL = 3.

Да смотрел я этот исходник смотрел , Вы вообще понимаете почему происходит исключение в том -самом исходнике и почему приходится его давить? Если бы все было так сказочно как вам показалось оно бы не возникало ,
еще раз прочтите пожалйста это:
http://www.void.ru/?do=printable&id=701
чтобы мы говорили с вами на одном языка и чтобы Вы поняли откуда берется тот самый IOPL и как он связан с IOPM.

Здравствуйте, Stanky, Вы писали:

>> располеженный в TSS
>>
S>А откуда такая информация, что винда использует TSS?
S>Я всю жизнь думал, что она брезгует этим аппаратным механизмом!!!

Повторяю ссылку :
http://www.void.ru/?do=printable&id=701
читайте и все станет понятно. На void.ru туфту редко прогоняли покрайней мере в те времена.

Здравствуйте, TarasCo, Вы писали:

TC>Здравствуйте, Аноним, Вы писали:

TC>>>Вот это как раз ни хера некарсиво — требуется устанавливать какой то левый драйвер в системе. В то время как NT сама позволяет для любого процесса менять привелегию инструкций in/out ( по умолчанию они привелигированные и могут выполнятся только в 0 кольце ) — меняется значение IOPL в регистре флагов для указанного процесса . Код, приведенный мной, не требует установки драйверов. При наличии драйвера лучше работать прямо в ядре — написать свой фильтр к parport.sys или yfghzve.

А>>Да с помощью тех недокументированых функций (которые в gwiopm описаны) , можно спокойно определять права в карте IOPL для конкретно заданного процесса-это красиво ,удобно , не напрягает SEH, в отличие от твоего примера, к томуже это просто напросто правольно.
А>>И еще откуда ты знаешь как часто обновляется IOPL для процесса из TSS??? И при каких условиях? Случится событие :


TC>Сдается мне, что Вы не смотрели на код ( он кстати не мой ) который я привел. А если смотрели то не поняли в чем дело; рассуждения по поводу task switch и обнновления IOPL из TSS — полный бред. Не нужно никакого драйвера, не нужно кода 0 кольца, никаких "грубых сил" — процессу можно вполне легально ( средствами ОС ) установить IOPL = 3.

Сдается мне что Вы вообще даже не догадываетесь о механизмах работы IOPM,IOPL e.t.c.

Цитата:
Вместо того чтобы статически определять какие уровни привилегий могут иметь доступ к в/в, CPU определяет уровень привилегий ввода/вывода – I/O Privilege Level (IOPL), значение которого сравнивается с CPL чтобы узнать могут ли команды в/в свободно использоваться. IOPL хранится в двух битах регистра EFLAGS (биты 12,13). Любой процесс с CPL численно большим чем IOPL должен пройти через мезанизм защиты в/в при попытке доступа к портам в/в. Так как IOPL не может быть меньше 0, программы, исполняющиеся на уровне привилений 0 (например, kernel-mode драйвера устройств) будут всегда иметь прямой доступ к портам в/в. NT устанавливает IOPL в 0. Код режима пользователя всегда имеет CPL 3, что больше чем IOPL. Следовательно, доступ к портам в/в в режиме пользователя должен проходить через механизм защиты. Определение того что CPL>IOPL – это первый этам в механизме защиты. Защита в/в – не по типу “всё или ничего”. Процессор использует гибкий механизм, который позволяет операционной системе предоставлять доступ к любому подмножеству портов в/в для каждой отдельной задачи.
взято с:
http://www.void.ru/?do=printable&id=701

А теперь объясните мне к каким именно портам дает доступ ваш метод ??????
Напоминаю:

это первый этам в механизме защиты. Защита в/в – не по типу “всё или ничего”. Процессор использует гибкий механизм, который позволяет операционной системе предоставлять доступ к любому подмножеству портов в/в для каждой отдельной задачи.

Так всетаки к каким именно портам вы получаете доступ с помощью рекомендованного Вами механизма?

Напоминаю:
IOPL хранится в двух битах регистра EFLAGS (биты 12,13).

Насколько я понимаю EFLAGS в вашем примере не используется.

TC>Сдается мне, что Вы не смотрели на код ( он кстати не мой ) который я привел. А если смотрели то не поняли в чем дело; рассуждения по поводу task switch и обнновления IOPL из TSS — полный бред. Не нужно никакого драйвера, не нужно кода 0 кольца, никаких "грубых сил" — процессу можно вполне легально ( средствами ОС ) установить IOPL = 3.

И что???

Процессор производит это с использованием битового массива, где каждый бит соответствует порту в/в. Если бит установлен в 1, доступ запрещён, и при доступе к соответствующему порту произойдет исключение(exception). Если бит установлен в 0, то к данному порту предоставлен прямой и беспрепятственный доступ.

Эксепшн откуда берется???
И что толку от того что он гасится???? try () e.t.c ?

Здравствуйте, Stanky, Вы писали:

>> располеженный в TSS
>>
S>А откуда такая информация, что винда использует TSS?
S>Я всю жизнь думал, что она брезгует этим аппаратным механизмом!!!

Ага многие думают что она и LDT брезгует . И забывают о существовании WOW16

Здравствуйте, Аноним, Вы писали:

А>Да смотрел я этот исходник смотрел , Вы вообще понимаете почему происходит исключение в том -самом исходнике и почему приходится его давить? Если бы все было так сказочно как вам показалось оно бы не возникало ,
А>еще раз прочтите пожалйста это:
А>http://www.void.ru/?do=printable&id=701
А>чтобы мы говорили с вами на одном языка и чтобы Вы поняли откуда берется тот самый IOPL и как он связан с IOPM.

Мне чего то не хочется с Вами на одном языке говорить......