-m 16700 = FileVault 2 does use a salt
hashcat doesn't really provide/have hashes generated on the host... only the OpenCL device (GPU or CPU) will compute the digest on that hardware accelerator directly... it would be WAY too slow to have those hashes on the host and to have a mechanism to being able to print them etc (disk I/O is just horrendously slow ! it just would make absolutely no sense in general). This is of course also due to the fact that hashcat is NOT a general hash generation tool (even though of course the kernel code is able to compute hashes to compare with).
That said, we have a tool that is able to generate hashes quite quickly (most of the time only disk I/O is the bottleneck, i.e. storing the hashes if you really have to)... and it is used like this
test.pl is available within the hashcat source code (github repository for instance, or source code download from https://hashcat.net/hashcat). You would of course need to install all the needed perl modules (on linux you could just run: ./tools/install_modules.sh).
as you can see from the output of the test.pl run the FileVault "hashes" do have a 32 bytes salt. so your statement of no salt for -m 16700 is wrong (see example hashes here: https://hashcat.net/wiki/example_hashes)... and that is also why it makes no particular sense for -m 16700 to build some kind of rainbow table... which most of the time makes no sense these days
hashcat doesn't really provide/have hashes generated on the host... only the OpenCL device (GPU or CPU) will compute the digest on that hardware accelerator directly... it would be WAY too slow to have those hashes on the host and to have a mechanism to being able to print them etc (disk I/O is just horrendously slow ! it just would make absolutely no sense in general). This is of course also due to the fact that hashcat is NOT a general hash generation tool (even though of course the kernel code is able to compute hashes to compare with).
That said, we have a tool that is able to generate hashes quite quickly (most of the time only disk I/O is the bottleneck, i.e. storing the hashes if you really have to)... and it is used like this
Code:
perl tools/test.pl passthrough 16700 dict.txttest.pl is available within the hashcat source code (github repository for instance, or source code download from https://hashcat.net/hashcat). You would of course need to install all the needed perl modules (on linux you could just run: ./tools/install_modules.sh).
as you can see from the output of the test.pl run the FileVault "hashes" do have a 32 bytes salt. so your statement of no salt for -m 16700 is wrong (see example hashes here: https://hashcat.net/wiki/example_hashes)... and that is also why it makes no particular sense for -m 16700 to build some kind of rainbow table... which most of the time makes no sense these days