How to write and execute PURE machine code manually without containers like EXE or ELF?

Question

I just need a hello world demo to see how machine code actually works.

Though windows\' EXE and linux\' ELF is near machine code,bu

Answer 1

The next program is an Hello World program I wrote in Machine Code 16 bit (intel 8086), If you want to know machine code, I suggest that you learn Assembly first, because every line of code in Assembly is converted to A code line in Machine Code. For well I know I am from the few people in the world, still programming in Machine Code, instead of Assembly.

BTW, To run it, save the file with a ".com" extension and run on DOSBOX!

So, this is an Hello World Program.

Answer 2

Everyone knows that the application we usually wrote is run on the operating system. And managed by it.

It means that the operating system is run on the machine. So I think that is PURE machine code which you said.

So, you need to study how an operating system works.

Here is some NASM assembly code for a boot sector which can print "Hello world" in PURE.

 org
   xor ax, ax
   mov ds, ax
   mov si, msg
boot_loop:lodsb
   or al, al 
   jz go_flag   
   mov ah, 0x0E
   int 0x10
   jmp boot_loop

go_flag:
   jmp go_flag

msg   db 'hello world', 13, 10, 0

   times 510-($-$$) db 0
   db 0x55
   db 0xAA

And you can find more resources here: http://wiki.osdev.org/Main_Page.

END.

If you had installed nasm and had a floppy, You can

nasm boot.asm -f bin -o boot.bin
dd if=boot.bin of=/dev/fd0

Then, you can boot from this floppy and you will see the message. (NOTE: you should make the first boot of your computer the floppy.)

In fact, I suggest you run that code in full virtual machine, like: bochs, virtualbox etc. Because it is hard to find a machines with a floppy.

So, the steps are First, you should need to install a full virtual machine. Second, create a visual floppy by commend: bximage Third, write bin file to that visual floppy. Last, start your visual machine from that visual floppy.

NOTE: In https://wiki.osdev.org , there are some basic information about that topic.

Answer 3

This are nice responses, but why someone would want to do this might guide the answer better. I think the most important reason is to get full control of their machine, especially over its cache writing, for maximum performance, and prevent any OS from sharing the processor or virtualizing your code (thus slowing it down) or especially in these days snooping on your code as well. As far as I can tell, assembler doesn't handle these issues and M$/Intel and other companies treat this like an infringement or "for hackers." This is very wrong headed however. If your assembler code is handed over to an OS or proprietary hardware, true optimization (potentially at GHz frequencies) will be out of reach. This is an very important issue with regards to science and technology, as our computers cannot be used to their full potential without hardware optimization, and are often computing several orders of magnitude below it. There probably is some workaround or some open-source hardware that enables this but I have yet to find it. Penny for anyones thoughts.

Answer 4

When targeting an embedded system you can make a binary image of the rom or ram that is strictly the instructions and associated data from the program. And often can write that binary into a flash/rom and run it.

Operating systems want to know more than that, and developers often want to leave more than that in their file so they can debug or do other things with it later (disassemble with some recognizable symbol names). Also, embedded or on an operating system you may need to separate .text from .data from .bss from .rodata, etc and file formats like .elf provide a mechanism for that, and the preferred use case is to load that elf with some sort of loader be it the operating system or something programming the rom and ram of a microcontroller.

.exe has some header info as well. As mentioned .com didnt it loaded at address 0x100h and branched there.

to create a raw binary from an executable, with a gcc created elf file for example you can do something like

objcopy file.elf -O binary file.bin

If the program is segmented (.text, .data, etc) and those segments are not back to back the binary can get quite large. Again using embedded as an example if the rom is at 0x00000000 and data or bss is at 0x20000000 even if your program only has 4 bytes of data objcopy will create a 0x20000004 byte file filling in the gap between .text and .data (as it should because that is what you asked it to do).

What is it you are trying to do? Reading a elf or intel hex or srec file are quite trivial and from that you can see all the bits and bytes of the binary. Or disassembling the elf or whatever will also show you that in a human readable form. (objdump -D file.elf > file.list)

Answer 5

With pure machine code, you can use any language that has an ability to write files. even visual basic.net can write 8,16,32,64 bit while interchanging between the int types while it writes.

You can even set up to have vb write out machine code in a loop as needed for something like setpixel, where x,y changes and you have your argb colors.

or, create your vb.net program regularly in windows, and use NGEN.exe to make a native code file of your program. It creates pure machine code specific to ia-32 all in one shot throwing the JIT debugger aside.

Answer 6

On Windows--at least 32bit Windows--you can execute RAW INSTRUCTIONS using a .com file.

For instance, if you take this string and save it in notepad with a .com extension:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

It will print a string and set off your antivirus software.