New Decoder table for Okteta

Work on Okteta has been stalled a little. My pet next big feature is also big in work needed, bigger than hoped for, so it looks like it will have it’s come-out time rather with KDE 4.3.

For some quick’n’easy success I turned to the Decoding Table tool the last evenings. As it comes with the 0.1 version of Okteta, it is pretty much inspired from the one of KHexEdit, minus the bitfield width setting:

Now with 64 bit architectures pretty much spread, one data type is missing there, 64 bit integer. Also support for UTF-8 might be useful in general. And perhaps even some more, or specific ones, one day hopefully addable by plugins.

The KHexEdit style table does not scale. So for the inclusion of the new datatypes I decided to replace it with a simple two-columned list table. Now done and committed it is, heading for the KDE 4.2 release:

Please tell me, what other decoders would you generally expect in the table?


10 thoughts on “New Decoder table for Okteta

  1. > Please tell me, what other decoders would you generally expect in the table?

    Perhaps not in the table, but would you also be able to decode a base64 string? I’d like to browse the various fields in the decoded byte array. This is very useful for me with reverse engineering the MSN protocol.

    I love your new decoding table layout btw 🙂

  2. Well, since you have space for more, I think plugins are the way to go. Simple Javascript functions probably — in comes the byte, out comes the {name : “Foo”, value: “88”} object.

  3. I can only join in on the idea of plugins, that would be a killer feature for reverse engineering memory dumps, I remember reverse engineering UltimaOnline and some datatypes were just annoying to track down because they were scrabmled

    propably very useful would be decoding of bitarrays with a identifier over every bit (aka overflow, carry, zero, negative …)

  4. What would be really cool IMHO is a (set of) plugin(s) that try to decode to the way Qt stores it’s data types through QDataStream. See for the formats.
    Since not all formats make sense in all context, maybe the list should become filter-able, or should become more like a tree so you could collapse for instance the list of possible Qt types?

  5. Not really decoder related, but: What I recently found missing is the ability to simply count the number of the selected bytes (alternatively by specifying a starting and an end point). Also mark/highlight the next x bytes from cursor position. Another useful thing would be the highlighting of line ending characters (i.e. \r\n, \r and \n), like it’s done for printable and nonprintable characters.

  6. What is the ‘Character’ field encoding in? You have a ‘utf8’ field so clearly ‘Character’ is not being parsed in utf8. Do you use the currently set locale or what?

  7. Thanks for your comments!

    @Diederik: Yes, base64 seems to be a good candidate. But not for this simple decoding table which I did more for pod types. Decoders/Encoders for more complex types will need to get a tool of their own. KDE 4.3 stuff.

    @gnud: Yes, scripting should be supported for plugins. And even for POD types it can be more than one byte 😉

    @Karsten,Andre: Interesting ideas. No promises, though. Really need to get a plugin API so that you could do this on your own 🙂

    @Michael: The selected bytes get counted by the Info tool, but only on pressing Update. Adding “Extend selection” to the Goto-Plugin is planned. Highlighting ending characters, hm, could be done, will see if I like this idea also tommorrow 🙂

    @John: Yes, Character uses the current 8bit encoding of the character column. Any good suggestion how to avoid this confusion you have?

  8. It would be nice to be able to map defined structure (in C maybe) on file at given offset. And than just browse this structure.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.