[justinclift]

Reading through that, it seems like Mendeley uses SQLite for it's local database.

There aren't that many SQLite encryption libraries around (generalising), so it's probably using either SQLCipher or SEE.

https://www.zetetic.net/sqlcipher

https://www.sqlite.org/see/doc/trunk/www/index.wiki

There's a reasonable chance the page size and passphrase is stored or cached on the machine. If someone (not me) takes the time and effort to trace through the application, it should be feasible to figure out what's going on. :)

[Lord_Nightmare]

They're using SEE, see https://eighty-twenty.org/2018/06/13/mendeley-encrypted-db

[shittyadmin]

Unfortunately here's the catch - while it's probably trivial to reverse engineer enough to extract the key for the SEE database, it means that Zotero would need an SEE license to be able to handle the file still.

As an alternative it should be quite possible to produce a hook using Frida or similar that would disable database encryption on the Mendeley side so it can be imported through the usual channels. Not pretty though.

[shittyadmin]

Yeah, this sounds like an interesting reverse engineering challenge, do you need any special accounts to use Mendeley or can it be freely installed by anyone? It'd likely just be a hard-coded key, you wouldn't want to restrict people from copying their own databases around... probably.

[dunham]

I did this a while back with dropbox (I was curious about their database structure).

I ended up adapting some code that scans an OSX process for AES key schedules and prints any keys that it finds (caveat - sqlite3 rolls its own AES and the key schedule ends up byte-swapped in memory).

I also had to write some Go code to decrypt the sqlite3 database file. There is code to read an encrypted database buried in sqlite3's revision history, but it's an old enough version of sqlite3 that it didn't understand dropbox's schema.