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.
how2runonwindows?
>>601
HAHAHAHAHAHAHAHAHAHAHAHAHhahahahahahahahahahahaHAHAHAHAHAHAHAHAHA!!!!!!!!!!!!!!¡!!!!!!!!!!!!!!!!!!1!!!!!!!!
Why exactly do you have that as a non-capturing group?
can someone tl;dr this thread for me?
I just want to make a secure tripcode with words in it, I've been attempting to use >>http://trip-table.com/
but it doesn't seem to be working.
Suggestions?
Just makes no difference in a die condition and adds to verbosity. KISS, lel.
asdf
Reading this thread is like nostalgia to me. More than 5 years ago, commodity PCs could barely get 1 million trips per second. Now the average i7 can manage over 10M, and GPGPU solutions like MTY exceed 100MT/s. There's rumor of a CUDA version getting close to 1GT/s too. How far we've come...
.
/* 4tripper -- brute-force searching for simple crypt() tripcodes,
* as used by the futallaby-based image boards (i.e: 4chan.org)
* --
* Compile:
* gcc -O3 -o tripper 4tripper.c -lssl # Most Linux
* gcc -O3 -o tripper 4tripper.c -ldes # NetBSD
* gcc -O3 -o tripper 4tripper.c ../mumble/libdes.a # Mine
* gcc -O3 -fast -mcpu=7450 -o 4tripper 4tripper.c -lcrypto -lssl # OSX on a G4
* --
* Usage:
* ./tripper | grep -i monkey
* --
* Copyright 2004 Chris Baird,, <[email protected]>
* Licenced as per the GNU Public Licence Version 2.
* Released: 2004/12/22. Your CPU heatsink /is/ working, right?
* --
* TODO:
* Accept arguments for the key to resume/finish searching from (for
* simple load distribution)
*/
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
/* Not quite the fastest DES library around, but still reasonable, and
* most free Unixen should have it available. (Works for at least NetBSD
* and Debian GNU/Linux (after "apt-get install libssl-dev")
*/
#include <openssl/des.h>
/* How I call a special DES library.. It has to supply a des_fcrypt() as
* declared below.
* #include "../libqwikdes/des.h"
*/
/* gotta ask for a robust way to tell the difference between the two..
*/
#if !NEW_OPENSSL
# define our_fcrypt des_fcrypt /* NetBSD, Linux... */
#else
# define our_fcrypt DES_fcrypt /* Gentoo, OSX... */
#endif
extern char *our_fcrypt(const char *buf,const char *salt, char *ret);
int main()
{
#define BUFSIZE 8192
int quit=0, i, counts[8], bp;
char c, buffer[BUFSIZE+32], result[14], salt[3], word[9];
/* I haven't throughly checked whether all these characters are valid
* in a tripcode as yet. */
char table[]="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"
"0123456789 .!:#/`()_$[]+*{-"; bp = 0;
salt[2] = 0;
for (i=0; i<8; i++)
{
counts[i] = -1;
word[i] = 0;
} counts[0] = 0;
word[0] = table[0];
while (!quit)
{
salt[0] = word[1];
salt[1] = word[2]; our_fcrypt (word, salt, result); for (i = 0; (word[i] != 0) && (i < 8); i++)
buffer[bp++] = word[i];
buffer[bp++] = ' '; for (i = 3; i < 13; i++)
buffer[bp++] = result[i];
buffer[bp++] = '\n'; if ((bp > BUFSIZE))
{
write (1, buffer, bp);
bp = 0;
} i = 0;
check:
counts[i]++;
c = table[counts[i]];
word[i] = c; if (c == 0)
{
counts[i] = 0;
word[i] = table[0];
i++;
if (i < 8)
goto check;
quit = 1;
}
} return 0;
}
dudebro
This program is incorrect, it doesn't call htmlspecialchars.
>>615
Of course not. Constantly tripping over a bunch of dumb string transforms is a great way to make a searcher much much slower. And notice that the character set it searches isn't even affected by that, so it's a moot point regardless.
Also, note that not every tripcode implementation does the same combination of dumb things.
> Constantly tripping over a bunch of dumb string transforms is a great way to make a searcher much much slower.
The amount of time spent generating the string vs hashing is completely insignificant no matter how much time is spent on it.
> Also, note that not every tripcode implementation does the same combination of dumb things.
Yes they do. Otherwise they're wrong. No point in a tripcode that doesn't match 2ch.
>>617
No, sorry, you're wrong on both counts. Learn more.
> Constantly tripping over a bunch of dumb string transforms is a great way to make a searcher much much slower.
Another great way: Print every single tripcode to stdout.
>>619
Hahahwhat the hell?
I didn't bother actually looking at that code, as I have seen more than enough tripcode searchers before.
Wow that's pretty idiotic.
>>619
well, unless you use multiple threads or processes, that can be faster on a lot of systems than checking the tripcodes in the searcher.
Fyi, trip explorer is not the fastest anymore (though it does offer a gui)
MTY for ATI is multithreaded (like trip explorer) AND uses ATI stream compatible graphics cards.
Intel Core 2 Quad Q8200 @ 3Ghz is doing 13.8Mtrips/s, while the ATI 4850 is doing 63.75Mtrips/s
I'm currently trying a case sensitive seven character trip. I'll report back with the time it takes.
>>623
if you just output all tripcodes, you can generate tripcodes on one core and grep on another, instead of doing both on one core.
It won't be faster. It's more expensive to fill the queue between threads with generated tripcodes than it is to just filter them in the first place.
>>627
of course it's more expensive, but is it twice as expensive? you do get almost twice as much processing power that way...
but obviously the real solution is to filter them in the first place and do that in multiple threads or processes.
> of course it's more expensive, but is it twice as expensive? you do get almost twice as much processing power that way...
You don't use all of it, because the tasks are unequal (one is faster)…
> but obviously the real solution is to filter them in the first place and do that in multiple threads or processes.
…which is why you can should that, yes. OpenCL looks pretty convenient for this, it seems like it can be made to run well even without having to write bitslice algorithms.
virus
>>213
That doesn't work, as you need the des library that it's trying to include. It just gives you compile errors.
Kyon
testing
last testing@2
1
831
>>649,652-654
wtf is this shit? incompetent spammers?
>>655
You missed >>630-634,636-646,650-651.
For some reason this thread's become a retard magnet.
>>656
i think i just heard that someone wanted me to post ITT
http://github.com/astrange/tripper
Lots of minor cleanup changes just because I don't like my old code, no actual feature changes. forking (or rewriting it to be reentrant and threading…) is the obvious next step, that and being able to search SJIS strings.
fag
bump
test
boxxy
sd
,.....
'll even pretend to believe that you don't like furry for the ENTIRE thread
Hanstanding ?! Oh Yeahhh
Roni
dfdf
>>676-684
are people really that stupid, or is there some sort of broken spambot making posts like that everywhere there's any thread with "tripcode" in the title?
asd