Valhalla Legends Archive

Quote from: Camel on December 01, 2009, 08:11 PM
run it in a debugger and compare what the C code does to the Java code

Yes, you're not allowed to reuse ids. I don't think any browsers will expressly forbid you from doing it, but it's a violation of some standard.

You're still using the sign extending shift right operator, for one. Other than that, all I can really say is that you should run it in a debugger and compare what the C code does to the Java code, so you can pinpoint the areas where things are going wrong.

You can't do a mechanical port of getPacketSize(), because you can't pass a pointer to an int for the function to write the offset to, and you can't return a pointer to the offset in the buffer. You're probably best off getting rid of that method, and switching gamePacketDecode() to the prototype: byte[] gamePacketDecode(byte[] in), and throwing an Exception if there's a decoding error.

So you're saying (b>>>0x18) comes out to -1? That's not possible, buddy. Give more info if you want help.

[edit] Okay, I've taken a closer look at this. Looks like you've just tried to do a mechanical port without any regard for how the languages differ. I suggest you run through the C code in a debugger to figure out how it works, and then try to reproduce that behavior in your Java code. The C code uses pointers and "out" parameters pretty heavily, and those concepts just don't exist in Java, so you're going to have to take the time to understand how it works in order to port it.

In C/C++, there is only the need for one shift-right operator, because signedness is determined declaratively by the type. In Java, all types are signed, so there needs to be two different shift-right operators to accommodate both uses. I'm not sure why they made >> the uncommonly used one, but they did.

More on Java shifts: http://java.sun.com/docs/books/tutorial/java/nutsandbolts/op3.html
More on C shifts: http://msdn.microsoft.com/en-us/library/336xbhcz(VS.80).aspx

Yes, I'm sure someone here can help. Do you have a more specific question? If you're just looking for someone to do it for you, I doubt you'll get that here.

Quote from: Hdx on November 23, 2009, 12:24 AM
3) For CDKey, you need to send it a valid cdkey IIRC 3333333333333 works.

To elaborate, it has to decode. It doesn't have to be accepted by [the real] Battle.net, or probably even have the right product ID.

Quote from: Strilanc on October 23, 2009, 01:36 PM
Because the battle.net check is significantly stronger.

This is sort of misleading; the installer just checks that the key is decodable, and is for the product - like buying a car on ebay based on the picture looking like a car instead of a motorcycle, but without starting it up to see if it runs. When you send the 3 DWORDs to Battle.net, it checks that the private key matches the other two values according to whatever algorithm they used to generate the CD keys in the first place.

Sort of going off on a tangent here, but the private value from the cd key is never sent in plain text; it's hashed (BS1) with 32 bits of salt from the client, and 32 more from the server, to protect the key from being sniffed off the wire. It's a pretty weak security measure, since it only takes a few hours in the worst case to brute the private key (it's only a 32-bit value) with a poor implementation of BS1 and a slow computer.

Quote from: Strilanc on October 23, 2009, 01:29 PM
I believe the private is not related to the public key mathematically, it is just generated randomly. Blizzard stores all the information on cd keys it has generated, so when you connect to bnet they can lookup your private key given the public key.

That's extremely unlikely, considering there's a huge amount of evidence that the relationship is algorithmic. I don't recall all the details exactly, but there has been a great deal of work put in to studying the relationship, and someone was able to come up with code that generated a battle.net-acceptable SC key about 5% of the time. If it was truly random, they either used a really shitty random number generator, or all the moons were just perfectly aligned.

Really, the only way to know would be to ask someone who implemented it, but you'd have to be pretty crazy to believe that they're random.

I don't think you understood what I'm saying at all. If you create an object, and the jitter knows that there's no code path where it can have remote references at the end of its declarative scope, it will create machine code that destroys and deallocates it at the end of its scope instead of sending it to the collector for reference monitoring.

In the example:

int[] getInts() {
    List<Integer> ints = new ArrayList<Integer>(100);
    for(int x = 0; x < 100; x++)
        ints.add(new Integer(x));
    return ints.toArray();
}

the object referenced by ints will never make it to the collector.

The limitation on this enhancement is the same limitation that you'd inherently get with stack-bound data anyways: it can't leave its declarative scope. That completely invalidates any argument for performance gain by putting non-references/primitives in the stack that I can think of.

[edit] Of course, if you pass the object to overridable/external code, the jitter won't be able to perform the enhancement; but I think it's unlikely that someone would choose such a pattern in a time-critical segment of code.

There's no checksum. The CD key is just 3 DWORDs encoded in to a form a human can type.

If it decodes, it's a valid key. If the product ID matches the product, the installer accepts it. You're only going to know if the public/private IDs match by trying to log in to battle.net.

Quote from: Strilanc on October 21, 2009, 01:26 PM
That is code for extracting the public/private/product values from a cd key. It is needed for bnet login, and is probably involved in verifying the key, but doesn't actually perform verification.

If you say so.

A the GC would never have to worry about the equivalent object to a stack-bound struct, because its scope will end within the method, and the GC will therefore not have to 'watch' its life-cycle.