Napper 1.3 is stacking without no results at the "Reading PCR values of TPM and checking a vulnerability ..." step #8
Comments
|
Hello @HarlockP4, Thank you for visiting my project. Hmm... It seems that the kernel module of Napper, napper.ko, wasn't loaded successfully. Did you enable Secure Boot on your system? If not, would you give me the kernel log after running Napper? You can get the log with dmesg command. :) Best regards, Seunghun |
|
Hi @kkamagui, Thanks for your reply and support, I've attached the screenshoot of the BIOS that show the Secure Boot settings. Thanks again for the support
|
|
Hi @HarlockP4, Thank you for your reply. The BIOS says UEFI secure boot is enabled. Please turn off the "Secure Boot Enable" check box and run my napper tool to check the TPM vulnerability. Best regards, Seunghun |
|
Hi @kkamagui, I disabled the secure boot as you suggested me, now the errror is vanished but the program is stacked here: |
|
@kkamagui , sorry to bother you again, but do you know why your program is not moving over but just stack at the step of the pic above? |
|
@HarlockP4, I need more information to know the reason stopped. Would you follow the process below and tell me the result? # Open terminal and run resource manager
$> sudo resourcemgr
# Open another terminal and run pcrread command
$> tpm2_listpcrs
<Tell me the result below...> |
|
@kkamagui , these are the pics of the output of the 2 commands you requested me: |
|
@HarlockP4 , # Check SHA1 hashes
$> tpm2_listpcrs -g 0x04
# Check SHA256 hashes
$> tpm2_listpcrs -g 0x0b |
|
@kkamagui , here we go: |
|
@HarlockP4 , After it, rerun Napper tool with "sudo ./napper.py". Then you can see that your system has the TPM vulnerability or not. |
|
@kkamagui , so if I will understand I have just to replace all "-g 0x04" occurance to "-g 0x0b" into napper.py file? just this? |
|
Yes, exactly!
2021년 7월 22일 (목) 오후 8:01, HarlockP4 ***@***.***>님이 작성:
… @kkamagui <https://github.com/kkamagui> , so if I will understand I have
just to replace all "-g 0x04" occurance to "-g 0x0b" into napper.py file?
just this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#8 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJA43U3H67Y3UD5I43TUBLTY73BLANCNFSM5APNERAQ>
.
|
|
@kkamagui , ok I replaced the 2 "0x04" with "0x0b"
Meanwhile I really wanna thank you for your fantastic project and support, thanks again for all your efforts and I wish the best on all |
|
@HarlockP4 - Just a question, if you didn't turn on Bitlocker, I presume you have seen your disk encrypted which indicates Bitlocker was just ON? Did you look at the output of Dislocker? If it is encrypted, but not locked, then it should actually be able to retrieve your data, and a TPM won't actually have your key anyway. The TPM only has your key if THAT protector was enabled. And it doesn't sound like you enabled it.
|
|
Oh... I'm sorry to hear that. Fortunately and unfortunately, your system is safe. I hope you can get your data back soon. Best regards, Seunghun |
|
Hi,Thanks, I hope to find a way to unlock the data of my friend :)RegardsSent from my Galaxy
-------- Original message --------From: Seunghun Han ***@***.***> Date: 23/07/2021 03:35 (GMT+01:00) To: kkamagui/bitleaker ***@***.***> Cc: HarlockP4 ***@***.***>, Mention ***@***.***> Subject: Re: [kkamagui/bitleaker] Napper 1.3 is stacking without no results at
the "Reading PCR values of TPM and checking a vulnerability ..." step (#8)
@HarlockP4,
Oh... I'm sorry to hear that. Fortunately and unfortunately, your system is safe. I hope you can get your data back soon.
Best regards,
Seunghun
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Hi Brandon, Thanks for your suggestion, as I'm away from home for 1 week I will give it a go at my return. I'll keep you updated. Thanks again. Hope to not dream the recovery key request meanwhile I'm sleeping:)RegardsSent from my Galaxy
-------- Original message --------From: Brandon Warhurst ***@***.***> Date: 22/07/2021 18:13 (GMT+01:00) To: kkamagui/bitleaker ***@***.***> Cc: HarlockP4 ***@***.***>, Mention ***@***.***> Subject: Re: [kkamagui/bitleaker] Napper 1.3 is stacking without no results at
the "Reading PCR values of TPM and checking a vulnerability ..." step (#8)
@HarlockP4 - Just a question, if you didn't turn on Bitlocker, I presume you have seen your disk encrypted which indicates Bitlocker was just ON? Did you look at the output of Dislocker? If it is encrypted, but not locked, then it should actually be able to retrieve your data, and a TPM won't actually have your key anyway. The TPM only has your key if THAT protector was enabled. And it doesn't sound like you enabled it.
dislocker-meta -v -v -v -v -V YourPathToBitlockerVolumeHere Will provide a lot of output, but if you look back through it, you'll see if there is a key available allowing decryption (no protectors needed).
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@roboknight Hi Brandon, I was finally able to try dislocker-metadata -v -v -v -v -V YourPathToBitlockerVolumeHere command |
|
I see the TPM is engaged in the output, which means that bitlocker was set up somewhere (at this point, who knows where if YOU didn't set it and your friend didn't set it). I see that there were 2 recovery keys. The current one is likely the one you mention (same GUID), and there was a previous one (maybe when the system was set up). The key, is of course, encrypted. So the trick now is to undo the system via Bitleaker, if in fact, it is vulnerable. Unfortunately, because I DO see the TPM enabled, the key I hoped would be there is not there (that's the one that is just unlocked). Since the system is SAFE (as I gathered from above), undoing the key via Bitleaker also will NOT work. One thing you MIGHT try is checking the BIOS settings. Is it possible that the BIOS settings have changed such that the system is booting without Secure Boot? Because, from what I can tell, one of two things is happening: 1) the BIOS is somehow corrupted causing bad PCRs or 2) the system just can't talk to the TPM correctly (which doesn't appear to be the case as Linux appears to work with it). Those are the only two real cases where I've seen Windows really fail to boot with Bitlocker enabled. Somehow the system cannot acquire the VMK from the TPM and then of course requires the recovery key. Unless you have the recovery key, which you don't, the only real hope is to make the TPM work correctly and give up the key. Otherwise, it looks like a re-install of Windows. Unless Bitleaker actually DOES work and there was some weirdness, but from the output I see above, it isn't likely. And the BIOS appears new enough, that Dell may have fixed the Bitleaker vuln. According to the link you posted above, it also appears that neither Dell, nor Microsoft, can get you the recovery key. |
|
@roboknight thanks for your reply, I was able to create an image of the bitlocker disk with FTK imager and then run bitlocker2john against it. I have an hask to attack now but if I try to run the command: john.exe --incremental:digits --format=bitlocker-opencl --mask=?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d hash_to_crack.txt the output stops after few minutes with: Device 1: GeForce GTX 750 Ti I cannot understand why, do you? |
|
@roboknight I also wondering if restoring the original firmware when bitlocker was turned on (not sure which one it is but I will try all the available from DELL site) can fix the issue, I 'm aware that all is started because a firmware upgrade and I'm also aware that my friend tried a downgrade as from suggestions coming from https://www.dell.com/community/Windows-10/BitLocker-need-a-key-but-I-never-installed-it/td-p/6019486 |
|
OH, now it makes WAY more sense. Yeah, if he/she upgraded, the hashes that were likely used to lock the key have probably changed. I don't know if downgrading will actually work, because there is no telling where you really need to downgrade to, but yeah, bitlocker probably should have been turned off before the upgrade. Of course, if your friend didn't think it was on, then that explains the whole problem. Dell is really stupid for forcing that feature ON in their loaded version of Windows. However, if you can downgrade far enough, it might be possible to make things vulnerable to bitleaker again. Although, you have one final issue. You now don't really know what hashes were provided to protect the key in the first place. |
|
@roboknight as I wrote you above bitlocker2john produced this result: Signature found at 0x76dfd1db1c now I'm trying to run john like this: john.exe --format=bitlocker-opencl --mask=?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d hash_to_crack.txt as I know that the recovery key is 48 digits On the other side I'm wondering if I'm able to restore the previous version of the bios ( I don't what version it was) the one used when bitlocker was turned on can let the laptop reboot without asking you for a recovery key, what's your tought about it? |
|
If you can get the original BIOS, and the original settings, it should boot to Windows. If that occurs, and you can log in, then manage-bde can get you the recovery key AND turn off Bitlocker. Then you can upgrade and turn it back on if you like. Otherwise, bitlocker2john it is…. And pray to the gods of chance that you hit the key soon. You have seen a recovery key before, right? I ask because it is 48 digits, but the groupings are odd. 8 groups of 6 digits. |
|
@roboknight the problem is that I don't know which version of the bios was installed before of the bios upgrade, I'm wondering if I flash to a different bios, will the TPM keys stored being affected? I would say no but I would like to be sure before to move on that yeah, 48 digits key I've already saw it I don't know how many times John will take to brute force it but I have no rush on that, I just got a doubt about it because if TMP is involved John will just produce false positive |
|
Flashing the bios to YAV (yet another version) won't leave you in a different state than you are now. The only thing that will REALLY screw you up is if you clear the TPM, so don't do that. Bitlocker2John might take forever, not sure. The key SHOULD only be digits. The mask looks right. I guess now you wait? Did you use the fast or slow hash? |
|
@roboknight ok, in this case I just will try to flash to different version without touching the TPM, I'm wondering if it's possible to backup it and restore. the test that I will try to do will be the following:
Actually I 'm running John with slow hash I don't want to finish faster but with false positive, so bitlocker$3$, by the way when I started John, he is warning me about it could produce false positive so, it seems that also the slow one is no error free |
|
@roboknight you know what it's really bad, no distribuited john exists to split the work among multiple machines :( |
|
Like I said, even if bitleaker "works"... it won't work because unless you have a "bootable" device (i.e. the TPM recognizes the BIOS) it won't give you the key because the hash of the BIOS doesn't match. If you had the old values from the device BEFORE uploading, then you could just replay those (you wouldn't even need the bitleaker code per-se... just the module to reset the TPM and then you could read your file and replay the hashes. As it stands, I'm going to pray that the version you downgrade to is the correct version. And you'll know because the device should "just boot" (tm) ... This is where all this great security turns everyone sour... poor implementation. They should have WARNED, PLEADED and BEGGED your friend to shut off Bitlocker PRIOR to doing ANYTHING with an upgrade. In fact, just refusing the upgrade politely would have been a FANTASTIC option. |
|
@roboknight so I can avoid to run john to try to hack the hash as also with a result from it, it will not work anyway. Ok I will just focus on the bios thing and I keep you updated |
|
@roboknight tried all the BIOS and none of them is working ............... I'm feeling lost |
|
Yeah, you are probably going to have to let Bitlocker2John try to hack the recovery password. That may not be possible because it will be 9^48 options... That's a LOT of options. I'm not sure you'll be able to break it either way. Dell can't help you with the original BIOS? Dell might have actually modified it somehow, which may be why you can't "hit" the right one. |
|
@roboknight I opened a ticket on John's site too, and this was the reply of one of them about Bitlocker2John: Having said that, your task is impossible: The keyspace for 48 unknown
|
|
Yeah, I left out "0"... it should have been 10^48.... Yeah, that's a pretty huge number. I don't know how fast Bitlocker2John cracks "keys", but I was kind of dubious. It's likely on the order of "heat death of the universe" amount of time. I was hoping you might "get lucky"... but as the respondent above pointed out, you're more likely to win the EuroLotto 5 times in a row. I definitely would talk to Dell and see if there is SOME way you can roll back to the correct BIOS. Once you do that, it will likely boot. And if it does, and its vulnerable, you'll have better luck (or, you can then use manage-bde as I mentioned before). You really need those hashes to match, but without having them in hand... There is ONE outside alternative... but that requires getting another exact model laptop (and I'm sure you'd rather not do that after this experience). With that, you MIGHT be able to reproduce the original hashes you need. The only OTHER way I can REMOTELY think to recover your key is by using some of the tools that attempt to divine the private key of the TPM. With that, you might be able to just decrypt the data you need (i.e. the VMK). You might attempt to looking into side-channel attacks, but they are not all that simple to implement. |
|
@roboknight I think my friend has to accept the offer of the recovery company and pay 1000€ for the task. |
|
Actually, I just checked Dell and they only have versions running back to 2020... how old was the BIOS BEFORE the upgrade? Because Dell only seems to have ones going back to 1.1.5 (which appears to be from 2020).. |
|
@roboknight yep correct I cannot find any older than 1.1.5, where I tested the bitleacker. I got no idea about which version was the bios before of the flash as the owner of the laptop is not exactly an IT :( |
|
Its possible it did... I don't know if MS would help him or not. Encryption, when it works, is pretty hard to circumvent. When it doesn't, it is usually implemented incorrectly. If you tried ALL of Dell's versions of the BIOS, with the TPM turned on and so forth, then finding the recovery key is the only hope. Otherwise, erase the entire thing. I don't know how much data your friend is losing. I'm guessing quite a bit. I suppose unencrypted backups are a thing, but it is a tough lesson to learn. I'm not so sure I've got that one down as I still lose data frequently (not to encryption, but system failures). |
|
I miss the skills to do this: |
|
I do that frequently, but unless the TPM is letting you boot, even that will fail. Basically it just lets you monitor all of Bitlocker’s traffic to the TPM. But, if your PCRs don’t match, “no soup for you!” |
|
@roboknight so is a way to decrypt that HD exist? The company that are offering you to recover data, what kind of tools are using? |
|
The way I've done it in the past was to use a Saleae to attach to the TPM. I don't know if the Dell 5511 has a physical TPM. If it has an fTPM, then that technique doesn't work. The way Bitlocker generally works is by sending a request to unencrypt the key. This depends on the BIOS having sent its appropriate hashes to the TPM. Since it appears that Secure Boot was turned on, this means the following several hashes were sent into the TPM (the following list is just from ONE laptop I've looked at) (NOTE: The list below indicates WHAT is being hashed): PCR0 : Boot.Guard.Measured.S.CRTM. PCR7 : EFI Variable Driver Config -- The first entry is some weired random looking value with SecureBoot appended to it. There are SEVERAL more separators for other PCRs as well as other data for other PCRs (depending on what needs protecting, presumably)... I'm just going to continue with PCR7 and PCR11 because I believe that's all you care about... PCR7 : The microsoft boot manager signature. PCR11 Never gets written to up to the point you need to get the key. It gets written to later (presumably to prevent you from getting the key later, but I think they also write to PCR7 again after Windows boots, which would prevent you just getting the encryption key out of the TPM after boot). The Bootmanager, Separator, Certs ... Those are ALL the same (I'm pretty sure) and I could likely give you those hashes. kkamagui's code probably doesn't even need to play the WHOLE set of TPM data. Its just easier to read the logs and do what everything else does. The only issue I can possibly see is that random number prefixed to "SecureBoot"... maybe it prevents you from downgrading and extracting the key (as in, it might be a NONCE). I've never really done a test to see if that ever changes. It seems to get prefixed to other PCR register values (for example, PCR1 gets something labelled "BootOrder", which then has the hash of the order of bootable things appended after it is, so PCR1, if it were associated with the key, would prevent you from changing the boot order). But, if every time you update the BIOS, that value changes, you will get "locked out" from the TPM. So, likely, you'd have to make sure to turn OFF Bitlocker before an upgrade (or downgrade) as you might lose that value. I'm unsure what $1000 (euros I know, I just can't remember where the symbol is on my keyboard) buys you. They may have a side channel attack that would actually let them get the TPM private key and, with that, they might be able to decrypt your data. I can't tell you to spend that kind of money on a system. I don't know how valuable your friend's data is. If he has passwords and stuff he needs for banking, then he might be in some trouble. If it was a gaming system and it has all his high scores or something, its definitely going to hurt, but I think 1000 Euros will hurt a lot more. |
|
As a side note, manage-bde has options to turn off the encryption (and provide a plaintext key in the metadata) for some specified number of boots (or just until next boot)... likely for just the case the BIOS is upgraded. I don't know why THAT wasn't invoked automatically. Also, this presents a HORRIBLE technique for DoS to a person's laptop that has Bitlocker turned on. Evil maid upgrade's the BIOS. As long as you didn't save your recovery key... No data for you. And of course, when you pay up, the joke's on you because they can't decrypt it either. |
|
@roboknight wow, that is really over my skills, if I have to do something by software is fine but if I have to phisically act over the hardware I'm out of game. In this case I have to give up and return the laptop to my friend. I can provide him the bitlocker hash I recovered and if he likes he can try to be the most lucky man in the world and try to decode it otherwise he has to pay 1000€ |
|
I've had a chance to look at it... It seems that the value I was looking at isn't a NONCE because it is the same across Dell and Microsoft (between a Surface Book and Dell 7579). The main differences are, the hardware cert (which, in one case is, of course, Dell's, and in the other case it is Microsoft's which are obviously different). This leads to a possibility that even if you downgrade, they still give you the updated hardware cert which means sad trombone sound for you because it will STILL be different from the original firmware value. The other place, it appears, is later on. They have some UEFI driver config value which appears to be a Microsoft root cert in one case (as I think I mentioned above), but in the Microsoft Surface book case it appears to be something else. It certainly isn't any X509 style cert (which all the other certs appear to be in). So, ultimately, there seems to be 2 main things that might have changed for you. Since you don't have the old set of hashes to work with, we'll never know exactly what changed, but I'm betting on Dell having updated the hardware cert without turning off Bitlocker or even bothering to WARN anyone about it. And, as many other people have likely done, you're friend upgraded without knowing how screwed he would later be. I don't even know if there would be a way tp put that old cert back in the UEFI so that you could just get to the system to turn off Bitlocker for a BIOS update. If you could even get Bitleaker to work, I could send you the hash for the Dell 7579 I have. It MIGHT be the correct hash. You could then possible just "edit" the output of Bitleaker so that you could feed in a different set of hashes. However, I don't know if any of your firmware revs were vulnerable to Bitleaker. Another possibility is to look for a Dell 5511 that hasn't been upgraded. If you could run Bitleaker on that, then you might have a correct set of hashes. Again, this all assumes you aren't "SAFE" when running an older firmware. If you are then NONE of this matters. |
|
It looks like tour system is not going into the sleep state. You need to restart the system with Ubuntu. And again run the bitleaker.py file |
|
@HarlockP4 did you solve your problem? I have exactly the same problem and my Asus has a firmware TPM, so even trying to catch VMK via LPC bus will not work :( |
|
Those would be things like Differential Power Analysis (I.e. monitor the power and try monitoring it with many inputs and many times). This lets you determine, if things aren’t done correctly, the key watching the power and determining the 1’s and 0’s of the key. With a TPM, you are looking for a private RSA key. Don’t know if that’s what you were looking for, but you can look for DPA and CPA… that will help. |
|
On 12/13/21 00:43, Kolar94 wrote:
@HarlockP4 <https://github.com/HarlockP4> did you solve your problem?
I have exactly the same problem and my Asus has a firmware TPM, so
even trying to catch VMK via LPC bus will not work :(
I am looking for any ideas.
@roboknight <https://github.com/roboknight> can you explain
"side-channel attacks"?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#8 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AU3Y7NGJQZGEFGF6VT7FBB3UQUXTXANCNFSM5APNERAQ>.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
Hi @Kolar94,
no, I haven't fixed it, I suggested to my friend to ask a company that
is doing data recovery as the only viable solutions is an HW attack, the
bruteforcing of bitlocker algorthim has a work factor that is not
viable, please keep me update if you find a viable solution
Regards
|
Hi, I'm trying to recover my data from my Dell Latitude 5511 laptop, as I cannot recover the recovery key since I've never activated bitlocker.
I found your amazing project and I thought perhaps I have a chance to get back my data.
I run Napper 1.3 live cd but after starting Napper, it seems to stack with no progress at the "Napper 1.3 is stacking without no results at the "Reading PCR values of TPM and checking a vulnerability ..." , I noted that there is an error, I will add a picture to let you understand better my problem
Can you please help me?
The text was updated successfully, but these errors were encountered: