XML for C!

delfinom

So I am dealing with reading in some to remained unnamed companies proprietary data format they totally don't realize I broke the encryption on because fucking XOR ciphers are not encryption in the 21st century.

These files describe the layout of a devices memory, i.e. addresses to item along with what type it is, size, etc.
Now thats all well and dandy right?

Hahahahahaha

First off they literally wrote it like defining C structs (I think they may even use it to generate their C structs for memory usage). For those that don't know. in C you define a struct which is like a collection of variables

struct blah
{
int member1;
int member2;
}

and the compiler will more or less group the variables together in memory which is useful in many situations.

So my goal here was to obtain the individual addresses of each struct member.

Starting off, their format is roughly like this:

<struct name="blah">
<member>
<name />
<type />
<length />
</member>
<member></member>
</struct>

So first wtf, you have to compute address of each member based on the address of the struct + previously used lengths of members as they do not put individual addresses. Ok, slightly annoying but ok, they have a map definition for some reason that puts the struct address outside the struct member entirely, also annoying but ok.

<map>
<symbol name="struct name" address="0x00">
</map>

But then suddenly they decide, lets put a struct inside a struct!

<struct name="blah">
<member>
<name />
<type />
<length />
</member>
<member></member>

Ok, slightly more annoying but as long as they define the base address in the map its fine? NO. They may or may not define the base address of the sub struct and so you have to pass the parent address in your recursion logic. (Because C would pack the structs inside structs to be in sequential addresses just like normal variables)

FINE FINE FINE FUCK.

Ok, continuing on....WHAT IF WE PUT DATA ITEMS OUTSIDE STRUCTS AND THUS IN FACT GIVE SOME DATA ITEMS ADDRESSES THAT MAY OR MAY NOT BE IN THE MAP!!!!

    <member>
    <name />
    <type />
    <length />
    </member>
    <struct name="blah">
    <member>
    <name />
    <type />
    <length />
    </member>
    <member></member>
   <struct name="blah2">
   </struct>
    </struct>

OMG, FINE RECURSION WILL SOLVE THIS.

BUT WHAT IF WE SPLIT THE STRUCT AMONG TWO FILES AND YOU HAVE TO READ THEM IN THE RIGHT ORDER TO COMPUTE THE OFFSET OF EACH STRUCT MEMBER CORRECTLY

gun in mouth

antiquarian

XML is like violence. If it isn't solving your problem yet, you're not using enough of it.

ScholRLEA

@antiquarian said:

> XML is like violence. If it isn't solving your problem yet, you're not using enough of it.

... and it is likely to get you hurt sooner or later.

accalia

@antiquarian said:

XML is like violence. If it isn't solving your problem yet, you're not using enough of it.

Maxim #6: If violence wasn’t your last resort, you failed to resort to enough of it.

delfinom

This post is deleted!

delfinom

I am so so glad they didn't implement a <union>

Vaire

Jesus Tap-dancing Christ! You're giving me PTSD flashbacks to my time with Enterprisey-XML. Make it stop. Make it stooooop. [whimper]
o_O

delfinom

https://what.thedailywtf.com/t/csv-xml/2123

Kian

@delfinom said:

BUT WHAT IF WE SPLIT THE STRUCT AMONG TWO FILES AND YOU HAVE TO READ THEM IN THE RIGHT ORDER TO COMPUTE THE OFFSET OF EACH STRUCT MEMBER CORRECTLY

gun in mouth

See, the XOR cipher was only the first step of the encryption strategy. The goal of encryption is not to be impossible to crack, but to make the attacker give up before then. Rather than make you waste a computer's time trying to crack it, they hope to get the attacker to kill themselves. Dastardly clever.

The implementers probably already killed themselves after being asked to maintain what they had created, preserving the secret forever.