Trying to read a serialized Java object that I did not create

Question

I'm trying to create a web GUI for a Minecraft game server I run. The data I'm trying to read is from CoreProtect, a logging plugin.

I'm mainly using PHP and then trying to write a small Java service that can convert the serialized data into a JSON string that I can then use - since I can't deserialize a Java object directly in PHP and it's only some meta data that's stored as a Java serialized object, the rest is normal non-blob columns.

I've identified that the CoreProtect plugin is using ObjectOutputStream to serialize the object and then writes it to a MySQL BLOB field, this is the code I've identified from CoreProtect that's handling this:

try {
  ByteArrayOutputStream bos = new ByteArrayOutputStream();
  ObjectOutputStream oos = new ObjectOutputStream(bos);
  oos.writeObject(data);
  oos.flush();
  oos.close();
  bos.close();
  byte[] byte_data = bos.toByteArray();
  preparedStmt.setInt(1, time);
  preparedStmt.setObject(2, byte_data);
  preparedStmt.executeUpdate();
  preparedStmt.clearParameters();
} catch (Exception e) {
  e.printStackTrace();
} 

This is then outputting the bytes to the database. All of the rows in the database start with the same few characters (from what I've seen this should be Java's 'magic' header). However, when trying to use the below code to unserialize the data I receive an error stating that the header is corrupt 'invalid stream header: C2ACC3AD'

byte[] serializedData = ctx.bodyAsBytes();

ByteArrayInputStream bais = new ByteArrayInputStream(serializedData);
try {
    ObjectInputStream ois = new ObjectInputStream(bais);

    Object object = ois.readObject();

    Gson gson = new Gson();

    ctx.result(gson.toJson(object));
} catch (IOException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
} catch (ClassNotFoundException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
}

I'm using Javalin as the web service and am just sending the raw output from the BLOB column to a post route, I'm then reading this with the bodyAsBytes method. I'm tried testing this by writing the BLOB column to a file and then copying the contents of the file into a test POST request using Postman. I've also tried using a PHP script to read directly from the DB and then send that as a POST request and I just get the same error.

I've looked into this and everything is pointing to corrupt data. However, the odd thing is when triggering a 'restore' via the CoreProtect plugin it correctly restores what it needs to, reading all of the relevant data from the database including this column. From what I've seen in CoreProtect's JAR it's just doing the same process with the InputStream method calls.

I'm not very familiar with Java and thought this would be a fairly simple process. Am I missing something here? I don't see anything in the CoreProtect plugin that may be overriding the stream header. It's unfortunately not open source so I'm having to use a Java decompiler to try and see how it's serializing the object so that I can then try and read it, I assume it's possible the decompiler is not reading how this is serialized/unserialized.

My other thought was maybe the 'magic' header changed between Java versions? Although I couldn't seem to confirm this online. The specific header I'm receiving I've also seen in some other similar posts, although those all lead to data corruption/using a different output stream.

I appreciate any help with this, it's not an essential feature but would be nice if I can read all of the data related to the logs generated by the server/plugin.

I understand the use case is niche, but hoping the issue/resolution is a general Java problem :).

Update ctx is an instance of Javelin's Context class. Since I'm trying to send a raw POST request to Java I needed some kind of web service and Javelin looked easy/lightweight for what I needed. On the PHP side I'm just reading the column from the database and then using Guzzle to send a raw body with the result to the Javelin service that's running.

Answer 1

Something, apparently ctx , is treating the binary data as a String. bodyAsBytes() is converting that String to bytes using the String's getBytes() method, which immediately corrupts the data.

The first two bytes of a serialized Java object stream are always AC ED. getAsBytes() is treating these as characters, namely U+00AC NOT SIGN and U+00ED LATIN SMALL LETTER I WITH ACUTE . When encoded in UTF-8, these two characters produce the bytes C2 AC C3 AD, which is what you're seeing.

Solution: Do not treat your data as a String under any circumstances. Binary data should only be treated as a byte stream. (I'm well aware that it was common to store bytes in a string in C, but Java is not C, and String and byte[] are distinct types.)

If you update your question and state what the type of ctx is, we may be able to suggest an exact course of action.