So I noticed that with hardware TPM you dont need a password (you just save the private key to external USB).
Now, imagine someone stole my PC (which has the TPM hardware on it), couldn't they just install a fresh copy of windows 10 in a new hard drive, connect my old drive that was protected with bitcopy as secondary drive, and access all my data?
because the TPM hardware module is still on the same motherboard.
Remember, they didn't just steal the HDD but he whole PC.
Thanks for reading,
Sean
https://learn.microsoft.com/en-us/windows/device-security/bitlocker/bitlocker-frequently-asked-questions#bkmk-deploy
What system changes would cause the integrity check on my operating system drive to fail?
The following types of system changes can cause an integrity check
failure and prevent the TPM from releasing the BitLocker key to
decrypt the protected operating system drive:
Moving the BitLocker-protected drive into a new computer.
Installing a new motherboard with a new TPM.
Turning off, disabling, or clearing the TPM.
Changing any boot configuration settings.
Changing the BIOS, UEFI firmware, master boot record, boot sector, boot manager, option ROM, or other early boot components or boot
configuration data.
Related
I am attempting to write an x86_64 PC emulator. I was wondering in what memory location the UEFI is mapped. I know that a BIOS is usually mapped from 0xf0000-0xfffff and 0xf0000000-0xffffffff. Is UEFI mapped to the same locations?
Yes, the UEFI firmware is loaded to the same locations as well as legacy BIOS. Otherwise, why is cs:ip is pointing 0xFFFFFFF0 in its initial state?
Check out the OvmfPkg in EDK II. This is an open-source UEFI firmware for virtual machines. You can load it into famous emulators like Bochs, QEMU.
You can also use VMware's EFI firmware, but in that it is proprietary, you might want to read VMware's license before you really want to proceed with it.
UEFI is not loaded in a specific memory location. Something needs to be placed where the processor starts fetching instructions, and then SEC and PEI stages prepare for DXE to be uncompressed somewhere dynamically - loading individual PE/COFF as it goes.
The way you find out what memory regions are reserved is by calling the GetMemoryMap boot service at runtime.
You may find the documentation of the existing EDK2 virtual machine port helpful.
My system is not infected with ransomware. I was just thinking about ways to deal with it if it ever happened. Since I can boot my windows PC with a Linux USB and access the HDD, shouldn't it be possible to use the USB drive to back-up the HDD after ransomware was installed? Most ransomware uses the browser to lock up the computer, does it not? All anyone would have to do is boot with a Linux USB and transfer the files from the HDD to an external drive. Then reformat the HDD, reinstall windows and be on their merry way. Unless BIOS is infected (which is unlikely) there should be no issue, right?
I would just like to know if this is a viable solution.
Most ransomware encrypt your HDD. So, if you were to boot to your Linux Drive, you will not be able to view the files in your HDD as it is encrypted and you don't know the key. Most common ransomware use your encrypted data as ransom and will only give you the decryption key if you pay them their ransom. So, using a USB drive to save your computer will not work.
However, you should be able to format your drive from the Linux bootable drive, but you will still lose all your data
I've got a CentOS setup with UEFI Secure Boot turned on. I'm working on debugging a set of BIOS tools that were developed quite some time ago. However when Secure Boot is turned on it appears user applications are not allow to get higher privilege levels any more.
Essentially I have a kernel module that maps a virtual to physical memory buffer which is used to communicate to the BIOS. The buffer is setup and a software SMI is called so the BIOS can retrieve it, process it, and put the results back into the buffer.
I'm trying to figure out how this can still be done with Secure Boot enabled? The kernel module can still setup the buffer, but it appears like I'm unable to call into my character device setup by the kernel module.
Any ideas?
I generally hear that LINUX OS can be downloaded on flash, pen drive (floppy disk?) etc. How we can do that?
I have RHEL 5.4 source code - so how can download it into pen drive and how much space is required?
What other functionality I can add apart from the OS - so that when I boot from that storage device I can make use of them?
Can we download Linux OS into micro-controllers also?
I generally hear that LINUX OS can be downloaded on flash, pen drive (floppy disk?) etc. How > we can do that?
If you can't get it to work on your own, you can buy a ready made Linux on a USB drive from
a site like http://www.osdisc.com or http://www.cheapbytes.com
Not all PCs, especially older PCs, can boot from the USB Drive. Even some newer PCs are beginning to ship with security features that can interfere with booting code. When it does work, you have to find out the proper way to boot the USB drive. You might have only a few seconds during reboot to enter the right key, or it will boot Windows (if Windows is installed). The key to get to the BIOS Boot Menu might be delete or escape or F10 or some other key (varies with PC motherboard manufacturer). A message on the screen that flashes by rather quickly might mention keys you can press. Boot to a specific device or changing boot order can also often be found in the BIOS setup.
There is a linux utility called unetbootin that will create a USB drive that will boot linux. It does not create a USB boot drive from a source code distribution, but rather from an ISO file representing a live CD or the live CD itself.
Since large USB drives (e.g. 32GB) are relatively inexpensive, if you want to compare systems or have multiple systems there is a way to have multiple linux and other operating systems on one USB drive and be able to choose which to boot into. See, for instance, http://www.pendrivelinux.com/ which has a wide variety of procedures for making a bootable USB using either windows or Linux to set up the USB and booting a variety of systems.
I have RHEL 5.4 source code - so how can download it into pen drive
and how much space is required?
RHEL 5.4 is a bit old. You need the Live CD, if there was one.
The ISO file can take up 600+MB. You want space left over to use the system. 2GB for the pen drive is OK. Sometimes you can get by with less.
What other functionality I can add apart from the OS - so that when I
boot from that storage device I can make use of them?
Upon boot the operating system will often recognize sound cards, other usb devices, the hard drives, etc. You need to know how to use these things within Linux, and how to enable them if they are not configured. Some Linux distributions have a place to put packages that are to be autoinstalled when a USB pen drive based system initializes. In this way you can "install" software from the distribution archives that are not included on the standard live system, even if you don't have internet access.
Can we download Linux OS into micro-controllers also?
People run it on raspberry pi and such, but the versions of Linux on non-PC hardware that has low memory are often quite tiny compared to a desktop version. They can be tiny enough to be challenging to work with or expand.
This might seem like a stupid question but...
After using a USB to install Ubuntu, is it possible to use it as a regular USB again or is it like a CD install and the USB is now only good for installing Ubuntu?
Thanks.
Yes you can.
Infact you can keep the Ubuntu setup as it is and use the remaining free space to store other things, just incase you need Ubuntu installation in future.
You can use it normally, just be sure you have cleaned up the MBR for the case you leave the device plugged in at restart (when USB boot is still enabled).
Easiest is to format the whole partition (or use a partition manager to clean up the whole device). GParted should be able to do this for you.
Some (sketchy!) technical background:
The USB device is a flash device, where bits are stored non-volatile, but eraseable and changeable. Bits at a normal CD-ROM will really be "burned" in as the reflection capacity will be permanently changed when creating a CD. When booting up your computer, there is small memory ROM that contains a bootloader, that is looking up for devices containing a MBR at the first 512 bytes, that will be executed and load the OS (or in your case the first steps of the Ubuntu installation process).
So if you want to use the USB device as normal data storage again, you should also clear up these first 512 Bytes, as the bootloader from the USB could be loaded otherwise when leaving the device plugged in at reboot. Then the bootloader could throw an exception, as it would normally expect the Ubuntu installation files to be present onto this device.