bitlocker2john code reworked

[e-ago]

bitlocker2john code reworked:

• check fseek/ftell return value
• 2 possible offsets for salt
• 2 possible offsets for AES

[kholia]

Thanks! I will take a look at this soon.

Do you have a new test disk image for testing this?

[e-ago]

Sure! Obviously this version correctly works with all the images in https://github.com/e-ago/bitcracker/tree/master/Images

In this issue e-ago/bitcracker#4 we are discussing about different BDE formats (devices encrypted using an authentication method different from the user password one)
@ejtaal provided this sample of image https://github.com/e-ago/bitcracker/blob/master/Images/tpm_recovery.bin . It seems a device encrypted with TPM but the extractor found also a recovery password metadata entry using a different offset between salt and AES.
Unfortunately we don't know the correct recovery password yet.

[kholia]

It would be great to get a test disk image with a known password. Otherwise, it seems that there is no way to verify our implementation.

We need to figure out the Windows version(s) which are able to generate such images.

[e-ago]

You’re right: as far as I know the volume has been encrypted with windows 7 enterprise N.

Anyway the code in this PR does the same checks of the current bitlocker2john with an improved code (errors check, variables renamed, etc..). There is only one difference: in this new version the code tests two possibile aes offsets after the salt instead of a single one

[kholia]

As far as I know the volume has been encrypted with Windows 7 enterprise N.

Next logical step -> Someone needs to grab a copy of that Windows version and create a sample BitLocker image from it. Verifying that the new code (and the crypto stuff within it) works is required, before we can advertise support for such types of BitLocker images.

[kholia]

@e-ago Hey, were you able to create/find a working test image? Also see my last post. Thanks!

[e-ago]

Hi @kholia , I've asked to ejtaal to provide an image with a know recovery password but no answer for now. Unfortunately now I haven't a computer with TPM to create a test image by myself

[kholia]

@e-ago I was able to test BitLocker on Windows 7 running in a VirtualBox VM without any TPM some years ago.

From the internet -> Enable BitLocker Disk Encryption in VirtualBox Windows VM ->

1. Run Group Policy Editor:

   gpedit.msc

2. Navigate to Local Computer Policy > Computer Configuration > Administrative Templates > 
   Windows Components > Bitlocker Drive Encryption > Operation System Drives > 
   Require additional authentication at startup.

3. Check Enabled and Allow Bitlocker without compatible TPM (...).

So, just grab the ISO for the target Windows version and run it inside VirtualBox. Other hypervisors should work too, I guess.

[kholia]

@e-ago I have one more suggestion.

What does bdeinfo says about this new disk image?

Please see the following links for more information on bdeinfo,

• https://github.com/libyal/libbde/blob/master/bdetools/bdeinfo.c

• http://manpages.ubuntu.com/manpages/xenial/man1/bdeinfo.1.html

I am curious to know if bdeinfo is correctly handling this disk image.

Thanks!

[e-ago]

The problem is that the user sent only the interesting part of the image, thus metadata formats may not be respected. Anyway I found a Windows 7 Enterprise N and I'll try to reproduce the test case. I'm going to remove the additional AES offset (67) so you can accept this PR.

dislocker:

dislocker -V ../../BitCracker/bitcracker/Images/tpm_recovery.bin -O 741
New memory allocation at 0x5631a44a1260 (0xd8 bytes allocated)
Verbosity level to CRITICAL (0) into 'stdout'
dislocker by Romain Coltel, v0.7.1 (compiled for Linux/x86_64)
Compiled version: master:747cbd6
Trying to open '../../BitCracker/bitcracker/Images/tpm_recovery.bin'...
Trying to open '../../BitCracker/bitcracker/Images/tpm_recovery.bin'...
Opened (fd #3).
Opened (fd #3).
New memory allocation at 0x5631a44a6cd0 (0x18 bytes allocated)
New memory allocation at 0x5631a44a6cf0 (0x90 bytes allocated)
New memory allocation at 0x5631a44a1750 (0x200 bytes allocated)
Positioning #3 at offset 741 from 0
Reading volume header...
Reading 0x200 bytes from #3 into 0x5631a44a1750
Volume header read
=====[ Volume header informations ]=====
  Signature: '-FVE-FS-'
  Sector size: 0x00b4 (180) bytes
  Sector per cluster: 0x02 (2) bytes
  Reserved clusters: 0x0400 (1024) bytes
  Fat count: 0x00 (0) bytes
  Root entries: 0x0004 (4) bytes
  Number of sectors (16 bits): 0x0000 (0) bytes
  Media descriptor: 0x80 (128) bytes
  Sectors per fat: 0x4a66 (19046) bytes
  Hidden sectors: 0x10000000 (268435456) bytes
  Number of sectors (32 bits): 0x00000000 (0) bytes
  Number of sectors (64 bits): 0x024b958000000000 (165390188317507584) bytes
  MFT start cluster: 0x022fd3f000000000 (157577539726868480) bytes
  Metadata Lcn: 0x024b968000000000 (165391287829135360) bytes
  Volume GUID: '0A514B6B-F3FD-926A-77B2-606FA19EDB97'
  First metadata header offset:  0x180b104b366dfdb4
  Second metadata header offset: 0xc6c3d254f36279c5
  Third metadata header offset:  0xedaefdece6e49874
  Boot Partition Identifier: '0xead4'
========================================
MetadataLcn = 165391287829135360 | SectorsPerCluster = 2 | SectorSize = 180
Changing first metadata offset from 0x180b104b366dfdb4 to 0x3a4ba40000000000
Positioning #3 at offset 4200631397360075493 from 0
Failed to seek in #3: Invalid argument
Reading bitlocker header at 0x3a4ba400000002e5...
Reading 0x70 bytes from #3 into 0x7fff6f953ab0
New memory allocation at 0x5631a44a7250 (0xd6ae bytes allocated)
Reading data...
Reading 0xd63e bytes from #3 into 0x5631a44a72c0
End get_metadata.
Freeing pointer at address 0x5631a44a7250
Entering get_metadata_lazy_checked
Positioning #3 at offset 4200631397360075493 from 0
Failed to seek in #3: Invalid argument
Reading bitlocker header at 0x3a4ba400000002e5...
Reading 0x70 bytes from #3 into 0x7fff6f953ab0
get_metadata::Error, metadata size is lesser than the size of the metadata header
Can't get metadata (n°1)
A problem occured during the retrieving of metadata. Abort.
Fri Jul 13 09:20:23 2018 [CRITICAL] A problem occured during the retrieving of metadata. Abort.
Freeing pointer at address 0x5631a44a1750
Freeing pointer at address 0x5631a44a6cd0
Freeing pointer at address 0x5631a44a6cf0
Freeing pointer at address 0x5631a44a1960
Trying to close fd #3...

bdeinfo:

./bdeinfo  ../../../bitcracker/Images/tpm_recovery.bin -o 741 -v
bdeinfo 20180704

Unable to open: ../../../bitcracker/Images/tpm_recovery.bin.
libbde_io_handle_read_volume_header: unsupported volume boot entry point.
libbde_volume_open_read: unable to read volume header.
libbde_volume_open_file_io_handle: unable to read from file IO handle.
info_handle_open_input: unable to open input volume.

[kholia]

@e-ago Your plan sounds good.

Please fix the following problems,

$ git am 3293.patch 
Applying: Code reworked. Two different salt and aes offsets. Tested on BDE volumes encrypted with TPM (recovery password found)
.git/rebase-apply/patch:16: space before tab in indent.
        	fprintf(stderr, "ftell error %s (%d)\n", strerror(errno),errno);	\
.git/rebase-apply/patch:17: space before tab in indent.
        	exit(EXIT_FAILURE);							\
.git/rebase-apply/patch:100: trailing whitespace.
			else 
.git/rebase-apply/patch:120: trailing whitespace.
			FRET_CHECK(ret)			
.git/rebase-apply/patch:240: trailing whitespace.
			if ((c == key_protection_clear[0]) && (d == key_protection_clear[1])) 
warning: squelched 7 whitespace errors
warning: 12 lines add whitespace errors.
Applying: Removing initial printf
Applying: Removing the additional AES offset untile we can't prove that it is correct

I see a bunch of whitespace errors and a typo in untile -> git commit --amend and git push -f should help you here.

Also make sure that you are not mixing spaces and tabs. The #define FRET_CHECK(ret) has this problem. Please double-check other parts too.

[kholia]

The git log --check command can be helpful in detecting where the whitespace problems are.