Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adding macos support to save files #33

Merged
merged 2 commits into from
Jan 13, 2024

Conversation

alejandrocfdev1
Copy link

Was bored last night and tried to make this API work with MacOS devices too.

With this change, the API will now also be able to decrypt MacOS GD save files

@alejandrocfdev1 alejandrocfdev1 force-pushed the feature/macos_save_support branch from 4ed04a0 to 5a61788 Compare December 27, 2023 02:41
@Folleach
Copy link
Owner

Thank you for pull request!
The implementation looks interesting, I didn't know that Mac fully encrypts the file, unlike Windows and Android :)

But now I don't have Mac OS on device or virtual machine, that's why I can't check it now.
Can you make a small .dat up to 4 KB from mac and add this file to the data folder for tests?
Here: https://github.com/Folleach/GeometryDashAPI/tree/master/GeometryDashAPI.Tests/data/saves

It would be good if there were several tests:

  • File loaded correctly
  • Load then save shouldn't corrupt data
    In the case of AES, the same data seems to generate the same bytes

Tests can be added here: https://github.com/Folleach/GeometryDashAPI/blob/master/GeometryDashAPI.Tests/GameDataTests.cs

If you can't do it, I can check it myself and write tests a little later, I think in the next week

The library also implies execution on any operating system with any types of files.
So, for example, someone can write an application for Linux on which they would like to process files for Mac OS
In this regard, the code

if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
    ...

in methods GetFileContent and LoadAsync is looks suspicious.
Because applications on Mac will not be able to unpack .dat files for windows and vice versa.
But this code is okay for ResolveFileName method.

I would recommend choosing the type of file reading/saving depending on its content.
Often there are headers and magic bytes at the beginning of files for this purpose

But we probably won't be able to find any magic bytes in the encrypted file, because it's just a mountain of random bytes.
So, I think we can rely on the knowledge of magic bytes for gzip. If there are any, perform reading using XOR, if not, using AES.
To save, we can make an enum, which will allow the library user to choose which option he wants to write the file.

@Folleach Folleach merged commit 00efdad into Folleach:master Jan 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants