I'm not sure if this observation you made about 90% NUL characters reveals some problems. Instead, I think that also the examples have several NUL chars within the "header". I would not conclude that this is 100% a problem (did you even compare if the example have much less NUL bytes?).
I would rather suggest looking at other possibilities:
1. what type of architecture (64 bit amd, x86 32 bit, mips, arm) is used by the system
2. little or big endian
3. what file system (ext3/ext4/ntfs...) does the system use
4. does the system use keyfiles together with luks
....
as you might know hashcat makes an entropy check to verify the data. This could in theory lead to problems if the decrypted data is random (which was never the case in our testings, see https://hashcat.net/forum/thread-6225.html)
You could also try to generate a test "volume" with the instructions from here: https://hashcat.net/forum/thread-6225.html
It would also make sense that you try to generate a luks volume on a different system (maybe on a 64-bit x86 system) just to make sure that those luks volume can be cracked correctly and to find out whether the problem only occurs whenever this openmediavault system is used.
I would rather suggest looking at other possibilities:
1. what type of architecture (64 bit amd, x86 32 bit, mips, arm) is used by the system
2. little or big endian
3. what file system (ext3/ext4/ntfs...) does the system use
4. does the system use keyfiles together with luks
....
as you might know hashcat makes an entropy check to verify the data. This could in theory lead to problems if the decrypted data is random (which was never the case in our testings, see https://hashcat.net/forum/thread-6225.html)
You could also try to generate a test "volume" with the instructions from here: https://hashcat.net/forum/thread-6225.html
Code:
$ dd if=/dev/urandom of=test bs=1M count=100
$ cryptsetup luksFormat test
$ cryptsetup luksOpen test tmp
$ xxd -l 512 /dev/mapper/tmp # is random data at this point
$ mkfs.XXX /dev/mapper/tmp # use the same file system that is used by your system/device
$ xxd -l 512 /dev/mapper/tmp # should no longer be random data
$ cryptsetup luksClose tmpIt would also make sense that you try to generate a luks volume on a different system (maybe on a 64-bit x86 system) just to make sure that those luks volume can be cracked correctly and to find out whether the problem only occurs whenever this openmediavault system is used.