I've been tinkering with Python all day today... it's pretty slick. Just for practice, I tried to cobble together a tripcode decoder that would let you have "real" words in your tripcode as !WAHa and Sling and others do, and it actually came out better than I thought it would be. I'm aware there's already a program that does this, but if memory serves me, it's Windows-only and in Japanese besides. My script is kind of dumb in the way it goes about things -- it basically just tears through random strings until it finds one that fits -- but I've tested it repeatedly and it seems to work. If you'd like to check it out, nab it here:
http://www.anre.org/crap/detripper.bz2
Of course, you may need to modify the hashbang line depending on where Python is on your machine, and don't forget those execute bits, people... Use "-h" for help.
First person to ask how to get this to run on Windows gets pointed and laughed at.
Using just A-Z, a-z, 0-9 and two more to pad out to 64 characters means (2^6)^8 = 2^48 tripcodes. Each one needs 12 bytes of storage if you sort them listed by hash (6 bytes if you keep them listed by password, but that makes for really slow searches), so 3072 terabytes. Using only lowercase a-z takes 2.3 terabytes, or a little bit less if you encode your data a bit more cleverly.
I think I'll just stick to brute-force, then. Maybe steal a faster crypt() from Jack The Ripper.
>>51
interesting idea...
i now have a list of all tripcodes 0-4 characters in length...
one file for each length... the one with the 4 character tripcodes took a little over an hour to generate on my 733mhz pentium 3 machine (using a perl script), and it takes about 5 minutes to grep the whole file...
I have a list of all tripcodes 0 characters in length too. I'll post it below:
How big is that four character file? Just curious.
the file of 0 character tripcodes has jPpg5.obl5 (the tripcode you get if you put # with nothing after it in the name field) in it...
the 4 character file is 1.16gb... 675mb when compressed with bzip2...
it probably could be a bit smaller if i listed them in a better format than hash = password
Incidentially, the 0-character tripcode is wrong in Wakaba and Kareha - it doesn't match the futaba one (haven't checked 2ch, though). The next release will update the tripcode code to fix this.
>>56: Oh, that's right... the script appends characters (".H" or something) to the end of codes before it hashes 'em... so a blank trip is never truly blank... My bad.
The funny thing is, the algorithm appends two characters ("H."), but then uses the second and third characters, thus making a zero-character tripcode technically invalid. Of course, it does generate SOMETHING anyway, and it appears this differs between languages due to different handling of strings, no doubt. Appending "H.." instead seems to get the same behaviour as the futaba script, at least.
It appends "H." to the salt, which is different behavior than doing it to the actual hash. Look at tripcode_2ch() in tripper.c; as far as I know, I get it right.
hmm... crypt("",".") in perl and crypt . "" both return "..Qfnkquv7jY2" (same as using ".\0" as the salt), unix_std_crypt("",".") (ufc crypt in perl) returns "..X8NBuQ4l6uQ" (same as using ".." for the salt), and openssl passwd -salt . "" returns ".AmEwFrvDWaHo" (same as using ".A" for the salt)...
"..X8NBuQ4l6uQ" is what Futaba uses. I just checked 2ch, and they don't allow 0-character trips. I changed the salt postfix string in the development versions of Wakaba and Kareha to "H.." to match the Futaba generator.