Bug when converting between UNIX Timestamp and Windows Filetime

[atlsor]

Describe the bug See attached picture - Wrong timestamp when converting between UNIX Timestamp and Windows Filetime.

To Reproduce See picture

Desktop (if relevant, please complete the following information):

• OS: MAC OS
• Browser: Chrome 101.0.4951.54
• CyberChef version: Version 9.37.3

Additional context

[LukeSerne]

This is a smaller example that reproduces the bug. In this example, the input and output are different, while they should be the same. This only occurs when the Input/Output format on the operations is set to "Hex (little endian)". Setting them to "Hex (big endian)" or "Decimal" works fine.

The root cause is a bug in the endianness flipping inside the UNIX Timestamp To Windows Filetime implementation. This works fine as long as there is an even number of hexadecimal digits, but it discards the most significant digit if there is an odd number of hexadecimal digits.

https://github.com/gchq/CyberChef/blob/master/src/core/operations/UNIXTimestampToWindowsFiletime.mjs#L76-L82

The easiest fix would probably be to pad result to an even length with 0s before doing the endianness swap. Something like

if (result.length % 2 != 0) {
    result = result.padStart(result.length + 1, "0");
}