Ads displayed for guests and not donating members only. Get ad-free by donating. If you have already donated, please read here.
Results 1 to 8 of 8

Thread: Decrypting replays

  1. #1
    Retired Commander Phalynx.eu's Avatar
    Join Date
    Jan 2013
    Location
    Erlangen, Germany
    Posts
    2,127

    Decrypting replays

    To make things easier we can use this semi-private forum to get a productive discussion about the encrypted part of the replay format.

    euvido/Jan and Scrambled/Ben you are both working on the same stuff, so maybe we can concentrate on doing unknown stuff instead of re-inventing the wheel.

    Ben is doing Perl, while Jan is doing C++. And I'm doing PHP and Python.

    If you know some other guy who should be added, just name him.

  2. #2
    Retired Commander Phalynx.eu's Avatar
    Join Date
    Jan 2013
    Location
    Erlangen, Germany
    Posts
    2,127

  3. #3
    I'll probably still work on it anyway because I <3 Perl heheh

  4. #4
    Retired Commander Phalynx.eu's Avatar
    Join Date
    Jan 2013
    Location
    Erlangen, Germany
    Posts
    2,127
    Nobody told you to stop work on the Perl version. We should use this forum to exchange information on how replays are encoded.

  5. #5
    LOL I know, just saying

    I'm a bit sad because my old "hunt down consumables/ammo" code doesn't work anymore, seems WG changed how that stuff is sent so I can't find it anymore.

  6. #6
    Scrambled, I quickly reviewed your code and wondered what kind of extra information you get from the pickle property, can you give some examples ?

    About the further extraction of new information of replays, what I really need to do is do so more specific training battles focussing on one specific property that could be located in the packets. It's a bit tedious work to do, so any suggestions to improve this work would help.

  7. #7
    Some progress in decoding the 'packet stream' (the encrypted part in the replay files), found out today the layout is as following.

    payload size in bytes (4) | packet type (4) | zero bytes (4) | payload (size indicted by first part)

    Using this method to read the packets, should make it a lot more robust to future changes (previous method was determining each of the packet sizes beforehand). I also found out that the packet with type 0xFFFFFFFF indicates the last packet of the stream.

  8. #8
    Retired Commander Phalynx.eu's Avatar
    Join Date
    Jan 2013
    Location
    Erlangen, Germany
    Posts
    2,127
    Somehow Scrambled does not have access to this forum. If you want to contact him, use this eMail Address:
    benvanstaveren@gmail.com

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •