11 ms·

> Why did they conclude the second field was a message type rather than just a string? Strings and messages are isomorphic on the wire. Presumably its contents

> Why did they conclude the second field was a message type rather than just a string? Strings and messages are isomorphic on the wire. Presumably its contents. The included protobuf-inspector output shows it's a valid submessage, including length-delimited fields having valid lengths. A two-deep string matches the expected title. The tag numbers are also in order, which adds plausibility. (Tags aren't required to be in a particular order but IIRC the stock implementations in most languages output them in ascending tag number order for known fields.) This is pretty strong evidence. If it's not strong enough for you, reverse engineering might not be your thing. That's okay. Nit: message is isomorphic with bytes, not string. string has the additional restriction of being valid UTF-8. I didn't check, but I wouldn't be surprised if field 2 is not a valid string.

jeffbee 6y ago
Right but the fact that a bytes can be decoded as a message doesn't mean that's how it's declared in the proto. Sometimes a message will have `bytes opaquemsg = 42;` when an application wants to proxy through a nested protocol message, but without caring about the contents. What I'm getting at is the article has arrived at one of many possible proto files that could be the one the app actually uses.
- scottlamb 6y ago
  They're reverse engineering the program from its effects (the files it reads and writes). It's not possible to exactly duplicate the original program's source code in that manner, nor is it necessary. When there are two indistinguishable approaches—in this case representing something as a message in the .proto vs representing it as bytes and later decoding it separately as a message—it makes more sense to choose the simpler way.
- thesnarky1 6y ago
  You're absolutely right that this is not supposed to be a 100% correct representation of the protobuf, which I tried to capture in a few places, including the conclusion. There's some hand-wavy magic in this article, which was written months after doing the actual work. One aspect of that is I made a lot of test data and while yes, it could be any number of things, dealing with Occam's razor meant as I saw what looked like a message type (and not just a byte sequence which represented many other potential protobufs) I went with that as the conclusion. That conclusion seemed to hold as I test many other, more complicated notes generated from different types of devices. Hence why I present it here as a message. But, yes, you're absolutely right that this is not the protobuf definition used by Apple (which is copyrighted) and there is certainly information missing from it. My goal was simply to be able to recover what I see on the Apple device's screen.

jeffbee 6y ago

Right but the fact that a bytes can be decoded as a message doesn't mean that's how it's declared in the proto. Sometimes a message will have `bytes opaquemsg = 42;` when an application wants to proxy through a nested protocol message, but without caring about the contents. What I'm getting at is the article has arrived at one of many possible proto files that could be the one the app actually uses.

scottlamb 6y ago
They're reverse engineering the program from its effects (the files it reads and writes). It's not possible to exactly duplicate the original program's source code in that manner, nor is it necessary. When there are two indistinguishable approaches—in this case representing something as a message in the .proto vs representing it as bytes and later decoding it separately as a message—it makes more sense to choose the simpler way.
thesnarky1 6y ago
You're absolutely right that this is not supposed to be a 100% correct representation of the protobuf, which I tried to capture in a few places, including the conclusion. There's some hand-wavy magic in this article, which was written months after doing the actual work. One aspect of that is I made a lot of test data and while yes, it could be any number of things, dealing with Occam's razor meant as I saw what looked like a message type (and not just a byte sequence which represented many other potential protobufs) I went with that as the conclusion. That conclusion seemed to hold as I test many other, more complicated notes generated from different types of devices. Hence why I present it here as a message. But, yes, you're absolutely right that this is not the protobuf definition used by Apple (which is copyrighted) and there is certainly information missing from it. My goal was simply to be able to recover what I see on the Apple device's screen.