Compiling C to printable x86 to make an executable research paper (2017) [video] | Hacker News Reader

Compiling C to printable x86 to make an executable research paper (2017) [video]

youtube.com

63 pointsgus_massa15 comments

I have a story about executable text-file and it goes like this:

In 1990 I got Atari Portfolio from liquidation sale in Sweden. Copyright was expired so there were no romcard, which contained various tools to program the bloody thing. It was an empty MSDOS-machine without DEBUG or anything. All I could do was to copy 7 bit ASCII-characters to a file from the keyboard. After few days, or maybe weeks, I managed to construct small ASCII TXT-file, which, when renamed to EXE-file, executed a loop, which read and interpreted hexadecimal code from keyboard and executed this piece of code at <CR>.

This was the gateway and bootstrap to everything else.

And yes: I was now in Finland. So there was no other Atari Portfolio owner anywhere nearby from whom I could have borrowed this romcard.

could you share the rest of the story please?

what does "copy from keyboard" mean? was there a way to type numbers to produce any 7bit sequence?

and with that you wrote a program that could read hex (which was easier to type than raw 7bit code)?

so you wrote the initial program in raw machinecode? not as a script that would be interpreted?

and then what did you type in hex? the whole contents of the romcard? and you got that from where? you had a printout of that?

This is what I was trying to do:

    c:\> echo ABCDEFG > file.txt
    c:\> ren file.txt file.exe
    c:\> file.exe

    DOSBOX: Exit to error: Illegal GRP4 Call 5

Now. Imagine that you study very hard raw machine code and find a new string (replacing ABCDEFG), which constitute valid EXE-header and a piece of code, which does not cause error and does something useful.

And useful thing here was to interpret letter-pairs in the string as hexadecimal numbers, so you then can write any program you want.

Did this help any?

yes, you are confirming what i guessed. so you were able to type out the initial program only with the keys on the keyboard? how did you find what to type?

and then once you had the hex-reader, where did you get the hexdump to type in? which programs did you create this way?

No thank you kindly. I give up. This was 31 years ago and it was once-only issue. Who cares.

Remembered however that COM-files were the simple ones. EXE-headers were more complicated.

But quite obviously I made a program that read stuff from serial port. And once you had ZMODEM you could copy rest of standard MSDOS command set from anywhere. The machine was truly empty, the was only hardwired COMMAND.COM running.

well, that wasn't obvious to me. thank you. so you did have access to the right executables, just no direct way to get them into the machine.

i only dabbled with old unix workstations. the oldest one being a machine from 1989 running apollo domain OS. and i remember booting an AIX workstation into some kind of rescue mode and using ed to fix config files (fstab probably) to allow it to boot.

tom7 / suckerpinch is great, I love his "30 Weird Chess Algorithms" video:

https://www.youtube.com/watch?v=DpXy041BIlA

I loved the video and presentation style. And the idea itself is very much fun.

If you like this brand of wonderful nonsense, you should check out his other videos. He usually posts a video on at least one wacky idea each year, then publishes a research paper about it at SIGBOVIK[0], a joke computer science conference with proceedings released every April 1st.

0: http://sigbovik.org/

Thank you.

I think I read about this a long time ago where it was thought that this could be used to potentially bypass anti-virus checks

To be fair something as simple as adding a self-signed cert bypasses more AVs than it should.

It would work as long as it doesn't become popular. Very few people would put in as much effort as long as there are easier ways around.

I think antivirus would be fine. There is a test file by EICAR https://en.wikipedia.org/wiki/EICAR_test_file . It's also 100% text, but it's and ".com" instead of a ".exe" so the internal structure is easier. And more importantly, it use self-modifying code to modify an instruction and run a non printable instruction, that is somewhat cheating.

Why cheating?

I don't think complying with any kind of "fairness" was ever the point. EICAR was created to fulfill a need to test antiviruses with some additional requirements, and how exactly it achieved it wasn't really important.

I'm not sure if anybody ever described the official design goals for it, but based on some previous reading it seems that being able to type it on a keyboard was a requirement.

I'm guessing this is because the kind of environment in which one experiments with viruses and their detection, it's desirable to maintain physical separation, and so using any kind of media or requiring a network connection would create danger. Or perhaps they also wanted it to be suitable for testing locked down environments where a more convenient way of introducing the test would have already been removed.

The part about cheating was tongue in check, self modifying code makes writing printable executables easier.

An excuse to avoid it is that some operative system are trying to enforce W^X, so executable code can't be modified. (But I think the real reason is that he wanted the harder challenge.)

Reply on news.ycombinator.com