Bug when converting between UNIX Timestamp and Windows Filetime
atlsor opened this issue · comments
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
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.
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");
}