> Попытался сделать по твоему совету. Прописал его в > автоэкзеке. Но комп > зависает при загрузке виндов.А с 09h загружается, но только > в DN и NC работает. Если есть приведи исходник,пожалуйста.
Ты немного ошибся вот в чем: прерывание Int 16h возвращает в качестве ответа - была ли нажата клавиша - установленный или сброшенный флаг ZF ! Ниже я указал, где именно !
> ;...
> main_ proc far > jmp init > > old_16h dd 0 > counter_ dw 0 > > new_16h: > cli > pushf > call cs:old_16h ; Флаг ZF установлен ! Его надо вернуть !!!
; А ты его сбрасываешь командой iret (у тебя она в конце)
> push ax ; Тут ты что-то делаешь ....
> pop ax > sti > iret ; А вот iret вернет вызывающей прогамме те флаги, которые были у нее до вызова !!! - Надо использовать команду retf 2 - Она не испортит тебе флаги.
Ниже я послал тебе свою программку - как пример такого рода перехватов. Тока я там int 13h ловлю. Сделай по аналогии что-нибудь.
Да, и еще ! Зря ты тягаешь из буффера клавы клавиши - они же возвращаются самой int 16h. Так вроде проще ? ;)))
; Программа для выдачи серийного номера жесткого диска.
; Выдает серийный номер жесткого диска в указнный буфер из 256 слов.
; Необходимо указать в autoexec.bat ее инсталляцию.
; Будучи загружена перед Windows 95/98, попадает в 0-кольцо защиты OS
; И потому способна корректно работать с портами ввода-вывода ЖД.
; Под DOS работает так же, как обычная программа, читающая порты ЖД.
; Поддерживает 2 функции (регистр AL):
; AL = 00h - INSTALLATION CHECK
; Если инсталлировна, то AL = FBh(Номер резерв. ф-ции), CF флаг сброшен
; AL = 01h - READ SERIAL DISK NUMBER
; В случае успешного чтения возвращает:
; - AL = FBh (Номер резерв. ф-ции), CF флаг сброшен;
; - В переданный буфер ES:DI читает серийный номер диска, буфер
; должен быть длиной 256 слов;
; Если чтение не удалось, то AL = FF и флаг CF установлен
; На другие значения в AL возвращает FF + установленный флаг CF
.286 ; Команды процессора 286+ незащищенного режима
HookedVector equ 13h ; Перехватываем вектор 13h - работа с диском BIOS
OurFunction equ 0fbh ; Резервируем ф-цию 0fbh прерывания 13h для себя
Drive equ 00h ; Видимо, номер жесткого диска (0,1,..)
FuncNumber equ 2 ; Число поддерживаемых функций
InstallCheck equ 0 ; Запрос на инсталляцию
ReadSerial equ 1 ; Запрос на чтение серийного номера
ErrorFunc equ 0ffh ; Ответ на ошибочный запрос
cseg segment byte 'code'
assume cs:cseg
org 100h ; Обычный PSP com - программы
begin: jmp Iniz ; Обойдем резидентный код
messagekey proc near
pushf ; Сохраним флаги вызывающей программы
cmp ah,OurFunction
jnz @NotOurFunction
popf ; Парная команда к pushf в начале кода
call Dispatcher ; Отработать возможные функции
retf 2 ; Вернуться с установленными внутри флагами
@NotOurFunction:
popf ; Восстановим флаги вызывающей программы
db 0eah ; код команды jmp far
Old_13H dd ? ; На предидущий обработчик int 13h
messagekey endp
Dispatcher proc near
push si
xor si,si
@FindFunc:
cmp al,cs:Functions[si]
jz @FuncFound
inc si
cmp si,FuncNumber
jb @FindFunc
pop si
mov al,ErrorFunc
stc
retn
@FuncFound:
shl si,1
call word ptr cs:FuncOfs[si]
pop si
retn
Dispatcher endp
Functions db InstallCheck,ReadSerial
FuncOfs dw offset Install, offset ReadInfo
Install proc near
mov al,OurFunction
clc
retn
Install endp
ReadInfo proc near
pusha
mov word ptr cs:Counter,0
@TryAgain:
mov dx,03f6h
mov al,0ah
out dx,al ; outportb(0x3F6,0x0A)
call Waiter
@Wait1: mov dx,01f7h
in al,dx
call TimeOut
test al,80h ; while(inportb(0x1F7)&0x80);
jnz @Wait1
call Waiter
mov dx,01f6h
mov al,Drive
shl al,4
add al,0a0h
out dx,al ; outportb(0x1F6,0xA0+(drive<<4));
call Waiter
@Wait2: mov dx,01f7h
in al,dx
call TimeOut
test al,40h ; while(!(inportb(0x1F7)&0x40));
jz @Wait2
call Waiter
mov dx,01f7h
mov al,0ech
out dx,al ; outportb(0x1F7,0xEC);
call Waiter
@Wait3: mov dx,01f7h
in al,dx
call TimeOut
test al,08h ; while(!(inportb(0x1F7)&0x08));
jz @Wait3
call Waiter
; for(i=0; i<256; i++) infoArray[i] = swap(inportw(0x1F0)) (to es:[di])
mov cx,256
@FillBuf:
call Waiter
mov dx,01f0h
in ax,dx
xchg al,ah
mov es:[di],ax ; es:[di] = ax, di:=di+2
inc di
inc di
loop @FillBuf
mov dx,01f7h
in al,dx
call TimeOut
test al,80h ; if(inportb(0x1F7)&0x80) continue;
jz @ReadOK
jmp @TryAgain
@ReadOK:popa
clc
mov al,OurFunction
retn
TimeOut proc near
inc word ptr cs:Counter
jnz @TimeDone
pop ax
popa
mov al,ErrorFunc
stc
@TimeDone:
retn
Counter dw 0
TimeOut endp
ReadInfo endp
Waiter proc near
push cx
xor cx,cx
@Wait: loop @Wait
pop cx
retn
Waiter endp
Iniz proc
assume ds:cseg
push ds
mov ax,(35H shl 8) + HookedVector
int 21h ; Get old HookedVector to es:bx
mov word ptr Old_13h,bx
mov word ptr Old_13h+2,es
mov dx,offset MessageKey
mov ah,25h
int 21H ; Set new Vector
mov dx,offset Iniz
int 27H ; Terminate and Stay Rezident
Iniz endp
cseg ends
end Begin
Нужно сделать прогу на 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 ты услышишь при всяком нажатии пробела даже в ворде...
int 16h ?
Не так давно в статье от одного умного человека я прочитал,что в защищенном режиме int 09h вообще не используется, а int 16h используется для чего-то другого - но точно не для определения нажатых клавиш.
[ASM] Chingachguku18.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 - тем более.
> А вот и нет. Винды 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] Chingachguku19.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] Chingachguku19.10.01 16:22 Автор: Chingachguk <Chingachguk> Статус: Member
> небольшое уточнение (как win9x определяет int13): > > при старте атапишного драйвера (справедливо в общем случае > и для scsi) винда читает несколько секторов начиная с CHS > 0:0:1 через int13 и через драйвер. если результаты сходятся > - грузится драйвер. если нет - режим совместимости через > шлюз на int13
Точно !!! Я вот читал предидущее разъяснение и думал, почему когда я пробовал свой бут-вир под вин 98 гонять, то она (винда) безусловно через него работала, иначе гря - через стандартный биос. А в случае OneHalf - работала через свой драйвер (так, по крайней мере, выше написано) ?! Ну тогда понятно: у меня вирь был стеллс, а в этом случае р-ты через int 13h (я ему чистый подставлял mbr) и через драйвер немного разный результат получается ... ;)
Спасибо !
[ASM] Chingachguku20.10.01 11:09 Автор: z0 <z0> Статус: Member
> Точно !!! Я вот читал предидущее разъяснение и думал, > почему когда я пробовал свой бут-вир под вин 98 гонять, то > она (винда) безусловно через него работала, иначе гря - > через стандартный биос. А в случае OneHalf - работала через > свой драйвер (так, по крайней мере, выше написано) ?! Ну > тогда понятно: у меня вирь был стеллс, а в этом случае р-ты > через int 13h (я ему чистый подставлял mbr) и через драйвер > немного разный результат получается ... ;) > Спасибо !
так я тоже вирус делал ;-)
а если винде в int13 давать CHS 0:0:? правильно то вирус БУДЕТ работать!
Что-то не стыкуется... 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 на эту команду
> > Получается, что алгоритм не совсем такой, как описал > 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
> 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
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
;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'е. Спасибо!