0

I am trying to understand how to read iOS notes files as they are saved in the NoteStore.sqlite database in the iOS backup.

Here are some sample files. Each file is a different note. I want to get only the text out of it but can't figure out how.

I already understand that the textual part of the note is seperate from other parts (like links, pictures etc.) Can't find the length field so I can get the textual part.

When the note is shorter than 256 characters the 14th byte is the length. But when it's longer, I can't figure it out.

Can anyone reverse this?

| improve this question | |
  • Are you sure those are not just sqlite files? If they are, there are plenty of libraries to parse this file format and there's no need to reverse engineer it. – NirIzr Jan 13 '17 at 17:33
2

You are right about the 14th byte being the length on (some) short notes, like your file 4:

00000000  08 00 12 d6 02 08 00 10 00 1a cf 02 12 1b 54 68   ..............Th
00000010  69 73 20 6e 6f 74 65 20 69 73 20 74 68 65 20 66   is note is the f
00000020  69 72 73 74 20 6f 6e 65 20 1a 10 0a 04 08 00 10   irst one .......
00000030  00 10 00 1a 04 08 00 10 00 28 01 1a 10 0a 04 08   .........(......

However, this is not always the case; in your file 9, which is even shorter, the length, at first glance, is at position 26, with the text after that:

00000000  08 00 12 81 01 08 00 10 00 1a 7b 12 17 d7 90 d7   ..........{.....
00000010  91 d7 90 0a d7 92 d7 93 d7 94 0a 31 32 33 34 35   ...........12345
00000020  36 37 38 39 1a 10 0a 04 08 00 10 00 10 00 1a 04   6789............

and observing closely, you can see that in longer files, the text starts one byte behind that:

00000000  08 00 12 c5 07 08 00 10 00 1a be 07 12 ac 02 49   ...............I
00000010  6e 67 72 65 64 69 65 6e 74 73 20 0a 0a 32 20 63   ngredients ..2 c

The reason for this is that the length is coded in a special format: if the byte has its low order bit clear, then the byte is the length itself. If the high order bit is set, take only the low 7 bits, and prepend the next byte before that. For example, ac 02:

1010 1100 0000 0011       => remove 1st bit from 1st byte and prepend 2nd byte
0000 0011 010 1100        => fill a 0 bit from the left and write in standard nibble notation
0000 0001 1010 1100       => this is 1AC hex, or 428 bytes, which is the length of the note

It seems that the length of the file (minus some header) is encoded in the same way starting at position 11. This explains why file 9 is different: it's the only one short enough to have a length < 0x80 (0x7b), so it needs only one byte here, so everything else is shifted left one byte.

And actually, I guess that the "first glance" was wrong; the real length of note 9 is 23 (hex 17), and it consists of 2 lines of 3 unicode characters each (utf-8? This translates those bytes to hebrew characters, or maybe integers in the same encoding as above, yielding unicode code points), ended with a newline, and it's an unfortunate coincidence that the 0a newline looks like the length byte for the numbers.

So, to extract the text, seek to position 11, read a number which can be 1 or 2 bytes according to above, skip one byte which should be 12, read the length of 1 or 2 bytes, then read the text. Actually, i suspect that bytes 4 and 5 are some integer as well; so maybe you should start with byte 4 and adjust the offsets depending on whether it has bit 8 set or not.

| improve this answer | |
  • can you check note 8. it should result with a length of 0x919 and by your way i get 0x999. – Nlandau Jan 14 '17 at 11:14
  • o.k first let me say: EXCELLENT WORK! secondly, you have some typoes which caused me to make a bad calcullation. but now i've got it. thank you very much! – Nlandau Jan 14 '17 at 11:30
  • typeoes: "if the byte has its low order bit clear" should be "high order bit clear", instead of AC 02 you did AC 03. – Nlandau Jan 14 '17 at 11:34
  • BTW note 9 does have hebrew letters :) – Nlandau Jan 14 '17 at 11:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.