Valhalla Legends Archive

Naturally, I had to correct them:
http://www.skullsecurity.org/blog/2012/battle-net-authentication-misconceptions

It's been awhile, was fun to dig up my old code and remember how stuff worked.

JavaOp2 is opensource and plugin-able (which should make the AI stuff easier), but I don't know whether or not it works anymore (due to Battle.net changes), so your mileage may vary.

Java/ABAP are the standard languages used by SAP, so I imagine that that's what the project is using.

Woo! -56!

FWIW, our winters have become more extreme in the last decade. When I was young, we rarely fell below -30, now we spend at least a week or two each year below -50.

Jared? Jared who?

Quote from: brew on December 17, 2008, 08:52 PM

Quote from: iago on December 17, 2008, 07:48 PM
I work for the provincial government as a Security Analyst, as an application security specialist.

What happened to Symantec =?

I was offered a better job, so I took it.

I work for the provincial government as a Security Analyst, as an application security specialist.

Quote from: Explicit on December 16, 2008, 08:29 PM
Your conversation should have been encrypted into either hex, or base-64.

Not encryption!

It's *possible* to sniff and modify packets, for things like traffic shaping or whatever, but it isn't something that'll affect the connections.

Quote from: Andy on December 10, 2008, 06:49 PM
For one user constantly? I find it much more likely a hop along the route (for example, the ISP) is just not disconnecting from the server.

The problem is that that doesn't make sense. That's not how the Internet works.

A hop happens at layer 2 (link layer), while the connection happens at layer 4 (transport). There is no concept of a connection at layer 2 -- packets are sent from one mac address to another with no regard to what's in the packet. A connection starts with a SYN is sent, which is a TCP concept (layer 4) -- the routers along the way don't know that the connection exists, and they can be swapped out *during* the connection without breaking it. The connection ends with FIN is sent, which is also a TCP concept. The routers in the middle again don't care.

Quote from: MysT_DooM on December 11, 2008, 10:16 AM
best off using wireshark

Wireshark is, by far, the best.

Quote from: Andy on December 08, 2008, 03:58 PM
It's DRTL. The official client. On the official server.

Then the server isn't managing state properly.

The ISP CAN'T do what Andy's saying, the Internet doesn't work like that.

The behaviour you're seeing is likely because of a broken client, or because the server doesn't bother to clean up sessions properly.

Quote from: Andy on December 03, 2008, 05:17 PM
iago: it was on the actual D1 client. It also happened to the same person on SC, D2, and W2. It was most definitely the ISP.

ISPs have absolutely nothing to do with this, unless they're *preventing* you from sending the teardown (like, maybe they dropped the packet); but that wouldn't really make sense.

The concept of this being caused by the ISP doesn't actually make sense.

Quote from: Andy on December 03, 2008, 12:33 AM
Clients send leavechat before disconnecting. The client has to actually terminate the connection in order to be offline. Before that state, you are in an empty area. If your ISP is stupid, it won't send the connection termination, thus leaving your account logged in to that empty area until BNet times you out and disconnects you itself.

It has nothing to do with your ISP sending the connection termination, it's about your client not sending the connection tear-down packets (FIN) correctly.