Post #1787454

2026-04-29 22:31 UTC

It really bugged me that copy.fail only published the (very poorly) minified Python proof of concept exploit, so I unminified it https://www.thea.net.nz/~thea/unminified.py Why do I say very poorly? There are at least 5 extraneous bytes: a redundant comma and two cases of a value which is also the default parameter. That and including a shebang in a .py file is redundant. Additionally Python has a function specifically for AF_ALG sockets, which would save even more bytes. They said 732 bytes, I say 688. Anyway here's a slightly more pythonic version: https://www.thea.net.nz/~thea/unminified_pythonic.py

Replies (4)

@sitharus@cloudisland.nz 2026-04-29 22:51

I should add that I haven’t validated the unminified version because I don’t have a vulnerable system to check, and I need to do my Real Job so don’t have time to spin up a VM.

Open ##1788169
@gwen@tech.lgbt 2026-04-30 07:18

@sitharus@cloudisland.nz there’s also a few bytes to be saved in the embedded ELF you don’t really need exit() after execve() I’m not sure if the setuid call is necessary since it should already be executed with effective uid 0 the instructions that load constants into registers look like they could be using one byte less but I’m not enough of an assembly expert to say for sure And does it even make sense to count the payload as part of the exploit? In a real scenario that payload would likely be larger to do anything useful anyways That said, why are they even golfing the poc in the first place, it feels like they’re trying to create the impression that less bytes makes it better/scarier/easier to exploit

Open ##1800939
@sitharus@cloudisland.nz 2026-04-30 11:56

OK I blogged about this, got it down to 654 bytes if you exclude Python 3.5, 672 if you need 3.5 support: https://thea.hutchings.gen.nz/2026/April/copy_fail_code_golf.html

Open ##1806135
@yakmoose@cloudisland.nz 2026-04-29 23:16

@sitharus now do one in rust ….

Open ##1888679