After creating the boot loader, if I copy the bytes of the boot loader and paste it on the 1st 512 bytes of the pen drive using a hex editor, will it work? (Actually I want to learn creating an operating system from scratch.)
I'm not entirely sure I understand your question, but to answer the title: yes. You can write to any part of the drive with an appropriately-designed hex editor with appropriate permissions (usually "sudo" access is required on Linux).
For instance, writing to the boot sector of a flash drive is necessary for automating booting of the CHDK system.
Not all hex editors are designed to access drives, some can only work with files. For instance, the NCurses Hexeditor normally works only with files, but can be made to access disks as files in Linux/Unix environment by employing the -d flag.
The Linux dd command also enables low-level writing to drives. This may be useful in your case as it can be used to perform byte-by-byte copies of drive contents, including MBR sections.
Do not know about HEX editors, but looks like on Windows you can try to CreateFile with name like this \\.\PHYSICALDRIVE0 or just \\PHYSICALDRIVE0. And alter them with WriteFile (with caution!!! otherwise you can damage your OS install or other data).
You can probably figure out device name with WinObj. Also take a look at this project and this question.
Related
What would be the simplest and most portable way (in the sense of only having to copy a few files to the target machine, like procdump is) to generate a kernel dump that has handle information?
procdump has the -mk option which generates a limited dump file pertaining to the specified process. It is reported in WinDbg as:
Mini Kernel Dump File: Only registers and stack trace are available. Most of the commands I try (!handle, !process 0 0) fail to read the data.
Seems that officially, windbg and kd would generate dumps (which would require kernel debugging).
A weird solution I found is using livekd with -ml: Generate live dump using native support (Windows 8.1 and above only).. livekd still looks for kd.exe, but does not use it :) so I can trick it with an empty file, and does not require kernel debugging. Any idea how that works?
LiveKD uses the undocumented NtSystemDebugControl API to capture the memory dump. While you can easily find information about that API online the easiest thing to do is just use LiveKD.
I can't seem to find an answer to this question. I'd just like to understand how one single OS can implement and run (support) multiple file systems?
Assume that there's a global name-space where all file and directory names have some sort of prefix to determine which file system the file or directory is from. For some operating systems (DOS) the prefix might be a device letter (e.g. the C:\ at the start of C:\foo\bar.txt). For other operating systems it might look like a normal part of the file's path (e.g. the /home at the start of /home/foo/bar.txt/ might tell the OS that the file is in the file system mounted at /home).
Once the OS has figured out which file system contains the file it can ask that file system about the file using the remaining part of the file's "global name" (e.g. for the file /home/foo/bar.txt it'd ask the file system mounted at /home for the file /foo.bar.txt).
To allow this to work there will be a layer built into the OS to register file systems and figure out which file system to ask about which file or directory (likely in addition to providing other features - e.g. caching directory info and file data). Often (but not always) this is called "the Virtual File System" (or VFS).
During boot, and when a new storage device is plugged in, there will be "something" to figure out which type of file system to use and how it will be added to the global name space. This can include auto-detection (e.g. from partition table entries on the storage device), a set of rules for removable media, and/or a configuration file (/etc/fstab).
The basic function of a file system is to provide the mapping to translate virtual blocks into logical blocks (or in ye olde days, physical blocks). For a file system, the operating system has to implement a translation system that will convert virtual block N of a file into logical block Q on the disk.
There is nothing that prevents an operating system from having multiple subsystems for performing that translation in different ways corresponding to multiple file systems.
Most operating systems have some kind of MOUNT command that tells the operating system to connect to a disk and determine what kind of file system it has. It is during the mount process that the operating system selects the appropriate virtual to logical translation software to use.
Operating system has supported multiple file systems from the beginning. In ye olde days, there were 9-track tapes with their own file systems in addition to disks. The operating system had to support those as well.
I'm studying OS development and I use brokenthorn resource but with a little bit different tool, namely, I use CentOS, NASM and Qemu as a test/dev environment. I've been facing some issues while creating bootable img file with secondary loader.
I've got two files:
1. bootloader.bin which is first stage loader.
2. stage2.bin which is secondary loader.
In order to create bootable img file I do the following:
dd if=/dev/zero of=floppy.iso bs=1024 count=1440 -- Creating empty file
mkfs.vfat -F 12 floppy.iso --Creating file system in the file
dd if=../bin/bootloader.bin of=floppy.iso bs=512 count=1 conv=notrunc --Writing first loader to the boot sector
sudo mount -o loop floppy.iso /mnt/floppy/ -- Try to mount file system to write secondary loader using previously create FAT-12 files system.
In the last step I'm getting the following error:
mount: /dev/loop0 is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
Can you please help me to understand what I'm doing wrong and what other ways I can use to accomplish creating bootable img with file system on board.
Thanks!
I once stumbled upon the similar problem and this answer may be of help to you.
However I would strongly recommend you switching to bootloader like Grub and spend time and effort developing the actual OS of yours. For that I would reccomend grub resque as it's simple to use and allows to to quickly create ISO that you can either burn or feed to virtual machine. Otherwise, you may just drown in all these minor things like enabling protected mode, loading your stages and so on.
I have a hard drive was crypted by TryeCrypt,a custom edtion ,self input password,and i have found this 40-bytes password via MBR debugging, but can't mount it using standard version 7.1a.
what i want is get some files from this hard drive,good news is,this hard drive is bootable and it is a windows xp sp2,but a fullscreen app was auto startup and any input(keyboard,mouse etc.) was blocked,therefore,the only way to touch it is debugging it with vmware gdb stub.
The ida's remote dbg debugger is working very well, now I touch the guest's memory, edit it's codes, set breakpoints and the symbols was loaded.
so the question is,how can I start a process via patching the kernel?
What I thinking is,build a winddk project , implement a driver to do this with user APC, and then disassemble it to get it's assembler code ,and then patch it into guest via ida.
Any idea? thanks.
I'm currently installing virtual box, and one of the steps requires that I add a disk image (in my case, an ubuntu ISO file) to a virtual CD/DVD drive listed under the virtual machines Storage.
From what I understand the ISO basically contains all the contents of ubuntu. And once I've allocated enough disk space for my virtual machine, I need to install ubuntu by reading from this ISO file into my virtual hard drive.
So- is that the reason why I need to add the ISO image to my dvd/cd? Because it acts as an ACTUAL cd/dvd? My understanding is limited - I just want more clarification about this process!
.iso files are images of the entire content of a CD. They are meant to be burnt on a actual CD. But there are now several programs allowing to read the content of an .iso file without actually writing the data to a CD.
You're right in everything you said.
Virtual Box simulates (almost) everything of a real computer: disks, drives, memory, USB ports...
The drive is initially empty, i.e. has no CD/DVD inside.
Then you choose which CD should be simulated inside the drive. It can be either the actual CD on your physical machine, or a CD image, i.e. a .iso file.
When some program inside the virtual machine wants to access the data written on what it thinks is the CD, Virtual Box reads the .iso file and answer the program, as if the data came from a CD.
Virtual box uses virtual drives. These drives act as 'actual' drives on the guest OS, in your case Ubuntu would be the guest OS.
When you create a new virtual machine, it is clean, nothing has been installed yet.
In order to install Ubuntu on the machine you will need to load the ISO image into the virtual CD/DVD drive to install it.
Note: A ISO is a 'disk image' that contains the entire contents of a disk in a single file, that can be loaded into virtual drives, or burned to physical CD/DVDs
Here is a small tutorial on install Ubuntu to virtual box, the screen shots may differ a little bit, but the process will generally be the same for you.
http://osxdaily.com/2012/03/27/install-run-ubuntu-linux-virtualbox/