• The Problem
• The Breakthrough
  • 1. The Salt
  • 2. The Password
• The Solution
  • The Script
• The Role of LLMs in Reverse Engineering
• Conclusion

Have you ever worked on a Guitar Pro tab, saved it, and then realized you couldn’t edit it anymore because it was “locked”? Or perhaps you downloaded a tab that was perfect but needed just one small tweak, and the author had locked it?

I recently went down a rabbit hole reverse-engineering this “protection” mechanism in Guitar Pro 8. What I found was a classic case of “security through obscurity” — and not very deep obscurity at that.

The Problem

Guitar Pro has a feature to “lock” a file. When locked, the file can be opened and played, but the editing features are disabled. If you peek inside the .gp file (which is just a ZIP archive), you’ll see a few interesting things:

1. A file named editLocked.
2. The main content Content/score.gpif is encrypted (it doesn’t have the standard XML header).

Removing editLocked isn’t enough. The app sees it’s missing, but the content remains encrypted and unreadable.

The Breakthrough

As Guitar Pro can open and play the file without ever prompting for a password, it was clear that the key to decrypt the content must be available to the application without user input. This realization led me to investigate how the application handles these files internally.

I analyzed the GuitarPro binary and its libraries, specifically libGPIO.dylib.

1. The Salt

Deep in the binary, I found a reference to a static salt used in the encryption routine. da40cc64900b617a0f72ad4e6ef42f9c

2. The Password

Tracing the assembly code for Score::setLockPwd, I found something surprising. The application reads the entire content of the editLocked file (which contains a salt and a hash of the user’s original password) and sets that string as the internal password for decryption.

So, the “password” to decrypt audio and score data isn’t what you typed. It’s the metadata file itself.

The Solution

Putting it all together, the encryption scheme is:

• Algorithm: AES-256-CBC
• Key Derivation: PBKDF2-HMAC-SHA1 (4096 iterations)
• Password: The content of editLocked (e.g., salt$hash)
• Salt: The static binary salt (da40cc...)

With this information, I wrote a Python script unlock_score.py that fully unlocks these files.

The Script

Here is the core logic of the unlocker:

STATIC_SALT_HEX = "da40cc64900b617a0f72ad4e6ef42f9c"

def decrypt_gpif(encrypted_data, password):
    salt = binascii.unhexlify(STATIC_SALT_HEX)
    # PBKDF2 with 4096 iterations
    key = hashlib.pbkdf2_hmac("sha1", password.encode(), salt, 4096, 32)
    
    iv = encrypted_data[:16]
    ciphertext = encrypted_data[16:]
    
    cipher = Cipher(algorithms.AES(key), modes.CBC(iv), backend=default_backend())
    decryptor = cipher.decryptor()
    decrypted = decryptor.update(ciphertext) + decryptor.finalize()
    
    # Decompress zlib payload
    return zlib.decompress(decrypted)

You can find the full tool on GitHub Gist.

The Role of LLMs in Reverse Engineering

A fascinating part of this project was using an LLM to accelerate the reverse engineering process. While tools like otool and grep provided the raw data, the AI acted as a “force multiplier”:

• Reading Code at Scale: The most daunting part of reverse engineering is the sheer volume of information. A binary dump can contain millions of lines of assembly instructions. For a human, “reading” this to build a mental model of the software’s behavior is a task that takes days or weeks. The LLM, however, could digest these massive text dumps instantly.
• Semantic Understanding: It didn’t just match patterns; it understood the intent of the low-level code. By analyzing the context around function calls (like AES_encrypt or setLockPwd), the AI could infer high-level logic—such as identifying that the password was being sourced from file metadata—without us having to manually trace every register.
• Time Compression: This ability to essentially “read” the binary allowed us to bypass the tedious manual tracing phase entirely. We could ask high-level questions about the software’s behavior and get answers derived from the raw assembly, compressing what would be an “forever” task for a human into a quick conversation.

This collaboration turned what could have been a multi-day debugging session into a targeted, systematic investigation.

Conclusion

This exercise showed that the “lock” feature in Guitar Pro is effectively just a UI flag backed by a fixed-key obfuscation. It prevents casual editing but offers no real security against someone determined to access the data.

Disclaimer: This information is for educational purposes only. Always respect copyright and the wishes of content creators.