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.
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.
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.
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.
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.
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.)
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.
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?
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?
and then once you had the hex-reader, where did you get the hexdump to type in? which programs did you create this way?
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.
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.
https://www.youtube.com/watch?v=DpXy041BIlA
0: http://sigbovik.org/
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 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.
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.)