https://github.com/albertz/PyCParser/blob/master/demos/disse...
Would be nice if they moved to storing diff sidecars.
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)
And, as a bonus, creating, say, a filesystem implementation is now often as easy as copy/pasting existing C structure definitions, either from the original source (which is usually C) or from reversing tools such as IDA/Ghidra.
There’s no right or wrong way in my opinion, just preferences.
C structs seem less bad than python structs, so why not use them? Especially why write a struct parser and create a DSL for it, when there's already one that you can use that uses a well known DSL you might already understand.
The library used in the author's post seems perfectly readable to me, enough that it didn't even register until I read your comment. Could it be tweaked slightly to not use C syntax? Sure, but it's still going to need roughly the same pattern of identifier + type (including size). Types in C are straightforward so long as you don't have functions/pointers (which have the "inside out" problem, but they're not needed for binary encodings), so you're going to be looking at pretty trivial changes to syntax. Certainly not enough to warrant this level of quibbling.
But yeah, while I think the `cstruct` helper function to describe a binary data layout in Python is more elegant than the builtin alternatives, it would have been much less painful to just go with a minimal C command line program (or any other programming language where a struct directly maps to memory). Python and most other scripting languages have been built for manipulating text data, but suck when working with binary data.
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.
Disk images are supposed to function as if they're attached storage I think, and have different properties from what FS you're running on boot or your home folder (which themselves can be different, I run my home folder on my main Mac off a NAS via iSCSI). I'm not sure any underlying FS would avoid a copy operation there in general?