"Actually Portable Executable" Incase anyone searches on hn.aloglia in future!
... or uses a screenreader.
αcτµαlly pδrταblε εxεcµταblε
51–60 of 309 posts
Re: αcτµαlly pδrταblε εxεcµταblε
#52Back when all you had was minicom dialing a BBS, there was a chicken and egg problem where you needed uudecode to decode any executable you downloaded. If you did not have uudecode you were stuck. If you are unfamiliar, unencoding a file allows you to send binary data through text transmission. Then a clever version of a DOS .COM file was posted which implemented uudecode, but it only used x86 instructions that were…
but it only used x86 instructions that were also ASCII characters That was a somewhat common approach back then. It's hard to find references to that technique now, but here's something I did find: https://news.ycombinator.com/item?id=16312562
This is still quite useful when working on constrained shellcode, specifically the kind of shellcode you'd enter through a text input field.
Re: αcτµαlly pδrταblε εxεcµταblε
#53I believe that scripts without a shebang line cannot be executed by execve. They will only run if the shell sees them before the kernel does. It's an annoying limitation of this approach and it wasn't clear to me whether this technique includes a workaround for this. Also the push for code signing everywhere is going to make this harder in the future as well. (I heard a rumor that the workaround to run unsigned execu…
> the workaround to run unsigned executables
Was there ever a workaround for this? I thought you just ran them…
Re: αcτµαlly pδrταblε εxεcµταblε
#54Earlier quoted context omitted.
I believe the claim is that there exists a stable subset: > Bell System Five is the umbrella term we use to describe Linux, FreeBSD, OpenBSD, and Mac OS X which all have nearly-identical application binary interfaces that stood the test of time, having definitions nearly the same as those of AT&T back in the 1980's. However, only Linux guarantees stability at this level so I too am very sceptical that this will "stan…
Isn't Windows also known for being committed to both API and ABI stability?
Yes, but the stable interface is functions exported from kernel32, ntdll, etc. Syscall numbers can and do change freely between builds.
Re: αcτµαlly pδrταblε εxεcµταblε
#55This is perverse in the best way possible.
No, this is perverse in the worst way possible. It's incompatible with modern debuggers. It's incompatible with shared libraries. It's limited to a feature-poor "unified" API (that might as well be seen as a crippled VM). It's complex in both interface and implementation. The bad aspects of Unix made even worse. The justifications make no sense whatsoever. It wants to do future-proofing but invents an adhoc "VM" with…
> It's incompatible with modern debuggers.
Any debugger that can't debug this binary is broken and should be treated as such.
Re: αcτµαlly pδrταblε εxεcµταblε
#56Earlier quoted context omitted.
but it only used x86 instructions that were also ASCII characters That was a somewhat common approach back then. It's hard to find references to that technique now, but here's something I did find: https://news.ycombinator.com/item?id=16312562
This is still quite useful when working on constrained shellcode, specifically the kind of shellcode you'd enter through a text input field.
You can even do one better, you can construct shellcode out of valid english sentences.
http://www.cs.jhu.edu/~sam/ccs243-mason.pdf
Since COM files are basically just raw binary code without headers or metadata, it should be easy to adapt the technique to make valid english language COM files.
Re: αcτµαlly pδrταblε εxεcµταblε
#57Earlier quoted context omitted.
I hate it when people do that. It looks tacky and it's super annoying when they (mis)use a script you can read.
It's especially annoying if you took two quarters of Greek like 35 years ago and recognize it just well enough to have trouble seeing it as weird English lettering.
I taught myself to read Greek recently and couldn’t parse it at first either.
Re: αcτµαlly pδrταblε εxεcµταblε
#58As expected, macOS Big Sur refuses to run the resulting executable:
$ ./program.com
-bash: ./program.com: cannot execute binary file: Exec format error
$ sh ./program.com
./program.com: ./program.com: cannot execute binary file
Re: αcτµαlly pδrταblε εxεcµταblε
#59Earlier quoted context omitted.
Isn't Windows also known for being committed to both API and ABI stability?
Yes, but the stable interface is functions exported from kernel32, ntdll, etc. Syscall numbers can and do change freely between builds.
Indeed. The Win32 API (and UWP et al) is the only one that's officially stable.
Kernel syscalls themselves are entirely unstable. Not even just the numbers but the calling convention and everything else. Microsoft reserves the right to add, remove or modify anything in or exposed by the NT kernel. Of course they won't do so frivolously but syscall numbers are especially prone to change with a new build of the kernel.
So as with MacOS, BSD, etc the stable interface is provided by userspace libraries.