Live data from Hacker News

Manually Creating an ELF Executable

robinhoksbergen.com

11–20 of 27 posts

Re: Manually Creating an ELF Executable

#11
post #2

Awesome. My wife and kids asked me if you can write computer programs using just 1s and 0s and I told them that assembly was the lowest you could use, apparently mistakenly. Gonna have to try this out!

The easiest way to do this is to actually build a COM file and run it in a 32-bit version of Windows. COM has no header information at all and just starts running the x86 instructions after loading the file to 0100h.

Re: Manually Creating an ELF Executable

#12
post #4
post #3

Very similar to several posts that have come up before: https://news.ycombinator.com/item?id=5508981 and https://news.ycombinator.com/item?id=3158862 as well as things mentioned therein: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm... which is a 45 byte executable (it doesn't say Hello World), and http://asm.sourceforge.net/intro/hello.html . All the same, very cool, this is a great experiment for any…

> http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm... . which is a 45 byte executable (it doesn't say Hello World) True, I needed 62 bytes to get the greeting in there.

Man, that's an extremely interesting and thorough exploration of the nitty-gritty of how programs work, and I found it totally satisfying to read. I've had many little questions I barely knew I had answered by reading this. Thanks very much for making it!

Re: Manually Creating an ELF Executable

#14
post #13

Is it explained where the values for ecx and edx get filled in? I'm confused as to why edx=0x080480B1 instead of the length of the string (14).

It's the HWLENADDR you're talking about? It's placed as the last byte in (not in: after) the string. Down in the final product the edx part ends up BA B1 80 04 08 (0x080480B1). It's a pointer to that '14' stored 13 bytes past the start of the string ("hello, world\n" is 13 bytes). The ecx points to (0x..A4), exactly 13 less than B1.

edit: You're probably thinking it should be placed as an immediate value. It's hard to say exactly how many bytes it'd take up that way, so using an address to an immediate value is a bit simpler.

Re: Manually Creating an ELF Executable

#15
post #8
post #2

Awesome. My wife and kids asked me if you can write computer programs using just 1s and 0s and I told them that assembly was the lowest you could use, apparently mistakenly. Gonna have to try this out!

Of course you can, though on a modern system it's no longer possible to get code into the system by toggling electrical switches, which was the way computers were bootstrapped way back in the day. But hand assembly isn't so far away from our experience. Woz famously wrote the original Apple ][ ROM by hand, including the BASIC interpreter (itself written in a "SWEET16" bytecode for which he hand-assembled the interpre…

> Of course you can, though on a modern system it's no longer possible to get code into the system by toggling electrical switches, which was the way computers were bootstrapped way back in the day.

Challenge accepted.

Re: Manually Creating an ELF Executable

#16
post #2

Awesome. My wife and kids asked me if you can write computer programs using just 1s and 0s and I told them that assembly was the lowest you could use, apparently mistakenly. Gonna have to try this out!

Here's the DOS COM version. Copy this into HELLO.COM with a hex editor of your choice. It will run in dosbox (that's what I tested on) and should run in Windows COMMAND.COM on a 32-bit system.

  b409ba0d01cd21b44cb05dcd2148454c4c4f20574f524c442124
Here's the breakdown:

  b409    MOV AH, 09h    ; OUTPUT string
  ba0d01  MOV DX, 010Dh  ; address of output buffer (remember we're loaded into 0100h)
  cd21    INT 21h

  b44c    MOV AH, 4Ch    ; TERMINATE with return code
  b05d    MOV AL, 5Dh    ; return code
  cd21    INT 21h

  48454c4c4f20574f524c442124 "HELLO WORLD$" ; DOS strings are $ terminated
Back in the day we used to do this with the DEBUG.COM command. It's actually not that bad to do this. The thing that sucks is hand assembling and going back to fixup your addresses. It starts to get hairy if you need to flip around the CS and DS registers to shift in different segments.

As an exercise for the reader use the RET instruction instead of doing the return code stuff. If you want to really get into you you can look up how to read from the console and then display that string back to the user.

Re: Manually Creating an ELF Executable

#17
post #14
post #13

Is it explained where the values for ecx and edx get filled in? I'm confused as to why edx=0x080480B1 instead of the length of the string (14).

It's the HWLENADDR you're talking about? It's placed as the last byte in (not in: after) the string. Down in the final product the edx part ends up BA B1 80 04 08 (0x080480B1). It's a pointer to that '14' stored 13 bytes past the start of the string ("hello, world\n" is 13 bytes). The ecx points to (0x..A4), exactly 13 less than B1. edit: You're probably thinking it should be placed as an immediate value. It's hard t…

I see where I was off by one byte (14 instead of 13) but that still doesn't explain things. The code doesn't load edx with 13 but instead loads it with 0x080480B1. If you wanted to fetch a byte from that address and load it into edx you'd need to use something like "movzx edx, byte ptr [0x080480B1]" but the code on the page just does "mov edx, 0x080480B1". In fact when you run this the code actually prints out not just "Hello, World\n" but also prints out the 0x0D length byte and then the entire rest of the page (all 0x00). Of course these aren't visible in a terminal. I'm guessing the kernel tries to keep printing but it can't since the next page isn't mapped so it just gives up.

Re: Manually Creating an ELF Executable

#18
post #2

Awesome. My wife and kids asked me if you can write computer programs using just 1s and 0s and I told them that assembly was the lowest you could use, apparently mistakenly. Gonna have to try this out!

Here's the DOS COM version. Copy this into HELLO.COM with a hex editor of your choice. It will run in dosbox (that's what I tested on) and should run in Windows COMMAND.COM on a 32-bit system. b409ba0d01cd21b44cb05dcd2148454c4c4f20574f524c442124 Here's the breakdown: b409 MOV AH, 09h ; OUTPUT string ba0d01 MOV DX, 010Dh ; address of output buffer (remember we're loaded into 0100h) cd21 INT 21h b44c MOV AH, 4Ch ; TERM…

Wasn't there a Phrack Magazine article on typing in software from memory using debug.com? COM-files are funny. I seem to recall "echo d > restart.com" (or possibly "D") would give you a quick way to reboot a 3.11 machine (probably due to some crash or other, I never investigated why it worked - but a couple of other random characters would usually end up with a freeze...

Re: Manually Creating an ELF Executable

#19
post #17
post #14

Earlier quoted context omitted.

It's the HWLENADDR you're talking about? It's placed as the last byte in (not in: after) the string. Down in the final product the edx part ends up BA B1 80 04 08 (0x080480B1). It's a pointer to that '14' stored 13 bytes past the start of the string ("hello, world\n" is 13 bytes). The ecx points to (0x..A4), exactly 13 less than B1. edit: You're probably thinking it should be placed as an immediate value. It's hard t…

I see where I was off by one byte (14 instead of 13) but that still doesn't explain things. The code doesn't load edx with 13 but instead loads it with 0x080480B1. If you wanted to fetch a byte from that address and load it into edx you'd need to use something like "movzx edx, byte ptr [0x080480B1]" but the code on the page just does "mov edx, 0x080480B1". In fact when you run this the code actually prints out not ju…

[deleted]
Post reply on HN