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.

>>73

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

>>71-74

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.

>>66
i wanted to say that.

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.

http://astrange.ithinksw.net/tools/trippersrc.zip

>>82

You can test it against http://paracelsus.hollosite.com/ - SECRET is "fuck" there.

>>82

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"?

>>85

Oops, my bad: it's "FUCKME".

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>

>>87

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 status

hotaru@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.

http://hotaru.freelinuxhost.com/fasttrip.tar.gz
updated...

>>90

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...

>>64
>>65

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.

(w:
http://66.102.9.104/search?q=cache:pT8vFWxB7-QJ:life7.2ch.net/test/read.cgi/yume/1102100342/

test

another board bug.
tripcode passwords with # are allowed, ex:

lame#tes#tes

name lame, trip #tes#tes
(by proper 2ch)

>>104

Would you like some cheese with that whine?

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.

timecop is DQN

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.

>>4

>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.

>>123
Yes, that would be useful

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.

>>142

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'

>>144

yeah, right.
i see that in >>5 ...
so a 70cpspMHz cracker is ok, but a 270cpspMHz derived form of it that can actualy do free search as well is not?

that makes sooo much sense.
really.

Eh, I should remove that one too. It got left behind back in the day.

i fixed the 4brute/4tripper source

>>147
seconded

>>149
heya. if you are interested in the version that is about 4-5 times faster even at regex-like pattern matching for finding "cute" tripcodes (see >>127 >>129 >>130 >>131 ), feel free to visit #tma on irc.freenode.net ... :)

>>25
http://4dist.yi.org/4cute

but, of course, "there's no legitimate use" for this.

note that 4cute is just a quickly slapped-together CGI frontend for a souped-up 4brute that is pretty much unchanged since the link to it got deleted here for being "evil" two days ago.

(i did add a "exit after finding N solutions" commandlineoption, fixed some typos, added two things to the Usage() output, and shuffled around some defines. which are not exactly any changes to the main functionality, just touching up code i had not open in an editor for some weeks.)

>>151

No need to be ironic, you know damn well what I meant earlier.

Also, http://wakaba.c3.cx/sup/kareha.pl/1111365778/10

>>152
Of course there is need to be ironic about something like this.
Thats way better than me being pissed off about it.

4cute is a proof-of-concept frontend, obviously designing userinterfaces is not my strong point.
and of course its keeping a local copy of the results, in the very same format used by 4dist, so i dont end up wasting cputime on cracking 8char cutetrips i supplied myself.

of course, anyone interested and having a x86 mmx cpu could just go grab the source, and waste their own cpu cycles on generating whatever amount of cutetrips they want.
if they were allowed to know where the source is.
not that it is hard to find without the direct link.
which just confirms again that "no legitimate use" is not exactly true, and deleting the link is pretty pointless.

>>153

You are wilfully misinterpreting what I said (I am being generous here and not assuming you are too dumb to read what I said). I said, and I quote, "I'd really rather people did not link to programs for doing cracking of actual tripcodes." Your 4cute does not do that, and has nothing to do with the discussion. It seems to do much the same as anything else in this discussion, none of which I had a problem with. Why are you assuming I'd have a problem with yours if I didn't with everybody else's?

>>154
its the very same program you deleted the link to, with your little "no legitimate use" comment.
just run from a perl CGI that feeds it with four commandline options, and wraps its output in some html.
so either there is a legitimate use for 4brute, or 4cute isnt one either.
cant have it both ways.

>>155

I never said there weren't legitimate uses for your program, I said there was no legitimate use for cracking tripcodes. I understand your program does that, which is why I didn't want a link to it. All you'd be doing is supplying script kiddies with tools. Make a version that doesn't do that, and I won't mind you linking it.

And how is that supposed to work?
ship it with a "complete" list of "known to be used" tripcodes and make it not output these? yeah, right.
include an AI that evaluates cuteness rating of supplied targets? sure.

of course, in any case of "exit_if_not_political_correct_target();" or other artificial "policy" limits, i would have to start shipping it closed source too.
because else people might comment out that call.

4brute generates plaintexts (or reads them from a pipe), crypt()s them in a tripcode way, and compares the results.
how is it supposed to know what are "good" or "bad" targets for a comparison?

if i take any of the "good" tripcode generators in this thread, tell it to use an alphanumeric charset, begin with one char length and rotate-enlarge, and run it to find me stuff that matches /^WAHa\./, how long would it take to find !WAHa.06x36 ?

seriously, whats the difference between a "bad_cracker" and a "good_generator | grep" ?

How many people do you see using Tripper++ for cracking? It just doesn't work, because it only uses randomized long strings for input. It also has no facilities for doing birthday attacks.

>>158
... which of course only works because its a closed-source GUI-thing?
better delete those links to "Mr VacBob"s tools too, those are evil opensource commandline hackery.

oh, and either you dont understand what a "birthday attack" is or you are assuming i dont know and want to confuse me by using the term? because i fail to see how an "any to any" attack with free choice of targets is related to the current topic.

i repeat: whats the difference between a "bad_cracker" and a "good_generator | grep" ?

Birthday attack in the sense of having many targets. Not entirely correct usage, I guess, but eh.

And stop trying to pick a fight, OK? There's a pretty obvious difference between making a tool that can be used out-of-the-box for cracking tripcodes, and one that can be modified to do it with some work. If you're a good enough programmer to modify it, chances are you could make it from scratch anyway.

Of course, releasing something that is a lot faster than all the others is a bit of a problem, since most people wouldn't develop that on their own. You may have noticed I did a lot of the same as you did, but chose not to release it because it didn't feel it was for the common good.

Now for some less faggy discussion:

I noticed your code said it was comparing against 32 candidates to do a case-insensitve match for 5 characters. I don't remember exactly how the bitslice data was laid out, so I am not enitrely sure it would work, but I'd think you'd get away much easier with a single bitmasked comparison.

>>160
I strongly disagree. Even if it does use UFC crypt() or John's bitslice stuff, the legitimacy is the same... It's just faster.

>>160
actualy, due to the "first character of crypt output cut off" aspect of tripcodes, you could in theory do a birthday-style attack on it, to find a pair of plaintexts that result in the same tripcode.
and if i make you use one of those, i could post with the other.
too bad no one would realize what clever hackish thing i have done, so they wont give me head for it, so its pointless. ;)

>>161
my comparison is doing a two-layered hashed check, then a full recheck using openssl.
meaning:
first it grabs 12-16 bit (a #define, actualy, thats one of the things i changed yesterday) of the bitslice output, and looks it up in a table.
and only if it has any targets in that table-slot it fetches another 16-20 bit (well, 32-$firstmatch) bit, and compares those to the targets in the slot discovered in step one.
and if there is a match in this step, it runs openssl on the plaintext, and compares it char by char to the may-be-a-match.

sounds bad?
Exiting after 1000000485 crypt, 565 inner, 41 salts, 0 found
565 times it hit the openssl inner-stage comparison, and none of it was a true match. gasp
but wait, openssl does more than 70000 crypt per second on this hardware, so its ... even assuming a 2x overhead for it not being in cpu cache or whatever, its less than 200ms of a 1 Gcrypt() batch taking more than an hour total. so its pretty insignificant.

in exchange, the comparison doesnt really slow down even with a lot of match targets. the default target limit is set to 4096, and the mask for stage 1 to 16 bit. that gives me a nice 1:16 rate of its-not-a-match detection right in the first stage.
it could even be scaled up quite a bit (at least to 24 bit, and an equally increased maxtargs), but at that point the ram footprint grows and grows and grows, and since i am allocating all the lookup tables statically...

how is that relevant for the case-insensitive comparison? a 5-char-alpha case-insensitive prefix has 32 possible variants. instead of doing that 1:32 step in the comparison stage for every single of the very many tried crypt()s, i do it before even firing up the crypter, by generating all those possible 32 targets.
what? two of the chars have l33tmode alternatives? thats 72 variants. scary.
what? you want only 4-char case-insensitive alpha prefix? that means full 64 options for char5, giving 1024 variants. bring it on.

oh, i forgot. for matching 5char prefixes, i only have 30bit at all to match, so the stage-2 comparison has 4x less reliability. but, of course thats nonsense, because if all 30 bits match, its a match in stage-3 for sure.

the "where are the bits hiding in johns format" for the individual tripchars is in 4brute-johnbs.h ... those defines are not used anywhere, but i kept them there just in case i ever need them again. it does not say which bit is which, so figuring out which one to ignore for case-insensitive direct matching would be another run of "see which bit flips".

i prefer the current system that stands up to whatever the user may throw at it, even if its leet-mode substitutions, which would be moderately hard to do bitmasked.
rethinks ... aeh, and since we are matching base64 targets here, it wont really work at all, because case-insensitive bitmatching works with ascii, but not base64.
but the idea was good! :)

>>162
would SOMEONE please run benchmarks comparing UFC and openssl crypt() speed?
and by someone, i dont mean me, and not anyone using my code?
my benchmarks (somewhere earlier in this thread) indicated that UFC was really, really bad.
it may have had a point in 1992 (when it was last updated) on 30MHz RISC machines, but i really, really fail to see any use for it today.

but, who knows, perhaps i did something really wrong, or was using an outdated variant, or whatever.
so, please, someone do some benchmarking.
and i dont mean the benchmark included in ufc, because that compares ufc against the libc crypt(), which indeed is the only thing worse than UFC in my tests.

well, or use the benchmark in ufc, and cram in the openssl crypt() so it uses the same framework for testing.

> aeh, and since we are matching base64 targets here, it wont really work at all, because case-insensitive bitmatching works with ascii, but not base64.

Ah, damn, that's right. Oh well!

>>141
my code is at http://hotaru.freelinuxhost.com/fasttrip.tar.bz2 now

>>164
I did some testing on a Pentium M with 1.6GHz. Time for 5,000,000 iterations, changing the salt every 500,000 iterations:

OpenSSL DES_crypt(): 45.144s
UFC-crypt crypt(): 37.078s

>>169
interesting. can i get the code you used somewhere?

i just did some benchmarking again too, not using the sodomized 4brute as framework, but the "speeds.c" that comes with ufc. runs the crypt() for 10sec cpu time, reports number of done cycles. no saltchanges at all. it has defines for ufc and libc, i added a ossl variant.
Results from my trusty Duron900 (64kB cache):

• 37956.700000 crypt(libc)s per second.
• 49705.200000 fcrypt(UFC)s per second.
• 71742.300000 DES_fcrypt(ossl)s per second.

code here: http://4dist.yi.org/misc/ufc-crypt/
the speeds.c and Makefile are modified to add ossl.

this agrees with the numbers i had for 4brute using different backends.
perhaps i am using somethings that calls itself ufc, but really is outdated, wrong, or so?
from patchlevel.h: "UFC-crypt, patchlevel 1c, @(#)patchlevel.h 1.9 03/02/92"

from the README (most people reading this probably dont know any of those except the 386. ;):

• Tested on 680x0, 386, SPARC, MIPS, HP-PA, Convex, Cray, Pyramid and IBM RS/6000 systems as well as with gcc on IBM PS/2(DOS) and Linux on a 386 PC.

but, the README contains also a possible reason for the sucky performance i am seeing:

• Requires 165 kb for tables.

165 > 64. uh-oh.
let me guess, the Penti-M has 1MB cache?
goes to find something with bigger cache to rerun benches

athlon1000, 256kB

• 40874.800000 crypt(libc)s per second.
• 54356.900000 fcrypt(UFC)s per second.
• 79682.900000 DES_fcrypt(ossl)s per second.

pentiumII 266, 512kB, 2.4.31 SMP

• 10205.200000 crypt(libc)s per second.
• 4692.900000 fcrypt(UFC)s per second.
• 2039.100000 DES_fcrypt(ossl)s per second.

pentiumII 266, 512kB, 2.6.12.1 SMP

• 11079.100000 crypt(libc)s per second.
• 12916.800000 fcrypt(UFC)s per second.
• 19783.000000 DES_fcrypt(ossl)s per second.

(note that the first P2 run only confirms that the linux 2.4.x SMP scheduler sucks frozen goats through nanotubes, with 2.6.x its right back in the pattern seen on the other hosts)

so, it does not seem to be just the size of the cpu cache.
makes me more interested in seeing the code used in >>169 ...

Hrm, i dont quite see the use of cracking tripcodes if you cant post.
I wonder if there is a working proxy server somewhere...

>>170
I used my code from >>96 and compiled with -DBENCHMARK and an increased number of iterations. For OpenSSL I just changed crypt() zu DES_crypt(), included the necessary header file and linked against OpenSSL.

>>172
uhm, most of them are supposed to also work on 4chan, wakaba, kareha ...

>>173
are you using the same "UFC" as >>170 / >>171 ?
as in, something that got last updated 13 years ago?