[XtremeDiscount]

Bitlocker can gen multiple hashes for various reasons (passwords, recovery key, TPM key, etc.)

Try making a full copy and reextracting the hashes, then update us please.

Ok, I'll keep you all updated when I get the full image

[possessed-client]

Hashes 0 and 1 are for the password, 2 and 3 are for the recovery key, the secondary hashes for each are an extra check. As far as I know, you only need the header of the volume to get the hashes and all other information, making a full image of the drive shouldn't give you more information above what you can get from the very beginning of volume data.
As 5chn4pp said, try finding the recovery key. It's your best bet if you don't have any extra info that can help with cracking.

[G-EZE]

I ran

py -3 .\bitlocker2john.py '\\.\PhysicalDrive1' -o 0x100000 > current_hashes.txt 2> current_log.txt

and it generated a current_hashes.txt file that's empty.

It also generated a current_log.txt file that says

Traceback (most recent call last):
File "C:\john-1.9.0-jumbo-1-win64\run\bitlocker2john.py", line 273, in <module>
main()
^^
File "C:\john-1.9.0-jumbo-1-win64\run\bitlocker2john.py", line 218, in main
with open(bitlocker_partition, 'rb') as fp:
^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: "'\\\\.\\PhysicalDrive1'"

PhysicalDrive1 might not be the correct drive and 0x100000 might not be the correct byte offset that begins on the BitLocker partition. Open up PowerShell and run Get-Disk, you will see some output like:

Code

Number    Friendly Name    Size
-------  --------------   -----
0         My SSD Pro       1 TB
1         External USB     2 TB

If your using "My SSD Pro" for example it would be PhysicalDrive0.

To get the byte offset run Get-Partition or u can run Get-BitLockerVolume in PowerShell. The output will look something like:

Code

DiskNumber    PartitionNumber    DriveLetter    Offset
----------   ----------------   -------------   --------
0             1                  C              123456
0             2                  D              987654321

If the BitLocker partition starts at 123456, run this in PowerShell to get the hex: "{0:X}" -f 123456 which would be 1E240 in this example.

Putting the command together: py -3 .\bitlocker2john.py \\.\PhysicalDrive0 -o 0x1E240 > current_hashes.txt 2> current_log.txt

Try this and let us kno what the output becomes.

[5chn4pp]

These hashes have now been confirmed by me:

Code

$bitlocker$0$16$eac7b3ac70197dfe91505abae28e6556$1048576$12$c0fbafa6000fdc0103000000$60$55f8db1043db29d4b2dce30384440ef20b6cb2f9244e0d9d90f91b74144b22de4a4b3a02641dc3bb73f96a71683b6a4959dbe2d98a5089dd5ac7723f
$bitlocker$1$16$eac7b3ac70197dfe91505abae28e6556$1048576$12$c0fbafa6000fdc0103000000$60$55f8db1043db29d4b2dce30384440ef20b6cb2f9244e0d9d90f91b74144b22de4a4b3a02641dc3bb73f96a71683b6a4959dbe2d98a5089dd5ac7723f
$bitlocker$2$16$1f3f1d6e0c8ca9d5551911940c4eb7c0$1048576$12$c0fbafa6000fdc0106000000$60$e6345665d2e653b114260c6cf22dc0a70571d571e13d2e2fbe454a41f6bb6e090d4317e5d1b1684d8e85ec9a490091cec6b3a59643870747f493329d
$bitlocker$3$16$1f3f1d6e0c8ca9d5551911940c4eb7c0$1048576$12$c0fbafa6000fdc0106000000$60$e6345665d2e653b114260c6cf22dc0a70571d571e13d2e2fbe454a41f6bb6e090d4317e5d1b1684d8e85ec9a490091cec6b3a59643870747f493329d

This means the image hashes we got earlier is indeed the hashes of the actual locked drive.

For cracking, don't waste time on $2 and $3, those are the 48-digit recovery key. Spend time on $0 and verify any hit against $1.

As for the BitLocker file, the chances are looking slim. OP only had C: and the BitLocker volume, and C: has now been searched.

The only path for the BitLocker file left is a deleted file recovery for the file, which I have instructed OP to run.

If that fails, the only path forward is either a crack on the hash, or take the C: drive to a specialized shop for recovery on the BitLocker file.

[possessed-client]

These hashes have now been confirmed by me:

Code

$bitlocker$0$16$eac7b3ac70197dfe91505abae28e6556$1048576$12$c0fbafa6000fdc0103000000$60$55f8db1043db29d4b2dce30384440ef20b6cb2f9244e0d9d90f91b74144b22de4a4b3a02641dc3bb73f96a71683b6a4959dbe2d98a5089dd5ac7723f
$bitlocker$1$16$eac7b3ac70197dfe91505abae28e6556$1048576$12$c0fbafa6000fdc0103000000$60$55f8db1043db29d4b2dce30384440ef20b6cb2f9244e0d9d90f91b74144b22de4a4b3a02641dc3bb73f96a71683b6a4959dbe2d98a5089dd5ac7723f
$bitlocker$2$16$1f3f1d6e0c8ca9d5551911940c4eb7c0$1048576$12$c0fbafa6000fdc0106000000$60$e6345665d2e653b114260c6cf22dc0a70571d571e13d2e2fbe454a41f6bb6e090d4317e5d1b1684d8e85ec9a490091cec6b3a59643870747f493329d
$bitlocker$3$16$1f3f1d6e0c8ca9d5551911940c4eb7c0$1048576$12$c0fbafa6000fdc0106000000$60$e6345665d2e653b114260c6cf22dc0a70571d571e13d2e2fbe454a41f6bb6e090d4317e5d1b1684d8e85ec9a490091cec6b3a59643870747f493329d

This means the image hashes we got earlier is indeed the hashes of the actual locked drive.

For cracking, don't waste time on $2 and $3, those are the 48-digit recovery key. Spend time on $0 and verify any hit against $1.

As for the BitLocker file, the chances are looking slim. OP only had C: and the BitLocker volume, and C: has now been searched.

The only path for the BitLocker file left is a deleted file recovery for the file, which I have instructed OP to run.

If that fails, the only path forward is either a crack on the hash, or take the C: drive to a specialized shop for recovery on the BitLocker file.

Did OP only run the commands for searching for the key from your previous post? Maybe OP fully renamed the file, in which case it might be worth to search for all recent .txt files on C: or on any other removable drive that might've possibly been plugged in.

[5chn4pp]

Did OP only run the commands for searching for the key from your previous post? Maybe OP fully renamed the file, in which case it might be worth to search for all recent .txt files on C: or on any other removable drive that might've possibly been plugged in.

I sent him more commands with wider searches, no result.

And only OP knows what happened with the file, I don't have that information sadly.

He told me the only drives was the BitLocker volume and the C: Drive.

[possessed-client]

I sent him more commands with wider searches, no result.

And only OP knows what happened with the file, I don't have that information sadly.

He told me the only drives was the BitLocker volume and the C: Drive.

Wider as in searching all txt files on C: since the day of encryption for having "BitLocker" or the key pattern in its contents? Well, if that gave zero then tough luck, hard to recover deleted files on SSDs. I suppose it does increase security to delete the recovery key and all is fine - well, unless you forget the only password.

[5chn4pp]

Wider as in searching all txt files on C: since the day of encryption for having "BitLocker" or the key pattern in its contents? Well, if that gave zero then tough luck, hard to recover deleted files on SSDs. I suppose it does increase security to delete the recovery key and all is fine - well, unless you forget the only password.

I know, here is an example of what was run and resulted in no return:

Code

Get-PSDrive -PSProvider FileSystem | ForEach-Object { Get-ChildItem -Path "$($_.Root)" -Recurse -ErrorAction SilentlyContinue -Filter "BitLocker Recovery Key*.txt"} | Select-Object FullName,LastWriteTime,Length

Get-PSDrive -PSProvider FileSystem | ForEach-Object {  Get-ChildItem -Path "$($_.Root)" -Recurse -ErrorAction SilentlyContinue -Filter "*.txt" |  Select-String -Pattern "65917A4D-411E-41EB-9530-BC479C120596" -List} | Select-Object Path,LineNumber,Line

Get-PSDrive -PSProvider FileSystem | ForEach-Object { Get-ChildItem -Path "$($_.Root)" -Recurse -ErrorAction SilentlyContinue -Filter "*.txt" | Select-String -Pattern "65917A4D" -List} | Select-Object Path,LineNumber,Line

Get-PSDrive -PSProvider FileSystem | ForEach-Object { Get-ChildItem -Path "$($_.Root)" -Recurse -ErrorAction SilentlyContinue -Include *.txt,*.bek,*.csv,*.rtf,*.doc,*.docx | Select-String -Pattern '\b\d{6}-\d{6}-\d{6}-\d{6}-\d{6}-\d{6}-\d{6}-\d{6}\b' -List } | Select-Object Path,LineNumber,Line

[smartLink]

hello, I've been trying what you gave for 3 days but it seems there's a mistake somewhere. Now I know your request: Clean re-extraction of the hash/protector

Because your technical history clearly shows problems:

salt-value exception,
hash parse error,
multiple protectors,
suspicious offsets,
partial images,
signature found at unusual offset.

There are still real chances that:

the good hash is not attacked,
or is incomplete.

Especially this:

Loaded 2 password hashes with 2 different salts

shows that there are 2 different protectors.

One can:

be old,

recovery protector,
incomplete,
or irrelevant.

[CyberneticsX]

Have you got it yet, or no?.

[ItsMehRAWR]

In reverse engineering, the most critical "no dependency" skill is the ability to navigate the Process Environment Block (PEB). When you are writing a custom debugger, unpacker, or instrumentation tool, you cannot rely on standard imports because they make your tool easy to detect and analyze.

To get a headstart, you need to be able to resolve function addresses (like `GetProcAddress` or `LoadLibrary`) manually by walking the PEB in memory. This is the foundation of shellcode development and advanced dynamic analysis.

Below is a minimal, dependency-free x64 MASM skeleton. This code locates `kernel32.dll` in memory by walking the `Ldr` list, parses its Export Address Table (EAT), and finds the address of any function—all without calling a single imported API.

### The "PEB Walker" Template (x64 MASM)

This code provides a clean entry point. Compile this with `ml64.exe` and link it without standard C libraries (`/nodefaultlib`).

```asm
; Minimal x64 MASM PEB Walker
; Purpose: Resolve function addresses dynamically
; Compile: ml64 /c /nologo /Fo: walker.obj walker.asm
; Link: link /nodefaultlib /entry:main walker.obj /subsystem:console

.code

main PROC
; 1. Locate the PEB
mov rax, gs:[60h] ; PEB is at GS:[60h] in x64
mov rax, [rax + 18h] ; PEB_LDR_DATA
mov rax, [rax + 20h] ; InInitializationOrderModuleList

; 2. Walk the linked list to find kernel32.dll
; (This is a simplified loop; you would compare module names here)
; For brevity, we assume the 3rd entry is kernel32.dll
mov rax, [rax]
mov rax, [rax]
mov rbx, [rax + 20h] ; Base address of kernel32.dll

; 3. Now rbx points to the Base of kernel32.dll
; You would then parse the DOS Header and NT Headers here
; to find the Export Directory, then scan for a function name.

ret
main ENDP

END

```

### Strategic Headstart for Reverse Engineering

If you want to master this domain, don't waste time writing complex UI code. Focus your "under 3500 lines" on these three modules:

1. The PE Parser: Write a function that takes a base address and returns the `IMAGE_EXPORT_DIRECTORY` pointer. You will need to calculate the offsets for `e_lfanew` (DOS Header) and `OptionalHeader` (NT Headers).
2. The String Hasher: Never store raw function strings (e.g., "VirtualAlloc") in your code—it’s the first thing reverse engineers look for. Implement a ROR13 hashing algorithm to store the hashes of your target functions instead. You resolve the hash by hashing the names in the export table at runtime.
3. The Hooking Engine: Write a 14-byte trampoline generator. To hook a function in x64: Overwrite the first 14 bytes of the target function with a `jmp qword ptr [rip + 0] ; <64-bit address>`.
Redirect execution to your function. Restore the original bytes when finished to avoid crashing the process.



### Why this approach?

No Dependencies: By walking the PEB, your code is "self-contained." It doesn't need the Windows Loader to resolve its imports before it starts running. This is vital for injecting into other processes. Stealth: This is how you avoid IAT (Import Address Table) hooks and API monitors that flag you for suspicious imports.
Portability: This logic works on almost any version of Windows x64, as the PEB structure has remained remarkably stable for decades.

### Next Steps

Once you have the PEB walker functional, your next logical task is to write a routine that takes a hash as input and returns the function address by iterating through the `AddressOfNames`, `AddressOfFunctions`, and `AddressOfNameOrdinals` arrays in the `kernel32.dll` export table.

Do you have the specific offset structures for the `IMAGE_NT_HEADERS` or `IMAGE_EXPORT_DIRECTORY` on hand, or would you like me to provide the structure definitions for your MASM header file?

[signed0]

Cant you just ping microsoft like the fbi does to provide the private key

[snarie]

This sounds silly, but I ran into a similar situation. Microsoft stores the keys online unless it's disabled. Have you checked that?

(That's how I got back on my drive)

[mtpakisi]

Hey did you come right ?
Can assist