Dissecting Apple's Sparse Image Format (ASIF)
schamper.dev
Dissecting Apple's Sparse Image Format (ASIF)
1–10 of 25 posts
Re: Dissecting Apple's Sparse Image Format (ASIF)
#2My other question is why does it take so long to copy an app out of a dmg and into /Applications. Like, just change some pointers to pointers to data on disk and shit.
Re: Dissecting Apple's Sparse Image Format (ASIF)
#3I like a good jaunt with IDApro as much as the next RE, but my question is what does ASIF do that Qcow2 doesn't? My other question is why does it take so long to copy an app out of a dmg and into /Applications. Like, just change some pointers to pointers to data on disk and shit.
Mount natively in macOS
> why does it take so long to copy [...] out of a dmg
Compression mostly. DMG contents can optionally be compressed using zlib, lzfse, or slow as molasses bzip2.
Also Gatekeeper.
Re: Dissecting Apple's Sparse Image Format (ASIF)
#4I like a good jaunt with IDApro as much as the next RE, but my question is what does ASIF do that Qcow2 doesn't? My other question is why does it take so long to copy an app out of a dmg and into /Applications. Like, just change some pointers to pointers to data on disk and shit.
> what does ASIF do that Qcow2 doesn't Mount natively in macOS > why does it take so long to copy [...] out of a dmg Compression mostly. DMG contents can optionally be compressed using zlib, lzfse, or slow as molasses bzip2. Also Gatekeeper.
Re: Dissecting Apple's Sparse Image Format (ASIF)
#5Re: Dissecting Apple's Sparse Image Format (ASIF)
#6Re: Dissecting Apple's Sparse Image Format (ASIF)
#7I have to admit that using C syntax as a string to parse something from Python is definitely a choice. I'm not even sure I would use C structs to lay things out in C…
Re: Dissecting Apple's Sparse Image Format (ASIF)
#8I have to admit that using C syntax as a string to parse something from Python is definitely a choice. I'm not even sure I would use C structs to lay things out in C…
import sys
import struct
from collections import namedtuple
# Bake the layout once into a reusable, precompiled object.
HEADER = struct.Struct(">4sIIIQQ16sQQIIII")
# struct only knows positions, not names — pair it with a namedtuple
# to recover the named-field access that cstruct gives you for free.
Header = namedtuple("Header", [
"magic", "field4", "field8", "fieldC",
"field10", "field18", "field20",
"field30", "field38",
"field40", "field44", "field48", "field4C",
])
with open(sys.argv[1], "rb") as fh:
header = Header._make(HEADER.unpack(fh.read(HEADER.size)))
print(header)
To me, this seems significantly less readable... less Pythonic, even. The printed output is also less readable.Re: Dissecting Apple's Sparse Image Format (ASIF)
#9I have to admit that using C syntax as a string to parse something from Python is definitely a choice. I'm not even sure I would use C structs to lay things out in C…
I asked an LLM to rewrite it for me using the Python built-in struct module, and it gave me this: import sys import struct from collections import namedtuple # Bake the layout once into a reusable, precompiled object. HEADER = struct.Struct(">4sIIIQQ16sQQIIII") # struct only knows positions, not names — pair it with a namedtuple # to recover the named-field access that cstruct gives you for free. Header = namedtuple(…
Re: Dissecting Apple's Sparse Image Format (ASIF)
#10I have to admit that using C syntax as a string to parse something from Python is definitely a choice. I'm not even sure I would use C structs to lay things out in C…
in video/image space most code we deal with day to day is still C, lots more rust plugins in gstreamer ecosystem, but 90%+ still C