Unlike the linked it didn't alter the commit date, but altered the Git
code itself to add a new custom header to the commit object.
Git handles custom headers just fine since it ignores unknown headers
for future compatibility. This commit still lives in the main Git repo
at work without any issues:
> git commit -F message
Try 0/4000000 to get a 1337 commit = 3650e08c9e1ecbbeec83daf7a959e3edcf15bd4f
Try 100000/4000000 to get a 1337 commit = 3952f7d5035f5e88f66aa5c70e5cc11fdd734852
Try 200000/4000000 to get a 1337 commit = 51c910f5d535c515a04796eb7c7a70cbd2325599
Try 300000/4000000 to get a 1337 commit = d70c3e64b1d963461a6ee2f518c613483b979d68
...
commit id = 313378458f8c4fb53c808f4b0bae5bf71ba5e23b
[master 3133784] 1337 Test Commit
1 file changed, 60 insertions(+), 35 deletions(-)
If you're wondering how he did it, Brad wrote a tool called 'gitbrute'[1] that (as the name suggests) brute-forces the prefix of the hash to whatever you like.
Not just for vanity, either - it makes phishing a hidden service harder: if users know the .onion for Agora starts with 'agora', then a phisher has to invest weeks of compute-time just to get a plausible .onion to start his phish with, rather generate than any old .onion in a millisecond.
It is almost certain that there are a quarter-billion published Git commits by now. (GitHub says there were 150 million pushes in 2013 alone, and many of those have multiple commits.)
This means it is likely that, purely by coincidence, someone has at some point had their commit labeled as (badc0de).
Github doesn't seem to allow searching revision hashes, but presumably Google has most of Github crawled by now, and I didn't spot any commits with that as a label: https://encrypted.google.com/search?num=100&q=badc0de%20site... (more hits than I expected though).
Google doesn't appear to match partial hashes. I searched for a random GitHub commit hash, and it showed up, then removed one character, and it didn't.
Each hex character represents 4 bits. That means that a 7 character string is 28 bits. That's about 268 million possibilities. On average, it would take around 134 million commits to get one that started with "badc0de".
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.
> In the talk about git in 2007, Linus said something about git being secure — that if someone would attempt to alter git history (as in attack that happened at Linux repo before), it would be instantly noticed because of hashes.
> Does this mean that compromising someone's git repo without anyone noticing can actually be done?
No. Brute forcing 4 bytes of the commit hash is something different than brute forcing 20 bytes. Because you know, exponentials.
By the way. That's pretty much what you're doing when you're mining bitcoin.
Edit: added parents comment, because deleted and i see no reason to delete this, others might ask the same question.
Unlike the linked it didn't alter the commit date, but altered the Git code itself to add a new custom header to the commit object.
Git handles custom headers just fine since it ignores unknown headers for future compatibility. This commit still lives in the main Git repo at work without any issues: