Anyone know how the breakdown of individual child blocks changes when the conversation index starts with an additional reserved byte? Normally the conversation index only starts with 01.. sometimes however it starts with 0101 instead.
I have read online that denotes a reserved byte that isn't part of the FILETIME structure and must be omitted.. but then the child blocks after the first one seem to give me values that are sub 1 seconds in time?
For example the conversation index -
0101DA71727C814696A637E92446A36574D21F90B594B12E05C500800003D08080000079008000019680800001D50080043BDF008000043980
If the first byte is omitted, the FILETIME structure becomes a hexadecimal of 01DA71727C810000 (with the additional padding) which gives the correct date time when converted..
Then the next 16 bytes should be the GUID -
4696A637E92446A36574D21F90B594B1 but that would make the remaining child blocks 34 bytes, which doesn't make sense as they should all be 5 bytes.
If you instead move the GUID back a byte you do get 35 bytes for the remaining 7 Child blocks but even when addressing the low and the high padding of bits any child block after the first one ends up being sub 1 second which doesn't make sense.
Why is that, and how would you breakdown the bytes in the hexadecimal so it makes sense? When the conversation index starts with a single byte of 01 the conversion works just fine.