Re:Reverse Engineering Apple Location Services Protocol
by shabble on Wednesday May 10, 2017 @02:03PM
(#14310223)
Although it looks like all the interesting content is in the protobuf payload, it looks like the header might not be the NUL-delimited/ASCII control char sequence the author inteprets it as.
Unless it's coincidence, each of the string portions is prefixed by its length in bytes. Since they're all so short[1], it's not obvious if they're 1,2 or 4 byte lengths, or if those are just padding or other flag bytes. It smells almost like the binary plist format[2], but doesn't seem to obviously decode.
This is just casual inspection of only the sequences in the article, so might be wildly wrong, and probably irrelevant.
Brute-forcing the protobuf message without the schema surprisingly effective here though. I didn't realise it left as much structure in there.
Re:Reverse Engineering Apple Location Services Protocol
by tuupola on Wednesday May 10, 2017 @11:20PM
(#14313630)
You are correct. I have not tested this yet, but they are most likely strings prefixed with their lengths. I was trying to be too smart and assumed they used ASCII control characters.
Unless it's coincidence, each of the string portions is prefixed by its length in bytes. Since they're all so short[1], it's not obvious if they're 1,2 or 4 byte lengths, or if those are just padding or other flag bytes. It smells almost like the binary plist format[2], but doesn't seem to obviously decode.
This is just casual inspection of only the sequences in the article, so might be wildly wrong, and probably irrelevant.
Brute-forcing the protobuf message without the schema surprisingly effective here though. I didn't realise it left as much structure in there.
[1] NPI
[2] https://synalysis.com/how-to-decode-apple-binary-property-li...