5

I want to find out the compression method used by an iOS app used for music notation to store its files. The files of its OSX counterpart are zipped files. You cannot create files in the iOS app, but you can upload them using the desktop application to the application's cloud server and from there download them to your iOS device for offline viewing. My findings so far:

  • The header of the files is 58 54 5A 00, which isn't listed in any file signatures table I have searched in
  • The usual suspects, commands file and binwalk, do not identify the format
  • The entropy histogram is flat
  • Each time I download the same file from the server to the iOS device, a file of the exact same size but with different content (apart from the header 58 54 5A 00`) gets saved.
  • Altering hex values
    • last two bytes: file is read normally by the iOS app
    • third byte from the end: app becomes unresponsive when opening the folder the file is in. Since each file is shown as a thumbnail of the musical score I suspect this byte has something to do with the thumbnail.
    • Any other random byte: thumbnail is shown correctly, app doesn't crash, but a blank page appears when the file is opened

The following files are actually all the same file downloaded from the server 4 times.

I have produced three files, the first contains "A", the second "AA", the third "AAA". The first set of files comes from iOS, the second from OSX.

.

Improve this question
5
  • Screen shot of the app where you're inputting the text. 9k for one sentence is pretty big. Try creating a file with only the letter 'a' as input, and then create another file with 'aa' as the input. How much do the two files differ in size? Then create a file with 'aaa', does it vary from file 'aa' by the same amount?
    – pythonpython
    Dec 22, 2020 at 18:13
  • I have edited the question with more information and a different set of files with screenshots . All three iOS files are exactly 4400 bytes.
    – Dimitris
    Dec 22, 2020 at 19:35
  • If you create another file with only A in it, are the byte values in that file the same as the earlier file with only A in it?
    – pythonpython
    Dec 22, 2020 at 23:26
  • First 3 bytes decode to XTZ. Is that meaningful? The byte value 0x82 (Decimal 130) occurs 16 times in each file. Can you explain the relation of these files to this app: apps.apple.com/us/app/musescore-sheet-music/id835731296 You are uploading the OSX files into the IOS App and the IOS App stores them in the mscze format?
    – pythonpython
    Dec 23, 2020 at 0:21
  • - No the byte values are not the same. I guess there is a timestamp in the file saved - The header XTZ is not meaningful, neither the byte value you mentioned - It is indeed the musescore app these files belong to - The desktop application uploads the files to musescore's servers and from there they are downloaded to the iOS device
    – Dimitris
    Dec 23, 2020 at 23:10

1 Answer 1

Reset to default
0

I think these files are encrypted rather than compressed.

I've run file at all offsets from start and found format consistent across the files at the same offset.

The files have only a constant value in the first 4 bytes. The rest is high entropy.

The same content saved at different times produces a different binary file each time.

File sizes are similar in previous instances when content was different in size, indicating padding of some sort.

I think this is may how IOS handles file security for some apps

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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