I am going through os-dev by Nick Blundell. There he has taken through the hex data inside a bin file after compiling the boot sector assembly code using NASM. Is there a way to interpret all the 512 bytes manually, just by looking at the code. Say, for example, following is the code
mov ah,0x0E
;First attempt
mov al,the_secret
int 10h
;Second attempt
mov al,[the_secret]
int 10h
;Third attempt
mov bx,the_secret
add bx,0x7c00
mov al,[bx]
int 10h
;Fourth attempt
mov al,[0x7c1e]
int 0x10
jmp $
the_secret: db "X"
times 510 - ($ - $$) db 0
dw 0xaa55
The above code generates a 512 byte bin file after compiling. Is it possible to determine all the 512 bytes just by looking at the code? I think it should be possible, Otherwise he wouldn't know that the_secret is present at 0x7c1e. If it's possible, please direct me to relevant articles explaining this part. Thank you
Have you tried using
ndisasm foo.bin? You'll findmov bx, 0x1dwith the address of the secret, and anothermov al,[0x7c1e]. Then you'd look at the disassembly at that address (the 0x7c00 load address), and see the byte. Also, it's the first byte after the infinite-loop jump, which makes it also in a pretty obvious place.It looks like this bootloader assumes that DS = 0 when it starts up, but doesn't bother to actually set DS itself to match the implicit default
org 0. The earliermov al,[0x1d]will work for the other perhaps-likely case of DS=0x07C0. (It's common for bootloaders to start with CS:IP =07C0:0000or0000:7C00, but I'm not sure if DS is normally set to anything relevant. Best to assume not.)Also, from the source you posted, the secret is at a
0x1doffset into the binary file, not0x1e. Somov al,[0x7c1e]is wrong.mov al, [0x7c00 + the_secret]would have made sense and adjusted to fit wherever the label ended up.