Issue with endianness in type::GUID

[d-Rickyy-b]

While writing a new pattern for keepass kdbx files I wanted to display a specific value of the keepass db file as UUID. KeePass uses specific CipherIDs for the used encryption algorithm. The known value for AES256-CBC is 31c1f2e6-bf71-4350-be58-05216afc5aff.

I was a bit irritated to find another value in the header:

base64: McHy5r9xQ1C+WAUhavxa/w==
hex: 0x31, 0xC1, 0xF2, 0xE6, 0xBF, 0x71, 0x43, 0x50, 0xBE, 0x58, 0x05, 0x21, 0x6A, 0xFC, 0x5A, 0xFF

wanted: 31c1f2e6-bf71-4350-be58-05216afc5aff
got:    e6f2c131-71bf-5043-be58-05216afc5aff
diff:	________ ____ ____

I checked back with two different sources and the uuid generated by imhex is definitely wrong. It seems like the endianness is not considered here:

https://github.com/WerWolv/ImHex-Patterns/blob/c0c117ac1960c3df811763a4a485b859d876bdaf/includes/type/guid.pat#L33-L37

Changing the endianness from le to be fixes the issue:

35,37c35,37
< 	            le u32(guid.time_low),
< 	            le u16(guid.time_mid),
< 	            le u16(guid.time_high_and_version),
---
> 	            be u32(guid.time_low),
> 	            be u16(guid.time_mid),
> 	            be u16(guid.time_high_and_version),

[paxcut]

the problem is not in the include file. when your input file is not the default endianess (little) you need to specify the ebdianess either globally or per variable. in this case if the array of hex values is as shown above and at location zero. the following pattern will display it correctly

#include "type/guid.pat"


be type::GUID id @0;

[d-Rickyy-b]

when your input file is not the default endianess (little)

The keepass db files are little endian. I just found an article stating the following:

"In an RFC 4122 UUID, the bytes are stored in the same order as you see presented in the string representation. This is often called network byte order, or big-endian order. In a GUID, the order of the bytes are reversed in each grouping for the first 64 bits and stored in little-endian order."

There are also other people out there with endian issues related to uuids. I assume that my issue basically is UUID vs GUID.

#include "type/guid.pat"


be type::GUID id @0;

That works like a charm, thank you!

[paxcut]

GUID is also a Microsoft format and the define it as

typedef struct _GUID {
  DWORD Data1;
  WORD  Data2;
  WORD  Data3;
  BYTE  Data4[8];
} GUID;

So the endianess is arch dependent which does not follow the UUID convention (always big endian). Wanting to allow both of them to exist, ImHex gives you the option to choose by adding be or le before the variable.

[d-Rickyy-b]

Since I found the solution for my case as described in an earlier comment, I'll close this issue.