Active Topics
-
Firefox with Leste (5)
to Maemo 7 / Leste by teroyk - 1 day, 4 hrs ago -
Handbook (2)
to Maemo 7 / Leste by teroyk - 2 days, 4 hrs ago - more...
| The Following User Says Thank You to leiter For This Useful Post: | ||
 |
|
2012-01-11
, 22:45
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#12
|
As there hasn't been any 'showstopper' bug popping up, I've promoted TrueCrypt 7.1 into testing. If You feel that it fulfills Q&A criteria (i.e You've been using it, and haven't noticed major bugs), please vote for it, so it can enter "legendary" Extras at last:
http://maemo.org/packages/package_in...pt/7.1-maemo6/
First post was updated.
/Estel
Last edited by Estel; 2012-01-11 at 23:32.
http://maemo.org/packages/package_in...pt/7.1-maemo6/
First post was updated.
/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
Last edited by Estel; 2012-01-11 at 23:32.
| The Following User Says Thank You to Estel For This Useful Post: | ||
|
|
2012-01-11
, 23:33
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#13
|
As many of You already know, to get highest security level possible (i.e. when You want to protect your data against serious cracking attempts, not only ensuring that random thief wouldn't have access to your photos and contacts), one should encrypt swap. While it's rather trivial, it decreases swap performance - not by high amount, but always.
For people, that -like me - are concerned about max performance, yet would also like to have safe way to carry ''top-secret''
files on Your device (and work on them), I'm currently preparing a experimental solution. Concept look like this:
Legend (don't get used to names, they're only plain templates for easier understanding ):
/dev/truecrypt - our example encrypted partition.
/dev/cryptoswap - swap partition, that would get encrypted with masterpassword from '/dev/urandom' every time it's enabled (of course, every time using different password from, urandom, it isn't cached anywhere)
/dev/plainswap - regular swap partition
/.top-secret/area-51-plans.odf - a file stored in /dev/truecrypt, that is highly confidential and we wan't to be sure that it wouldn't leak in any case.
(optional):
/dev/lowcrypt - encrypted swap partition, that contain private files, which aren't of such priority (or interest to possible adversaries), which would require top-secret level of safety. Also, user would like to have it mounted "all the time" (from device bootup, to shutdown, for example, via automount script)
---
Normally, device uses a /dev/plainswap as enabled swap, and /dev/lowcrypt mounted ''all the time''. When user want to take a look on/modify area-51-plans.pdf, she/he enables /dev/cryptoswap as swap, disables swap on /dev/plainswap, mount /dev/truecrypt, and start having fun with area-51-plans.odf. After work/fun is finished, user unmount /dev/truecrypt, enables [b/]/dev/plainswap[/b] (which, on moment of enabling, have lower priority that still working /dev/cryptoswap), and disables /dev/cryptoswap.
Rationale (+ EUE, aka Easily Understandable Explanation):
For normal operation, we're using regular swap without any cryptographic slowdowns. Things that we have on /dev/lowcrypt are generally safe in case of thievery (if we use short timeout for lock code), as thief doesn't have password needed to mount it after reboot/reflash/whatever. Yet, things from /dev/lowcrypt can get into memory and swapped in swap partition. If someone would leave swap in "frozen" state (i.e. would not use it after thievery), and analyze swap partition using software designed to pull data from swaps, he would be able to get our private data/parts of it from swap. Trying to overwrite it in any way is utterly useless, due to wear-leveling on both eMMC and SD cards, and overwriting whole swap partition with zeros isn't too wear&tear-precautions friendly, anyway (let alone fact, that hardware wear-leveling on SD card ignore partitions layout, and throw chunks of data written into one logical partition, into whole hardware surface of card).
Generally, it's acceptable, as we don't expect someone to steal our device, just to suck swap for photos of our wife in bikini - still, we would (well, most of us) not like to see photos of our wife sold to porn site by some plain, lame thief (neither our wifes would like to), so TrueCrypt encryption of /dev/lowcrypt suits our needs, without requiring encrypting swap.
Yet, we have been recently contacted by UFO, which gave us plans of area-51, of course written as Open Document Format (area51-plans.odf). We are sympathetic towards Little Green Folks, and we're smart enough to know, that Mens in Black may be on our back soon. So, we use our top-secret /dev/truecrypt partition (that we *never* automount, always mounting it manually when needed, and unmount just after finishing messing on it) to store area51-plans.odf there. We don't want tracker to look there ever, so we've put it like /.top-secret/area51-plans.odf (tracker ignores folders with names starting as '.' - dot).
Then, every time we need to check something on our area51-plans.odf - whie preparing World Wide Conspiracy - we enable /dev/cryptoswap (encrypting it with password from /dev/urandom at the moment of enabling, it shouldn't take more than few seconds), disable /dev/plainswap, and mount or /dev/truecrypt, providing password. Then, we can safely look at our area51-plans.odf, without risk that it gets swapped out to unencrypted swap - it just land on encrypted swap, so adversaries gain nothing. Then, after finishing work, we unmount /dev/truecrypt, mount /dev/plainswap (no risk of swap transferring something there from /dev/cryptoswap, as plainswap gots lower priority initially), and disable /dev/plainswap (which, after this, is only one swap active, thus gaining highest priority).
That's the concept.
---
Of course, if someone want - let's say - open area51-plain.odf in LibreOffice, she/he need to ensure, that all LibreOffice caching etc also lands on encrypted partition (no matter on which one, as during work, we're using only encrypted swap, so no risk of swapping to plainswap - but, for paranoia security level, we can use /dev/truecrypt for this purpose, as our /dev/lowcrypt is mounted all the time, thus posing more risk of falling into adversary's hands mounted = decrypted), etc.
Also, to make it more convenient, I'm planning to prepare two scripts - lets name them for now [i]top-secret-start.sh and top-secret-stop.sh. First one would automatically do all work needed *before* we can access our /dev/truecrypt partition - enabling encrypted swap, disabling plain one, and at last, mounting /dev/truecrypt, thus opening TrueCrypt dialog, asking us for password. The latter would be executed after we finished our job on top secret encrypted partition - it would unmount /dev/truecrypt, enable plain swap, and disable encrypted swap.
Of course, those two script would require customization from user side - entering actual encrypted partition's and swap's location (instead of our funny /dev/truecrypt, /dev/cryptoswap and so goes on). Maybe in future, I would prepare a single, separate GUI for assisting in such one-time configuration, and release it as separate package.
---
This concept was created entirely in my head - it isn't based on any existing solution, that I'm aware of. So, people knowledgeable about encryption, TrueCrypt etc - if You see any rationale, why such approach would be insecure, please write here. I said - it is experimental, and if you find yourself in mood of trying it - before or after I release something related (because everyone can prepare something like that even now, based on my description) - don't blame me, if it turns out posing security threat. Yet, as for my current knowledge, it shouldn't.
/Estel
Last edited by Estel; 2012-01-11 at 23:46.
For people, that -like me - are concerned about max performance, yet would also like to have safe way to carry ''top-secret''
files on Your device (and work on them), I'm currently preparing a experimental solution. Concept look like this:Legend (don't get used to names, they're only plain templates for easier understanding
):/dev/truecrypt - our example encrypted partition.
/dev/cryptoswap - swap partition, that would get encrypted with masterpassword from '/dev/urandom' every time it's enabled (of course, every time using different password from, urandom, it isn't cached anywhere)
/dev/plainswap - regular swap partition
/.top-secret/area-51-plans.odf - a file stored in /dev/truecrypt, that is highly confidential and we wan't to be sure that it wouldn't leak in any case.
(optional):
/dev/lowcrypt - encrypted swap partition, that contain private files, which aren't of such priority (or interest to possible adversaries), which would require top-secret level of safety. Also, user would like to have it mounted "all the time" (from device bootup, to shutdown, for example, via automount script)
---
Normally, device uses a /dev/plainswap as enabled swap, and /dev/lowcrypt mounted ''all the time''. When user want to take a look on/modify area-51-plans.pdf, she/he enables /dev/cryptoswap as swap, disables swap on /dev/plainswap, mount /dev/truecrypt, and start having fun with area-51-plans.odf. After work/fun is finished, user unmount /dev/truecrypt, enables [b/]/dev/plainswap[/b] (which, on moment of enabling, have lower priority that still working /dev/cryptoswap), and disables /dev/cryptoswap.
Rationale (+ EUE, aka Easily Understandable Explanation):
For normal operation, we're using regular swap without any cryptographic slowdowns. Things that we have on /dev/lowcrypt are generally safe in case of thievery (if we use short timeout for lock code), as thief doesn't have password needed to mount it after reboot/reflash/whatever. Yet, things from /dev/lowcrypt can get into memory and swapped in swap partition. If someone would leave swap in "frozen" state (i.e. would not use it after thievery), and analyze swap partition using software designed to pull data from swaps, he would be able to get our private data/parts of it from swap. Trying to overwrite it in any way is utterly useless, due to wear-leveling on both eMMC and SD cards, and overwriting whole swap partition with zeros isn't too wear&tear-precautions friendly, anyway (let alone fact, that hardware wear-leveling on SD card ignore partitions layout, and throw chunks of data written into one logical partition, into whole hardware surface of card).
Generally, it's acceptable, as we don't expect someone to steal our device, just to suck swap for photos of our wife in bikini - still, we would (well, most of us) not like to see photos of our wife sold to porn site by some plain, lame thief (neither our wifes would like to), so TrueCrypt encryption of /dev/lowcrypt suits our needs, without requiring encrypting swap.
Yet, we have been recently contacted by UFO, which gave us plans of area-51, of course written as Open Document Format (area51-plans.odf). We are sympathetic towards Little Green Folks, and we're smart enough to know, that Mens in Black may be on our back soon. So, we use our top-secret /dev/truecrypt partition (that we *never* automount, always mounting it manually when needed, and unmount just after finishing messing on it) to store area51-plans.odf there. We don't want tracker to look there ever, so we've put it like /.top-secret/area51-plans.odf (tracker ignores folders with names starting as '.' - dot).
Then, every time we need to check something on our area51-plans.odf - whie preparing World Wide Conspiracy - we enable /dev/cryptoswap (encrypting it with password from /dev/urandom at the moment of enabling, it shouldn't take more than few seconds), disable /dev/plainswap, and mount or /dev/truecrypt, providing password. Then, we can safely look at our area51-plans.odf, without risk that it gets swapped out to unencrypted swap - it just land on encrypted swap, so adversaries gain nothing. Then, after finishing work, we unmount /dev/truecrypt, mount /dev/plainswap (no risk of swap transferring something there from /dev/cryptoswap, as plainswap gots lower priority initially), and disable /dev/plainswap (which, after this, is only one swap active, thus gaining highest priority).
That's the concept.
---
Of course, if someone want - let's say - open area51-plain.odf in LibreOffice, she/he need to ensure, that all LibreOffice caching etc also lands on encrypted partition (no matter on which one, as during work, we're using only encrypted swap, so no risk of swapping to plainswap - but, for paranoia security level, we can use /dev/truecrypt for this purpose, as our /dev/lowcrypt is mounted all the time, thus posing more risk of falling into adversary's hands mounted = decrypted), etc.
Also, to make it more convenient, I'm planning to prepare two scripts - lets name them for now [i]top-secret-start.sh and top-secret-stop.sh. First one would automatically do all work needed *before* we can access our /dev/truecrypt partition - enabling encrypted swap, disabling plain one, and at last, mounting /dev/truecrypt, thus opening TrueCrypt dialog, asking us for password. The latter would be executed after we finished our job on top secret encrypted partition - it would unmount /dev/truecrypt, enable plain swap, and disable encrypted swap.
Of course, those two script would require customization from user side - entering actual encrypted partition's and swap's location (instead of our funny /dev/truecrypt, /dev/cryptoswap and so goes on). Maybe in future, I would prepare a single, separate GUI for assisting in such one-time configuration, and release it as separate package.
---
This concept was created entirely in my head - it isn't based on any existing solution, that I'm aware of. So, people knowledgeable about encryption, TrueCrypt etc - if You see any rationale, why such approach would be insecure, please write here. I said - it is experimental, and if you find yourself in mood of trying it - before or after I release something related (because everyone can prepare something like that even now, based on my description) - don't blame me, if it turns out posing security threat. Yet, as for my current knowledge, it shouldn't.
/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
Last edited by Estel; 2012-01-11 at 23:46.
|
|
2012-01-12
, 00:10
|
|
Posts: 440 |
Thanked: 160 times |
Joined on Aug 2010
@ Las Vegas, NV
|
#14
|
Whatever it is beware even FBI's were not able to crack it: http://www.webcitation.org/query?url=g1.globo.com/English/noticia/2010/06/not-even-fbi-can-de-crypt-files-daniel-dantas.html
In case you forgot your password, you would have to say good bye to your precious data.
Noob part. I am still not sure what exactly is the purpose of the app: Will it ask for password if I connect my N900 with password protected (truecrypted) MyDocs partition to any pc?
In case you forgot your password, you would have to say good bye to your precious data.
Noob part. I am still not sure what exactly is the purpose of the app: Will it ask for password if I connect my N900 with password protected (truecrypted) MyDocs partition to any pc?
|
|
2012-01-12
, 01:03
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#15
|
It is full TrueCrypt implementation for N900 - You just got the same TrueCrypt, that You can install in your desktop, including GUI. So.you can encrypt partitions/file containers (be it on N900 eMMC itself, on microSD, or on some thing connected to N900, like HD's via hostmode). you can - of course- also mount them, decrypt, delete etc. I though it's clear enough in first post's description.
As for mass storage mode, obviously Your PC won't be able to see MyDocs content, if You encrypt it - without having TrueCrypt installed on PC. Even if so, it may be required to use USB Networking instead of Mass Storage (for example, via nice QtMobileHostpot program), but don't quote me on that, as I've never tried such strange combinatiuon myself.
If You want to just play a little with TrueCrypt and learn what it can do, use encrypted file container (You can create it anywhere, it may even sit inside MyDocs) - outside TGrueCrypt, it's a plain file, that you can copy, paste, move etc. when mounted via TrueCrypt, it's shown as container (let's call it quasi-partition), where you can have other files securely stored.
For reasons, that I've written in first post, encrypted file container isn't entirely secure, when used on flash-based media with hardware wear-leveling (as it's in the case of our eMMC or any SD card) - still would be a no-go tom decrypt for random thief that may pick up your device, but FBI or NSA *could* have a nice chance of decrypting it (especially, if file container is relatively old, due to wear-leveling things I've described in first post).
So, when top level security is required, it's best to encrypt whole partition (You can repartition your eMMC, see Community Wiki), and for top-top-top security, use for this purpose a *whole* freshly-formatted microSD card This way, we negate anti-criptographic side effects of wear leveling completely, although, even for partitions being a part of eMMC, chance that anyone - even Men in Blacks - could decrypt it, are minimal and purely theoretical).
---
If You - or anyone else - still doesn't understand what's TrueCrypt is for, please read TrueCrypt web page and documentation (google it or use links that I've provided in first page).
Have fun and be secure
/Estel
// Edit
Trivia - in case of mentioned "even FBI wasn't able to(...)'' article, they were just hoping, that he used some stupid password, derived from dictionary word, with none or too small/too common modifications. In either case - which seems to be what they've learned - even NSA can kiss their a**, as TrueCrypt is really a state-of-art cryptographic solutions, better than *any* commercial software you may find.
Also, TrueCrypt doesn't cheat you that You'll be secure no matter what - it's up to *you* to educate yourself about side-effects (like wear leveling) that may compromise security in extreme cases. fortunately, most popular concerns are verbosely listed in TrueCrypt documentation.
Last edited by Estel; 2012-01-12 at 01:06.
As for mass storage mode, obviously Your PC won't be able to see MyDocs content, if You encrypt it - without having TrueCrypt installed on PC. Even if so, it may be required to use USB Networking instead of Mass Storage (for example, via nice QtMobileHostpot program), but don't quote me on that, as I've never tried such strange combinatiuon myself.
If You want to just play a little with TrueCrypt and learn what it can do, use encrypted file container (You can create it anywhere, it may even sit inside MyDocs) - outside TGrueCrypt, it's a plain file, that you can copy, paste, move etc. when mounted via TrueCrypt, it's shown as container (let's call it quasi-partition), where you can have other files securely stored.
For reasons, that I've written in first post, encrypted file container isn't entirely secure, when used on flash-based media with hardware wear-leveling (as it's in the case of our eMMC or any SD card) - still would be a no-go tom decrypt for random thief that may pick up your device, but FBI or NSA *could* have a nice chance of decrypting it (especially, if file container is relatively old, due to wear-leveling things I've described in first post).
So, when top level security is required, it's best to encrypt whole partition (You can repartition your eMMC, see Community Wiki), and for top-top-top security, use for this purpose a *whole* freshly-formatted microSD card This way, we negate anti-criptographic side effects of wear leveling completely, although, even for partitions being a part of eMMC, chance that anyone - even Men in Blacks - could decrypt it, are minimal and purely theoretical).
---
If You - or anyone else - still doesn't understand what's TrueCrypt is for, please read TrueCrypt web page and documentation (google it or use links that I've provided in first page).
Have fun and be secure
/Estel
// Edit
Trivia - in case of mentioned "even FBI wasn't able to(...)'' article, they were just hoping, that he used some stupid password, derived from dictionary word, with none or too small/too common modifications. In either case - which seems to be what they've learned - even NSA can kiss their a**, as TrueCrypt is really a state-of-art cryptographic solutions, better than *any* commercial software you may find.
Also, TrueCrypt doesn't cheat you that You'll be secure no matter what - it's up to *you* to educate yourself about side-effects (like wear leveling) that may compromise security in extreme cases. fortunately, most popular concerns are verbosely listed in TrueCrypt documentation.
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
Last edited by Estel; 2012-01-12 at 01:06.
|
|
2012-01-15
, 14:22
|
|
Posts: 115 |
Thanked: 342 times |
Joined on Dec 2010
|
#16
|
: Will it ask for password if I connect my N900 with password protected (truecrypted) MyDocs partition to any pc?
[quote}Whatever it is beware even FBI's were not able to crack it[/quote]
What if they are saying that so you think you are secure while they in fact cracked it :P? Well, unlikely. Anyway, the FBI isn't the NSA, who I think should be the secret service in the world with the biggest chances to crack it. However, it uses AES, Twofish or Serpent, which are considered safe if implemented corrected. If they know a method to crack those algorithms in a reasonable amount of time, the IT world is in big trouble.
Last edited by NIN101; 2012-02-08 at 20:39. Reason: URL rewrite
| The Following User Says Thank You to NIN101 For This Useful Post: | ||
|
|
2012-01-15
, 18:19
|
|
Posts: 124 |
Thanked: 105 times |
Joined on Jul 2010
|
#17
|
Originally Posted by Estel
I wanted to keep decryption on the n900 too, for the same reasons as NIN101. (plus that way you don't have to install TC on the PC)
As for mass storage mode, obviously Your PC won't be able to see MyDocs content, if You encrypt it - without having TrueCrypt installed on PC. Even if so, it may be required to use USB Networking instead of Mass Storage (for example, via nice QtMobileHostpot program), but don't quote me on that, as I've never tried such strange combinatiuon myself.
Finally managed to get it set up the way I want this weekend.
I like my method because it's automatic and transparent:
-it mounts MyDocs and SD card as normal when you're not using TC
-if a decrypted TC volume is available, it mounts that instead of MyDocs.
-you can use it with more than one volume (though only the first one decrypted will mount - if you want to simultaneusly access multiple volumes other changes will need to be made)
For example on my phone i have a file container volume and a partition volume - the first volume I decrypt will mount over USB, doesn't matter which one it is
-you can still normally access the volumes on the n900 itself - no need to mount the TC volumes differently
The changes are made it /usr/sbin/osso-usb-mass-storage-enable.sh
(backup this file beforehand)
First I added IF statement that checks for the presence of /media/truecrypt1
If it exists then an alternate snippet is executed that mounts
the decrypted TC block device instead of MyDocs
(in most cases this seems to be /dev/mapper/truecrypt1
But you can doublecheck on your device with truecrypt -l, if it's different (i.e /dev/loop0) use that instead)
(I found that snippet in one of titan's posts, thanks to him)
find the section below (it's at the end of the file) and add code in red:
Code:
if [ $# = 1 ]; then
STR= 'cat $LUN0'
if [ "x$STR" = "x" ]; then
if [ -e /media/truecrypt1 ]; then
DEV=/dev/mapper/truecrypt1
echo $DEV > LUN0
else
echo $1 > LUN0
fi
else
echo $1 > LUN1
fi
fi
you need to manuall run /usr/bin/osso-mass-storage-disable.sh
You will then be able to dismount. (Or can reboot the phone)
Last edited by nman; 2012-01-17 at 15:26. Reason: Changed script to reflect correct filenames used by TC 7.X
| The Following 2 Users Say Thank You to nman For This Useful Post: | ||
|
|
2012-01-15
, 23:04
|
|
Posts: 124 |
Thanked: 105 times |
Joined on Jul 2010
|
#18
|
Ugh, I know what the problem is...just realized I was using version 6.X of truecrypt.
Version 7 doesn't seem to create /dev/mapper/truecrypt1, so my changes of course do nothing.
A quick look shows /media/truecrypt1 is the mount point for /dev/loop1 now.... I'll play a bit later with replacing /mapper/truecrypt1 with this loop1 to see it that fixes things.
Version 7 doesn't seem to create /dev/mapper/truecrypt1, so my changes of course do nothing.
A quick look shows /media/truecrypt1 is the mount point for /dev/loop1 now.... I'll play a bit later with replacing /mapper/truecrypt1 with this loop1 to see it that fixes things.
| The Following User Says Thank You to nman For This Useful Post: | ||
|
|
2012-01-15
, 23:04
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#19
|
Thanks NIN and nman! Unfortunately, the...
Any hints greatly appreciated, as mass-storage'ing TC partitions without requirement to mount them (in TC) without filesystem first, would be great thing to have.
---
On the other hand, the:
...replacing /dev/mapper/truecrypt1 with actual truecrypt device we want to map.
One flaw noticed - even, if we mount partition via truecrypt as read-only (of course, without filesystem), after mass storage'ing it, it's possible to both read and write. So, be careful with partitions containing hidden volumes. I wonder if it could be fixed by some edit to osso-usb-(...)-enable.sh - one that would made it to respect rw settings, or just one that set is as read-only for mass storage (we would just make copy of osso(...)-enable.sh under different name, and use it to mount read-only mass storage).
Also, I have no idea if it respect hidden volume protection. When we have such partitions mounted, instead of being /dev/mapper/truecrypt1 (etc), they're /dev/loop0, so theoretically, mounting such loop0 to mass-storage should respect reserved zone for hidden volume. Yet, only one method to get sure is actually checking it in practice - mounting partition containing hidden volume with protection ON, and trying to write file large enough to either trigger read-only switch, or corrupt hidden volume
---
In any case, it's really a great drop-in replacement for expensive and (often) insecure "encrypted" pendrives. Really impressive. After hammering current doubts (nman approach), I'll summarize it on the first page - for now, I've linked instructions for both methods.
/Estel
Originally Posted by nman
...doesn't work for me. I've also tried copy'ing osso-usb-(...)-enable.sh with a different name, and running it manually. It gives a G_FILE_STORAGE_READY response (just like original oss-usb(...)-enable.sh), but on the desktop computer, it's still just like without running it at all. Also, if I connect device in mass storage mode using *original* osso-usb-(...)-enable.sh - thus, gaining access to regular MyDocs - and run *modified* osso-usb-(...)-enable.sh on top of it, despite returning G_FILE_STORAGE_READY message, it don't even disconnect MyDocs (it' still available from desktop).
Code:if [ $# = 1 ]; then STR= 'cat $LUN0' if [ "x$STR" = "x" ]; then if [ -e /dev/mapper/truecrypt1 ]; then DEV=/dev/mapper/truecrypt1 echo $DEV > LUN0 else echo $1 > LUN0 fi else echo $1 > LUN1 fi fi
Any hints greatly appreciated, as mass-storage'ing TC partitions without requirement to mount them (in TC) without filesystem first, would be great thing to have.
---
On the other hand, the:
Originally Posted by NIN101
...works for me. Also, I would like to mention, that instead of writing quite sophisticated '/usr/sbin/osso-usb-mass-storage-enable.sh `truecrypt -t -l | grep [path to volume] | cut -f3 -d" "`' (or saving it as .sh), one can just use:
I played around
Code:
/usr/sbin/osso-usb-mass-storage-enable.sh /dev/mapper/truecrypt1
One flaw noticed - even, if we mount partition via truecrypt as read-only (of course, without filesystem), after mass storage'ing it, it's possible to both read and write. So, be careful with partitions containing hidden volumes. I wonder if it could be fixed by some edit to osso-usb-(...)-enable.sh - one that would made it to respect rw settings, or just one that set is as read-only for mass storage (we would just make copy of osso(...)-enable.sh under different name, and use it to mount read-only mass storage).
Also, I have no idea if it respect hidden volume protection. When we have such partitions mounted, instead of being /dev/mapper/truecrypt1 (etc), they're /dev/loop0, so theoretically, mounting such loop0 to mass-storage should respect reserved zone for hidden volume. Yet, only one method to get sure is actually checking it in practice - mounting partition containing hidden volume with protection ON, and trying to write file large enough to either trigger read-only switch, or corrupt hidden volume
---
In any case, it's really a great drop-in replacement for expensive and (often) insecure "encrypted" pendrives. Really impressive. After hammering current doubts (nman approach), I'll summarize it on the first page - for now, I've linked instructions for both methods.
/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
| The Following User Says Thank You to Estel For This Useful Post: | ||
|
|
2012-01-16
, 01:58
|
|
Posts: 124 |
Thanked: 105 times |
Joined on Jul 2010
|
#20
|
Estel my post above was a reply to yours, I don't know why it timestamped before.
Anyway I managed to get this to work with 7.x version - the script in my previous post was updated.
Version 7.x uses /dev/loop0 (at least on my n900) instead of /dev/mapper/truecrypt1...problem is, loop0 exists whether or not a decrypted TC volume is present, so can't use it's existence to trigger the script change.
But, decrypted volume is still mounted to /media/truecrypt1, and that does get created upon decrypt and removed on dismount, so I used that to trigger.
Then the script will mount /dev/loop0 instead of /dev/mmcblk0p1.
I am a bit worried this won't work if loop0 is used by something else and truecrypt ends up using loopX instead. It would be really good to find a way to know where the decrypted volume is mounted and then pass that to the script.
Actually this can be obtained using truecrypt --list. but I am too noobish to know how to capture and use that output
*Edit - After using my script above I occasionally get an error where TC will refuse to dismount the volume (even after disconnecting from PC)
In this case I manually execute /usr/sbin/osso-usb-mass-storage-disable.sh
After that I can dismount properly using TC.
For me no big deal since I use a queen beecon widget to dismount, so I just added that command to the widget.
But would be nice to get it fixed properly...
Last edited by nman; 2012-01-16 at 02:16.
Anyway I managed to get this to work with 7.x version - the script in my previous post was updated.
Version 7.x uses /dev/loop0 (at least on my n900) instead of /dev/mapper/truecrypt1...problem is, loop0 exists whether or not a decrypted TC volume is present, so can't use it's existence to trigger the script change.
But, decrypted volume is still mounted to /media/truecrypt1, and that does get created upon decrypt and removed on dismount, so I used that to trigger.
Then the script will mount /dev/loop0 instead of /dev/mmcblk0p1.
I am a bit worried this won't work if loop0 is used by something else and truecrypt ends up using loopX instead. It would be really good to find a way to know where the decrypted volume is mounted and then pass that to the script.
Actually this can be obtained using truecrypt --list. but I am too noobish to know how to capture and use that output
*Edit - After using my script above I occasionally get an error where TC will refuse to dismount the volume (even after disconnecting from PC)
In this case I manually execute /usr/sbin/osso-usb-mass-storage-disable.sh
After that I can dismount properly using TC.
For me no big deal since I use a queen beecon widget to dismount, so I just added that command to the widget.
But would be nice to get it fixed properly...
Last edited by nman; 2012-01-16 at 02:16.
| The Following User Says Thank You to nman For This Useful Post: | ||
 |
| Tags |
| cryptography, encrypted, kernelcrypto, security, truecrypt |
«
Previous Thread
|
Next Thread
»
| Thread Tools | |
|
All times are GMT. The time now is 14:57.
Thank you very much.
P.s. The gui was just to small for my eyes.
Last edited by leiter; 2012-01-11 at 18:11.