Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse Engineering Apple's typedstream Format

chrissardegna.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: Reverse Engineering Apple's typedstream Format

#11

Post by pixel_tracing »

bengarney wrote: post #7
css wrote: post #6

Earlier quoted context omitted.

iMessage uses a very strange amalgamation of typedstream (message content), keyed archives (app messages, sticker data), and protobufs (Digital Touch, handwriting) for different features. I wonder what motivated all of those design decisions.

This is stuff is such a PIA to parse. I assume it's just different teams doing different features over the years, and being alternately repulsed/seduced by each format. Probably features are implemented as libraries so there isn't a master oversight - they aren't trying to make iMessage's internal formats follow a consistent plan, just let all the libs coexist...

As someone who used to work on that team, it’s so interesting hearing thoughts from external public on the team.

Re: Reverse Engineering Apple's typedstream Format

#12

Post by meibo »

bengarney wrote: post #7
css wrote: post #6

Earlier quoted context omitted.

iMessage uses a very strange amalgamation of typedstream (message content), keyed archives (app messages, sticker data), and protobufs (Digital Touch, handwriting) for different features. I wonder what motivated all of those design decisions.

This is stuff is such a PIA to parse. I assume it's just different teams doing different features over the years, and being alternately repulsed/seduced by each format. Probably features are implemented as libraries so there isn't a master oversight - they aren't trying to make iMessage's internal formats follow a consistent plan, just let all the libs coexist...

Maybe they should be repulsed, considering all of the journalists that are getting persecuted and/or murdered because they are getting pwned through iMessage serialization bugs :)

Re: Reverse Engineering Apple's typedstream Format

#13

Post by foobiekr »

dim13 wrote: post #9
dbyte wrote: post #5

The grandfather of protobuf. Lost in the tales of time.

Grandfather of Protobuf is ASN.1

Very much so. Pretty much all of these protocols are simplifications of asn1 and in some cases (like protobuf) there are a handful of things that got lost because the wire formats didn’t have them as they didn’t need them. A schema indicator being the single biggest flaw in protobuf.

Re: Reverse Engineering Apple's typedstream Format

#14

Post by setr »

nativeit wrote: post #3

Question from a relatively uninformed sysadmin/freelance I.T. provider—will these new iMessage functions allow for 3rd-party applications (ie—CRMs, client support platforms, etc.) to read and/or work with incoming iMessages from my iCloud account? The only thing I really miss since coming from Android was my ability to consolidate all of my client communications, many of whom send text messages first and foremost (wh…

Don’t know if it helps, but I know iMessage stores message data on MacBooks inside a SQLite file; I was scanning through it previously because I was trying to do a bulk search

Re: Reverse Engineering Apple's typedstream Format

#15

Post by wpm »

This is perfectly timed, as I wanted to find a way to programmatically modify my Mac's AppleScript display settings/theme. For whatever reason, they're stored as typedstream format, embedded in a plist in base64. Found an old implementation/header from 1999 from Mac OS X Server v1.2, signed by Bertrand Serlet, and was going to dig in when I found the time. Now I can dig into this.

Re: Reverse Engineering Apple's typedstream Format

#16

Post by css »

wpm wrote: post #15

This is perfectly timed, as I wanted to find a way to programmatically modify my Mac's AppleScript display settings/theme. For whatever reason, they're stored as typedstream format, embedded in a plist in base64. Found an old implementation/header from 1999 from Mac OS X Server v1.2, signed by Bertrand Serlet, and was going to dig in when I found the time. Now I can dig into this.

The plist is probably a binary plist (header bytes `bplist00`) generated by NSKeyedArchiver, and then the specific data you need is encoded inside. Edited iMessages are stored in the exact same way. Luckily the plist itself is not that complex–but typedstream is pesky to work with.

Re: Reverse Engineering Apple's typedstream Format

#17

Post by wpm »

css wrote: post #16
wpm wrote: post #15

This is perfectly timed, as I wanted to find a way to programmatically modify my Mac's AppleScript display settings/theme. For whatever reason, they're stored as typedstream format, embedded in a plist in base64. Found an old implementation/header from 1999 from Mac OS X Server v1.2, signed by Bertrand Serlet, and was going to dig in when I found the time. Now I can dig into this.

The plist is probably a binary plist (header bytes `bplist00`) generated by NSKeyedArchiver, and then the specific data you need is encoded inside. Edited iMessages are stored in the exact same way. Luckily the plist itself is not that complex–but typedstream is pesky to work with.

The plist is no issue, but it's the values therein where you run into typedstreams. For every setting for the Script Editor's formatting, is a separate dictionary, with an NSColor and NSFont key set to a data type value. The data is a base64 encoded `streamtyped` file. Passing it through base64 decode and running `file` on the output gives back `NeXT/Apple typedstream data, little endian, version 4, system 1000`, just as in the OP.

Re: Reverse Engineering Apple's typedstream Format

#18

Post by wpm »

wpm wrote: post #17
css wrote: post #16

Earlier quoted context omitted.

The plist is probably a binary plist (header bytes `bplist00`) generated by NSKeyedArchiver, and then the specific data you need is encoded inside. Edited iMessages are stored in the exact same way. Luckily the plist itself is not that complex–but typedstream is pesky to work with.

The plist is no issue, but it's the values therein where you run into typedstreams. For every setting for the Script Editor's formatting, is a separate dictionary, with an NSColor and NSFont key set to a data type value. The data is a base64 encoded `streamtyped` file. Passing it through base64 decode and running `file` on the output gives back `NeXT/Apple typedstream data, little endian, version 4, system 1000`, jus…

The only reason I want to do this is because I wipe a Mac nearly weekly, and need it setup more or less the same way again. I could probably just drop the .plist in that directory and bobs your uncle, but I also would change the fonts Script Editor is using to a third-party font not installed, so I don't want to have to worry about weird order of operation BS, and also find a way to set it to any arbitrary font, as I often change out the "fixed width" font I use in all the editors for that week (I have favorites, not just a favorite, gotta keep it fresh, ya know).

I figured that since Script Editor, and the AppleScript components of macOS are so old and creaky, forgotten leftovers in the Yellow Box that no one bothered to fix. I had no idea typedstreams were still being used in modern Apple software.

Re: Reverse Engineering Apple's typedstream Format

#20

Post by userbinator »

css wrote: post #6
dbyte wrote: post #5

The grandfather of protobuf. Lost in the tales of time.

iMessage uses a very strange amalgamation of typedstream (message content), keyed archives (app messages, sticker data), and protobufs (Digital Touch, handwriting) for different features. I wonder what motivated all of those design decisions.

"Those who don't understand ASN.1 are doomed to reinvent it, poorly."

That said, it could be much worse --- JSON, or XML.

Post reply on HN