Valhalla Legends Archive

Quote from: Hdx on January 01, 2009, 12:53 AM
Yar, do me a favor cuz i cant think right now, define PDU.
Anyways, I think I understand you correctly, due to it containing NT Strings. {AE: variable length data} it is difficult without the proper habbits {buffer classes} to obtain the data. On the other hand if it was simply x number of fixed size objects it'd be simple. {AE if each item had nothing but 5 dwords you'd know that you needed count * 20 bytes of data}
BUT, it still stands, that to obtain the entire packet load you would use the length in the BNCS header neh?

Protocol Data Unit.  Many posters here refer to it simply as a "packet," but I try to avoid that since it can confuse people since BNCS PDUs don't have any fixed mapping to TCP packets.  It comes up a fair bit in Wireshark documentation, though looking at the Wikipedia page for PDU, it seems my use for application data isn't very common, and so could be misleading in its own right.

Yes, you still need the BNCS header to know when you have the entire PDU.  When I first entered the thread, I assumed he'd gotten past basic PDU reassembly if he was to the point of looking at the game query packet.  I could be wrong on that, though.

Quote from: brew on December 31, 2008, 05:09 PM
I'm not quite following you. You do realize (in my code) it's not being parsed until the entirety of the packet is there in the buffer, right? The size of each individual entry would therefore be irrelevant.
I took the OP's post to mean reassembling the primary packet, nothing to do with subextraction at all.

I took it to mean that he couldn't figure out how to access over the individual records within the packet.  We approached different problems.

Quote from: Hdx on December 31, 2008, 05:26 PM
What do you mean subextraction? There is nothing different in 0x09 as any other packet. I think you're confusing me, From my understanding you're saying you have to extract more data from the socket then specified in the BNCS header, which, you don't.

I meant no such thing.

Quote from: Hdx on December 31, 2008, 05:26 PM
As for extracting the data from each of the games listed, its a simple for loop (for x = 0; x < data.gamecount; x++) {remove shit} not hard

Removing individual records isn't entirely trivial since they don't have an internal length count, so you have to step over the contained strings to find the boundary, but no, it's not hard.  On the other hand, neither is reassembling the main PDU, but look how many people can't figure that out.

Quote from: Hdx on December 31, 2008, 12:42 AM
Yes, but if it was BNCS 0x09 everyone above has it correct, sorta. The BNCS header for 0x09 works jsut the same as everyone else's, and includes the length of ALL the data.

Yes, but after he has the whole BNCS 9 message reassembled via the header length, he needs to go through another round of parsing to pull out the individual game records, and there is no separate length field for those.  There is a count field, which is sufficient when combined with a buffer that knows the total PDU size.  brew's instructions are completely inappropriate for the subextraction, and Yegg's code doesn't look too relevant either.

Looking back at the original message, I think the poster needs to answer your question, tell us what language he's using, and give us some sample data.  He's too vague.

Assuming he meant BNCS 9, the game listing message, every one of the responders seems to have forgotten that this message has the property that it contains many records within it.  It has a fixed length header, followed by a variable number of variable length records, one per game enumerated.  The same basic principles used for reassembling PDUs from a TCP stream apply here, though of course the rules for what constitutes a record differ a bit from what constitutes a PDU.

I haven't checked in a while, but historically, there was a bug in the Blizzard clients that the SNP would not close the socket until the client unloaded the SNP.  Returning to the multiplayer menu is not sufficient to unload the SNP.  Returning to the main menu is sufficient.  I know this applied to Diablo, and it wouldn't surprise me if it affected the other clients, especially the legacy ones.

No, I could not be more specific, as I haven't built this package.  I didn't have it on hand to check the documentation for exactly how to run it.  I only recognized that your invocation was confusing nmake.  I'd hoped the documentation from Detours would tell you exactly what to do when I sent you back to it.  Glad to see you got it working anyway.

For the benefit of any future readers, could you post the exact steps you followed to get it to build?  I assume the key was getting nmake in the right directory and/or getting some environment variables set in a particular way.

You're running nmake incorrectly.  You're telling it that the directory is a target that should be updated.  It doesn't know how to update the directory, so it considers it up-to-date and does nothing.  Recheck the instructions on how to run nmake.

Ignoring the overhead costs of preparing each method, you will get better performance by a large margin if you generate the code at runtime, for the simple reason that it avoids both the jumps/calls inherent in the switch and the repeated loads of the operator to identify what statement should be next.  For a large enough data set, the preparation overhead will be lost in the time spent executing the computation itself.  Depending on the data set, it's possible that fetching the data to checksum will evict the control string, making repeated switches even more expensive.  By generating the checksum function, you can keep the generated code in the icache, so it is protected from getting evicted by data loads.

If not for the sheer number of possible control strings, you could unroll the switch and get performance equal to, if not greater than (due to reduced overhead), the performance of doing runtime generation.

Although it might be possible, it's very likely not worth the trouble to come up with a platform independent way to do runtime generation.  One way to minimize your platform dependence would be to create a set of platform specific helper functions that know the opcodes for each operation.  Then the main, independent loop can do:

switch(op1) { case '+': add_op_plus(...); break; case '-': add_op_minus(...); break; ... }

Porting to a new platform then becomes a matter of updating the add_op_* functions, and writing something to generate new prolog/epilog.

Quote from: l2k-Shadow on September 10, 2008, 11:57 PM
Error 6 is Invalid Handle.  This means that HttpOpenRequest or one of the previous calls is failing. Your error check if statements will not work, you are using incorrect syntax make the compiler compare the values, you need to use double equal signs, ==, instead of =.

Actually, since he is overwriting the handles instead of testing them, the prior calls may be working fine.  His attempts at testing ensure he always passes NULL to the subsequent calls.

Quote from: Don Cullen on September 02, 2008, 04:14 AM

Code Select Expand

<!-- relatedurls would be delimited by commas -->


If you need to have a repeated field, I suggest you follow your later convention.  Move the related URLs out into a child tag, and have one instance of the tag per related URL.

Quote from: Don Cullen on September 02, 2008, 04:14 AM

Code Select Expand


<!-- if any, can include html for formatting, but use [] instead of <> -->

Although your method makes the remark a bit easier to read in a text editor, it would simplify display tools if the embedded HTML used quoted angle brackets.  For example, <b>This will have an HTML b tag around it.</b>

Quote from: Don Cullen on September 02, 2008, 04:14 AM

Code Select Expand

<format>
<field type="DWORD" descr="Number of Games" />
<field type="DWORD" case="if DWORD1 == 0" descr="Status" />
<repeat case="DWORD1 > 0" amtdefined="true" amt="1">
<!-- If amtdefined is set to true, tell it which field contains amount (Ex: amt="1" means first field) -->

This isn't consistent.  Also, a few minor improvements are needed if you want to be able to synthesize parsers from the XML description.  For Status, your case has the word if, but for the repeat directive, you don't.  Although a client could use different case handlers for field vs. repeat, it would be simpler if the two case attributes had the same internal structure.  Second, you refer to DWORD1, but never name it explicitly.  Anyone familiar with the packet format will know that you're referring to the DWORD labeled "Number of Games", but new readers might not figure it out -- and it's unnecessarily vague for any sort of parser generator.  I suggest adding an optional attribute name to field.  If present, the reader should save the value of name and use it for matching up future references.  Your block could then be rewritten as: <field type="DWORD" name="dwGameCount" descr="Number of Games" />
<field type="DWORD" case="dwGameCount == 0" descr="Status" />
<repeat case="dwGameCount > 0">

Looking back, your comment suggests you may have intended to solve this problem by having the repeat directive set some tracking variables.  I think my way is cleaner, though, since naming the fields makes it easier for people to match up the intended usage visually, as well as simplifying doing a search through large definitions to jump to all references to a conditional field.

For your tests, what're you allowed to do?  For example, can you run scans that may crash badly coded applications?  Are you focused on knowing what's in the network or on checking that known programs are secure?  Are you validating programs that are only available to employees/contractors, or is there a risk that J. Random Hacker on the Internet can try to hit the target?  Are the scanned targets mostly running closed source third party stuff, or can you get the source to the targets (either because they're OSS or because they were written in house)?  If the latter, source code analysis tools would be worth checking as well.  You might be able to find vulnerabilities through code analysis without ever touching a production application.

There is no Diablo 1 game server.  Diablo 1 games are peer-to-peer.

Perhaps the new version was built with a different compiler version or different options, such as switching from dynamic CRT to static CRT.  Perhaps debugging code was mistakenly shipped, causing the file to grow due to all the extra debug strings and/or sanity checking.

The best way to find the correct answer is to analyze the files, as Hdx suggested.  Start with easy tests like checking whether the DLL dependency list has changed.  Move on to checking whether functions known to be in the old version are unchanged in the new version (as opposed to picking up instrumentation).  If that doesn't turn up anything useful, then try to identify functions which are new in this version and determine what they do.

He seemed very focused on using /whereis, so I didn't want to confuse the issue by switching to a more appropriate command.

Even if Warden doesn't object to changing the text of the /astat, there's still the issue that he needs to be hooked into the returning data stream to parse the server responses.  That almost guarantees a Warden failure.  He never specifically said he wanted this to work on official BNCSs, though.

As Dale notes, you don't need to mess with the UDP stream for that.  As such, it's pretty easy, albeit not completely accurate.  Last I looked, the name advertised when joining didn't have the #number suffix that gets applied to clones, so you might end up banning legitimate players if they happen to join while cloned.

Hook in around the spot where SC sends the /astat command to query the new player's statistics.  Replace it with the /whereis or add your own, as appropriate.  Replacing is safer, since adding it doubles your transmissions and could more easily flood you off.  Save a record that this player is in a provisional state, and check those records when you get /whereis responses.  The only hard part is automatically banning the player on failure.  If you're willing to just display a note to the user that he ought to ban that player, then it's trivially easy.