cannot read opcode 0x0, but next byte is a string opcode

[svaningelgem]

Attached you'll find a charles proxy dump of a session which is basically a Session object serialized.
I'm trying to load this in so I can read it in a python-way.

However, I think the reader is wrong somewhere because when your library wants to read alpnProtocol, it fails with RuntimeError("Unknown OpCode in the stream: 0x0 (at offset 0x967)"). But when going to check the actual binary data, I can see the next byte is 0x74 (string-opcode).

So my best guess is that the reader peeked somewhere and didn't advance the file pointer?
Or that a certain object has a 0x0 "closing opcode" or so?

I hope you could have a look at this and fix the issue at hand.

github.zip

---

EDIT1: when checking the code, I saw that `"actualPort"` was a very weird number, so I advanced the file pointer. And lo-and-behold, the `actualPort=443`. So the filepointer is already wrong there.

---

EDIT2: I think I found the place:

Reading field: Ljava/util/List; - children
                  OpCode: 0x70 -- TC_NULL (at offset 0x8EB)
                * L children: None

Inside the binary it looks like: 0x70 (null) 0x78 (endblock)
I don't know what object needs to read that endblock, but that one is skewing the further reading of the file.

[svaningelgem]

Ok, I think I found why:

Java code

import java.io.*;
import java.util.List;

class SuperClass implements Serializable {
    private List<String> superItems = null;

    private void writeObject(ObjectOutputStream out) throws IOException {
        out.defaultWriteObject();
        // Custom serialization logic that triggers SC_WRITE_METHOD flag
        out.writeUTF("custom_marker");
    }

    private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
        in.defaultReadObject();
        // Custom deserialization logic
        String marker = in.readUTF();
        System.out.println("Read custom marker: " + marker);
    }
}

class CustomClass extends SuperClass {
    private static final long serialVersionUID = 1L;

    private String name;
    private List<String> items = null;
    private int port = 443;

    public CustomClass(String name) {
        this.name = name;
    }

    private void writeObject(ObjectOutputStream out) throws IOException {
        out.defaultWriteObject();
        // Custom serialization for child class too
        out.writeInt(42);
    }

    private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
        in.defaultReadObject();
        int customValue = in.readInt();
        System.out.println("Read custom value: " + customValue);
    }

    @Override
    public String toString() {
        return "CustomClass{name='" + name + "', items=" + items + "', port=" + port + "}";
    }
}

public class SerializationExample {
    public static void main(String[] args) {
        try {
            // Create and serialize
            CustomClass obj = new CustomClass("test");
            System.out.println("Original: " + obj);

            // Serialize to file
            try (ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("data.ser"))) {
                oos.writeObject(obj);
            }

            // Deserialize from file
            try (ObjectInputStream ois = new ObjectInputStream(new FileInputStream("data.ser"))) {
                CustomClass deserialized = (CustomClass) ois.readObject();
                System.out.println("Deserialized: " + deserialized);
            }

        } catch (IOException | ClassNotFoundException e) {
            e.printStackTrace();
        }
    }
}

I think when the class implements a custom reader/writer, you can't combine everything in this metalist, but need to handle the superclasses first, including the 0x78 marker.

Only afterwards you can read the fields from the derived class.

[tcalmant]

Hi
Thanks for the issue description and fix proposal. I'm busy this week, I'll try to check it the next one.

[tcalmant]

This was fixed by #61, which you contributed: the class hierarchy is now read
one level at a time, each with its own block data and its TC_ENDBLOCKDATA.
The repro you gave came with it, as Issue60CustomReaderEndblock.java /
tests/issue60_custom_reader_endblock.ser, and is checked by
tests/test_v1.py::TestJavaobjV1::test_read_custom, which passes on master.

I have rechecked with the session file you attached here: the
Unknown OpCode in the stream: 0x0 it used to fail on is gone.

That file did not load completely yet, but for two unrelated reasons, both
now fixed and waiting on their own pull requests:

• RuntimeError: Unknown OpCode in the stream: 0x8 ? #30, a LinkedHashMap whose block data was read twice by v1 -> Fixed the reading of LinkedHashMap in v1 and v3 #70
• After fixing #60, I noticed that it fails with invalid references (in v2) #62, arrays which were given a reference handle but never stored -> Fixed the reading of arrays referenced more than once in v2 #72

With those, v1 and v2 read your session from end to end.

Closing this one, thanks again for the report and the fix.