Thanks for your answer, of course I have identified the verbyte, but did not explain that clearly, sorry ...
But, as said above, I am really interested in the hex strand - and it seems to change per day ...
Today, it is 00 00 00 00 68 29 77 4A 29 AF 6F 01 00 00 00 00
EDIT: Okay, after a long time I took another look on this stuff and found the easy answer: It's just random stack rubbish. The function which constructs the 0x68-packet calls SUB ESP, 28h in the beginning and starts to write the data. Because it doesn't zero the strand before copying the character's name to it, these bytes remain. At the moment, for example, there are two returning addresses (one inside USER32.DLL, another inside D2CLIENT.DLL) and a parameter for GetSystemMetrics() in it, but this may change from patch to patch.
The other unknown byte (00 in documentation, 02 in my post) results from a call to D2Lang_10001 and retrieves the language ID which was English in the documentation and German for me.
But, as said above, I am really interested in the hex strand - and it seems to change per day ...
Today, it is 00 00 00 00 68 29 77 4A 29 AF 6F 01 00 00 00 00
EDIT: Okay, after a long time I took another look on this stuff and found the easy answer: It's just random stack rubbish. The function which constructs the 0x68-packet calls SUB ESP, 28h in the beginning and starts to write the data. Because it doesn't zero the strand before copying the character's name to it, these bytes remain. At the moment, for example, there are two returning addresses (one inside USER32.DLL, another inside D2CLIENT.DLL) and a parameter for GetSystemMetrics() in it, but this may change from patch to patch.
The other unknown byte (00 in documentation, 02 in my post) results from a call to D2Lang_10001 and retrieves the language ID which was English in the documentation and German for me.