China DOS Union

Load the MBR to 7C00h and then jump over.

I ran it under DOS but it failed. Is there any expert who can tell me why?

.model tiny

.code

org 100h

start: jmp begin

begin:
CLI

xor ax,ax
mov ss,ax
MOV SP,7C00h
MOV SI,SP
PUSH AX
POP ES
PUSH AX
POP DS
STI
CLD

mov bx,7C00h
mov ah,02h
mov al,01h
mov cx,1
mov dl,80h
mov dh,0
int 13h

;JMP cs:7c00h
db 0EAH,0,7CH,0,0
end start

First of all, it should be understood that MBR is executed when the hard disk is loaded at boot. When the BIOS is about to boot from the hard disk, the values of CPU registers are all initial values. Assigning values to SS, DS, and ES in the MBR code is just for reliability.

The real problem lies in the interrupt vectors. Operating systems including DOS will take over INT13 after startup. Taking DOS as an example, the entry address of INT13 after loading IO.SYS is absolutely different from that when loading MBR. You can try it with the p command of debug and you will know. (I discovered this when I wrote a multi-system boot program a long time ago).

Another point, is the memory at physical address 0:7C00h used by other programs when you debug the program? Who knows what will happen if other programs use this area.

In fact, you can restart the system with just one INT19, but the premise is that it does not conflict with the memory management program. Take the WIN98 boot disk as an example, without HIMEM and EMM386, INT19 will only directly load the boot device and no longer go through the self-test step.

DOS95

I copied the MBR to the place starting at space 0000:9000, changed the relative address in memory, and started running from this place. At this time, I can correctly boot ntldr, but the problem is with the interrupt vector you mentioned, that is, int 13h. A dead loop occurs when a call is made. The extended int 13h called is mov ax,42h. At this time, there may be a problem with the operation of 42h. Do you have any way?

In DOS programming, one thing that is strictly prohibited is non-reentrant interrupts. After the DOS operating system is started, it resets INT13, adds some functions it deems necessary, and finally calls the functions of the original INT13 to implement.

When NTLDR is loaded, NTLDR will also reset INT13. Then the problem comes. NTLDR calls its own INT13 function, which is based on BIOS's INT13, but the original INT13 entry under IO.SYS has not been restored to the original INT13 entry of BIOS, so there will be an INT13 call conflict problem. It can only be said that it is lucky if there is no problem.

For this situation, the best solution is to establish a new function similar to INT13 through the IO port by oneself; otherwise, one has to analyze the most original INT13 entry and use the original entry in one's own program to implement the required functions.

To find the original INT13 entry? Is there any way?

The interrupt vector table is stored starting at memory 0:0. Each interrupt occupies 4 bytes of memory. There are 256 interrupts in total, occupying all memory from 0:0 to 0:03FF.

debug
-d 0:40
0000:0040 10 10 10 10 11 11 11 11 - 12 12 12 12 13 13 13 13
0000:0050 14 14 14 14 15 15 15 15 - 16

The above 13 13 13 13 refers to the entry address of INT13, which is the original entry of the BIOS when the operating system is not started. So, as long as it is saved to other places when the system is not started.

Taking saving the interrupt vector table in the MBR as an example: (You need to make a backup of the MBR first!)

xor bx,bx
mov ds,bx
mov es,bx
mov ss,bx
mov sp,7c00h
mov ax,302h
mov mov cx,3
mov dx,80h
int 13h

In this way, the original interrupt vector table can be saved to the 3rd and 4th sectors at the beginning of the hard disk. The subsequent program can first restore the saved interrupt vector table, and then the call will be the original entry.

debug
-a
mov ax,202
mov bx,200
mov cx,3
mov dx,80
int 13
cli
mov si,bx
xor di,di
mov es,di
mov cx,200
repz movsw
sti

OK! Restored.

Through hard coding, the int13 interrupt is restored, and the system can be successfully loaded. Thanks for your information~

A short code can be added in the MBR to input characters, without affecting any interrupts to achieve the purpose of encryption. I tried it before