Hacker News Reader

Comment by cdelsolar | Hacker News Reader

I thought the commit hashes had to do with the actual code being checked in. There's a random component to them as well?

View on HN

Not random.

A Git commit is one kind of "object" in git. Objects in Git are hashed like so:

SHA1("[objecttype] [objectlen]\0[objectdata]")

and a commit object looks like this (blatantly stolen from the Stripe V3 CTF):

    tree #{tree}
    parent #{parent}
    author CTF user <me@example.com> #{timestamp} +0000
    committer CTF user <me@example.com> #{timestamp} +0000

    Give me a Gitcoin

The "tree" in the commit is the hash tree reference that actually points to your code.

You can probably cycle through a couple million milliseconds in the various timestamps involved to get a large selection of hashes to pick from without making your commit stand out.

Iterating through the author timestamp gives you a bit more than 16 bits for one day. Then you may wonder how much freedom you want to take with the committed timestamp; it should be later than the author timestamp, but if it's off by a few hours to a day it might still be fine, which gives you another ~14 bits, and you're already at 30 bits. Throw in flippable punctuation (i.e., in the commit message, do you write deadbeef as a single word or not? Do you add a full stop or not?) and perhaps some other variations of the commit message and file contents, and 32 bits of nonce is actually fairly easy to get.

It's still a very cool demonstration of why you really need to compare every single bit of your hashes.

No, but the hash also covers the commit message and meta data. Here, it was fiddled with the commit and author date for the desired effect.

Talk about how it was done, and a pointer to the code that was used: https://plus.google.com/115863474911002159675/posts/RT2Tvb1w...

they're hashes of the /commit/, which is the code + metadata including time + previous commit(s).

Reply on news.ycombinator.com