Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

αcτµαlly pδrταblε εxεcµταblε

justine.storage.googleapis.com

Post reply on HN
Print view View original

61–70 of 309 posts

Re: αcτµαlly pδrταblε εxεcµταblε

#61

Post by bigiain »

userbinator wrote: post #5
Rebelgecko wrote: post #3

This is incredible and also very frightening. Has anyone tried to distribute one of these binaries in a real context?

I think the closest to that would be https://en.wikipedia.org/wiki/Shar and I've seen ones that were both valid shell scripts and Windows batch files. Of course, the actual polyglot part is tiny and serves only to direct execution to continue with the appropriate platform-specific binary.

How about most issues of PoC||GTFO?

From issue 2:

"A careful reader may have noticed that a bootable OS image was hidden in the last issue of PoC‖GTFO,as one of the files in its dual PDF/ZIP structure (if you haven’t, download and extract it now!). This time, though, let’s hide it in plain sight. You will find by running ‘qemu-system-i386 -fda pocorgtfo02.pdf’ that the PDF file you are reading is also a bootable disk image."

Re: αcτµαlly pδrταblε εxεcµταblε

#62

Post by tbodt »

krackers wrote: post #12

Can someone eli5 how this works? I sort of get that you can create one big binary file with all the necessary file headers for each platform and the actual x86 code being shared, but what about stuff like syscalls? The post also lost me when it started mentioning the need for shell scripts and emulators.

It turns out to be impossible to create a file that is simultaneously a valid ELF and Windows PE. The solution to this is to make a file that is simultaneously a valid PE and shell script, and have the shell script overwrite the start of the file with an ELF header and re-exec itself.

Re: αcτµαlly pδrταblε εxεcµταblε

#63

Post by marcan_42 »

ChrisSD wrote: post #59
mrpippy wrote: post #54

Earlier quoted context omitted.

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.…

Go tried to break the rules and call macOS syscalls directly (like they do on Linux, because Go is a massively NIH language so they don't use libc where they can get away with it) and it bit them hard when an OS update broke all Go apps.

Re: αcτµαlly pδrταblε εxεcµταblε

#64

Post by zwegner »

userbinator wrote: post #38
snarfy wrote: post #28

Back 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

There's also this compiler (with accompanying paper/video), that compiles C89 to x86 with the output executable restricted even further, to only printable ASCII bytes: http://tom7.org/abc/

Re: αcτµαlly pδrταblε εxεcµταblε

#65

Post by modeless »

saagarjha wrote: post #53
modeless wrote: post #16

I 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…

Downloaded unsigned executables will not run by default on macOS and the error dialog provides no affordance to override this. You just have to know that if you option-click and select "Open", which is always identical to double-clicking except in this special case, you get a different dialog that allows you to override the block.

Re: αcτµαlly pδrταblε εxεcµταblε

#66

Post by celrod »

> the x86_64 patents should expire this year. Apple could have probably made their own x86 chip without paying royalties. The free/open architecture that we've always dreamed of, might turn out to be the one we're already using.

I've never seen anyone mention this before. Is this really in the cards? Or are all the extensions patented as well, so that a hypothetical Apple (or whoever else takes it on) x86 wouldn't be able to use x86 without licensing it?

Re: αcτµαlly pδrταblε εxεcµταblε

#67

Post by saagarjha »

modeless wrote: post #65
saagarjha wrote: post #53

Earlier quoted context omitted.

> the workaround to run unsigned executables Was there ever a workaround for this? I thought you just ran them…

Downloaded unsigned executables will not run by default on macOS and the error dialog provides no affordance to override this. You just have to know that if you option-click and select "Open", which is always identical to double-clicking except in this special case, you get a different dialog that allows you to override the block.

You've always been able to run those without any warnings from the command line.

Re: αcτµαlly pδrταblε εxεcµταblε

#68

Post by modeless »

saagarjha wrote: post #67
modeless wrote: post #65

Earlier quoted context omitted.

Downloaded unsigned executables will not run by default on macOS and the error dialog provides no affordance to override this. You just have to know that if you option-click and select "Open", which is always identical to double-clicking except in this special case, you get a different dialog that allows you to override the block.

You've always been able to run those without any warnings from the command line.

I think that counts as a workaround and no longer works on Apple Silicon. But I haven't verified this myself. Would be interesting to hear from someone who knows.

Edit: Here are the details. Looks like it's true that it simply won't run totally unsigned ARM code. But self-signing is allowed. For now. https://lapcatsoftware.com/articles/unsigned.html

Re: αcτµαlly pδrταblε εxεcµταblε

#69

Post by rkv »

celrod wrote: post #66

> the x86_64 patents should expire this year. Apple could have probably made their own x86 chip without paying royalties. The free/open architecture that we've always dreamed of, might turn out to be the one we're already using. I've never seen anyone mention this before. Is this really in the cards? Or are all the extensions patented as well, so that a hypothetical Apple (or whoever else takes it on) x86 wouldn't be…

https://www.blopeur.com/2020/04/08/Intel-x86-patent-never-en...

Re: αcτµαlly pδrταblε εxεcµταblε

#70

Post by zozbot234 »

rkv wrote: post #69
celrod wrote: post #66

> the x86_64 patents should expire this year. Apple could have probably made their own x86 chip without paying royalties. The free/open architecture that we've always dreamed of, might turn out to be the one we're already using. I've never seen anyone mention this before. Is this really in the cards? Or are all the extensions patented as well, so that a hypothetical Apple (or whoever else takes it on) x86 wouldn't be…

https://www.blopeur.com/2020/04/08/Intel-x86-patent-never-en...

The TL;DR seems to be that if you restrict yourself to implementing an ISA from 20 years ago, your chip can indeed be patent free, but that isn't going to run modern software - maybe not even modern x86 32-bit software!
Post reply on HN