How to compile a simple operating system and make it bootable? - gcc

I'm interested in operating system concepts, so I downloaded the Hello world OS. I'd like to know how to compile and link the code and make a bootable image. I'm using an old version of Cygwin on Windows (Cygwin-b20) from 1999.
My code for main.c is:
#include "bloader.h"
int main();
unsigned int oldEBP;
struct boot_dir *viewableDirectory;
int totalMem;
char * passedParams;
void _start(int memSize, char *parms, struct boot_dir *loadedfiles)
{
asm("mov %%ebp, %0":"=m"(oldEBP));
viewableDirectory = loadedfiles; /*make file mem locations global*/
totalMem = memSize; /*make mem of system global*/
passedParams = parms; /*make paramaters passed to system global*/
main();
asm("hlt"); /* this halts the machine, solving the problem of triple-faults on
some machines, but also making it impossible to return to DOS */
}
int main()
{
char *vidmem = (char *) 0xb8000;
/* "Hello " */
vidmem[0] = 'H';
vidmem[1] = 0x7;
vidmem[2] = 'e';
vidmem[3] = 0x7;
vidmem[4] = 'l';
vidmem[5] = 0x7;
vidmem[6] = 'l';
vidmem[7] = 0x7;
vidmem[8] = 'o';
vidmem[9] = 0x7;
vidmem[10] = ' ';
vidmem[11] = 0x7;
/* "World " */
vidmem[12] = 'W';
vidmem[13] = 0x7;
vidmem[14] = 'o';
vidmem[15] = 0x7;
vidmem[16] = 'r';
vidmem[17] = 0x7;
vidmem[18] = 'l';
vidmem[19] = 0x7;
vidmem[20] = 'd';
vidmem[21] = 0x7;
vidmem[22] = ' ';
vidmem[23] = 0x7;
/* "OS" */
vidmem[24] = 'O';
vidmem[25] = 0x7;
vidmem[26] = 'S';
vidmem[27] = 0x7;
return 0;
}
I'm interested in instructions to:
Create ISO file after compile and run it with VMware (or other virtual machines)
Run this code after compiling in real machine when system boots and how to add it to bootloader (for example GRUB) entry

Make an empty file and give it the extension .vmdk
open it up in your favorite hex editor
and place your compiled boot loader code
its exactly the same as a hard drive
also the last 2 bytes in the sector must be 55 and AA
your bootloader code starts from 00
it will look something like this
Sector Offset Hex Values Ascii
x00000000 x000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x0A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x0B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x0C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x0D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x0E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x0F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-------------
x1F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
here is a guide to make run a boot loader
http://www.codeproject.com/Articles/36907/How-to-develop-your-own-Boot-Loader#_Toc231383191

Related

Wider hexdump output

I'm a big fan of the default formatting of the hd command. For example:
$ head -c128 /bin/bash |hd
00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 03 00 3e 00 01 00 00 00 30 f6 02 00 00 00 00 00 |..>.....0.......|
00000020 40 00 00 00 00 00 00 00 48 ce 11 00 00 00 00 00 |#.......H.......|
00000030 00 00 00 00 40 00 38 00 0b 00 40 00 1d 00 1c 00 |....#.8...#.....|
00000040 06 00 00 00 04 00 00 00 40 00 00 00 00 00 00 00 |........#.......|
00000050 40 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 |#.......#.......|
00000060 68 02 00 00 00 00 00 00 68 02 00 00 00 00 00 00 |h.......h.......|
00000070 08 00 00 00 00 00 00 00 03 00 00 00 04 00 00 00 |................|
00000080
I'm looking for a hexdump command that does the same thing but is double-wide. Output should look something like:
$ head -c128 /bin/bash |2hd
00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 03 00 3e 00 01 00 00 00 30 f6 02 00 00 00 00 00 |.ELF............| |..>.....0.......|
00000020 40 00 00 00 00 00 00 00 48 ce 11 00 00 00 00 00 00 00 00 00 40 00 38 00 0b 00 40 00 1d 00 1c 00 |#.......H.......| |....#.8...#.....|
00000040 06 00 00 00 04 00 00 00 40 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 |........#.......| |#.......#.......|
00000060 68 02 00 00 00 00 00 00 68 02 00 00 00 00 00 00 08 00 00 00 00 00 00 00 03 00 00 00 04 00 00 00 |h.......h.......| |................|
00000080
So far, I've got this. It does not line up properly.
2hd() {
local poe='" " 8/1 "%02x "' # pieces of eight, heh
hexdump -e '"%07.7_Ax\n"' \
-e '"%07.7_ax" '"$poe $poe $poe $poe"' " |" 32/1 "%_p" "|\n"' "$#"
}
$ head -c128 /bin/bash |2hd
0000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 03 00 3e 00 01 00 00 00 30 f6 02 00 00 00 00 00 |#.......H...........#.8...#.....|
0000040 06 00 00 00 04 00 00 00 40 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 |h.......h.......................|
0000080 a8 02 00 00 00 00 00 00 a8 02 00 00 00 00 00 00 a8 02 00 00 00 00 00 00 1c 00 00 00 00 00 00 00 |................................|
00000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 98 cd 02 00 00 00 00 00 98 cd 02 00 00 00 00 00 |................................|
0000100
(I haven't decided whether or not I want the right-side display to be in one part or two.)
I'm hoping to do this entirely within a single reference to hexdump. It'd help to know what the hexdump command to get the 16-col hd output would look like too. (The docs I can find are not helpful at this.)
I think you may just need to split the second -e:
2hd() {
local poe='" " 8/1 "%02x "'
hexdump -e '"%07.7_Ax\n"' \
-e '"%07.7_ax" '"$poe $poe $poe $poe" \
-e ' " |" 32/1 "%_p" "|\n"' "$#"
}
Multiple -e each work on the same input. In your original, the %_p applies to the input after the %x because it is in the same -e.
busybox hexdump source defines -C as:
bb_dump_add(dumper, "\"%08.8_Ax\n\""); // final address line after dump
//------------------- "address " 8 * "xx " " " 8 * "xx "
bb_dump_add(dumper, "\"%08.8_ax \"8/1 \"%02x \"\" \"8/1 \"%02x \"");
//------------------- " |ASCII...........|\n"
bb_dump_add(dumper, "\" |\"16/1 \"%_p\"\"|\n\"");
so that means you can implement hd as:
hexdump -e "\"%08.8_Ax\n\"" -e "\"%08.8_ax \"8/1 \"%02x \"\" \"8/1 \"%02x \"" \
-e "\" |\"16/1 \"%_p\"\"|\n\""

What format are GCC's object files in?

I assembled an assembly file in GCC under Windows like so:
as main.s -o main.o
And now I have the following object file:
4C 01 03 00 00 00 00 00 90 00 00 00 08 00 00 00
00 00 05 01 2E 74 65 78 74 00 00 00 00 00 00 00
00 00 00 00 04 00 00 00 8C 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 20 00 30 60 2E 64 61 74
61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40 00 30 C0 2E 62 73 73 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 80 00 30 C0 C3 90 90 90
2E 66 69 6C 65 00 00 00 00 00 00 00 FE FF 00 00
67 01 66 61 6B 65 00 00 00 00 00 00 00 00 00 00
00 00 00 00 2E 74 65 78 74 00 00 00 00 00 00 00
01 00 00 00 03 01 01 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 2E 64 61 74 61 00 00 00
00 00 00 00 02 00 00 00 03 01 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 2E 62 73 73
00 00 00 00 00 00 00 00 03 00 00 00 03 01 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
04 00 00 00
I'd like to look inside this file to try and understand how object files are put together. Where can I find a format specification for whatever format this file is?

SSH: Understanding Algorithm Negotiation

I'm currently writing an ssh honeypot in Java as a personal project. I'm having trouble understanding the algorithm negotiation. To be precise, the structure of the received data from the client. Here is what I receive, with my personal annotations:
00 00 07 AC == packet length
08 == padding length
14 == SSH_MSG_KEXINIT
6C 31 89 77 EB 54 E1 8B D4 B1 35 08 FD 52 65 6E == cookie
00 00 00 D4 == string length
kex algorithms in byte form
00 00 01 67 == string length
server host key algorithms in byte form
00 00 00 E9 == string length
encryption_algorithms_client_to_server in byte form
00 00 00 E9 == string length
encryption_algorithms_server_to_client in byte form
00 00 01 92 == string length
mac_algorithms_client_to_server in byte form
00 00 01 92 == string length
mac_algorithms_server_to_client in byte form
00 00 00 1A == string length
compression_algorithms_client_to_server in byte form
00 00 00 1A == string length
compression_algorithms_server_to_client in byte form
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Information about the negotiation can be found here:
rfc4253
There are two things I don't fully understand:
The padding: How is it calculated? According to rfc4253, there should be a random padding (8 bytes in this case). I don't see it anywhere. Moreover, the size of the packet length + padding length + payload + padding should be a multiple of 8, which isn't the case here. (?)
The packet length: If I just sum up everything after the packet length, I get 0x797. Adding the 8 byte padding (wherever it is), I get 0x79F. Am I correct in thinking that the languages for client->server and server->client, although not defined, still take 4 byte each? That gets me to 0x7A7. If I now add the boolean and the reserved 4 bytes (see packet structure), I finally get 0x7AC. Is that correct? That would mean the trailing zeros have the following structure:
00 00 00 00 == length of string for language_client_to_server
00 00 00 00 == length of string for language_server_to_client
00 == boolean first_kex_packet_follows
00 00 00 00 == reserved
rest: garbage?

What are the differences between a Windows bitmap and DIBSection?

I'm loading a DIBSection from a file with the following:
HBITMAP bmpIn = (HBITMAP) LoadImage(NULL, _T("c:\\Temp\\Temp.bmp"), IMAGE_BITMAP, 0, 0, LR_CREATEDIBSECTION | LR_LOADFROMFILE);
Empirically I've discovered the following differences between the loaded bitmap and the bitmaps that I've used in the past, but I can't find any documentation stating that there should be a difference.
The lines are ordered in memory top down rather than bottom up. I've verified that the .bmp file itself is ordered bottom up.
The row padding is to a multiple of 2 bytes rather than 4.
I've also discovered a documented difference when you use CreateDIBSection to create a DIBSection from scratch.
The DIBSECTION.dsHandle and BITMAP.bmBits values returned by GetObject will be NULL.
Where's the documentation for the first two differences, and am I missing anything? This is with Windows 7 but I can't imagine it would be different for other versions of Windows.
Edit: Some additional details. Here's a hex dump of temp.bmp; it's a 7x7 image with a white stripe down the right side and blue values incrementing along the left (0x10,0x20,etc.). You can see that the bottom line (00,00,70) is first and that there's 3 bytes of padding.
00: 42 4d de 00 00 00 00 00 00 00 36 00 00 00 28 00
10: 00 00 07 00 00 00 07 00 00 00 01 00 18 00 00 00
20: 00 00 a8 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 70 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 ff ff ff 00 00 00 60 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: ff ff ff 00 00 00 50 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 ff ff ff 00 00 00 40 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: ff ff ff 00 00 00 30 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 ff ff ff 00 00 00 20 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: ff ff ff 00 00 00 10 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 ff ff ff 00 00 00
Here's a sample program to read the .bmp file and write out the contents. I've removed error checking for brevity.
int _tmain(int argc, _TCHAR* argv[])
{
HBITMAP bmpIn = (HBITMAP) LoadImage(NULL, argv[1], IMAGE_BITMAP, 0, 0, LR_CREATEDIBSECTION | LR_LOADFROMFILE);
FILE * out = _tfopen(argv[2], _T("wb"));
DIBSECTION obj = {0};
GetObject(bmpIn, sizeof(obj), &obj);
cout << "dsBm.bmHeight = " << obj.dsBm.bmHeight << endl;
cout << "dsBmih.biHeight = " << obj.dsBmih.biHeight << endl;
cout << "sizeof(DIBSECTION) = " << sizeof(DIBSECTION) << endl;
fwrite(&obj, sizeof(DIBSECTION), 1, out);
int stride = (((obj.dsBmih.biWidth * obj.dsBmih.biBitCount) + 15) / 16) * 2;
int bytecount = abs(obj.dsBmih.biHeight) * stride;
vector<BYTE> bits(bytecount);
GetBitmapBits(bmpIn, bytecount, &bits[0]);
fwrite(&bits[0], 1, bytecount, out);
fclose(out);
return 0;
}
And here's the output from the above program along with a hex dump of the file produced:
dsBm.bmHeight = 7
dsBmih.biHeight = 7
sizeof(DIBSECTION) = 84
00: 00 00 00 00 07 00 00 00 07 00 00 00 18 00 00 00
10: 01 00 18 00 00 00 11 00 28 00 00 00 07 00 00 00
20: 07 00 00 00 01 00 18 00 00 00 00 00 a8 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 ff ff ff 00 20 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff 00
80: 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 ff ff ff 00 40 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 ff ff ff 00 50 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff
c0: ff 00 60 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 ff ff ff 00 70 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 ff ff ff 00
Call GetDIBits instead of GetBitmapBits. The docs for GetBitmapBits (here) indicate that this is returning data for a device-dependent bitmap, whereas you have a device-independent bitmap. They also indicate that this call shouldn't be used and is just there for 16-bit compatibility. So, using GetDIBits should do the trick.

What is RIDI_PREPARSEDDATA in GetRawInputDeviceInfo?

Windows API function GetRawInputDeviceInfo has a parameter uiCommand. One of the options is RIDI_PREPARSEDDATA. It says "pData points to the previously parsed data".
I don't get what previously parsed data they are referring to. Is it the data that was last sent with WM_INPUT? Or is it data that was returned by any of the functions? Or something else? Also in what format is that data?
Preparsed data is report descriptor data associated with a top-level collection. User-mode applications or kernel-mode drivers use preparsed data to extract information about specific HID controls without having to obtain and interpret a device's entire report descriptor.
MSDN Link
"Also in what format is that data?"
Today I looked into GetRawInputDeviceInfo(), including the RIDI_PREPARSEDDATA data. Here's the output of the program when I test my XBOX controller. Everything except for displayable characters are in hex, and the hex for the displayable characters are given in parentheses after the displayable character.
getting device info...
Preparing 5 device lists...
Getting 5 devices...
index: type| location
0: HID| 0x01FB035F
1: Keyboard| 0x0001003F
2: Keyboard| 0x000B003D
3: Mouse| 0x0001003B
4: Mouse| 0x000B0039
Which would you like more info about?__
Pointer: 0x01FB035F
Type: HID
Name: \\?\HID#VID_0E6F&PID_0401&IG_00#7&2c93b906&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Vendor ID: 0x00000e6f
Product ID: 0x00000401
Version Number: 0x00000000
Usage Page: 0x0001
Usage: 0x0005
DATA: (940 bytes)
H(0x48) i(0x69) d(0x64) P(0x50)
(0x20) K(0x4b) D(0x44) R(0x52)
05 00 01 00
00 00 00 00
00 00 07 00
07 00 0f 00
07 00 00 00
07 00 00 00
07 00 00 00
07 00 00 00
d8 02 04 00
01 00 00 00
10 00 01 00
03 00 10 00
02 00 00 00
05 00 01 00
01 00 00 00
08 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
1(0x31) 00 1(0x31) 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
ff ff ff ff
00 00 00 00
ff ff ff ff
00 00 00 00
00 00 00 00
01 00 00 00
10 00 01 00
01 00 10 00
02 00 00 00
03 00 01 00
01 00 00 00
08 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
0(0x30) 00 0(0x30) 00
00 00 00 00
00 00 00 00
01 00 01 00
00 00 00 00
00 00 00 00
ff ff ff ff
00 00 00 00
ff ff ff ff
00 00 00 00
00 00 00 00
01 00 00 00
10 00 01 00
07 00 10 00
02 00 00 00
09 00 02 00
01 00 00 00
08 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
4(0x34) 00 4(0x34) 00
00 00 00 00
00 00 00 00
02 00 02 00
00 00 00 00
00 00 00 00
ff ff ff ff
00 00 00 00
ff ff ff ff
00 00 00 00
00 00 00 00
01 00 00 00
10 00 01 00
05 00 10 00
02 00 00 00
07 00 02 00
01 00 00 00
08 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
3(0x33) 00 3(0x33) 00
00 00 00 00
00 00 00 00
03 00 03 00
00 00 00 00
00 00 00 00
ff ff ff ff
00 00 00 00
ff ff ff ff
00 00 00 00
00 00 00 00
01 00 00 00
10 00 01 00
09 00 10 00
02 00 00 00
0b 00 03 00
01 00 00 00
08 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
2(0x32) 00 2(0x32) 00
00 00 00 00
00 00 00 00
04 00 04 00
00 00 00 00
00 00 00 00
ff ff ff ff
00 00 00 00
ff ff ff ff
00 00 00 00
00 00 00 00
09 00 00 00
01 00 0a 00
0b 00 0a 00
02 00 00 00
0d 00 00 00
01 00 05 00
1c 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
01 00 0a 00
00 00 00 00
00 00 00 00
05 00 0e 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
01 00 00 02
04 00 01 00
0c 00 04 00
B(0x42) 00 00 00
0d 00 00 00
01 00 05 00
08 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
9(0x39) 00 9(0x39) 00
00 00 00 00
00 00 00 00
0f 00 0f 00
01 00 00 00
01 00 00 00
08 00 00 00
00 00 00 00
;(0x3b) 10 00 00
0e 00 00 00
00 00 00 00
05 00 01 00
00 00 03 00
00 00 03 00
01 00 00 00
00 00 01 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 01 00
00 00 00 00
01 00 00 00
00 00 00 00
00 00 01 00
00 00 00 00
02 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
end of data.Press any key to continue . . .
Notice the HidP KDR at the beginning. Other than that it looks like gibberish. The program formatted it nicely into four-octet words, but it looks like it will not display properly here without extra effort from me. Yes, it is meant to display on a command line, and no, I do not want to get rid of the result of system("pause").

Resources