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.
I have no idea; I just verified by posting.
(Also, this would be a novelty tripcode "!FLYEt.NIEA" if htmlspecialchars() was run)
>>41
I guess I gotta change my normal tripcode then.
i just finished this...
http://hotaru.freelinuxhost.com/trip.zip
it's the first program i've ever written in c... the .exe requires cygwin1.dll to run...
I think the best way to go about this would be to follow RainbowCrack's example... generate every possible tripcode and store it in a database, and then search it. Since you know that 2ch-style tripcodes have to be eight characters or less, you can check every possibility.
I haven't checked how much disk space or CPU time that would take, though.
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.
I just rewrote Shiichan's tripcoding algorithm after realizing what was so good about the name#trip#securetrip setup. I couldn't get zero-character tripcodes to work (mostly because I don't understand regexes well enough), so I've just banned them from use.
Can anyone shed a light on the differences between tripper and tripper+, or what the C, R, H and T checkboxes or second input box do?
I think C forces the tripcode you want to be case-sensitive
and H forces the expression you want to appear in it to be
at the beginning of the tripcode.
lol tripcodes
lol
That would've worked better if everyone's secure trip hadn't just changed.
Testing tripcode bug... this is #' and should NOT trigger secure trips, but does on shiichan4.
Like I thought. ' -> htmlspecialchars -> ' -> # triggers securetrips. Oh well, not high priority bug.
There's a lot of special characters that trigger secure trips, also on Kareha/Wakaba.
Second quote should be & #039;.
Probably only under Shift_JIS. Pretending Shift_JIS is ASCII leads to problems with the double-byte encodings. I'll try to work on a fix for that.
> Probably only under Shift_JIS
I think there have also been some under utf-8. I am going to screw around with that and report back later, though.
i set up a sandbox if anyone wants to test anything
configs are almost identical to the ones used in nubchan /b/
http://www.blackmage.org/bm/wakaba/sandbox/wakaba.html
feel free to spam with attempts to break anything
Oh, also, in Wakaba and Kareha you can avoid this by using "!" as the tripcode marker instead. "name!'" should not trigger secure trips.
Also also, it will be fixed in the next version.
I'm working on adding WAHa's RC4 tripcodes to my searcher. I've so far created something that runs and prints out some tripcodes (with -DWAKABARC4), but not the right ones. I'm sure I'll get to that eventually, though.
You can test it against http://paracelsus.hollosite.com/ - SECRET is "fuck" there.
At a quick glance, I'd say your problem is that you should be discarding the 256 first bytes of the RC4 output. The tripcode is generated from bytes 256-261.
> You can test it against http://paracelsus.hollosite.com/ - SECRET is "fuck" there.
http://paracelsus.hollosite.com/res/1295.html
shouldn't "##a" be "!!axTADlL+" if SECRET is "fuck"?
Like I thought, I screwed up a bunch of stuff in the rc4() function. I've updated that archive with one that actually works and comes with a build script.
./tripperc4 <search substring> <wakaba secret word>
hotaru@firefly> ./build.sh < ~/My Documents/trip/vacbob/tripper >
In file included from tripper.c:33:
crypt.c: In function `crypt':
crypt.c:519: error: `_PASSWORD_EFMT1' undeclared (first use in this function)
crypt.c:519: error: (Each undeclared identifier is reported only once
crypt.c:519: error: for each function it appears in.)
tripper.c: In function `testeverytripoflength':
tripper.c:180: warning: comparison between pointer and integer
tripper.c: In function `testeverytripoflength':
tripper.c:180: warning: comparison between pointer and integer
/cygdrive/c/DOCUME~1/hotaru/LOCALS~1/Temp/ccXQSSQZ.o(.text+0x59f):tripper.c: undefined reference to `_strcasestr'
collect2: ld returned 1 exit status
tripper.c: In function `testeverytripoflength':
tripper.c:180: warning: comparison between pointer and integer
/cygdrive/c/DOCUME~1/hotaru/LOCALS~1/Temp/cca0ySOr.o(.text+0x39a):tripper.c: undefined reference to `_strcasestr'
collect2: ld returned 1 exit statushotaru@firefly> _ < ~/My Documents/trip/vacbob/tripper >
Oh, that part of the code was relying on pwd.h defining _PASSWORD_EFMT1. I just removed that since 2ch trips never use extended crypt(); I reuploaded the archive.
What kind of gimped libc doesn't have strcasestr()? I don't know of any simple replacement for that, but changing CFLAGS to
CFLAGS="-O3 -DCASE_SENSITIVE"
will make it compile with strstr(), at least.
usage:
trip [-c] <regex>
triprc4 [-c] <SECRET> <regex>
tripsha1 [-c] <salt> <regex>
rc4crack attempts to brute force the SECRET string using a known secure tripcode... brute forcing a SECRET string longer than 4 characters would probably take longer than you would want to wait, though...
The (C) is indeed for case sensitive.
The first blank is to be filled with a string that should go at the BEGINNING of the tripcodes. Check the (H) box.
The second blank is to be filled with a string that should go at the END of the search (when the (T) box is checked).
For searches where string placement doesn't matter, either blank can be used. Don't use both blanks simultaneously unless at least one of the blanks underneath is checked.
As for the (R) checkbox, I can't figure out what it does. It seemed at first to limit the characters used for tripcodes, but that doesn't seem to be the case. Perhaps it just eliminates the extra features in order to speed up the search.
(R) sounds like (R)egexp.
Ha, you're right, WAHa. That would explain why searching with a period didn't necessarily find periods. :)
Also - the original "tripper" only searches the last 8 digits of tripcodes. tripper+ does 10-digit tripcodes that most boards use. That's the only difference.
I only discovered this after searching over 24 hours using tripper and then realizing that my tripcodes had two extra characters at the end. :P For instance, this tripcode shows as ".umfash." in tripper, but if it was found in tripper+, it would show the full "JW.umfash."
I simply changed my Wakaba implementation (which I love, by the way) to just use the last 8 characters because I didn't really feel like generating a new batch. ;)
Here's my take on a tripcode searcher:
http://elite-dot.8bit.co.uk/tcs.c
Should be quite fast as it keeps the salts for a while, which allows UFC-crypt to utilise it's optimisations better. No support for regexps or such fancy stuff, though.
I updated mine again; no extreme changes, but I removed almost all the pointless memcpy calls, so it's much faster.
>>96
Updated. Less waste of cycles, benchmark mode and logging of results.
>>96
it only finds tripcodes where the search string is at the beginning of the tripcode ;_;
>it keeps the salts for a while, which allows UFC-crypt to utilise it's optimisations better.
i thought of doing that, but never got around to it...
done: http://hotaru.freelinuxhost.com/fasttrip.tar.gz
also, 100GET!
>>96
Added optional case insensitive mode and optional searching of strings in the whole string.
test
another board bug.
tripcode passwords with # are allowed, ex:
lame#tes#tes
name lame, trip #tes#tes
(by proper 2ch)
if you're the developer of this software, after reading that reply all i have to say at this point is go fuck yourself.
>>104
lol my tripcode password is '####' and it works here...
I saw you complaining on 4chan, and now you're complaining in here. Nobody cares that your customized hyper-special customized tripcodes don't work right, as secure tripcodes are in fact a useful feature.
hint: !
itt you have a stupid tripcode
sup
lol, fag.
see the difference is it works on 2ch, so i kind of expect it to work here too.
Well since you articulate your sentiments so eloquently, let me just remove this feature that people enjoy and use so you can think you're on another site, how about that?
the fuck what?
Not too bright, are you? Now get the fuck out of this thread already.
By request, I wrote a dictionary generator. It needs a system with fgetln(), though. Porting to glibc and getline() wouldn't be too hard, but I'm not interested enough.
Same URL as always.
>>116 typical whiteboy nerd pretending to be a jap while masturbating to shitty anime.
Oh come on, that's pathetic. Surely you can do better than THAT. Try again.
oh timecop-chan -_-
ID:gLTSfIiG
Does anyone think getting Tripper+ translated into English would be useful? 'Cause I'm working on it some, though I don't know any Japanese.
>Name: !WAHa.06x36 2004-11-15 14:22
>I've used some assembly-optimized crypt() code from John the Ripper to get up to 110000 crypts per second per gigahertz.
out of curiosity, was that in a "finding a cute tripstring" (wild discovery) or a "breaking some trips" (targeted discovery) context?
also, was it with the "normal" or the "bitslice" code from john?
and, was it done by cramming a tripcode-format specification into john, or by transplanting john crypto into a tripcode-specific framework?
I'm not too familiar with what the "bitslice" and "normal" code is. What I did was take the version of the DES code that generates results that are padded and out-of-order, and transformed those back to the normal format in base64, and used that to make a small utility that searched for specific substrings and output them. Even with the overhead of the conversion, it was nearly twice the speed of any other DES code. If I was trying to crack specific tripcodes, I could do the conversion in the other direction just once and make it even faster, but I didn't find that very interesting.
So, wild discovery, and using the john code in my own program.
>>126
ah, interesting.
that sounds very much like you used the bitslice code, the output is 64bit binary there, does not include the salt, and it looked like converting it back would be possible.
"bitslicing" is class III vooodoo that treats one N-bit CPU like N 1-bit CPUs. john has a (already somewhat optimized) "normal" DES implemtation (that generates 128bit output with the salt mangeled in), and a even more insane bitslice one that does 32 or 64 crypt()-like operations "in parallel".
some stats, 1GHz athlon, custom framework (based on 4brute.c) doing targeted discovery on about 4k targets, kcps == kilo crypt()-equivalent-operations per second, including comparison, and measured against process user-time (not wallclock. so its equivalent to johns "virtual" rate.):
'John 1.6.38 / 64/64 BS MMX' => 279kcps (this is the "bitslice" version)
'OpenSSL 0.9.7e 25 Oct 2004' => 71kcps
'John 1.6.38 / 48/64 4K MMX' => 64kcps (this is the "normal" one)
'UFC-crypt 1c, 1.9 03/02/92' => 37kcps
'glibc2.3.4 slackware crypt' => 30kcps
this session taught me some things i didnt really expect:
1) forget ufc-crypt unless you have prehistoric hardware.
2) openssl fcrypt() is a very good starting point.
3) at 279kcps, the framework spends 10-15% of the cputime on generating the next input plaintext and comparing output against targets. and that is after some serious optimization in those areas. was more like 60% before that.
How were you choosing the salt on those? Some algorithms take a big performance hit every time you change the salt, so to get them to perform well, you want to arrange your lookups to do many lookups with the same salt in a row.
for the bitslice code to be really useful i had to run it on N sets with the same salt at once, which in case of the odd "salt derived from plaintext" tripcodes made me buffer up candidate-plaintexts mapping to the same salt, only activating the real backend when a salt-bank is full.
in case of john-bitslice the banksize is 64 (didnt have much choice there), for all other backends i was using 128 (thats the "max keys per crypt" johns non-bitslice des code was using).
(exception to the "only fire full banks" is the "endgame" phase when the plaintext-generator says "i am done" and there are partially full banks to purge, but that is pretty much irrelevant for the total performance on a run of several Mcrypt().)
as a sidenote, openssl performance seem to be the same even with not-sorted-by-salt use, but i guess it just initializes by salt every time, even if you pass it the same one again on next call.
Searching through: 0123456789abcdef
Number of users scanned: 4129
...
Exiting after 4581298448 crypt, 35442 inner, 71582993 salts, 22 found
'John 1.6.38 / 64/64 BS MMX' => Real: 26626s, 172kcps
'John 1.6.38 / 64/64 BS MMX' => Virt: 18416s, 248kcps
that was on a duron900 that does a lot of other things all the time.
4.3 Gcrypt run through the bitslice code, changing salts 68M times.
35442 fcrypt() run through openssl in response to the john-crypt giving a 29bit confidence match, 22 actually were full matches.
35420 openssl fcrypt() "wasted" sounds like much, until you realize its (even assuming a worst-case with some swapping) still less than 2 seconds total on a 7hour+ run, so i dont give a damn.
68M salt-changes also sounds like much, but profiling said its responsible for less than 3% of the cpuload, so again i dont give a damn.
so, i couldnt help myself and wasted even more time on it.
here some more highly unrepresentative stats of different systems, all using the john-bitslice code:
Penti-M 1600MHz 1024kB 526kcps 328cpspMHz
Duron 895MHz 64kB 248kcps 277cpspMHz
Athlon 1009MHz 256kB 279kcps 276cpspMHz
Pentium 233MHz 52kcps 223cpspMHz
Penti-4 2000MHz 512kB 406kcps 203cpspMHz
Celeron 2400MHz 256kB 436kcps 181cpspMHz
3rd column is second level cache size.
4th is raw "kilo-crypt() per second", virtual.
5th is "crypt() per second per MHz"
the insanely high score of the Pentium M, and the insanely low ones for the Pentium4 and P4Celeron indicate that version of the code was working on data-sets between 512kB and 1MB.
the Duron with the tiny cache scoring second seemed odd, but if i am trashing through the whole cache anyways, second-most-important feature is ram speed, and that machine is using dual-port DDR.
the pentium 233 using johnbs pushing almost twice the crypt()s the athlon1000 did with UFC amused me. unless i was using some kind of "wrong (version of) UFC", it seems that optimizations done 13+ years ago do not consider modern hardware. shocking.
(so unless you are running a cracking cluster with 15 year old RISC machines, dont bother with UFC)
did some improvements in the comparison framework to reduce the activity-relevant ramsize, in particular some lookup tables where i traded ram for speed earlier, got me another 10% or so, depending on the cachesize. trying this on the 512kB machine is still pending, this will be most interesting, i dont think i got it small enough for the 256kB cache to be enough. (thats where i am seeing 5-10% improvement, depending on how many targets i feed it.)
regarding dictionary generators, i found there is little need to write any, since john has a -stdout option. very handy.
even without any wordlists, just using character-probability/distribution lists and making up words, this is far more effective than the raw bruteforce tries 4brute implements.
the benchmarking-list is about 6800 tripcodes grabbed from various boards, and using "john -i -stdout | 4brute-johnbs -i", 1GHz of cpu find solutions for more than 1000 of those within a minute.
but to not just be a smelly-creepy cracker, i did some work in the direction of wild-discovery ("searching for cute tripcodes"), but without reversing the output of johns code. example, i want to find something beginning with a certain 4-5 char prefix, like /^waha\W/i ... which is just 32 different prefixes after all, upper-and-lowercase combinations for the four letters plus . or / behind it. at the same time, those 5 chars are 30bit worth of target, 5bit (32 strings) of which are considered "hits". so, i mongled the matching code in a way that allows it to just match prefixes, and handed it a list of those 32 possible prefixes i might like as targets. plus "random starting point of 8 char length" as input.
assuming an even distribution, the 30-5 bit suggest i should find a solution about every 33.5 million attempts. here output from a run of ~350 Million tries:
4brute using 'John 1.6.38 / 64/64 BS MMX'
Starting search from "sG+ym_8u"
Limit set to: 350000000
Searching through (randomised): ucWZXdw(P]Eb2gC_I7[/Q3MFKS$G`N}yql0jTm!Yz +UJa#5r89eh*D-:Ais)fOHtBRpvL.1x{k6V4no
Number of users scanned: 32
"WahA.DY8KI" == Gx "3Gxwm_8u" for WahA.aaaaa
"wAha.RNmpE" == .. "_}!Qu_8u" for wAha.aaaaa
"WaHA/D5Jq." == cY "j]Y0u_8u" for WaHA/aaaaa
"wAHA/GeRU." == R8 "NR8vu_8u" for wAHA/aaaaa
"WahA.7NzhI" == 9d "w9d{u_8u" for WahA.aaaaa
"WaHA/GE/Ng" == MU "hMU3c_8u" for WaHA/aaaaa
"WAhA.S/aOs" == bO "AbOac_8u" for WAhA.aaaaa
"wAHa/HPJco" == GC "KGC8c_8u" for wAHa/aaaaa
"WAhA.EyH8c" == l2 "ll2jX_8u" for WAhA.aaaaa
"WAhA/5Fmuw" == hC "+hCWd_8u" for WAhA/aaaaa
"Waha.D1AzY" == .M "G-MWd_8u" for Waha.aaaaa
"WAhA.2piT6" == K9 "LK9_d_8u" for WAhA.aaaaa
"WaHa/0qPHI" == xl "hxl7w_8u" for WaHa/aaaaa
"wAHA.jhgAw" == .x "x-xF(_8u" for wAHA.aaaaa
Exiting after 350059520 crypt, 14 inner, 4267664 salts, 14 found
'John 1.6.38 / 64/64 BS MMX' => Real: 1513s, 231kcps
'John 1.6.38 / 64/64 BS MMX' => Virt: 1308s, 267kcps
so, 25 minutes for finding 14 solutions. the 14 here is above average, i had other runs that coughed up only 8 hits in 350M tries. this run was on my trusty duron900 again, and as the difference between the "real" and "virtual" time indicates, 4brute only got about 85% of the cpu during the time.
I am your arch nemesis!
I updated my code again, now it compiles on Cygwin because I wrote my own strcasestr()!
In the process, I discovered a gcc optimization bug, but it doesn't cause miscompilation so it's not that bad.
Also, I think that at one point I tried dropping in hotaru's ufcrypt to replace the rather slow one I'm using, and it gave different (wrong) results for some tripcodes.
i've been playing around with the bitslice code from john the ripper... and i'm wondering... how the heck do i get a normal hash out of it? i see DES_bs_get_hash() returns an int, and i'm guessing i probably want to do something with that, but i have no idea what...
What John does is take a hash, and turn it into a bitslice, and then compares the bitslices. That's the faster way, but for searching for strings in tripcodes, you need the hash. What you do is take the algorithm for changing a hash to a bitslice and invert it.
>take the algorithm for changing a hash to a bitslice and invert it.
i don't think i can do that...
i updated mine...
i fixed it so it doesn't crash after a few minutes of searching now... and i made some other changes... i tried dropping in openssl's fcrypt(), but it gave wrong results and i don't really feel like trying to figure out what's wrong with it right now, so i'm still using ufc-crypt...
same url as before...
>>127
Can you please provide source code for your test application?
Anders
>>138
hotaru, your site doesn't work, can you put your code on another host or email it to me ([email protected]) ?
anders
>>138
Actually, the site does work, just not the .tar.gz links... If you can make these available somehow I'd be glad.
Anders
How do I get this to run on Windows? It's not working.
I'd really rather people did not link to programs for doing cracking of actual tripcodes. It's a fun academic exercise, but there's no legitimate use for those.
i didn't figure out how to use john's crypt(), tried linking the object with my code then changing the calls...
anyone who got 4brute.c compiling btw?
i get:
anders@home:~$ gcc -O3 -o 4brute 4brute.c -lssl
4brute.c:65: error: syntax error before '(' token
4brute.c:65: error: syntax error before 'const'