A deep dive into Apple's .car file format
1–10 of 73 posts
Re: A deep dive into Apple's .car file format
#2Looks very much like a format that should just have been gzipped JSON.
Don't use binary formats when it isn't absolutely needed.
Re: A deep dive into Apple's .car file format
#3This is cool work. However, the author claims the following:
> This knowledge could be useful for security research and building developer tools that does not rely on Xcode or Apple’s proprietary tools.
Yes it could be. But if you developed it for such altruistic purposes, why tease the code?
> I’m considering open-sourcing these tools, but no promises yet!
Maybe OOP is thinking of selling their reverse engineering tools? Seems like that’s still a proprietary tool, I’m just paying someone else for it
Re: A deep dive into Apple's .car file format
#4Looks very much like a format that should just have been gzipped JSON. Don't use binary formats when it isn't absolutely needed.
Uh. You want to store assets in JSON? Why? You generally want asset packs to be seekable so that you can extract just one asset, and why would you want to add the overhead of parsing potentially gigabytes of JSON and then, per asset, decoding potentially tens of megabytes of base64?
Re: A deep dive into Apple's .car file format
#5Looks very much like a format that should just have been gzipped JSON. Don't use binary formats when it isn't absolutely needed.
... and that is why all 'modern' software is incredibly memory and CPU intensive...
Re: A deep dive into Apple's .car file format
#6Looks very much like a format that should just have been gzipped JSON. Don't use binary formats when it isn't absolutely needed.
Uh. You want to store assets in JSON? Why? You generally want asset packs to be seekable so that you can extract just one asset, and why would you want to add the overhead of parsing potentially gigabytes of JSON and then, per asset, decoding potentially tens of megabytes of base64?
Keep all the meta info in JSON and then the big binary files in a zip file. Much easier to parse.
Re: A deep dive into Apple's .car file format
#7Looks very much like a format that should just have been gzipped JSON. Don't use binary formats when it isn't absolutely needed.
... and that is why all 'modern' software is incredibly memory and CPU intensive...
But when things go wrong, you can usually find some random json file and adjust it :)
Re: A deep dive into Apple's .car file format
#8Looks very much like a format that should just have been gzipped JSON. Don't use binary formats when it isn't absolutely needed.
Uh. You want to store assets in JSON? Why? You generally want asset packs to be seekable so that you can extract just one asset, and why would you want to add the overhead of parsing potentially gigabytes of JSON and then, per asset, decoding potentially tens of megabytes of base64?
> You want to store assets in JSON? Why?
Why not have both options? .gltf and .glb being possible for assets been more than helpful to me more than once, having the option gives you the best of both worlds :)
Re: A deep dive into Apple's .car file format
#9Looks very much like a format that should just have been gzipped JSON. Don't use binary formats when it isn't absolutely needed.
Strong disagree. I like binary formats because I can just fopen(), fseek() and fread() stuff. I don't need json parser dependency, and don't need to deal with compression. Binary formats are simple, fast and I need a way smaller buffer to read/write them normally. I don't like wasting resources.
Re: A deep dive into Apple's .car file format
#10Idea: pass the decompiled code through a "please rename variables according to their purpose" step using a coding agent. Not ideal, but arguably better than v03, v20. And almost zero effort at this time and age.