Idea: 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.
A deep dive into Apple's .car file format
11–20 of 73 posts
Re: A deep dive into Apple's .car file format
#12Looks 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.
Sane for 3rd party devs
Re: A deep dive into Apple's .car file format
#13Looks 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
#14i learned a lot about lldb debugging when i went spelunking through system service process memory. eventually i got too distracted learning about runtime introspection in Swift and obj-c and ended up building a dynamic object explorer/debugger instead of accomplishing my original goal. obj-c runtime dynamism is fascinating. it’s like, “what if we make C as dynamic as Ruby”. you can invent new classes at runtime, swap method implementations, create a new class that extends a specific existing object. you can even change what class an object is.
Swift is a lot less dynamic and a lot less introspectable at runtime :-( (there is a swift reflection api called Mirror but i struggled to do anything interesting with it)
Re: A deep dive into Apple's .car file format
#15Idea: 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.
And have it hallucinate stuff? Nah, this stuff is hard enough without LLMs guessing.
Re: A deep dive into Apple's .car file format
#16This 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 t…
Re: A deep dive into Apple's .car file format
#17Idea: 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.
And have it hallucinate stuff? Nah, this stuff is hard enough without LLMs guessing.
obj-c sendmsg use makes it more similar to understanding minified JS than decompiling static c because it literally calls many methods by string name.
Re: A deep dive into Apple's .car file format
#18Looks 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
#19Looks very much like a format that should just have been gzipped JSON. Don't use binary formats when it isn't absolutely needed.
Also, it's a format designed to hold binary data. JSON can't do that without hacks like base64 encoding.
Binary file stores like this are very common in highly optimized software, which operating systems tend to be, especially if you go looking at the older parts. Windows has a similar format embedded in EXE/DLL files. Same concept: a kind of pseudo-filesystem used to hold app icons and other resources.
Re: A deep dive into Apple's .car file format
#20Earlier quoted context omitted.
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 :)