Now I'm writing bootloader which starts in the middle of memory, but after it finishes I need to go to the main app, thought to try jmp 0x00, however my chip doesn't support jmp, how should I start main app?
I would use RJMP:
Relative jump to an address within PC - 2K +1 and PC + 2K (words). In
the assembler, labels are used instead of relative operands.
For example:
entry:
rjmp reset
.org 512
reset:
rjmp foo
.org 3072
foo:
rjmp entry
By the way, there are several other jump instructions (RJMP, IJMP, RCALL, ICALL, CALL, RET, RETI etc.) See this relevant discussion.
Well take a look into RET instruction. It returns to previous location, so you can try:
push 0x00
push 0x00
ret
This should work because while entering into any function you push your current location, and RET makes you go back.
As far as I remember ATmege8 has 16-bit address line, but if I'm not right you may need more push 0x00
why not simply use IJMP?
set Z to 0x00 and use IJMP. may be faster than 2xpush and ret
EOR R30, R30 ; clear ZL
EOR R31, R31 ; clear ZH
IJMP ; set PC to Z
should be 4 cycles and 3 instruction words (6 Bytes program memory)
Related
I am working on a custom 32-bit OS, and i have coded a bare bones bootloader. I am trying to make it load a simple kernel that puts a char onto the screen, however, instead of getting the char i get a triple fault (maybe?)
I've tried increasing the number of sectors read, the number of 'db 0's in my extended program, tampering with the compilation script...
Nothing, however, my OS also prints the letter 'H' if it succeeds to read the disk, and sometimes when I increase the number of sectors to something exponential, the vm doesn't restart, but the disk isn't read successfully.
Github: https://github.com/Nutty000/Broken-OS
"BROKEN-OS", you say?
Your GitHub ldr.asm file has many errors.
The Boot Sector and BPB Structure uses all the wrong data sizes! No wonder your VM gets all confused.
should be
---------
OEMIdentifier db "POSv0.10"
BytesPerSector dd 512 DW
SectorsPerCluster db 1
ReservedSectors db 32 DW
NumberOfFATs db 2
NUmberOfRootDirEntries db 224 DW
NumberOfSectors dd 2880 DW
MediaDescriptorType db 0xf0
SectorsPerFAT db 9 DW
SectorsPerTrack db 18 DW
NumberOfSides db 2 DW
HiddenSectors db 0 DD
LargeSectorCount db 0 DD
DriveNumber db 0x00
db 0
Signature db 0x29
VolumeID db 0x00, 0x00, 0x00, 0x00
VolumeLabel db "POSBOOTDSK "
SystemIdentifier db "FAT12 "
jmp short mbrcodestart
This short jump is encoded with 2 bytes, but the above mentioned structure must begin at offset 3 in your bootsector. You need to pad with a nop instruction, or force a near (non-short) jmp.
jmp short mbrcodestart
nop
The fact of storing a capital "H" as the first byte of your [ExtendedSpace] that you later jump to was a bad idea, but luckily for you that will not pose a problem as that particular encoding 72 happens to correspond to a valid one-byte instruction dec ax.
There's also:
not setting up the segment registers yourself
not setting up a stack in a safe place where the additional sectors can't overwrite it
ignoring the BH and BL parameters of the BIOS.Teletype call
not inspecting the carry flag that you get from the int 13h call
reading many sectors at once instead of the more reliable method of using a loop of reading individual sectors. (Some real-world BIOSes are somewhat broken; using only the simplest functionality will let your bootloader work even on such machines. See also Michael Petch's general tips for bootloaders.)
...
All of this happens even before diving into protected mode. First make sure the real mode part works fine before attempting to go further.
There are many good answers on this forum that deal with these issues:
Bootloader doesn't jump to kernel code
My OS is showing weird characters
Your current ldr.asm for reference:
[org 0x7c00]
jmp short mbrcodestart
OEMIdentifier db "POSv0.10"
BytesPerSector dd 512
SectorsPerCluster db 1
ReservedSectors db 32
NumberOfFATs db 2
NUmberOfRootDirEntries db 224
NumberOfSectors dd 2880
MediaDescriptorType db 0xf0 ;3.5 Inch Double-Sided HD Floppy disk(1.44MB or 2.88MB) should work with single-sided ones as well, maybe even 5.25 inch diskettes
SectorsPerFAT db 9
SectorsPerTrack db 18
NumberOfSides db 2
HiddenSectors db 0
LargeSectorCount db 0
;EBPB
DriveNumber db 0x00 ;Floppy Disk
db 0 ;Reserved
Signature db 0x29
VolumeID db 0x00, 0x00, 0x00, 0x00
VolumeLabel db "POSBOOTDSK "
SystemIdentifier db "FAT12 "
mbrcodestart:
mov bx, POSBL_WelcomeString
call print16
call read16
mov ah, 0x0e
mov al, [ExtendedSpace]
int 0x10
jmp ExtendedSpace
POSBL_WelcomeString:
db "PlanetOS BootLoader (POSBL) v0.1 (limited compatability)",0
print16:
mov ah, 0x0e
loop:
mov al, [bx]
cmp al, byte 0
je exit
int 0x10
inc bx
jmp loop
exit:
ret
ExtendedSpace equ 0x7e00
read16:
mov ah, 0x02
mov al, 20
mov bx, ExtendedSpace
mov ch, 0x00
mov cl, 0x02
mov dh, 0x00
mov dl, 0x00
int 0x13
ret
times 510-($-$$) db 0
dw 0xaa55
The first instruction executed after jmp ExtendedSpace is db 'H' i.e. not code
I am trying to make a operating system. I just finished the bootloader, however I am having a problem loading my kernel.
Boot.asm:
section .boot
bits 16
global boot
boot:
mov ax, 0x2401
int 0x15
mov ax, 0x3
int 0x10
mov [disk],dl
mov ah, 0x2 ;read sectors
mov al, 6 ;sectors to read
mov ch, 0 ;cylinder idx
mov dh, 0 ;head idx
mov cl, 2 ;sector idx
mov dl, [disk] ;disk idx
mov bx, copy_target;target pointer
int 0x13
cli
lgdt [gdt_pointer]
mov eax, cr0
or eax,0x1
mov cr0, eax
mov ax, DATA_SEG
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax
mov ss, ax
jmp CODE_SEG:boot2
gdt_start:
dq 0x0
gdt_code:
dw 0xFFFF
dw 0x0
db 0x0
db 10011010b
db 11001111b
db 0x0
gdt_data:
dw 0xFFFF
dw 0x0
db 0x0
db 10010010b
db 11001111b
db 0x0
gdt_end:
gdt_pointer:
dw gdt_end - gdt_start
dd gdt_start
disk:
db 0x0
CODE_SEG equ gdt_code - gdt_start
DATA_SEG equ gdt_data - gdt_start
times 510 - ($-$$) db 0
dw 0xaa55
copy_target:
bits 32
hello: db "Hello more than 512 bytes world!!",0
boot2:
mov esi,hello
mov ebx,0xb8000
.loop:
lodsb
or al,al
jz halt
or eax,0x0F00
mov word [ebx], ax
add ebx,2
jmp .loop
halt:
mov esp,kernel_stack_top
extern kzos
call kzos
cli
hlt
section .bss
align 4
kernel_stack_bottom: equ $
resb 16384 ; 16 KB
kernel_stack_top:
kzos.cpp
extern "C" void kzos()
{
const short color = 0x0F00;
const char* hello = "Kernel test!";
short* vga = (short*)0xb8000;
for (int i = 0; i<16;++i)
vga[i+80] = color | hello[i];
}
The error I am getting is with " extern kzos" the error reads "boot.asm:77: error: binary output format does not support external references"
I tried adding " extern kzos.cpp " but then I get "boot.asm:77: error: symbol `kmain' undefined"
if I add ".cpp" to the call function I get "boot4.asm:77: error: binary output format does not support external references"
I am using Nasm to compile to bin and qemu to run it.
I just finished the bootloader, ...
No you didn't. At least half of a boot loader's code exists to handle errors that "shouldn't" happen (things like checking if the BIOS failed to enable A20, or if the BIOS says there was a problem reading data from disk) and handling those cases somehow - at a minimum, by providing the user information that can help them fix the problem (and determine if it's faulty hardware or a problem with the way the OS was installed or ...), so the user isn't stuck wondering why their entire computer is unusable (and so that you're not stuck with a bug report saying "doesn't boot" with no useful information either).
how do I load my kernel from my bootloader?
Your choices for finding where the kernel is (its location on the disk and its size) are:
a) Put the kernel in some kind of normal file system, and have the boot loader support that file system (e.g. find the right directory entry and get location of file's data from the file's directory entry). Note that this is complicated (e.g. you'll have a lot of error handling, in case the file system's structures are corrupted, etc)
b) Put the kernel in some kind of purpose designed file system or in some kind of purpose designed "special/reserved area" of a normal file system. This could be as simple as a table of "offset and length" structures stored in the first sector, where kernel's file is always the first entry in that table.
c) Include the kernel's binary directly into the boot loader using something like the incbin directive in NASM. In this case you can use labels to determine the size of the kernel's file, like:
kernel_start:
incbin 'kernel.bin'
kernel_end:
In this case you can determine where the kernel is on disk from where the boot loader was on disk, and calculate how many sectors it is (e.g. (kernel_end - kernel_start + SECTOR_SIZE-1)/SECTOR_SIZE). Of course this is horribly inflexible (e.g. you can't easily update the kernel without assembling and then reinstalling the boot loader).
Once you've determined the location and size of the kernel on disk; you need to load it into memory somewhere. Note that this can depend on what kind of executable file format you chose to use for the kernel; and could involve loading the executable file's headers and parsing them to figure out which parts of the file should go where in memory (and setting up things like ".bss" that aren't in the file).
the output format is bin, flat format, that is
it does not support rellocations
thus call kzos's location/address is lost once the code is rendered
any linking utility will fail locating call kzos' in order
to link it to the new address of extern "C" void kzos() from kzos.cpp
In assembly we use the org instruction to set the location counter to a specific location in the memory. This is particularly helpful in making Operating Systems. Here's an example boot loader (From wikibooks):
org 7C00h
jmp short Start ;Jump over the data (the 'short' keyword makes the jmp instruction smaller)
Msg: db "Hello World! "
EndMsg:
Start: mov bx, 000Fh ;Page 0, colour attribute 15 (white) for the int 10 calls below
mov cx, 1 ;We will want to write 1 character
xor dx, dx ;Start at top left corner
mov ds, dx ;Ensure ds = 0 (to let us load the message)
cld ;Ensure direction flag is cleared (for LODSB)
Print: mov si, Msg ;Loads the address of the first byte of the message, 7C02h in this case
;PC BIOS Interrupt 10 Subfunction 2 - Set cursor position
;AH = 2
Char: mov ah, 2 ;BH = page, DH = row, DL = column
int 10h
lodsb ;Load a byte of the message into AL.
;Remember that DS is 0 and SI holds the
;offset of one of the bytes of the message.
;PC BIOS Interrupt 10 Subfunction 9 - Write character and colour
;AH = 9
mov ah, 9 ;BH = page, AL = character, BL = attribute, CX = character count
int 10h
inc dl ;Advance cursor
cmp dl, 80 ;Wrap around edge of screen if necessary
jne Skip
xor dl, dl
inc dh
cmp dh, 25 ;Wrap around bottom of screen if necessary
jne Skip
xor dh, dh
Skip: cmp si, EndMsg ;If we're not at end of message,
jne Char ;continue loading characters
jmp Print ;otherwise restart from the beginning of the message
times 0200h - 2 - ($ - $$) db 0 ;Zerofill up to 510 bytes
dw 0AA55h ;Boot Sector signature
;OPTIONAL:
;To zerofill up to the size of a standard 1.44MB, 3.5" floppy disk
;times 1474560 - ($ - $$) db 0
Is it possible accomplish the task with C++? Is there any command, function etc. like org where i can change the location of the program?
No it's not possible to do in any C compiler that I know of. You can however create your own linker script that places the code/data/bss segments at specific addresses.
Just for clarity, the org directive does not load the code at the specified address, it merely informs the assembler that the code will be loaded at that address. The code shown appears to be for Nasm (or similar) - in AT&T syntax, the .org directive does something different: it pads the code to that address - similar to the times line in the Nasm code.. Nasm can do this because in -f bin mode, it "acts as it's own linker".
The important thing for the code to know is the address where Msg can be found. The jmps and jnes (and call and ret which your example doesn't have, but a compiler may generate) are relative addressing mode. We code jmp target but the bytes that are actually emitted say jmp distance_to_target (plus or minus) so the address doesn't matter.
Gas doesn't do this, it emits a linkable object file. To use ld without a linker script the command line looks something like:
ld -o boot.bin boot.o -oformat binary -T text=0x7C00
(don't quote me on that exact syntax but "something like that") If you can get a linkable object file from your (16-bit capable!) C++ compiler, you might be able to do the same.
In the case of a bootsector, the code is loaded by the BIOS (or fake BIOS) at 0x7C00 - one of the few things we can assume about the bootsector. The sane thing for a bootsector to do is not fiddle-faddle around printing a message, but to load something else. You'll need to know how to find the something else on the disk and where you want to load it to (perhaps where your C++ compiler wants to put it by default) - and jmp there. This jmp will want to be a far jmp, which does need to know the address.
I'm guessing it's going to be some butt-ugly C++!
I'm currently working on hooking ntdll.dll calls via dll injection.
At first, I create thread in existing process via CreateRemoteThread() then I load my dll via LoadLibrary and finally hook calls on PROCESS_ATTACH.
Injection works fine, but then I want to log all registry and file system queries. And the problem is that it doesn't work properly.
I decided to publish code via PasteBin, because piece is pretty big. Here is the link:
http://pastebin.com/39r4Me6B
I'm trying to hook ZwOpenKey, then log key content and then launch "true" function by pointer. Function NOpenKey gets executed, but process stops without any errors.
Does anyone see any issues?
If you use OllyDbg, ZwOpenKey starts with 5 bytes MOV EAX, 77.
You can overwrite these bytes like so JMP _myZwOpenKey then from there you can do whatever with the values on the stack, restore all registers then do a JMP 7C90D5B5 which is address of ZwOpenKey + 5 bytes.
CPU Disasm
Address Hex dump Command Comments
7C90D5AF 90 NOP
7C90D5B0 /$ B8 77000000 MOV EAX,77 ; ntdll.ZwOpenKey(guessed rg1,Arg2,Arg3)
7C90D5B5 |. BA 0003FE7F MOV EDX,7FFE0300
7C90D5BA |. FF12 CALL DWORD PTR DS:[EDX]
7C90D5BC \. C2 0C00 RETN 0C
I usually do these in Assembly that way I don't have to mess around a lot with type casting and all that. Hope this helps.
Is it common for compilers (gcc for instance) to generate an instruction that loads some empty memory element into a register? Like... lw at,0(sp) where memory[sp + 0] = 0. This basically just places 0 into $at ($R1.) I ask because I'm looking through an executable file's hex dump (executable file is the result of the compilation of a c++ file) and I'm manually verifying it and if I start at the objdump state entry point I run into an instruction that does this. I'm not sure whether I should take this to be an error if it's just a common compiler action. It seems like a poor way to zero a register. ADDU $at,$0,$0 would be better. Or SLL $at,$0,$0..
The entry point is 400890. The jump target of the jal at the end is an empty memory location (tells me something is probably wrong...) Note that my previous example was purposefully arbitrated.
And just to be clear, -32636+gp is an empty memory location. I can post the memory contents at the point if you'd like proof :).
00400890 <__start>:
400890: 03e00021 move zero,ra
400894: 04110001 bal 40089c <__start+0xc>
400898: 00000000 nop
40089c: 3c1c0fc0 lui gp,0xfc0
4008a0: 279c7864 addiu gp,gp,30820
4008a4: 039fe021 addu gp,gp,ra
4008a8: 0000f821 move ra,zero
4008ac: 8f848034 lw a0,-32716(gp)
4008b0: 8fa50000 lw a1,0(sp)
4008b4: 27a60004 addiu a2,sp,4
4008b8: 2401fff8 li at,-8
4008bc: 03a1e824 and sp,sp,at
4008c0: 27bdffe0 addiu sp,sp,-32
4008c4: 8f878054 lw a3,-32684(gp)
4008c8: 8f888084 lw t0,-32636(gp)<------ this instruction
4008cc: 00000000 nop
4008d0: afa80010 sw t0,16(sp)
4008d4: afa20014 sw v0,20(sp)
4008d8: afbd0018 sw sp,24(sp)
4008dc: 8f998068 lw t9,-32664(gp)
4008e0: 00000000 nop
4008e4: 0320f809 jalr t9
4008e8: 00000000 nop
Jal target is 4010c0.
4010c0: 8f998010 lw t9,-32752(gp)
4010c4: 03e07821 move t7,ra
4010c8: 0320f809 jalr t9
Perhaps it's being placed after a jump statement? If so, that statement is run before the jump occurs and could be a do nothing instruction (nop). Beyond that, it could just be the compiler on a lower optimization setting. Another possibility is that the compiler is preserving the CPU flags field. Shift and Add play with flags while a load I don't believe does.
This looks like CRT code. I think this code is loading some parameters passed by the OS in to $a0 and $a1 registers. Probably some larger structure is passed on the stack and code is loading that structure in to correct stack location.
This code is probably not generated by C compiler but hand coded in assembly.