Why he is using 32-bit esp/ebp registers in 16-bit environment? There are 16-bit sp/bp registers. And there is 0xFFFF limit on segment descriptors in real mode anyway.
Writing a Tiny x86 Bootloader
21–30 of 55 posts
Re: Writing a Tiny x86 Bootloader
#22Earlier quoted context omitted.
What would be the equivalent of this in UEFI? I mean is there a one page tutorial on booting with UEFI by writing a few lines of assembly?
I actually looked this up after reading this comment. Best I could find after a quick google search was this: http://x86asm.net/articles/uefi-programming-first-steps/ which is certainly not an easy tutorial to follow. Seems like more robustness tends towards a greater barrier to entry.
It's a lot easier and nicer to use either UEFI or a Multiboot-protocol bootloader (GRUB, or qemu/bochs built-in bootloader). That also means you will be starting in long mode or protected mode.
In order to work with bare metal efficiently, you need to get a debuggable and bootable ELF image up and running as soon as possible. Once you can attach a remote GDB debugger to Qemu, you get things done much faster than using the Qemu/Bochs monitor/debugger.
Anything more complex than a hello world example is easier with UEFI or multiboot than BIOS boot sectors. You will need a linker script and a build script but things will be much easier after the first steps.
I made this pull request for someone else's bare metal project to add debuggable ELF images. It's a small but practical example:
Re: Writing a Tiny x86 Bootloader
#23Re: Writing a Tiny x86 Bootloader
#24Re: Writing a Tiny x86 Bootloader
#25Not saying he is wrong or anything,but he seems to have missed how modern machines ship with UEFI which tries to solve this problem on firmware level. That said: if you're curious and want to learn, I have no objections to digging into stuff, even "obsolete" stuff like BIOS boot :)
Thanks for giving it a look! You're certainly right about UEFI. I figured it would be easier and informative enough in the long run to just write a simple MBR bootloader instead of an EFI-format one. Either way, it was definitely fun.
http://www.advancemame.it/doc-makebootfat
and for an example of how much stuff you can actually put inside some 440 bytes, the base reference is mbldr:
Re: Writing a Tiny x86 Bootloader
#26Does anyone know of any resources for doing stuff like this on ARM? I have a board with u-boot, but I can't find any information about how to do even a hello world type program.
Re: Writing a Tiny x86 Bootloader
#27Re: Writing a Tiny x86 Bootloader
#28Earlier quoted context omitted.
The "findings" you are describing are characteristic of security-conscious users suffering from paranoid schizophrenia. This is not an isolated incident. The "badBIOS" incident reported by Dragos Ruiu a few years ago ([1]) had many of the same characteristics as what you are reporting: • Vague symptoms, affecting all computers (and, often, even non-computer devices) owned by the individual • Inability to isolate the…
Except I have isolated the code and can reproduce it on demand, and have the photo's & video's as evidence so nice try. However having just read this https://www.facebook.com/dragosr/posts/10151655183445588 I can see he has explained much of what I was witnessing on some systems as well. Cant rule out a modern day version of one of these https://en.wikipedia.org/wiki/Phoebus_cartel considering the Windows MSR partiti…
" The OS's seem to actively hide the malware if you use a hex editor to scan the drive or infected files, so over time, some of that open source code has become compromised"
This part, in particular, I find hard to believe. You can inspect open source system and compile everything yourself. Did you try to reproduce this behavior on minimal systems (i.e. BeagleBone) or QEMU?
Re: Writing a Tiny x86 Bootloader
#29It's sad that most of these "bootloader" guides don't take you into actualy boot-loading something. No searching a file system. No loading another binary. No setting up 32 mode. Nothing, just printing text. That's what most of these are on.