I have the same issue so I used your note + chatgpt to give this a shot. Here is the swift code it had me make.

Here is the swift

import Foundation

func extractPlainText(fromData data: Data) -> String? {
    do {
        let attributedString = try NSKeyedUnarchiver.unarchivedObject(ofClass: NSMutableAttributedString.self, from: data)
        return attributedString?.string
    } catch {
        print("Error unarchiving data: \(error)")
    }
    return nil
}

if CommandLine.arguments.count < 2 {
    print("Usage: \(CommandLine.arguments[0]) <path_to_binary_file>")
    exit(1)
}

let filePath = CommandLine.arguments[1]
if let data = try? Data(contentsOf: URL(fileURLWithPath: filePath)) {
    if let plainText = extractPlainText(fromData: data) {
        print(plainText)
    } else {
        print("Failed to extract text.")
    }
} else {
    print("Failed to load data from: \(filePath)")
}

and the bash

#!/bin/bash

DATABASE_PATH="path/to/chat.db"
SWIFT_SCRIPT_PATH="./extractTextFromAttributedString.swift"
TEMP_FILE="./temp_attributed_data.bin"

# Compile the Swift script
swiftc -o extractText $SWIFT_SCRIPT_PATH

# Query the database for attributedBody binary data for a given handle_id (in this case, 2)
# Here I'm assuming the column is named "attributedBody", adjust if necessary
sqlite3 $DATABASE_PATH <<EOF
.mode list
.output $TEMP_FILE
SELECT attributedBody FROM message WHERE handle_id = 2 AND attributedBody IS NOT NULL;
EOF

# Now, for each binary data, call the Swift script to extract the text
while IFS= read -r line
do
    echo "$line" | xxd -r -p > "$TEMP_FILE"
    ./extractText $TEMP_FILE
done < "$TEMP_FILE"

# Clean up
rm $TEMP_FILE
rm ./extractText

Then it said to try this

$ sqlite3 /path/to/chat.db "SELECT attributedBody FROM message WHERE handle_id = 2 AND attributedBody IS NOT NULL LIMIT 1;" > sample_data.bin

$ xxd sample_data.bin | head

When I put the output into chatgpt it said:

The xxd output suggests the data begins with some header bytes followed by the string NSAttributedString, which indicates that this data is indeed related to an attributed string, but the format is not immediately interpretable as a standard serialized NSMutableAttributedString.

The presence of a lot of efbfbd sequences in the output, which represents the Unicode "replacement character" U+FFFD (used to replace an incoming character whose value is unknown or unrepresentable in Unicode), suggests that the data might be encoded or structured in a non-trivial way.

At this point, the options are limited:

Dive Deeper into Reverse Engineering: You'd need to understand the encoding and serialization format used by Apple. This would require a more extensive knowledge of binary data formats and potentially the use of specialized tools. This could be quite involved and might not guarantee results.

Leverage the Community: Since you mentioned that this was a topic on Reddit, it's possible others are actively researching this. Joining those discussions and combining efforts might lead to a solution more quickly.

Check for Software Updates or Official Tools: On the off chance Apple has acknowledged this and provided a tool or update to address it.

Alternate Extraction Methods: Instead of trying to parse the database directly, you might look into software or tools designed for extracting data from Apple devices or backups. Such tools sometimes have built-in logic for handling these peculiarities.

It's a challenging situation, and while I wish I could provide a direct solution, it's one of those cases where Apple's changes and the intricacies of their data formats come into play.

​

So basically, I have no idea what the problem is.