Invites generator

[cinephilia]

Exactly. Let's say an invite code is only 16 characters longs, and composed of only lower-cased alphanumeric characters. The number of permutations is: n! / (n - k)! = (26 + 10)! / (26 + 10 - 16)! = 36! / 20! = 3.71993326789901217468e41 / 2.43290200817664e18 = 152901072685905223680000 permutations.

your post made them stfu
thanks.

[DanielleD87]

there is a difference between hacking and cracking. getting into someones SQL database is hacking. writing a keygen for software is cracking. you guys are getting the two mixed up.

hacking and cracking are night and day too. hacking involves finding a vulnerability aka an exploit and using it to your advantage. it is finding a hole. cracking is just looking through assem, seeing how a program works, and then either altering the code so it does what you want it to (easy) or reversing the code to make a keygen (harder).

cracking has nothing to do with hacking it is night and day.

[Brenya]

cracking has nothing to do with hacking it is night and day.

i've always thought of cracking as malicious hacking.

[pentomato]

Just create a virus, one that evolves itself and nothing can find it, and then as a trojan gets there and makes the tracker give you an invite and disapairs after the job is done.

[Artemis]

And how would such a program get past a system whereby the inviter needs to verify the invitee after activating the invite.

There is a world of difference between reverse engineering a program, which is there to be dissected, and a custom invite script, which is out of reach. The only way to decide whether a system can be bypassed is by having a working copy of that system to test. No system. No results.

The only post you should really take note of, since it from a coder that has designed the code for such systems and one of the major contributors to TBDev.

[waffles_jd]

A keygen works by attacking a hash based system, one where the keys aren't stored in the program. This is why many programs started using activation systems as well. However, few companies tie the activation system into the list of keys actually sold. If they did, keygens would no longer work. Most private trackers do not use hash based systems, but rather generated and stored keys, which cannot be guessed outside of brute forcing. Our site's code allows for 6277101735386680763835789423207666416102355444464034512896 combinations, literally, of which only 200-1000 are active at any time. To be able to pick one of the 1000 out of that many possible combinations in a week time window is impossible. Time will end before technology to handle that kind of work exists.

[BlackBird_]

OMFG, c'mon people, get a life... life is much more than private trackers...

[TheFoX]

Time will end before technology to handle that kind of work exists.

While the majority of your post is correct, that last statement isn't.

I can remember when it took a day to generate the mandelbrot set, yet a modern PC can generate the same set in less than one second.

The simple fact is that encryption today will become useless tomorrow. New methods of encryption have to be developed to keep up with processing power.

I have also been a member of the Distributed Net projects, and have seen how these decryption problems have got tougher due to newer, and faster, processors powering our machines. When I first joined, they were doing simple md5 algorithms, but nowadays they are hitting much more complicated routines.

The simple fact is that something that could take several years today, make only take several weeks in a few years time, or even days, or hours.

In response to what a lot of people have said, about brute forcing, if an invite requires the inviter to verify, then brute forcing is null. It's like picking a lock, only to find the family home.

[That1Guy]

And how would such a program get past a system whereby the inviter needs to verify the invitee after activating the invite.

There is a world of difference between reverse engineering a program, which is there to be dissected, and a custom invite script, which is out of reach. The only way to decide whether a system can be bypassed is by having a working copy of that system to test. No system. No results.

The only post you should really take note of, since it from a coder that has designed the code for such systems and one of the major contributors to TBDev.

Reading through the thread, I was hoping I would find a post by TheFoX. Honestly, he knows what he is talking about...

[waffles_jd]

Time will end before technology to handle that kind of work exists.

While the majority of your post is correct, that last statement isn't.

I can remember when it took a day to generate the mandelbrot set, yet a modern PC can generate the same set in less than one second.

The simple fact is that encryption today will become useless tomorrow. New methods of encryption have to be developed to keep up with processing power.

I have also been a member of the Distributed Net projects, and have seen how these decryption problems have got tougher due to newer, and faster, processors powering our machines. When I first joined, they were doing simple md5 algorithms, but nowadays they are hitting much more complicated routines.

The simple fact is that something that could take several years today, make only take several weeks in a few years time, or even days, or hours.

In response to what a lot of people have said, about brute forcing, if an invite requires the inviter to verify, then brute forcing is null. It's like picking a lock, only to find the family home.

Actually, it's not anything related to encryption. It's two people (the bad guy and the site) picking from a set of random numbers 6x10^57 (or so) strong and hoping to get a match in the same rolling week. Even if we completely ignore the fact that any admin would pick up on the attempts after awhile, it's still essentially impossible for it to happen.