Page 1 of 2
[SOLVED] Odd behavior with AH=0x03/INT=0x13
Posted: Sat Sep 07, 2024 9:35 am
by avcado
Hello, I'm writing a small program to dump the BIOS ROM into sectors 3-131. To do this, I loop from SI=0 to SI=0xFFFF (65535), and DI=0 through DI=512. Once DI hits 512, I reset DI, write the buffer to sector 3+DH (DH is sector number) and increase DH.
However, this wasn't working, so I just tried writing one sector:
Code: Select all
xor ax, ax
mov ax, 0xF000
mov es, ax
xor di, di
WriteToDisk:
cmp di, 512
je Exit2
mov ax, [es:di]
mov [buffer+di], al
inc di
jmp WriteToDisk
ret
Exit2:
mov dh, 3 ;; Sector number
mov bx, buffer ;; Buuff
call writeSector
My sector writing code looks like this:
Code: Select all
writeSector:
push es
xor ax, ax
mov es, ax
;; BX already buffer
mov ah, 0x03 ;; Hey, we want to write!
mov al, 0x01 ;; Only one sector
mov cl, dh
mov dh, 0
;; DL already set by BIOS
;; ES:BX set above
int 0x13
jc .Failure
ret
pop es
ret
.Failure:
mov ah, 0x01
;; DL set
int 0x13
hcf
Note that hcf is a macro for
Code: Select all
%macro hcf 0
cli
hlt
jmp $
%endmacro
"buffer" is defined as just
This fails immediately. I check EAX:
Code: Select all
(qemu) x/1i $eax
0x00002000: 00 00
Huh. AL is 0. That corresponds to a successful operation. But it shouldn't have been successful, since the CF was set. What's going on here? Why is it failing?
Re: Odd behavior with AH=0x03/INT=0x13
Posted: Sat Sep 07, 2024 11:11 am
by avcado
Turns out I needed to make a floppy disk to actually see the changes.
Re: [SOLVED] Odd behavior with AH=0x03/INT=0x13
Posted: Sat Sep 07, 2024 6:52 pm
by Octocontrabass
avcado wrote: ↑Sat Sep 07, 2024 9:35 amI'm writing a small program to dump the BIOS ROM
What are you trying to accomplish by dumping the BIOS ROM? On just about every PC, the "ROM" is actually RAM, and the data you dump might not be what you want.
Also, depending on the chipset and BIOS, specifying an INT 0x13 buffer address outside of normal RAM might not work, either failing with an error or silently misbehaving.
Re: [SOLVED] Odd behavior with AH=0x03/INT=0x13
Posted: Sun Sep 08, 2024 7:38 am
by avcado
Octocontrabass wrote: ↑Sat Sep 07, 2024 6:52 pm
avcado wrote: ↑Sat Sep 07, 2024 9:35 amI'm writing a small program to dump the BIOS ROM
What are you trying to accomplish by dumping the BIOS ROM?
Honestly? I just want to take a peek at it. Eventually, I may try and get it running on real hardware.
I read this SO question,
https://stackoverflow.com/a/41531355, and I decided it might be fun to try doing it.
Octocontrabass wrote: ↑Sat Sep 07, 2024 6:52 pm
On just about every PC, the "ROM" is actually RAM, and the data you dump might not be what you want.
From what I've been able to dump, the first few sectors (I'd say 1kb) is just format strings. What I'm trying to do is get the raw machine code and do stuff with that (i.e. disassemble). And this goes back to my point of wanting to run it on real hardware, since I know SeaBIOS is open source, I'd like to see (if possible) to reverse engineer some BIOS firmware, if that makes sense.
Re: [SOLVED] Odd behavior with AH=0x03/INT=0x13
Posted: Sun Sep 08, 2024 3:43 pm
by Octocontrabass
avcado wrote: ↑Sun Sep 08, 2024 7:38 amHonestly? I just want to take a peek at it.
I'm glad I'm not the only one.
avcado wrote: ↑Sun Sep 08, 2024 7:38 amWhat I'm trying to do is get the raw machine code and do stuff with that (i.e. disassemble). And this goes back to my point of wanting to run it on real hardware, since I know SeaBIOS is open source, I'd like to see (if possible) to reverse engineer some BIOS firmware, if that makes sense.
Sure, you can do that, but which part of the BIOS code do you want to reverse-engineer? Right now you're only looking at the runtime portion of it, which is great if you want to figure out how the BIOS expects you to call its various interrupts, but not helpful if you want to see how it initializes the chipset.
Re: [SOLVED] Odd behavior with AH=0x03/INT=0x13
Posted: Sun Sep 08, 2024 7:28 pm
by avcado
Octocontrabass wrote: ↑Sun Sep 08, 2024 3:43 pm
Sure, you can do that, but which part of the BIOS code do you want to reverse-engineer?
I mean that's mainly what I'm after -- to see the code that's loaded into RAM/ROM when you start your computer / the code that's flashed onto the physical BIOS chip. Obviously I could go out and compile SeaBIOS and run objdump on the compiled binary, but what's the fun in that? Besides, one of the main goals of this project is to get it on running on real hardware and be able to easily examine the firmware.
Octocontrabass wrote: ↑Sun Sep 08, 2024 3:43 pm
Right now you're only looking at the runtime portion of it, which is great if you want to figure out how the BIOS expects you to call its various interrupts, but not helpful if you want to see how it initializes the chipset.
What should I be doing instead?
Re: [SOLVED] Odd behavior with AH=0x03/INT=0x13
Posted: Sun Sep 08, 2024 7:58 pm
by Octocontrabass
avcado wrote: ↑Sun Sep 08, 2024 7:28 pmWhat should I be doing instead?
Ideally, pull the ROM chip out of its socket and dump it with an EEPROM programmer.
But if you need a software solution, try reading the ROM from just below 4GB. Chipsets usually provide direct access to the ROM contents that way. You can use
INT 0x15 AH=0x87 to avoid problems with the A20 gate. (In fact, there is
a program to do this under DOS.)
Re: [SOLVED] Odd behavior with AH=0x03/INT=0x13
Posted: Mon Sep 09, 2024 7:06 am
by avcado
Octocontrabass wrote: ↑Sun Sep 08, 2024 7:58 pm
But if you need a software solution, try reading the ROM from just below 4GB. Chipsets usually provide direct access to the ROM contents that way.
Wouldn't I need to be in protected mode for that, since I can only access 1MB in real mode?
How does that work? (the using BIOS interrupts [in what I assume to be real mode] to read the data)
Re: [SOLVED] Odd behavior with AH=0x03/INT=0x13
Posted: Mon Sep 09, 2024 9:32 am
by Octocontrabass
avcado wrote: ↑Mon Sep 09, 2024 7:06 amWouldn't I need to be in protected mode for that, since I can only access 1MB in real mode?
Accessing memory above 1MB involves switching the CPU to protected mode, but all of your code can stay in real mode if you use the BIOS.
When you call that interrupt, the BIOS switches the CPU to protected mode, copies data with REP MOVSW, and switches back to real mode to return to your program.
Re: [SOLVED] Odd behavior with AH=0x03/INT=0x13
Posted: Mon Sep 09, 2024 5:37 pm
by avcado
When you call that interrupt, the BIOS switches the CPU to protected mode, copies data with REP MOVSW, and switches back to real mode to return to your program.
[/quote]
I see. Though I am still a bit confused about what to put in the GDT. RBIL gives me a guide,
Code: Select all
Format of global descriptor table:
Offset Size Description (Table 00499)
00h 16 BYTEs zeros (used by BIOS)
10h WORD source segment length in bytes (2*CX-1 or greater)
12h 3 BYTEs 24-bit linear source address, low byte first
15h BYTE source segment access rights (93h)
16h WORD (286) zero
(386+) extended access rights and high byte of source address
18h WORD destination segment length in bytes (2*CX-1 or greater)
1Ah 3 BYTEs 24-bit linear destination address, low byte first
1Dh BYTE destination segment access rights (93h)
1Eh WORD (286) zero
(386+) extended access rights and high byte of destin. address
20h 16 BYTEs zeros (used by BIOS to build CS and SS descriptors)
The DOS program you gave me did help with implementing it up to byte 0x16,
Code: Select all
gdt:
dd 0, 0, 0, 0 ;; 16 bytes, 0
dw 0xFFFF ;; Source segment length
db 0 ;; Linear source address, low bits
db 0xF0 ;; High bits
db 0xFF ;; 386 high bits
db 0x93 ;; "Rights"
dw 0 ;; 286 zero
Though the code gets confusing, as there's no mention of what FP_SEG, FP_OFF is, and I'm not sure how I'd implement the rest in assembly. Maybe I'm doing it wrong.
Re: [SOLVED] Odd behavior with AH=0x03/INT=0x13
Posted: Mon Sep 09, 2024 6:58 pm
by Octocontrabass
avcado wrote: ↑Mon Sep 09, 2024 5:37 pmThough I am still a bit confused about what to put in the GDT.
The BIOS copies a block of data from DS:0 to ES:0. You're providing the segment descriptors for DS and ES.
avcado wrote: ↑Mon Sep 09, 2024 5:37 pmThough the code gets confusing, as there's no mention of what FP_SEG, FP_OFF is,
Those are macros to extract the segment and offset from a far pointer. The code doesn't explain them because they're a standard part of using C with 16-bit x86.
Re: [SOLVED] Odd behavior with AH=0x03/INT=0x13
Posted: Sat Sep 14, 2024 6:12 pm
by avcado
Octocontrabass wrote: ↑Mon Sep 09, 2024 6:58 pm
avcado wrote: ↑Mon Sep 09, 2024 5:37 pmThough the code gets confusing, as there's no mention of what FP_SEG, FP_OFF is,
Those are macros to extract the segment and offset from a far pointer. The code doesn't explain them because they're a standard part of using C with 16-bit x86.
I see. I've been messing around with it for a bit. Decided to see if I could port the DOS program to a bootsector with C. I got IA-16 to build me an ELF, that I objcopy to a binary and load into memory at 0x7e00.
I thought to myself, before I tried using INT 0x15/AH 0x87, to see if I could do something like I did before -- reading directly from memory.
Code: Select all
#define BIOS_START_386 0xfff0000
#define BIOS_SIZE 0xFFFF // 65kb
...
uint16_t byte = *(uint16_t*)(BIOS_START_386);
putw(byte);
...
This compiles fine. No warnings (I compile with -Wall -Wextra). However, when running in qemu, I get the output 0xFF03.
Note that my putw(uint16_t) implementation prints the high byte then low byte, so FF is the high byte. I then grab a copy of SeaBIOS from
the git repository, compiling it and checking if byte 0-1 is 0xFF03.
It isn't!
Code: Select all
$ hexdump out/bios.bin
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0011ee0 0344 0000 039c 0000 03a4 0000 03d4 0000
Then I boot up a hex editor (okteta) to see what the first occurrence of the 0xFF03 word is. It's at
byte 0001:936E (or offset 0x1936D i think?). I'm probably doing it wrong, but I'd like to know why before I rewrite it using the approach used in the DOS app.
I'll happily give more code/other files if needed.
Re: [SOLVED] Odd behavior with AH=0x03/INT=0x13
Posted: Sat Sep 14, 2024 6:56 pm
by Octocontrabass
avcado wrote: ↑Sat Sep 14, 2024 6:12 pmI thought to myself, before I tried using INT 0x15/AH 0x87, to see if I could do something like I did before -- reading directly from memory.
How? You're still in real mode, which means you can't directly read from memory addresses above 1MB. Writing your code in C instead of assembly isn't going to change that.
avcado wrote: ↑Sat Sep 14, 2024 6:12 pm
Did you mean 0xfff00000? Also, don't forget the start address depends on the size of the BIOS ROM.
avcado wrote: ↑Sat Sep 14, 2024 6:12 pmI then grab a copy of SeaBIOS from
the git repository, compiling it and checking if byte 0-1 is 0xFF03.
Why go through all the trouble of building a second SeaBIOS binary? You already have the one that QEMU is using. Plus, the one you built probably won't match the one QEMU is using.
Re: [SOLVED] Odd behavior with AH=0x03/INT=0x13
Posted: Sat Sep 14, 2024 7:25 pm
by avcado
Octocontrabass wrote: ↑Sat Sep 14, 2024 6:56 pm
avcado wrote: ↑Sat Sep 14, 2024 6:12 pmI thought to myself, before I tried using INT 0x15/AH 0x87, to see if I could do something like I did before -- reading directly from memory.
How? You're still in real mode, which means you can't directly read from memory addresses above 1MB. Writing your code in C instead of assembly isn't going to change that.
Right. Completely forgot that INT 0x15/AH 0x87 swapped into protected mode, and I wasn't doing that, I guess you're right.
Octocontrabass wrote: ↑Sat Sep 14, 2024 6:56 pm
avcado wrote: ↑Sat Sep 14, 2024 6:12 pm
Did you mean 0xfff00000? Also, don't forget the start address depends on the size of the BIOS ROM.
How would you know how big the BIOS ROM is?
Re: [SOLVED] Odd behavior with AH=0x03/INT=0x13
Posted: Sat Sep 14, 2024 8:34 pm
by MichaelPetch
Since you are in real mode and already using BIOS interrupts. You can use Int 0x15/ax=0xe820 to get a memory map. Look for all the Type 2 memory entries and those will include BIOS memory areas (plus some other reserved regions). If you are on *really ancient* hardware without 0x15/ax=0xe820 then it is possible to scan memory between 0xc0000 and 0xfffff to find where the BIOS ROM and option ROMS are. See
https://www.ctyme.com/intr/rb-1741.htm