How to crack truecrypt bootloader generator#
How to crack truecrypt bootloader manual#
How to crack truecrypt bootloader password#

Then losing your passwords is the least of your concerns. That way the only person getting those codes is anal raping you. Next time keep your passwords on note inside a watertight anal plug and wear at all times for maximum security. Your only bets at this point is the use the recovery media you made if available or brute force it. I would avoid using the CID of the SD card as a kind of 'password' - even if it cannot be changed, there are ways to spoof this value.Д¬opy protection is already included in the SD card specification as CPRM.If there was a way it would negate the entire point of the FDE. There are several full-disk encryption options that are already available and have been demonstrated to work just fine on the Raspberry Pi. TL,DR: Don't re-invent the wheel when it comes to encryption and security, stick with the tried and true.

How to crack truecrypt bootloader generator#

If an attacker has access even to a compiled kernel, analyzing something like a pseudo-random number generator is probably trivial unless the code is obfuscated on purpose. Conversely, de-assembly of a compiled application is often trivial, and there are many tools which can be used to assist with reverse engineering assembly back into another higher-level language. It's very difficult to decompile anything.

How easy is to decompile the kernel and find those custom encrypting

How to crack truecrypt bootloader manual#

It might be better to use a pre-made encrypted bootloader (like TrueCrypt or LUKS, which both work on the Raspberry Pi) and avoid having to make any manual kernel modifications. This would make it easier to brute-force the password, especially if one is just emulating an SD card after cloning yours (which is something else you might want to consider).ДЇinally, using any kind of pseudo-random number generator already has some intrinsic flaws, precisely because it's not random - there is a reason it's called pseudo-random. Some people have even demonstrated the ability to overwrite the CID with certain SD cards.

The CID of an SD card is only supposed to be read-only, but it's not uncommon to find non-compliant flash memory devices in this day and age. Without a doubt, using a predefined CID as a password, as well as using a custom pseudo-random number generation function. How hard it is to 'break' your setup depends on the number of bits of entropy in whatever method you're using to sign/encrypt the filesystem itself (as this determines the total number of unique combinations that can be used to brute-force the password). How easy it would be to break this setup (to decrypt the rootДЇilesystem and make it boot from any sd card)?

I understand that if using a SD card emulator someone can make a copy of this system start but this is OK with me, because its pretty difficult and not anyone can do this.(also not anyone will want to deal with emulators).

The pseudo random algorithm for initramfs encrypting will be in fact RC4, just the key will be generated using some custom function, because if I just store the key in a byte array it makes it dead simple to retrieve it (yeah this is security through obscurity but there seem no other way).

The root device will be encrypted with LUKS (aes256) and the key will be generated by some HMAC function using SD card's CID and some salt.

My question is: How easy it would be to break this setup (to decrypt the root filesystem and make it boot from any SD card)? What are the most weakest parts? How easy is to decompile the kernel and find those custom encrypting functions?Д®DIT: Here are some corrections so you don't waste time with the obvious things:

How to crack truecrypt bootloader password#

So after the bootloader loads kernel and initrd, the kernel decrypts the initrd and executes its init script, which will generate the password and mount the root filesystem.

The system itself is stripped down so there is no way to use a keyboard or external storage.

Kernel is modified to have the same encrypting function, which works as decryptor.

Now here is the most interesting/suspect part: The initrd itself is encrypted using a custom C function, basically each byte is XOR'ed using a custom made pseudo random generator.

Initrd will try to mount the filesystem using that generated password. (a hash function is used, did not decide yet over md5 or sha1).

The initrd generates the filesystems' password according to the CID of the SD card.

The approach uses an initrd to mount an encrypted root filesystem.

I am trying to copy-protect some work, which is a bootable SD card booting a Linux kernel on ARM device (Raspberry Pi).