It's not so difficult to produce two md5-collided exe files

[mcp]

Maybe I don't follow the discussion properly, but crafting two executables that have the same CRC is definitely not "nearly impossible". Same is of course not true for any true hashing function (like MD5)

[BlackWhite]

Originally Posted by mcp

Maybe I don't follow the discussion properly, but crafting two executables that have the same CRC is definitely not "nearly impossible". Same is of course not true for any true hashing function (like MD5)

If one exe file is specified by others, not crafted by yourself,
I think it's much hard to produce another exe file with the same
CRC or md5 hash.

If you can, would you please share your idea with us? Thanks.

[Kerlingen]

The point is that you don't modify any existing code to a specific value, you just add some random data without any meaning while leaving the original EXE completely untouched.

This is just a normal collision of random data which has been done many times by many people and has nothing to do with EXE file. (and which cannot be used to create "bad" EXE files with the same hash as existing "good" EXE files)

[BlackWhite]

Originally Posted by Kerlingen

The point is that you don't modify any existing code to a specific value, you just add some random data without any meaning while leaving the original EXE completely untouched.

This is just a normal collision of random data which has been done many times by many people and has nothing to do with EXE file. (and which cannot be used to create "bad" EXE files with the same hash as existing "good" EXE files)

Yes. No one can create a "bad" EXE with the same hash as the
existing "good" EXE if this "good" EXE is specified by others.

But if you craft that "good" EXE yourself, you can create a "bad" one,
and under some circumstances, you can defraud sb of a digital signature for
the "good" EXE and then apply to the "bad" one.

So my method is to some degrees concerned with EXE file. If you append
the collision data to a .doc file, it will not affect the contents of that
doc file, yet if you append the collision data to an exe, it can affect
the results of that exe.

[mcp]

This paper describes the process of reversing a CRC32 checksum

Here is some C# code that should do what you want:

public class Crc32
{
    public const uint poly = 0xedb88320;
    public const uint startxor = 0xffffffff;

    static uint[] table = null;
    static uint[] revtable = null;

    public void FixChecksum(byte[] bytes, int length, int fixpos, uint wantcrc)
    {
        if (fixpos + 4 > length) return;

        uint crc = startxor;
        for (int i = 0; i < fixpos; i++) {
            crc = (crc >> 8) ^ table[(crc ^ bytes[i]) & 0xff];
        }

        Array.Copy(BitConverter.GetBytes(crc), 0, bytes, fixpos, 4);

        crc = wantcrc ^ startxor;
        for (int i = length - 1; i >= fixpos; i--) {
            crc = (crc << 8) ^ revtable[crc >> (3 * 8)] ^ bytes[i];
        }

        Array.Copy(BitConverter.GetBytes(crc), 0, bytes, fixpos, 4);
    }

    public Crc32()
    {
        if (Crc32.table == null) {
            uint[] table = new uint[256];
            uint[] revtable = new uint[256];

            uint fwd, rev;
            for (int i = 0; i < table.Length; i++) {
                fwd = (uint)i;
                rev = (uint)(i) << (3 * 8);
                for (int j = 8; j > 0; j--) {
                    if ((fwd & 1) == 1) {
                        fwd = (uint)((fwd >> 1) ^ poly);
                    } else {
                        fwd >>= 1;
                    }

                    if ((rev & 0x80000000) != 0) {
                        rev = ((rev ^ poly) << 1) | 1;
                    } else {
                        rev <<= 1;
                    }
                }
                table[i] = fwd;
                revtable[i] = rev;
            }

            Crc32.table = table;
            Crc32.revtable = revtable;
        }
    }
}