Some online competitions require the user to input a code found on the product. Currently I am working on a script to generate these codes and post them to the server.
The code in question in a 10 digit alphanumeric code. After >500 000 codes tried, none of them have been valid.
My question is this:
How do these codes work? Does the company generateonly very specific codes from all the possible combinations or what?
Other urls found in this thread:
They probably have anti bruteforce protection. Rent a rotating proxy botnet then try again
>Does the company generateonly very specific codes from all the possible combinations or what?
Probably works the same way CD keys work.
It may be the case that the codes are only valid once activated at the register, meaning that an otherwise valid code would be rejected unless you happened to post the code after someone purchased something with that specific code and before they post it themselves.
>Does the company generateonly very specific codes from all the possible combinations or what?
How the fuck should we know? If they aren't retarded the codes are probably entirely random however.
Btw, for a 10-digit bigalphanumeric code, there's (10+26)10 ≈ 3.7E+15 possible combinations, so even if there's a billion sold products with unclaimed codes you still need to try 3.7 million random ones before getting one correct, on average.
10 digit alphanumeric code gives you over 51 bits. It probably uses some cryptographic hash function to generate the product keys so that a relatively tiny number of correct product keys are more re less uniformly (and apparently randomly, if you don't know the hash function and salt used) distributed over the entire space of possibilities.
This would make sense if the code (contained inside a pack of cigarettes) was somehow derived from the barcode. Which is unfortunately not the case. I don't see any other way the codes could be activated at the time of purchase
Funny enough, they don't. I sent a malformed SOAP envelope to the server and it crashed. It was offline for >7h..
As for bruteforce protection, the POST would have returned a response code other than 200 if this would be the case.
I didn't know the specifics, so I just gave one possibility.
No problem. I am just trying to get some ideas to optimize my chance for success.
>would have returned a response code other than 200 if they wanted to reveal that they're using bruteforce protection
FTFY
How would they implement bruteforce protection then? You said I should use a rotating proxy, which would imply some kind of IP ban. With an IP ban I wouldn't be able to post to the server AND get a valid SOAP envelope as a response telling me the code is invalid. Or am I missing something?
>How would they implement bruteforce protection then
They don't need bruteforce protection. Given the entire possible key space (36^10), the chances of stumbling into a correct one using a bruteforce search are vanishingly small. Suppose there are 100,000 correct keys "randomly" distributed over the entire possible key space. That means you'd have to check 36561584400 keys before running into a valid one. Even if you make 1 request every millisecond, it'd take you over a year to find one valid code on average.
Without bruteforce protection, they still have to process those fraudulent requests, which means checking each request against 100,000 real keys, which takes more CPU time than waiting about a quarter of a second (based on OP's screenshot) before replying "nope, no good."
>checking each request against 100,000 real keys
>takes more CPU time than waiting about a quarter of a second
First of all, that's retarded. Even doing it the bruteforce ways less than a millisecond, and there are non-bruteforce ways to do this quickly, like bloom filters. Secondly, it's probably not actually random but rather a secure salted hash that looks random if you have no access to the implementation.
If brute force detected
Then
Pretend no success
Elif brute force not detected
Success=check(key)
If success
Then
Walk the dinosaur
Else
Spurdo gunfight
Fi
Fi
OP revealing to everyone he's wasted his time and money
>OP revealing to everyone he's wasted his time and money
> wasted his time
The 10min it took me to write the Python script?
> and money
Yes, indeed I wasted hundreds of dollars on this :^)
How can u be this retarded? Please gtfo my board, Imagine trying to break into a safe, does the safe say "you tried to open me too many times so I will now help you by telling you this and ignore all future requests"
You delusional burger they simply have bad response cached and can return it instantly. The server just stores a table with your ip and how many requests you did in what timespan. If its over the limit it bans you.
Do a timing check by measuring response time after doing 1k checks from same IP vs timing check vs new IP.
>making it impossible for you to try at all helps your attempt to find something by trying all the options
36561584400 on a 10GE takes 5000 RAW seconds if you count 58 TCP/ETH/IPV4 headers + 128 POST req. (18 eth + 20 ipv4+ 20 tcp)
So with average req time of 500ms it wouldn't take long especially if you use custom network driver
>we're not listening to your attempts anymore
You stop trying to guess it and try a different approach, or you make your requests more subtle.
>you guessed wrong but we're still listening honest
You keep trying a method which won't get you anywhere until you've exhausted all possible keys, a very long time, before realising you've been had and trying a different approach.
>You stop trying to guess it and try a different approach
If you try the bruteforce approach in the first place, you are too much of an idiot for "a different approach" by definition, and filtering your spam is the best thing to do.
If it doesn't have bruteforce protection, then as seen in the OP's screenshot the server takes 1/4 second to process a request (minus the negligible time for OP to generate a key and the time for the request/response to travel over the internet to the server.) Whatever they're doing to check if a key's a winner takes that long to do; whether or not they're doing the most efficient way possible (or if it's efficient at all) is irrelevant.
>36561584400 on a 10GE takes 5000 RAW seconds if you count 58 TCP/ETH/IPV4 headers + 128 POST req. (18 eth + 20 ipv4+ 20 tcp)
And literally all it takes to foil your plan is to wait 1 ms before processing the next request.
Bruteforce is easy, the first thing anyone thinks of, and works more often than any of us would like to admit. If it's stupid but works, it's not stupid.
this is not OP - I'm OP
Normally everyone in this thread would be correct. But as I mentioned, their webserver is complete trash (also runs IIS7). It is also leaking their private API, so I doubt they are checking for bruteforce attempts. Also all the request times vary slightly - making me think the responses aren't cached. There is also a cookie "ASPSessionID" that gets sent with the returned response containing a unique value - once again making me think the responses aren't cached.
>as seen in the OP's screenshot the server takes 1/4 second to process a request
> Whatever they're doing to check if a key's a winner takes that long to do
This is a complete logical non-sequitur. Even if you're a total idiot and literally search a big array for keys, it takes less than 2ms per search in fucking javascript. Doing something as trivial as using a dictionary gives you ~2,000,000 checks per second even on my shit-tier 5 years old PC. You are ridiculous.
You can tell me how long it SHOULD take, but the screenshot shows how long it IS taking.
>the screenshot shows how long it IS taking.
The screenshot shows how long it is taking him to get a response, now how long it takes their program to validate the keys. Your "argument" is a logical non-sequitur and also a very poor defeasible argument (as demonstrated by my example).
HTTP overhead is not that huge, so unless OP is a third worlder (possible) or they send megabytes of data per request (also possible), the most likely scenario is that the method to process the request is taking up the majority of the time.
>the method to process the request
That is completely different from:
>the method to validate the key
It's entirely possible that they just put those requests on low priority or intentionally only handle a set number of them per second.
How does a CD key works?
Right, we don't know for sure how they set it up. It could be the case that they receive tens of thousands of requests per second, so this was the fastest they could manage to respond.
In such a case, every tiny optimisation they can squeeze out helps, even if the net gain is only a fraction of a ms per specific request. It's not even hard to come up with something that efficiently and transparently filters out bruteforce-detected requests; even I (someone who's probably painfully obviously a novice at networking) was able to come up with something.
Your original argument was that they must be using bruteforce protection because it would take longer than a quarter of a second to validate a key:
>which means checking each request against 100,000 real keys, which takes more CPU time than waiting about a quarter of a second
This is nonsense. It takes less than less than 2 milliseconds even using a simple search, on an old computer, in javascript. You're just trying to save face now.
OP.
They will ask for the receipt/packaging.
>How does a CD key works?
The general idea is to use a crypto hash function + a secret key to map a short subset of some predictable sequence onto a very large key space (in this case, 36^10) in more or less uniform and seemingly random fashion.
Excuse me if I'm wrong, but I just skimmed the reply chain and was my first post. All I said there was that if they weren't validating the keys, they would have no obligation to respond in any way which makes that obvious.
My next post was , where my argument was that it's more efficient (in CPU time, not real time) to not even try to validate keys which are being sent in a bruteforce attack. I was probably wrong in suggesting they were waiting, though.
My next post was , in which I erroneously believed that the majority of the time spent processing the request must have been spent either waiting to simulate validation or actually validating the key.
Point out where I said they MUST be using bruteforce protection rather than suggesting that it might be in their best interest to use bruteforce protection.
>Point out where I said they MUST be using bruteforce protection
I already did: >which means checking each request against 100,000 real keys, which takes more CPU time than waiting about a quarter of a second
Your argument was literally this:
>Without bruteforce protection, they'd have to check against 100,000 real keys
>Checking against 100,000 real keys would take more CPU time than 1/4s
>OP's screenshot shows it taking 1/4s or less
>Therefore they are not checking against 100,000 real keys
>Therefore they must be using bruteforce protection and ignoring his attempts
I don't care how much you try to weasel your way out of this, everyone can see exactly what you said. Just stop. It's embarrassing.
CPU time is not real time.
sleep(1/4 seconds) takes almost no CPU cycles, while validate(key) takes much more than no CPU cycles.
I'm sorry for not realising I was talking with someone who doesn't know the difference between CPU time and real time.
You're actually right. I should have paid attention to that detail. Sorry.
It happens.