Phreedom

As every section needs to be aligned to the smallest possible section alignment of 0x200 bytes (1KB), we inflate our file by at least that amount of bytes just because of that. 0x200 is 512, or 0.5K. It's been a long time since I've done PE size optimisation at this level but I remember 512 was the minimum accepted by Windows 9x but NT could accept alignments as small as 1. Also, I didn't see any mention of the old trick of overlapping the DOS MZ and PE headers, which was state-of-the-art when I was still doing this stuff: http://www.phreedom.org/research/tinype/ ...and then you realise that the demoscene has managed to do this in a 1k binary: https://www.pouet.net/prodlist.php?type%5B%5D=1k&platform%5B%5D=Wi…

Interesting read! I also enjoyed another article linked from the article, which seeks to find the smallest .exe possible on Windows.[1] [1] http://www.phreedom.org/research/tinype/

Of course 44 is off by 2 (the answer is actually 42) but apart the program doing nothing actually useful, the blog article is nice. We did something like that with actually some use some time ago (shameless plug): http://reboot.pro/topic/18792-if-anyone-is-up-for-a-challenge/ All the way down to 172, 164 and 148 bytes and even a 97 one which is the bare minimum on XP, same link as already posted on the work by Alexander Sotirov, but more readable: http://www.phreedom.org/research/tinype/ The limit on 64 bit (windows 7 64 bit) has been reported at the time to be 252 bytes, but simply padding with zeroes a smaller program worked to find this limit: http://reboot.pro/topic/18792-if-anyone-is-up-for-a-challenge/?p=17642…

Undisclosed "1-day" is real and has gone on forever. A popular set of tools is binary diff tools such as the now defunct Zynamics acquired by Google. There is evidence. The amount of tooling around examining MS patches should convince most. http://www.blackhat.com/presentations/bh-usa-09/OH/BHUSA09-Oh-DiffingB… http://www.phreedom.org/presentations/reverse-engineering-and-security… People built businesses around this. With so many eyeballs on release diffs, undisclosed vulnerable were often discovered (and still are). With the number of experts on file observing this it should not be controversial at all.

You don't need a preimage attack for SHA-1 to cause problems with CAs, just collisions. For example, MD5 does not have any preimage attacks I'm aware of, but it is possible to create rogue CA certificates that use MD5 [1]. Bruce Schneier estimates that we will see SHA-1 collisions relatively soon [2], so it's not like Microsoft is just making this stuff up. I agree that CA compromise is a serious problem, but it's not one Microsoft can do something about. They can ban SHA-1 in certificates, and I think it's a good idea. [1] http://www.phreedom.org/research/rogue-ca/ [2] https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html

You'd be surprised; on Windows, at least, there are people who reverse engineer the security patches from Microsoft in order to determine the initial vulnerability[1]. [1] http://www.phreedom.org/presentations/reverse-engineering-and-security… Edit: Misinterpreted your post. You're right, it's unlikely that they'll guess where it is until a patch comes out.

same for win32 PEs: http://www.phreedom.org/solar/code/tinype/

I think he's talking about this article: http://www.phreedom.org/solar/code/tinype/

The equivalent exercise for the Windows PE file format: http://www.phreedom.org/solar/code/tinype/

You can still inflict a lot of damage if you can create collisions. Producing a rogue CA is just one possibility. http://www.phreedom.org/research/rogue-ca/ The potential for intentional collisions makes it critical that an attacker cannot control or predict all of the inputs to your signing operation.

What's been done here is a chosen-prefix collision attack [1] where the attacker can produce two files that have the same hash. What you're asking about is a preimage attack [2] where one of the files is already created and the attacker can't influence it. The practical attack enabled here is mostly around digital signatures. An attacker could produce documents A and B that both have the same SHA-1. They can then get someone to sign document A (which really is signing the SHA-1 of document A), then use the signature with document B and make it look like they have a document B signed with a valid signature. As an example, if document A is a regular SSL certificate request, and document B is a "CA certificate", the attacker can trick a real CA into signing a rogue CA into existence, which can then sign its own certificates that will be trusted by every browser. This has already happened with MD5 in 2008 [3]. [1] https://en.wikipedia.org/wiki/Collision_attack [2] https://en.wikipedia.org/wiki/Preimage_attack [3] http://www.phreedom.org/research/rogue-ca/