> Точно !!! Я вот читал предидущее разъяснение и думал, > почему когда я пробовал свой бут-вир под вин 98 гонять, то > она (винда) безусловно через него работала, иначе гря - > через стандартный биос. А в случае OneHalf - работала через > свой драйвер (так, по крайней мере, выше написано) ?! Ну > тогда понятно: у меня вирь был стеллс, а в этом случае р-ты > через int 13h (я ему чистый подставлял mbr) и через драйвер > немного разный результат получается ... ;) > Спасибо !
так я тоже вирус делал ;-)
а если винде в int13 давать CHS 0:0:? правильно то вирус БУДЕТ работать!
Нужно сделать прогу на 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'е. Спасибо!