-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PCR get data from bitleaker driver fail? #4
Comments
Hello @mahmouddawod-it , It's a weird situation. Would you tell me about your testing process? Did you fail to start BitLeaker alone? Best regards, Seunghun |
I think I actually figured out what the problem was. I traced the
values in the TPM registers only to discover that, even though my
device was "sleeping", it was really only shutting down the screen. So
the TPM wasn't getting a chance to reset. I also realized, after
tracing things a bit more, that the TPM was changed from the beginning.
So I couldn't figure out a way to get to the values of the TPM right
off. I believe that the system may still work, but I have to work on
actually getting it to go to sleep correctly. So your code is working
beautifully, as far as I can tell, but the system I'm attempting to
target, though the TPM may be vulnerable (I checked the model and I
think its a pretty common one that is vulnerable), it isn't DIRECTLY
because Linux can't make the device sleep correctly. So I'm having to
rebuild a version of Linux that might work with it. Additionally, I
want it to work from a thumbdrive, which has made things a little more
tricky, since I have to use a signed bootloader (like Ubuntu's or
Redhat's)... I figured out how to fix some of that, and I believe it
will still work because it is only using PCR 7 and 11 (not the fully
protected set of registers). But I just have to get the registers to
reset by getting Linux to put the device to sleep correctly.
…On Wed, Apr 1, 2020 at 16:32, Seunghun Han ***@***.***> wrote:
Hello @mahmouddawod-it <https://github.com/mahmouddawod-it> ,
It's a weird situation. Would you tell me about your testing process?
Did you fail to start BitLeaker alone?
Best regards,
Seunghun
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABQ75544FTQ2XQEYTBTSRTRKPFIFANCNFSM4LVQVQ4A>.
|
Hi robotknight, I'm faced with the same issue as you. Did you manage to find a workaround for this? Thank you.
|
So ultimately I figured out that the device I was trying to deal with, a Microsoft Surface device, unfortunately for some reason, doesn't really HAVE a sleep state S3. So ultimately, since this is pretty much what Bitleaker depends on, it could never really achieve this sleep state in the device I targeted. I did "get it to work" in the sense that I believe I got things RUNNING, but it never produced good results because, as I said, I ultimately couldn't get to sleep state S3. So, even though I believe the hardware to ultimately be vulnerable to Bitleaker, they dodged the bullet by eliminating sleep state S3. I believe, at least in the particular Microsoft Surface I was targeting, sleep state S3 didn't make sense for them because I think in that sleep state, the device would ultimately just burn battery. So the designers likely nixed it (eliminated it) for that reason. |
https://www.cyberciti.biz/files/linux-kernel/Documentation/power/states.txt -- So kkamagui mentions that the TPM resets in state S3, which is what bitleaker uses. However, I forgot to mention above that I learned (as it states in the link I put here), that S3 is optional. So they don't always implement it. So even if the hardware maybe vulnerable, you need to first determine if your device supports sleep state S3. If you cat /sys/power/state, I believe it lists the power states available. It won't label them S0, S1, S2, S3 and so on, but things like "freeze", "mem", and "disk". I think the state you need here might be "mem". But the link above I believe does list the appropriate name. But S3 doesn't have to be implemented... its optional. Which may be why your system is failing. Oh, and you need to check "/sys/power/mem_sleep". This file, I believe, lists the available state for "mem", the one you ACTUALLY need is "deep" (according to link). If "deep" is not available, then it likely was not implemented, and you are out of luck with bitleaker. |
Last note on the issue:
from: |
@kkamagui In light of what I discovered, I was thinking maybe one of your tools might, during a check for the vulnerability, check for sleep state S3 availability? It might save some time for some trying to use this code? |
Are you trying to run on a newer version of Ubuntu? It might be possible that you need some adjustments. There may ALSO be one other problem (I don't know for sure). Even though it uses TPM 2.0, it may STILL use V1 of the registers (they use SHA1 instead of SHA2 I think). And there is a DIFFERENT interface to those. I don't know if kkamagui set up napper to use V1 or V2 of the TPM protocol. I have run into this in a few situations (the Microsoft Surface above, for example and now a Dell Inspiron that I'm working with). V1 doesn't use the same args as V2. That MAY cause your Segmentation Fault. I'm unsure because I do NOT know anything about your particular TPM (or fTPM as the case may be). I have noted, in the case of the Inspiron, they use an fTPM and were using V1, so I had to get bitleaker to use that as well. I haven't looked that closely at the napper code to see if it supports V2 only or also would support (or even has code for) V1. If there is code for V1, it may be #ifdef'd out and you may need to recompile with that support. |
I just ran napper on the Dell Inspiron 15 I'm looking at. It is vulnerable... but you may need this: ` echo 1 > /proc/sys/kernel/sysrqecho x > /proc/sysrq-trigger` This is if you require UEFI signing... This will disable that. I don't think his simple script does that. |
Hi roboknight, Thanks again for the wealth of information. I've learnt a lot from you. You are right. I was running Ubuntu 20.04 over 18.04 because of the former's capability to run it live from USB drive with persistence. The segmentation fault is due to the missing libsapi-utils and libsapi-dev for Ubuntu 20.04. I ran the bitleaker again using 18.04 and the whole process finished without any hiccup. Unfortunately/fortunately? my Thinkpad is not vulnerable to this. |
Hi @roboknight, |
Hi @dell224 , |
@kkamagui , |
Hi @roboknight , |
Hi
Napper working and get pcr vulnerable
Why in bitleaker fail.
And how change drive like /dev/sda3
To /dev/sda5
Sda3 is no lock
Sda5 have bitlock
The text was updated successfully, but these errors were encountered: