Valhalla Legends Archive

You'll find some who don't know the answer (or even the question) post things which aren't worth reading on these forums

Regardless....

The inscribed triangle will have to be equilateral to minimize the area.  IIRC, there is another area formula specifically for an equilateral triangle.

But there is some identity relationship between the equilateral (or general) triangle and the circle I'm missing...

Using this identity, you could probably make a formula for the area, differentiate it and set this equal to 0 to find the minimum...

Well I don't store every proof I know in my ol' noggin'.  I came across this when I was reviewing.  And sharing is caring 

And thanks for playing

QuoteIn other words, this is a homework problem of yours?

Nope...

Why would anyone assign someone a well known math proof as homework (IIRC, Gaussian distribution)?

Nonetheless, I always thought it was an interesting approach to a nonelementary integral.

But just to clarify, what Rule basically did was square the non-elementary integral (to make it elementary) and then converted it to polar coordinates.  Then after finding this value, he square rooted back to get to the original answer.

I need to brush up on a few things and thought it would be an interesting challenge for some of the Math geeks here

This might look familiar to some of you.

|Infinity      (-x^2)
|            e^              dx
|0

Read as: integral with respect to x from 0 to infinity of e to the negative x squared.
(Hint: this integral converges to a value)

Go yoni

I'm not sure if you were speaking to Skywing or yours truly.  But I was referring to this forum 

Methinks the program which was mentioned somewhere in the last page did not really affect anything...1/840 isn't much of an improvement from 1/1000.  And if it works an estimated 90% of the time, is it even a filter?

Example:
If there's an unknown number from 1-10, I don't think it's logical to say 'if I eliminate one of the possible numbers, there's a 90% chance that the number I eliminated isn't the unknown number'

But I must say there were a few interesting posts which may have been a bit more useful had there not been some quick moderation (or editing by the original poster). 

But that's why it's smart to have logs of these things

You've tested all 1000 private values for each of those?

Quote from: Skywing on January 21, 2006, 08:08 PM
Surprising that they repealed the ban on cdkeys outside of the released ranges and allowed keys like those to work once more.  Or, I suppose it would make sense that if they are using product 2, all of the product 1 keys that will fit in the obfuscated form are used up by now.

Well if the number of copies of Starcraft that Blizzard claims were sold are correct, they should have recently reached the limit.

Quote from: Arta[vL] on January 21, 2006, 03:19 PM

Quote from: Lenny on January 21, 2006, 12:37 PM
But you're on the assumption that decoding a key places it in a simpler form.

It does. Decoding produces the values that are used in the computation.

Quote from: Lenny on January 21, 2006, 12:37 PM
As you already said, any patterns are LIKELY to be produced as a result of decoding/encoding, but not necessarily.  And this is why comparing patterns in either the decoded or encoded form is difficult.  And finding patterns in either form which are apparent in valid keys (but not a result of encoding/decoding) is useful.

The analgous trend may not be as easy to recognize in decoded form (or vis versa) because there is a xor operation done between the two forms.  Therefore, seeing one trend in the encoded form does not mean it will appear as simplisticly in the decoded form.

Any pattern present in an encoded form would be the encoding of a pattern present in the decoded form. Looking for patterns in the encoded form serves only to increase the complexity of the problem: you are then required to make sure that your trend is meaningful, and not simply an artefact of encoding. What's the point in doing that when the trend will also be present in the decoded form? I see no reason why an encoded trend should be easier to spot than a decoded trend.

I'm not going to discuss this further as I've explained it numerous times and you are apparently unwilling to reconsider your position.

Well you can't make the claim that it is a simplification with out actual knowledge of how the 'valid key' algorithm works.  The public value could be easily xor'ed back, and from that value, be used to find the private.  The last xor in the decode could even be xor obfuscation.

And yes, any pattern in the encode will be in the decode, but as I've said earlier it may not be as simple to see.  To see it by a visual comparison of numbers would require someone to be able to mentally 'xor' numbers as easily as most can mentally perform addition and subtraction.

I agree there's no reason for this argument to continue.  But as a note, Ringo is an example of proof of concept.  As far as I have seen, he has been generating cdkeys with the best success rate here.  And as he has already said, he has accomplished this by observing many of the trends in encoded keys.

Quote from: Arta[vL] on January 21, 2006, 08:27 AM

Quote from: Lenny on January 21, 2006, 02:16 AM
It's simple process of elimination, nothing more.  You simply look for trends that ARE NOT a result of the decoding/encoding which is already known.  Any pattern which is found to be apparently only in valid keys while not in invalid keys (which were generated via encode or decoding) is valuable simply because you''re narrowing your set of possible keys.

Any patterns you see in an encoded key are likely to have been produced by the encoding process. The observation of such patterns is thus not useful. The observation of patterns in keys' decoded form is all that is of interest. The encoded form contains no more information that the decoded form, and the relationship between the encoded and decoded forms is understood, so there is no benefit in further analysis on that front.

I understand why it's appealing -- compared to the other avenues of investigation, it's very easy -- but it is not worth pursuing.

Quote from: Lenny on January 21, 2006, 02:16 AM
Now ask yourself, is this a pattern generated by all keys which are encoded correctly?

Any trend in an encoded key that is produced by all valid keys would have an analagous trend in the decoded form. It's that trend that is worth investigating.

Quote from: Lenny on January 21, 2006, 02:16 AM
Also, the problem with finding the actual algorithm are arbitrary functions which would prevent any 'mathematically gifted' person from simply finding the actual algorithm. 
Example:
if(key < 5)
  key = sqrt(43);
else if(sqrt(key) < e)
  key = ln(643);

There's no mathematical basis for such operations which could easily be in several parts of the algorithm.

That's plausible, but not confirmed. I agree that this task is very difficult, and is perhaps impossible, and I have made that quite clear in my posts from the beginning of this thread. I spent quite some time studying CD keys a few years ago, and concluded that I was unlikely to find anything useful.

There are really only two ways that the algorithm could be discovered:

1: It's based on an existing known algorithm with recognisable behaviour;
2: It's very simple.

If it's very simple, then the analysis of a large enough set of keys by an appropriately skilled person could yield useful results. As I said before, if it is neither of these things, then the task is likely impossible.

Quote from: Lenny on January 21, 2006, 02:16 AM
I doubt blizzard would need any outside sources to implement this algorithm.

That's a matter of opinion

But you're on the assumption that decoding a key places it in a simpler form.  Decoding places the key in another 12 digit form.  The largest importance of decoding keys in this situation is the filtering of only those which produce a product value of 01 or 02.

As you already said, any patterns are LIKELY to be produced as a result of decoding/encoding, but not necessarily.  And this is why comparing patterns in either the decoded or encoded form is difficult.  And finding patterns in either form which are apparent in valid keys (but not a result of encoding/decoding) is useful.


The analgous trend may not be as easy to recognize in decoded form (or vis versa) because there is a xor operation done between the two forms.  Therefore, seeing one trend in the encoded form does not mean it will appear as simplisticly in the decoded form.

It's simple process of elimination, nothing more.  You simply look for trends that ARE NOT a result of the decoding/encoding which is already known.  Any pattern which is found to be apparently only in valid keys while not in invalid keys (which were generated via encode or decoding) is valuable simply because you''re narrowing your set of possible keys.

Now ask yourself, is this a pattern generated by all keys which are encoded correctly?

Also, the problem with finding the actual algorithm are arbitrary functions which would prevent any 'mathematically gifted' person from simply finding the actual algorithm. 
Example:
if(key < 5)
  key = sqrt(43);
else if(sqrt(key) < e)
  key = ln(643);

There's no mathematical basis for such operations which could easily be in several parts of the algorithm.

I doubt blizzard would need any outside sources to implement this algorithm.  It's not difficult to create it (cracking it is a different story).  And if such a 'common' algorithm used existed, it would work in such which knowing what operations are done still makes it unfeasable to break (ie encryption).

Not if the pattern or trend is only apparent in valid keys and not a result of the actual decode.

Or are you still trying to find the definite algorithm for key generation (ie the F(public,product)=private)?  Because that's not feasable and would be exponentially more difficult if there were multiple algorithms involved (which is very possible).

Quote
The only reason that digit will change is in the xor stage. The pattern he found is a result of decoding. My advice, ignore any encoded form of the cdkey, and just look for relationships between private and public values of the same product.

I'm not following.  You're agreeing that the xor will change the 11th digit of the encoded key (or decoded since as you already said, the shuffling actually shuffles it back to the same place). 

Also, you can verify this yourself via the encode function.  For a product/public value pair, you can generate 1000 possible keys (only 1 being valid).  But of those 1000, not all follow the pattern.  Now if it were a result of the decode, wouldn't all 1000 keys follow this pattern?

 
It doesn't matter?

F(public,product) = encoded...Wouldn't that be just as useful?

There more than a few ways to look for patterns.  There are 4 values, encoded, product, public and private.  Patterns found between any 3 of those 4 values would be very useful. 

The only reason the encoded isn't the best choice is because many of the patterns are only as a result of the 'encode' function.
We already have part of the actual algorithm (known as decode cdkey).  But that doesn't mean the encoded value is useless.

The pattern that Myst_DooM has found is not a result of decoding.  You can check this yourself...And it's a rather frequent pattern in valid cdkeys (however there are a few exceptions).

And also there's 1000 possible keys associated with a specific product/public value pair.  So your chances are still 1/1000.....