информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Сетевые кракеры и правда о деле ЛевинаГде водятся OGRыСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[ASM] Да, согласен... 22.10.01 10:52  Число просмотров: 1044
Автор: Chingachguk <Chingachguk> Статус: Member
<"чистая" ссылка>
> > Как же объяснить тогда, что прога :-) не видна ? Если
> она ничем особо от моей не отличается ?
> Причина в том, что я делал это в Win95 OSR2. Сейчас
> попробовал на Win98 SE - мой Int 13h вызывается (в DIskEdit
> виден результат).
> Резюме: если перехватить Int 13h до загрузки ДОС, Win95 его
> не будет вызывать, а Win98 - будет. Получается, что Win98
> совместима с ДОС больше, чем Win95, хотя должно быть
> наоборот IMHO :-)

Да, верно ! Я - то глядел все на свои 98-е. И думал, что раз у меня все очевидно работает, то где-то у тебя непонятки...
И стеллс, я так понимаю, не при чем ? (у тебя и у меня без стеллса на 98 винда вызывает наши перехватчики).

Получается, мы тут процесс взаимодействия винды с интом 13h вдоль и поперек изъездили ;)))
<programming>
[ASM] 16.10.01 09:39  
Автор: J Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Нужно сделать прогу на ASM, которая бы обрабатывала некоторым образом нажатия клавиш при работе в Windows. Подобную резидентную прогу сделал, но для DOS. Не знаю литературы такой направленности для Windows.

Подскажите где в сети можно поискать подобное или как хоть оно называться может.
[ASM] 20.10.01 10:47  
Автор: finder Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Нужно сделать прогу на ASM, которая бы обрабатывала
> некоторым образом нажатия клавиш при работе в Windows.
> Подобную резидентную прогу сделал, но для DOS. Не знаю
> литературы такой направленности для Windows.
>
> Подскажите где в сети можно поискать подобное или как хоть
> оно называться может.

если ты хочешь писать обработчик под винду, то следуй правилам винды. не делай геморрой из прерываний, бо это иногда чревато и не всегда срабатывает. использый системные средства. для твоей задачи подойдут ХУКИ "hook". поставь хук (при помощи АПИ) на обработку клавиатуры и делай что хочешь. даже на асме это будет сделать проще простого. можешь поискать сурс на VC++ на www.codeguru.com я там видел один сурс (наверное он щас в архиве) хука клавиатуры для эхпорера. изучи сурс и сделай что те надо, тока на асме и не страдай прерываниями.
в крайнем случае обратись к МСДН, там тоже есть про хуки. проблема тривиальная и решается стандартными средствами. преимущество хука будет в том, что ты можешь пользоваться стандартным системным сервисом, а также обрабатывать клавиши для любого активного процесса.
[ASM] 16.10.01 11:16  
Автор: Chingachguk <Chingachguk> Статус: Member
<"чистая" ссылка>
> Нужно сделать прогу на ASM, которая бы обрабатывала
> некоторым образом нажатия клавиш при работе в Windows.
> Подобную резидентную прогу сделал, но для DOS. Не знаю
> литературы такой направленности для Windows.
>
> Подскажите где в сети можно поискать подобное или как хоть
> оно называться может.

Если под виндовс 95/98, то можно смело писать резидента под дос, тока перехватывать не int 9h, как это делают, например, русификаторы, а int 16h. Резидент должен быть указан в autoexec.bat. Или раньше ;)))Под виндой ты увидишь работу обработчиков int 9h тока в дос-окнах, а вот схватив int 16h - во всех-всех приложениях. Можешь сделать для тестирования примерно так:

@New16Handler:
; ...
Скажем, если клавиша - пробел,
то beep - какой нибудь
; ...
jmp dword ptr old16Handler

- И beep ты услышишь при всяком нажатии пробела даже в ворде...
[ASM] Chingachguku 18.10.01 08:14  
Автор: J Статус: Незарегистрированный пользователь
<"чистая" ссылка>
int 16h ?
Не так давно в статье от одного умного человека я прочитал,что в защищенном режиме int 09h вообще не используется, а int 16h используется для чего-то другого - но точно не для определения нажатых клавиш.
[ASM] Chingachguku 18.10.01 09:32  
Автор: Chingachguk <Chingachguk> Статус: Member
<"чистая" ссылка>
> int 16h ?
> Не так давно в статье от одного умного человека я
> прочитал,что в защищенном режиме int 09h вообще не
> используется, а int 16h используется для чего-то другого -
> но точно не для определения нажатых клавиш.

А вот и нет. Винды 95/98 при своей работе используют некоторые сервисы биоса(В любых задачах - и в вордах, и т.п.).Скажем, для работы с винтом вовсю вызывается оригинальный Int 13h, для получения нажатых клавиш - оригинальный обработчик int 16h реального режима. Видимо, для их вызова винда переключается в режим v86. А вот для работы с дискетами у винды есть свой собственный драйвер, и оригинальный биос не вызывается. Почему так ? Видимо, ребята не рискнули полностью взять на себя работу с устройствами ... Так вот, когда винда при разборе autoexec.bat обнаруживает обработчик прерывания, котрое она собирается вызывать в дальнейшем - в нашем случае int 16h - то дает ему все те же права и точно так же вызывает, как и оригинальный код bios- через v86... А вот любой обработчик int 9h она почему-то не хочет вызывать всякий раз, а только лишь в дос-задачах (посмотри, что будет с keyrus-ом). Так что смело можешь писать резидента к int 16h - при загрузке через autoexec он будет получать управление при нажатии клавиш в любых задачах ...
ps А вот в NT такой фокус не пройдет - у них все драйверы свои. Наверное, и в более продвинутых системах типа linux - тем более.
[ASM] Chingachguku 19.10.01 09:01  
Автор: :-) <:-)> Статус: Elderman
<"чистая" ссылка>
> А вот и нет. Винды 95/98 при своей работе используют
> некоторые сервисы биоса(В любых задачах - и в вордах, и
> т.п.).Скажем, для работы с винтом вовсю вызывается
> оригинальный Int 13h, для получения нажатых клавиш -
> оригинальный обработчик int 16h реального режима. Видимо,
> для их вызова винда переключается в режим v86. А вот для
> работы с дискетами у винды есть свой собственный драйвер, и
> оригинальный биос не вызывается. Почему так ? Видимо,
> ребята не рискнули полностью взять на себя работу с
> устройствами ...

Это было сделано в целях совместимости.
В Win9x есть драйверы для всех устройств, и она вызывает обработчик прерывания реального режима, только если видит, что обработчик нестандортный (не принадлежит ДОС или БИОС). Это называется paging through MS-DOS, и конечно, снижает быстродействие.
А если Win9x видит у переывания стандартный обработчик, она использует свои драйверы защищенного режима, а прежний обработчик не вызывает.
Был такой вирус - OneHalf (для тех, кто не помнит - он пишется в MBR и перехватывает Int 13h еще _до_загрузки_ДОС.) В результате винда не замечала, что Int 13h было перехвачено и не вызывала вирусный обработчик Int 13h. Из=за этого часть винта, которую вирус успел зашифровать, не читалась, зато при загрузке в Safe Mode или Command Prompt все было OK :)

И вообще очевидно, в таких случаях лучше писать VxD...
[ASM] Chingachguku 19.10.01 15:39  
Автор: z0 <z0> Статус: Member
<"чистая" ссылка>
> Был такой вирус - OneHalf (для тех, кто не помнит - он
> пишется в MBR и перехватывает Int 13h еще
> _до_загрузки_ДОС.) В результате винда не замечала, что Int
> 13h было перехвачено и не вызывала вирусный обработчик Int
> 13h. Из=за этого часть винта, которую вирус успел
> зашифровать, не читалась, зато при загрузке в Safe Mode или
> Command Prompt все было OK :)

небольшое уточнение (как win9x определяет int13):

при старте атапишного драйвера (справедливо в общем случае и для scsi) винда читает несколько секторов начиная с CHS 0:0:1 через int13 и через драйвер. если результаты сходятся - грузится драйвер. если нет - режим совместимости через шлюз на int13
[ASM] Chingachguku 19.10.01 16:22  
Автор: Chingachguk <Chingachguk> Статус: Member
<"чистая" ссылка>
> небольшое уточнение (как win9x определяет int13):
>
> при старте атапишного драйвера (справедливо в общем случае
> и для scsi) винда читает несколько секторов начиная с CHS
> 0:0:1 через int13 и через драйвер. если результаты сходятся
> - грузится драйвер. если нет - режим совместимости через
> шлюз на int13

Точно !!! Я вот читал предидущее разъяснение и думал, почему когда я пробовал свой бут-вир под вин 98 гонять, то она (винда) безусловно через него работала, иначе гря - через стандартный биос. А в случае OneHalf - работала через свой драйвер (так, по крайней мере, выше написано) ?! Ну тогда понятно: у меня вирь был стеллс, а в этом случае р-ты через int 13h (я ему чистый подставлял mbr) и через драйвер немного разный результат получается ... ;)
Спасибо !
[ASM] Chingachguku 20.10.01 11:09  
Автор: z0 <z0> Статус: Member
<"чистая" ссылка>
> Точно !!! Я вот читал предидущее разъяснение и думал,
> почему когда я пробовал свой бут-вир под вин 98 гонять, то
> она (винда) безусловно через него работала, иначе гря -
> через стандартный биос. А в случае OneHalf - работала через
> свой драйвер (так, по крайней мере, выше написано) ?! Ну
> тогда понятно: у меня вирь был стеллс, а в этом случае р-ты
> через int 13h (я ему чистый подставлял mbr) и через драйвер
> немного разный результат получается ... ;)
> Спасибо !

так я тоже вирус делал ;-)

а если винде в int13 давать CHS 0:0:? правильно то вирус БУДЕТ работать!
[ASM] Хмм... 19.10.01 23:23  
Автор: :-) <:-)> Статус: Elderman
<"чистая" ссылка>
Что-то не стыкуется... OneHalf ведь тоже подставляет незараженный MBR.

Для проверки я написал 2 проги, обе перехватывают Int 13h. Мой обработчик при считыании сектора 0/0/1 заменяет первые 4 байта этого сектора нулями.

Первая прога перехватывает Int 13h до загрузки ДОС (запускается из MBR, как бут-вирус)
Вторая - после (обычная TSR, запускается из autoexec.bat)

1) Ставим в MBR первую прогу, загружаем Win95 OSR2, читаем первый сектор DiskEdit'ом - первые 4 байта оригинальные, т.е. система не вызвала мой обработчик, а считала сектор с помощью своих драйверов.
Загружаемся в Safe Mode или Command Prompt only, читаем первый сектор - в нем первые 4 байта - нули (т.е. обработчик-то действует :-)

2) Ставим в autoexec.bat вторую прогу, загружаем Win95 OSR2, читаем первый сектор DiskEdit'ом - первые 4 байта - нули.

Получается, что алгоритм не совсем такой, как описал z0.
Или это только у меня так ? :))


; Первая прога - компилить в .com и назвать newmbr.i13
.386
CODE            SEGMENT USE16
	        ASSUME  CS:CODE, DS:CODE, ES:CODE
                ORG     100H

Start:
		xor	ax, ax
		mov	si, 7C00h
		cli
		mov	sp, si
		mov	ss, ax
		sti
		mov	ds, ax
		push	ax
		push	si
		sub	word ptr ds:[413h], 4
		int	12h			; Put (memory size)/1K in ax
		shl	ax, 6
		mov	es, ax

		mov	di, offset Start
		push	es
		push	offset Cont_Boot
		cld
		mov	cx, 200h / 4
	rep	movsd
		retf

Cont_Boot:

		mov	ax, 201h
		pop	bx
		pop	es
		push	es
		push	bx
		mov	cx, 3
		mov	dx, 80h
		int	13h			; Disk  dl=drive 0  ah=func 02h
						;  read sectors to memory es:bx
						;   al=#,ch=cyl,cl=sectr,dh=head
		mov	ax, cs
		shl	eax, 16
		mov	es, ax			; ES = 0
		mov	ax, offset New_13h
		cli
		xchg	eax, es:[13h*4]
		mov	cs:Old_13h, eax
		sti
		retf


New_13h		proc	far
		pushf
		cmp	ah,2
		jne	Sys_13h
		cmp	cx, 1
		jne	Sys_13h
		cmp	dx, 80h
		jne	Sys_13h

		popf
		push	es
		push	bx	
		pushf
		call	cs:Old_13h
		pop	bx
		pop	es	
		mov	dword ptr es:[bx], 0
		retf	2
Sys_13h:
		popf
		db	0EAh
Old_13h 	dd	0
New_13h		endp

CODE            ENDS

		END	Start
// ------------------------------------------------
// Инсталляция в MBR
#include <stdio.h>
#include <io.h>
#include <fcntl.h>
#include <bios.h>

void main()
{
   int filedes;
   char buffer[512];

   biosdisk(_DISK_READ, 0x80, 0, 0, 1, 1, buffer);
   biosdisk(_DISK_WRITE, 0x80, 0, 0, 3, 1, buffer);

   filedes = open("newmbr.i13",  O_BINARY | O_RDONLY);
   if (filedes == -1)
   {
     printf("ERROR: Failed to open file 'newmbr.i13'\n");
     return;
   }
   long fl = filelength(filedes);
   if (fl > 0x100)
   {
     printf("ERROR: newmbr.i13 size is too big\n");
     return;
   }
   read(filedes, buffer, fl);
   close (filedes);
   biosdisk(_DISK_WRITE, 0x80, 0, 0, 1, 1, buffer);
}
// ------------------------------------------------
// Деинсталляция из MBR

#include <bios.h>

void main()
{
   char buffer[512];

   biosdisk(_DISK_READ, 0x80, 0, 0, 3, 1, buffer);
   biosdisk(_DISK_WRITE, 0x80, 0, 0, 1, 1, buffer);
}

;--------------------------------------------------
; Вторая прога (tsrint13.asm) 
.386
CODE            SEGMENT USE16
	        ASSUME  CS:CODE, DS:CODE, ES:CODE
                ORG     100H

Start:
		mov	ax, cs
		shl	eax, 16
		mov	es, ax			; ES = 0
		mov	ax, offset New_13h
		cli
		xchg	eax, es:[13h*4]
		mov	Old_13h, eax
		sti
		lea	dx, VeryEnd+1
		int	27h


New_13h		proc	far
		pushf
		cmp	ah,2
		jne	Sys_13h
		cmp	cx, 1
		jne	Sys_13h
		cmp	dx, 80h
		jne	Sys_13h

		popf
		push	es
		push	bx	
		pushf
		call	cs:Old_13h
		pop	bx
		pop	es	
		mov	dword ptr es:[bx], 0
		retf	2
Sys_13h:
		popf
		db	0EAh
Old_13h 	dd	0
New_13h		endp

VeryEnd:

CODE            ENDS

		END	Start

---
[ASM] Это не док-во !? 20.10.01 20:46  
Автор: Chingachguk <Chingachguk> Статус: Member
<"чистая" ссылка>
Это не доказательство !
Я прочел ваши сообщения (z0 и :-)). Резюме получилось вроде такое(извиняйте, если не так понял):

- Если запускаем бут-стеллс (OneHalf (действительно, он стеллс - я сча исходник его глянул) или мой со стеллсом), то винда безусловно вызывает сначала вирь, а уже вирь - сам биос;
- Если проги грузить через autoexec.bat, то винда по-честному вызывает их, а потом они сами биос - как выше;
- :-) Грит, что его mbr-прога не видна в диск-едиторе(жаль, не знаком) - если тока не грузимся в SaveMode;

Для проверки я сначала отключил в своем вире стеллс (могу исходник кинуть) и увидел, что все прекрасно вызывается (в смысле, мой код. Ставил beep - и слышал его переодически из разных задач(виндовых тоже)). Как же объяснить тогда, что прога :-) не видна ? Если она ничем особо от моей не отличается ? Я думаю так: разница в сравнении(как мы определяем, что наш код винда все же зовет). У него ТОЖЕ винда использует вовсю MBR-код. Я смотрю в отладчике в дос окне трассировку int 13h и прекрасно свой код вижу - после всяких там убыстритилей попадаю в свой сегмент, откушенный из ds:[413h]. А диск - едитор, видимо, зовет совсем не Int 13h, а 25h (или 26h - я не силен в них). Видимо, их эмуляция зависит от загрузки ?!

Получается, стеллс тут не причем, любой бут будет участвовать во всем-всем из-под виндов ?!. Я еще немного дальше пошел. Ведь ежели заражаешь бутом винды, то первый разок (у меня 98) винда грит, что у вас, видимо, вирь ... Но это стандартным, который грузается первым и вместо mbr... Я написал кодец, правда нерезидент - тайма не хватило -котрый просто заменяет в Parti.Table номер головки и сектора настоящего бута системы. То есть mbr выполняется, а загружает меня. А я ее еще раз, уже исправленную. Так вот, на такое изменение mbr винда уже молчит...
Видимо:
- Винда все же читает винт без биос, но в особых случаях: когда определяет, заражен ли mbr, причем только код его, а part.table - нет.
- Если код (именно код!) через биос отличен от оригинала(через вин драйвер), то принимается решение использовать везде его, те вир.
- Ну а если в autoexec - то всегда.
[ASM] Это не док-во !? 22.10.01 10:19  
Автор: :-) <:-)> Статус: Elderman
<"чистая" ссылка>
> Как же объяснить тогда, что прога :-) не видна ? Если она ничем особо от моей не отличается ?

Причина в том, что я делал это в Win95 OSR2. Сейчас попробовал на Win98 SE - мой Int 13h вызывается (в DIskEdit виден результат).

Резюме: если перехватить Int 13h до загрузки ДОС, Win95 его не будет вызывать, а Win98 - будет. Получается, что Win98 совместима с ДОС больше, чем Win95, хотя должно быть наоборот IMHO :-)
[ASM] Да, согласен... 22.10.01 10:52  
Автор: Chingachguk <Chingachguk> Статус: Member
<"чистая" ссылка>
> > Как же объяснить тогда, что прога :-) не видна ? Если
> она ничем особо от моей не отличается ?
> Причина в том, что я делал это в Win95 OSR2. Сейчас
> попробовал на Win98 SE - мой Int 13h вызывается (в DIskEdit
> виден результат).
> Резюме: если перехватить Int 13h до загрузки ДОС, Win95 его
> не будет вызывать, а Win98 - будет. Получается, что Win98
> совместима с ДОС больше, чем Win95, хотя должно быть
> наоборот IMHO :-)

Да, верно ! Я - то глядел все на свои 98-е. И думал, что раз у меня все очевидно работает, то где-то у тебя непонятки...
И стеллс, я так понимаю, не при чем ? (у тебя и у меня без стеллса на 98 винда вызывает наши перехватчики).

Получается, мы тут процесс взаимодействия винды с интом 13h вдоль и поперек изъездили ;)))
[ASM] Хмм... 20.10.01 11:25  
Автор: z0 <z0> Статус: Member
<"чистая" ссылка>
> Получается, что алгоритм не совсем такой, как описал z0.

я не описывал никакого алгоритма
речь шла о том работает винда через int13 (DISK ? USE MS-DOS COMPATIBILITY MODE) или своим драйверок

а ты не указал в своих случаях кстати что происходило

по-поводу почему у тебя так работает предположу что сработала досовская функия получения REAL_INT13_HANDLER которая проверяет вызов из биоса или из другого участка памяти

никто так не делает - грубо меняет обработчик
надо искать в биосе CD ?? ставить его обработчик и направлять int13 на эту команду
[ASM] Хмм... 20.10.01 14:47  
Автор: :-) <:-)> Статус: Elderman
<"чистая" ссылка>
> > Получается, что алгоритм не совсем такой, как описал
> z0.
>
> я не описывал никакого алгоритма
> речь шла о том работает винда через int13 (DISK ? USE
> MS-DOS COMPATIBILITY MODE) или своим драйверок

Приехали :( Ты описывал алгоритм, по которому винда определяет, как работать с диском: через свой драйвер или через Int13.

> а ты не указал в своих случаях кстати что происходило
>
Да все я указал:
Если перехватить Int 13 до загрузки ДОС, винда работает через свой драйвер. А если перехватить Int 13 после загрузки ДОС, от винда работает через Int 13.
Похоже она просто смотрит на адрес обработчика Int13 - если он принадлежит ДОС или БИОС, винда загружает свой драйвер, если нет - работает через Int 13.
А если бы она использовала тот алгоритм, кот-й ты описал, винда работала бы через Int 13 независимо от того, когда было перехвачено Int 13: до или после ДОС

> по-поводу почему у тебя так работает предположу что
> сработала досовская функия получения REAL_INT13_HANDLER
> которая проверяет вызов из биоса или из другого участка
> памяти
>
> никто так не делает - грубо меняет обработчик

Большнство бутовых вирусов это делает

> надо искать в биосе CD ?? ставить его обработчик и
> направлять int13 на эту команду

Знаю, Adinf так когда-то обходили... изврат это :)
Похоже мы друг друга не поняли :-)
[ASM] резюме 21.10.01 16:01  
Автор: z0 <z0> Статус: Member
<"чистая" ссылка>
> Похоже мы друг друга не поняли :-)

да чего там понимать, подумаешь бином ньютона...

давай подведем черту:

1) при загрузке доса проверяется - показывает обработчик int13 на BIOS (адрес выше a0000) или на RAM. в досе 5 это уже точно было
это я так понимаю сделано для разделения перехватчиков int13 на те что нужны для работы с дисками (типа EBIOS.SYS by OnTrack) и тех что не нужны (типа смартдрайва) чтобы можно было из config.sys например подключить к int13 ASPI DISK правильно а не через кеш и т.п. и тогда уже real_int13 будет показывать на RAM, это можно сделать и из MBR и из конфига и из автоекзека. поэтому для перехватчика из MBR ити BOOT важно КУДА_НАПРАВИТЬ а для перехватчика из AUTOEXEC важно КАК_ПЕРЕХВАТЫВАТЬ т.к. mov es:[13h*4],eax уже не прокатит - у ДОСа уже сохранен правильный адрес int13 и он его продаст винде а энтот перехватчик будет классифиирован как дикий кеш ;-)

2) при загрузке виндовой части виндов винда интересуется у доса и если real_int13 показывает на RAM то считает что запущен штатный драйвер нестандартного блочного устройства и работает через int13
нечто похожее происходит если грузить в конфиг.цыц т.н. 16-битный драйвер сидирома

3) если int13 показывает на ROM то винда считывает для проверки сектора через int13 и свое чудо и сравнивает - если совпало можно грузить драйвер
видимо при отладке разработчики частенько сталкивались с кривыми биосами-контроллерами, а поскольку setup виндовый работает через int13 необходимо чтобы системный диск читался/писался одинаково

4) а вот куда мы не добрались в споре - потом уже в работе при вызове например из дос-бокса int13 тем же дискедитором оно эмулируется или передается в настоящий int13 ? я на какой-то версии видел что передается но не думаю что это так везде


PS: прокомментируй плиз свой код:

popf
push es
push bx
pushf
call cs:Old_13h
pop bx
pop es
mov dword ptr es:[bx], 0
retf 2

зачем PUSH/POP ES,BX ?
[ASM] резюме 22.10.01 10:38  
Автор: :-) <:-)> Статус: Elderman
<"чистая" ссылка>
> 2) при загрузке виндовой части виндов винда интересуется у
> доса и если real_int13 показывает на RAM то считает что
> запущен штатный драйвер нестандартного блочного устройства
> и работает через int13
> нечто похожее происходит если грузить в конфиг.цыц т.н.
> 16-битный драйвер сидирома

Это в Win98, а Win95 OSR2 как выяснилось real_int13 не анализирует и поэтому мой хук не вызывался

> 4) а вот куда мы не добрались в споре - потом уже в работе
> при вызове например из дос-бокса int13 тем же дискедитором
> оно эмулируется или передается в настоящий int13 ? я на
> какой-то версии видел что передается но не думаю что это
> так везде

Если вся винда работает через Int 13, то очевидно оно передается в настоящий int13 и в дос-боксе тоже

>
>
> PS: прокомментируй плиз свой код:
>
> popf
> push es
> push bx
> pushf
> call cs:Old_13h
> pop bx
> pop es
> mov dword ptr es:[bx], 0
> retf 2
>
> зачем PUSH/POP ES,BX ?

Обычная паранойя :-)
А вдруг после call cs:Old_13h изменятся ES:BX ? Лучше сейчас 4 лишних байта написать, чем потом с дискетки грузиться IMHO :-)
[ASM] резюме 26.10.01 11:28  
Автор: z0 <z0> Статус: Member
<"чистая" ссылка>
> Это в Win98, а Win95 OSR2 как выяснилось real_int13 не
> анализирует и поэтому мой хук не вызывался

ну понятно, я имел в виду 98

> >
> >
> > PS: прокомментируй плиз свой код:
> >
> > popf
> > push es
> > push bx
> > pushf
> > call cs:Old_13h
> > pop bx
> > pop es
> > mov dword ptr es:[bx], 0
> > retf 2
> >
> > зачем PUSH/POP ES,BX ?
>
> Обычная паранойя :-)
> А вдруг после call cs:Old_13h изменятся ES:BX ? Лучше
> сейчас 4 лишних байта написать, чем потом с дискетки
> грузиться IMHO :-)

действительно он изменится например на 8 функции и даст никому не нужный указатель прибив правильный ES
[ASM] а вот вам исходничек на закусь, на многие вопросы ответит 21.10.01 16:31  
Автор: z0 <z0> Статус: Member
<"чистая" ссылка>
comment #
This is MBR. It monitors IDE port 0 master disk and int 13h.
Coded in Russia by z0, 1998. (WATCOM C/C++ 11.0)
With utils: install.asm, restore.asm, test.asm.
E:\Z0\MBR\>wasm mbr.asm
E:\Z0\MBR\>wlink file mbr.obj format dos com name mbr.bin
E:\Z0\MBR\>install
<CTRL-ALT-DEL>
#

v_start equ 80h ;from vector 80h to vector
v_stop equ 90h ;8fh we search in BIOS for 'cd vector'
i_0 equ 13h*4 ;interrupt 0 offset in vector table
i_1 equ 01h*4 ;interrupt 1 offset in vector table
i_2 equ 21h*4 ;interrupt 1 offset in vector table

.386p
cs16 segment use16 byte
assume cs:cs16
assume ds:cs16
org 7c00h
c_0: cli
cld
xor cx,cx
mov ds,cx
mov di,0f000h
mov es,di
shl edi,10h ;mov edi,0f0000000h
mov al,0cdh
mov bx,v_start
c_2: dec cx ;mov cx,0ffffh
c_3: repnz scasb
jnz c_4
cmp es:[di],bl
jnz c_3
jmp c_5
c_4: inc bx
inc di ;xor di,di
cmp bx,v_stop
jnz c_2
hlt
c_5: dec di ;edi - BIOS seg:off 'cd bl'
mov eax,ds:[i_0]
mov ds:[i_0],edi ;new i_0 ->BIOS handler
mov [i_0_1],edi ;i_1 -> i_0 (relocation)
mov [i_0_0],eax ;old i_0 handler (relocation)
shl bx,2
xor eax,eax
mov ax,bx
add ax,4
mov [bx],eax ;new i_0 BIOS-> handler
mov cx,e_1 ;handlers' total size
push ds
pop es
mov si,offset i_0_c ;handlers' entry
mov di,ax ;where to copy
add ax,((offset i_1_c)-(offset i_0_c))
mov [i_1_0],eax ;i_0 -> i_1 (relocation)
mov ds:[i_1],eax ;new i_1 handler
add ax,((offset i_2_c)-(offset i_1_c))
mov [i_2_0],eax ;i_0 -> i_2 (relocation)
rep movsb
mov eax,cr4
or eax,8 ;i/o breakpoints
mov cr4,eax
mov eax,1f6h ;ide 0 master
mov dr0,eax
mov eax,020703h ;enable port trace
mov dr7,eax
sti
mov di,7bfeh
mov word ptr [di],13cdh
mov cx,1
mov dx,80h
mov bx,7c00h
mov ax,201h
jmp di ;local reboot

;i_0 handler on DOS stack. Called by int 13 (DOS) -> int 8?h (BIOS).
i_0_c: add sp,6 ;remove int 8?'s data from stack
db 66h ;install i_1 handler
db 2eh
db 0c7h
db 6
dw i_1 ;i_1 offset in cs:
i_1_0 dd 0 ;(relocation)
push ax
push bx
push es
mov ax,es
sub ax,11h
; js b_5
jmp b_5
mov es,ax
cmp byte ptr es:[bx],5ah
jnz b_5
db 0e8h ;call cs:[ip+0]
dw 0
b_2: pop bx
add bx,((offset i_2_0)-(offset b_2))
mov eax,cs:[i_2]
cmp eax,cs:[bx] ;i_2->i_2 ?
jz b_5 ;yes
add bx,((offset i_2_2)-(offset i_2_0))
mov cs:[bx],eax
db 66h ;install i_2 handler
db 2eh
db 0c7h
db 6
dw i_2 ;i_2 offset in cs:
i_2_0 dd 0 ;(relocation)
b_5: pop es
pop bx
pop ax
b_4: test cx,0ffc0h ;cylinder
jnz b_0
cmp dx,80h ;drive/head
jnz b_0
cmp ah,2 ;ah=0 reset, ah=1 status
jb b_0
cmp ah,0bh ;normal BIOS ends r/w here
ja b_0
cmp ah,8 ;get params
jz b_0
cmp ah,9 ;set params
jz b_0
cmp al,1 ;sector count
jnz b_0
cmp cl,2 ;sector number
jb b_1
ja b_3
jz b_0
b_1: inc cl
jmp b_0
b_3: mov cl,3
b_0: db 0eah
i_0_0 dd 0 ;(relocation)

;i_1 handler on caller's stack. Called by hardware i/o breakpoint
i_1_c: db 66h ;install i_0 handler
db 2eh
db 0c7h
db 6
dw i_0
i_0_1 dd 0 ;(relocation)
push ax
mov eax,dr6
bt eax,13
jnc y_3
hlt
y_3: pop ax
push ax
push dx
push bx
cmp dx,1f6h ;drive/head
jnz y_0
test al,1fh ;drive 0, head 0 ?
jnz y_0 ;not
mov bl,al
dec dx ;cylinder high
in al,dx
mov ah,al
dec dx ;cylinder low
in al,dx
or ax,ax
jnz y_0
sub dx,2 ;sector count
in al,dx
cmp al,1
jnz y_0
inc dx ;sector number
in al,dx
test bl,040h ;LBA ?
mov bl,0
jnz y_4 ;yes
inc bl
y_4: inc bl
cmp al,bl
jz y_0
ja y_1
inc al
jmp y_2
y_1: add bl,3eh
cmp al,bl
jae y_0
sub bl,3dh
mov al,bl
y_2: out dx,al
y_0: pop bx
pop dx
pop ax
iret ;repeat command with RF=1

;i_2 handler on DOS stack. Called by DOS
i_2_c: cmp ah,4bh
jnz r_0
push ax
push dx
push bx
mov al,4
xor dx,dx
r_3: push ax
out 70h,al
in al,71h
push ax
and al,0f0h
shr al,4
or al,30h
call s_0
pop ax
and al,0fh
or al,30h
call s_0
mov al,3ah
call s_0
pop ax
sub ax,2
inc dx
cmp dx,3
jnz r_3
mov al,20h
call s_0
pop bx
pop dx
pop ax
push ax
push dx
push bx
r_2: push dx
pop bx
mov al,[bx]
or al,al
jz r_1
call s_0
inc dx
jmp r_2
r_1: mov al,0ah
call s_0
mov ax,0dh
call s_0
pop bx
pop dx
pop ax
r_0: db 0eah ;to real handler
i_2_2 dd 0 ;(relocation)

s_0: mov ah,0eh
xor bx,bx
int 10h
retn

z0 db 'Coded in Russia by z0, 1998'

e_1 equ $-i_0_c
org 7dfeh
dw 0aa55h ;this must be
cs16 ends
end c_0
Народ, спасибо за общественно полезный разговор! 26.10.01 19:19  
Автор: alad Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Я только начал учить ассамблер и было очень интересно почитать вашу беседу. Только вы пожалуйста почаще общайтесь, тогда у нас будет больше народу пишущего на ASM'е. Спасибо!
1  |  2 >>  »  




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach