I did yet not try Il2CppInspector on Windows, but will give it a try at the next occasion.
Binary files in repositories aren't a good idea. If you would like to publically share the logs, feel free to upload those to a 3rd party file hoster and add a download link to one of the documents.
FYI: The logs contain your user ID, computer name and perhaps network MAC address of the adaptor you used. Perhaps those could be replaced/deleted to ensure more privacy but I don't know how.
(same as PM on POL)
Thank you for continuing the research!
I did yet not try Il2CppInspector on Windows, but will give it a try at the next occasion.
Binary files in repositories aren't a good idea. If you would like to publically share the logs, feel free to upload those to a 3rd party file hoster and add a download link to one of the documents.
FYI: The logs contain your user ID, computer name and perhaps network MAC address of the adaptor you used. Perhaps those could be replaced/deleted to ensure more privacy but I don't know how.
Sorry for the wait. Yeah, I think I removed all my account data from the messages, but if I missed a spot then so be it.
Mitmproxy doesn't really use a raw binary dump format, it rather uses a text based format that just contains the TLS/http layer I think.
It's still not really easily human readable though.
You can use mitmproxy -nr <file> to view the dump file.
Sorry for the wait. Yeah, I think I removed all my account data from the messages, but if I missed a spot then so be it.
Mitmproxy doesn't really use a raw binary dump format, it rather uses a text based format that just contains the TLS/http layer I think.
It's still not really easily human readable though.
You can use `mitmproxy -nr <file>` to view the dump file.
I uploaded it to google drive for now: https://drive.google.com/file/d/1RZxMs_5g_sg1iCpWIg-itJHjAM5rmyHK/view?usp=sharing
Amazing! Thank you for the logs.
Here's some interesting things that I found.
EDIT: all those differences are irrelevant. The hash value is sent over UDP
key "modified": true received from []/compareProtocolVersion
It's inside a Response text, hence probably not as interesting.
key "heartbeat": false received from []/login/v2/login?
Sends "sign": "58a8c8e5bcc8c75e50a642[...]" to the server
What does it send on Windows?
Does it change when (and only when) UnityPlayer is modified? Or is it constant?
it's sending a base64 string to []/sdk/upload
contents: hash 56b7daba5a3de731e034[....]
@timbuntu: Is this a private value that you removed in other places? I cannot find anything like that in the other logs. Might be interesting to us.
Does it change when (and only when) UnityPlayer is modified? Or is it constant?
There's a typo in their API: "safe_moblie_required": false
Note to other readers: Please download mitmproxy from their website. Older versions (like the one from the Ubuntu repository) cannot read this dump data.
Amazing! Thank you for the logs.
Here's some interesting things that I found.
**EDIT: all those differences are irrelevant. The hash value is sent over UDP**
1. key `"modified": true` received from `[]/compareProtocolVersion`
* It's inside a Response text, hence probably not as interesting.
2. key `"heartbeat": false` received from `[]/login/v2/login?`
* Sends `"sign": "58a8c8e5bcc8c75e50a642[...]"` to the server
* What does it send on Windows?
* Does it change when (and only when) UnityPlayer is modified? Or is it constant?
3. it's sending a base64 string to `[]/sdk/upload `
* contents: hash 56b7daba5a3de731e034[....]
* @timbuntu: Is this a private value that you removed in other places? I cannot find anything like that in the other logs. Might be interesting to us.
* Does it change when (and only when) UnityPlayer is modified? Or is it constant?
4. There's a typo in their API: `"safe_moblie_required": false`
Note to other readers: Please download mitmproxy from their website. Older versions (like the one from the Ubuntu repository) cannot read this dump data.
I think I only removed the userid and auth token, ip, and at only some places the device name. And I never actually just removed anything, I only replaced the corresponding value with the same length of 'x'.
Was some of the decoded base64 also weirdly formatted for you?
The content value in the requests to /log/sdk/upload
I think I only removed the userid and auth token, ip, and at only some places the device name. And I never actually just removed anything, I only replaced the corresponding value with the same length of 'x'.
Was some of the decoded base64 also weirdly formatted for you?
The content value in the requests to /log/sdk/upload
They look like this for me:
```
xxxxxxxxwindows_playerWine (The Wine Project)"Windows 10 (10.0.0) 64bit*56b7daba5a3de731e034385252552a2a0b4914c9816033997059101.10.1.0\
1603966523* autologin:
resolution_x1920:
resolution_y1080:
app_use_local_days8
```
Yes. It looks the same way here. The byte before each string value indicates the string length (no null termination). No idea what the leftover bytes do. This data is sent to a /log URL, thus I don't think it is related to anticheat.
Yes. It looks the same way here. The byte before each string value indicates the string length (no null termination). No idea what the leftover bytes do. This data is sent to a `/log` URL, thus I don't think it is related to anticheat.
For me the /log/sdk/upload hash matches my device_id (except the first and last numbers).
Also for me on Windows v2/login sends "sign": "cf1286f3f080f81f238e65ee3fa692c132178c2645142581af1db0568fed8a56" with and without the patch applied to UnityPlayer.dll
For me the <code>/log/sdk/upload</code> hash matches my device_id (except the first and last numbers).
Also for me on Windows <code>v2/login</code> sends <code>"sign": "cf1286f3f080f81f238e65ee3fa692c132178c2645142581af1db0568fed8a56"</code> with and without the patch applied to UnityPlayer.dll
@SeppNei: What does it send/receive from compareProtocolVersion? Is the "modified" value also true?
How about "heartbeat" from v2/login? Is that also false, like on Linux?
@SeppNei: What does it send/receive from `compareProtocolVersion`? Is the `"modified"` value also `true`?
How about `"heartbeat"` from `v2/login`? Is that also `false`, like on Linux?
@Krock Yes, the "modified" value is also true both ways. And "heatbeat" is again the same.
Here are the mitmproxy flows: flows.zip. I replaced my email from the data, i know there is more information there but whatever, you alredy got it with the wireshark logs.
@Krock Yes, the <code>"modified"</code> value is also true both ways. And <code>"heatbeat"</code> is again the same.
Here are the mitmproxy flows: <a href="http://pertusa.myftp.org/gi-linux/flows-GI.zip">flows.zip</a>. I replaced my email from the data, i know there is more information there but whatever, you alredy got it with the wireshark logs.
@SeppNel Thank you for the MITM logs for comparison. The Wireshark logs I got from you in private are now obsolete - the UDP traffic seems to be a custom format, and the hidden TLS information is now contained in this log file.
May I include this link in this repository, so that other people could analyze it if they want to do that? Perhaps someone finds a difference that we yet missed.
@SeppNel Thank you for the MITM logs for comparison. The Wireshark logs I got from you in private are now obsolete - the UDP traffic seems to be a custom format, and the hidden TLS information is now contained in this log file.
May I include this link in this repository, so that other people could analyze it if they want to do that? Perhaps someone finds a difference that we yet missed.
@Krock Sure, no problem. But please use this google drive link beacuse the one i shared before is from my server and right now it's not very reliable (disk failure).
@Krock Sure, no problem. But please use <a href="https://drive.google.com/file/d/1NRxE6aLqpsRAMOfMbDAgU8KkRzFpgHIR/view?usp=sharing">this google drive link</a> beacuse the one i shared before is from my server and right now it's not very reliable (disk failure).
The hash is sent over UDP. mitmproxy does not support this (yet), and the encryption code for those packets might be custom.
TLS data is a dead end for now. Closing until someone discovers something that's relevant.
The hash is sent over UDP. mitmproxy does not support this (yet), and the encryption code for those packets might be custom.
TLS data is a dead end for now. Closing until someone discovers something that's relevant.
I have the decrypted TLS traffic, in what way/format would you like to add it to the repo? I have it as a mitmproxy dump file right now.
(same as PM on POL)
Thank you for continuing the research!
I did yet not try Il2CppInspector on Windows, but will give it a try at the next occasion.
Binary files in repositories aren't a good idea. If you would like to publically share the logs, feel free to upload those to a 3rd party file hoster and add a download link to one of the documents.
FYI: The logs contain your user ID, computer name and perhaps network MAC address of the adaptor you used. Perhaps those could be replaced/deleted to ensure more privacy but I don't know how.
Sorry for the wait. Yeah, I think I removed all my account data from the messages, but if I missed a spot then so be it.
Mitmproxy doesn't really use a raw binary dump format, it rather uses a text based format that just contains the TLS/http layer I think. It's still not really easily human readable though.
You can use
mitmproxy -nr <file>to view the dump file.I uploaded it to google drive for now: https://drive.google.com/file/d/1RZxMs_5g_sg1iCpWIg-itJHjAM5rmyHK/view?usp=sharing
Amazing! Thank you for the logs. Here's some interesting things that I found.
EDIT: all those differences are irrelevant. The hash value is sent over UDP
"modified": truereceived from[]/compareProtocolVersion"heartbeat": falsereceived from[]/login/v2/login?"sign": "58a8c8e5bcc8c75e50a642[...]"to the server[]/sdk/upload"safe_moblie_required": falseNote to other readers: Please download mitmproxy from their website. Older versions (like the one from the Ubuntu repository) cannot read this dump data.
I think I only removed the userid and auth token, ip, and at only some places the device name. And I never actually just removed anything, I only replaced the corresponding value with the same length of 'x'.
Was some of the decoded base64 also weirdly formatted for you? The content value in the requests to /log/sdk/upload
They look like this for me:
Yes. It looks the same way here. The byte before each string value indicates the string length (no null termination). No idea what the leftover bytes do. This data is sent to a
/logURL, thus I don't think it is related to anticheat.For me the
/log/sdk/uploadhash matches my device_id (except the first and last numbers).Also for me on Windows
v2/loginsends"sign": "cf1286f3f080f81f238e65ee3fa692c132178c2645142581af1db0568fed8a56"with and without the patch applied to UnityPlayer.dll@SeppNei: What does it send/receive from
compareProtocolVersion? Is the"modified"value alsotrue?How about
"heartbeat"fromv2/login? Is that alsofalse, like on Linux?@Krock Yes, the
"modified"value is also true both ways. And"heatbeat"is again the same.Here are the mitmproxy flows: flows.zip. I replaced my email from the data, i know there is more information there but whatever, you alredy got it with the wireshark logs.
@SeppNel Thank you for the MITM logs for comparison. The Wireshark logs I got from you in private are now obsolete - the UDP traffic seems to be a custom format, and the hidden TLS information is now contained in this log file.
May I include this link in this repository, so that other people could analyze it if they want to do that? Perhaps someone finds a difference that we yet missed.
@Krock Sure, no problem. But please use this google drive link beacuse the one i shared before is from my server and right now it's not very reliable (disk failure).
The hash is sent over UDP. mitmproxy does not support this (yet), and the encryption code for those packets might be custom.
TLS data is a dead end for now. Closing until someone discovers something that's relevant.