Use base64 --decode on the command line? It’s part of coreutils, so should be on just about every linux box on the planet. If you’re not using Linux… somebody else might pipe up. /-:
base64 --help
Usage: base64 [OPTION]... [FILE]
Base64 encode or decode FILE, or standard input, to standard output.
With no FILE, or when FILE is -, read standard input.
Mandatory arguments to long options are mandatory for short options too.
-d, --decode decode data
-i, --ignore-garbage when decoding, ignore non-alphabet characters
-w, --wrap=COLS wrap encoded lines after COLS character (default 76).
Use 0 to disable line wrapping
--help display this help and exit
--version output version information and exit
The data are encoded as described for the base64 alphabet in RFC 4648.
When decoding, the input may contain newlines in addition to the bytes of
the formal base64 alphabet. Use --ignore-garbage to attempt to recover
from any other non-alphabet bytes in the encoded stream.
GNU coreutils online help: <http://www.gnu.org/software/coreutils/>
Full documentation at: <http://www.gnu.org/software/coreutils/base64>
or available locally via: info '(coreutils) base64 invocation'
Unfortunately, if you’re already getting base64 data in the quarantine export you’re not going to be able to turn this into human readable data. Most data types should be converted before going into export in 7.9.4, but it looks like this might be a generic INSERT/UPDATE that we’re not sure how to deserialize?
You can create a new DB connection, copy over the HSQL db files (in the /datacache/<database name> directory in the installation folder), then retry the records and see what it tries to push into the database.
That’s the only way to force these records to deserialize and unpack. Even the data stored in the HSQL db is an (encrypted) BLOB, so it’s not human readable.
Thanks a lot guys, it’s been enlightening.
Just out of curiosity, any idea why some data gets saved as a BLOB and some other data gets saved in human readable form when exporting?
Is there any way to see where these queries are coming from or going to (table in addition to database)? I have a hard time troubleshooting these in a large system.
No. The BLOB itself represents a Java object of some kind - we have to manually register them for deserialization in the export mechanism. If you get in contact with support, they may be able to help - or, at the very least, add some urgency to the ticket to make all first-party quarantine data types export-able in a friendly format.