информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Очередное исследование 19 миллиардов... 
 Оптимизация ввода-вывода как инструмент... 
 Зловреды выбирают Lisp и Delphi 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
если вы видите этот текст, отключите в настройках форума использование JavaScript
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





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

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

а если винде в int13 давать CHS 0:0:? правильно то вирус БУДЕТ работать!
<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-2025 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach