Database Users

sdcard encryption

I'd like to keep my data private (in case anyone finds the phone). has anyone got truecrypt to compile for the G1 ?

There's a lot more to making a program work in a given environment than just compiling it for the target processor...
If what you wanted to do was akin to running TC's system volume encryption, significant hacking and writing of new code would have to occur, not to mention hacking of the Android boot process.
It would probably be easier to just write a new program from scratch.

are there any other options for having an encrypted volume ?

ido said:
are there any other options for having an encrypted volume ?
Click to expand...
Click to collapse
Are you talking about having the whole partition encrypted, or just having an encrypted volume on the SD card with some data in it?
After setting up a debian partition on my card (a la this), the native "cryptsetup" mechanism in conjunction with a loop-mounted image works fine. Here's what I did from the debian bash shell:
Install cryptsetup from the debian repo:
Code:
apt-get install cryptsetup
Create an empty image (this is for 1 GB):
Code:
dd if=/dev/zero of=/sdcard/file.img bs=1 seek=1G count=1
Mount the image on a loop device:
Code:
losetup -f
(returns the next available loop device - probably /dev/loop2)
losetup /dev/loop2 /sdcard/file.img
Create an encrypted abstraction over the block device, using AES and a passphrase ('encvol' is just a name that can be anything):
Code:
cryptsetup -y create encvol /dev/loop2
(enter passphrase to use for this volume when prompted. the '-y' option prompts twice for verification)
Create an ext2 filesystem on the encrypted device:
Code:
mkfs.ext2 /dev/mapper/encvol
Mount the encrypted volume:
Code:
mount /dev/mapper/encvol /sdcard/mnt (or wherever)
I might have had to install losetup separately from the repo as well, I don't remember.
To mount it again later and use, after rebooting or manually unmounting, you need to do the losetup, cryptsetup (don't need the '-y' option anymore), and then mount the /dev/mapper/encvol device.
- Chris

I don't want to encrypt the whole drive, a bit afraid to do so, since I think there are things the G1 does on the sd card that wouldn't handle it well (like mounting/unmounting when sharing the usb drive, etc)
have you tested this ?

As I said, the steps I listed above are what I did, and yes, they work for me. Obviously, you'd want to take precautions before doing anything funky involving data that is valuable to you, as always, but I can say that the general scenario of reading and writing to a loop device, backed by an image file on my FAT32 SD card partition, through a cryptsetup indirection using AES (defaults), worked for me in a Debian shell on the G1 no differently than as if running on Ubuntu, for example.

[Q] [Help]

Hey i have really messed up my nexus 4.Please help.I'll tell you my problem in short:I have flashed recovery.img onto userdata by mistake using quikIMG.So now the phone got reset and the whole phone was seemed wiped.There was nothing on the phone.Thats what i assumed after peeking into galary/music etc but when i connected my phone to the pc it is showning that the phone's 10gb is used.Basically it is showing that the data is still there.Can you tell me any way to bring back the data?

Try factory reset

This may or may not work, no guarantees. This will be difficult, time consuming, and you must do everything exactly as written; so read it first and ask questions before you begin. I am using a Windows PC, most of these commands will be similar on other OS's, those when in the adb shell are identical. This will require adb and a custom recovery (I use TWRP, so I'll be able to offer TWRP specific help quicker), find a method to flash that before you begin, and find where that recovery keeps it backup files. Also this will require you to flash a rooted ROM, of the same android version you had before: if you had stock, I recommend you flash stock and root it; either way, have that ready to go before you start. Lastly, the worst case scenario will require you to have a linux system and possibly some kind of removable media (USB stick, external HDD, etc), you can just boot a linux live disk, and that's what I'll be doing with Ubuntu; again, have this ready first. There will come a point about mid way through, where, depending on the results you may need to wait for me to follow up with you, I will try to do this in a timely manner, but I can't promise anything.
Basically what we are going to do is explore the file system in an adb shell while it is booted to a custom recovery, hopefully from there your /data and /sdcard partitions will still be intact; if they are not we may still be able to recover some of your data. If they are intact you can simply use the recovery to make a backup of them.
And so, with your phone connected to your computer, boot to recovery. Then open a command prompt and enter:
Code:
adb shell
cat /proc/mounts
The output will look like:
/dev/block/mmcblk0p23 /data ext4 rw,relatime,data=ordered 0 0
/dev/block/mmcblk0p23 /sdcard ext4 rw,relatime,data=ordered 0 0
/dev/block/mmcblk0p22 /cache ext4 rw,relatime,data=ordered 0 0
Click to expand...
Click to collapse
First is the block, then the mount point, then the file system type, last is information about how recovery treats it.
If you do not see /dev/block/mmcblk0p23 associated with a mount point then enter:
Code:
mount -o rw /dev/block/mmcblk0p23 /data
mount -o rw /dev/block/mmcblk0p23 /sdcard
If you get an error on both of these then skip to the breakt.
Now check both these directories to ensure it is the data you expect it to be, enter:
Code:
cd /data
ls
cd /sdcard
ls
Maybe go down a few levels to confirm your data is really there. If the output doesn't look right, then skip to the break.
Otherwise, enter:
Code:
exit
Use the phone screen to navigate to the backups menu and backup data.
When the backup is complete use adb pull to copy the backup onto your computer, this may take a very long time.
Code:
adb pull /sdcard/TWRP TWRP
Now flash your ROM, including a data wipe, and boot it, once it is running fully, reboot into recovery and push the backup to the phone.
Code:
adb push TWRP /sdcard/TWRP
Use the phone screen to restore the data.
--------------------THE BREAK, cause XDA automagically made these two posts one, ****ers--------------------
Hopefully you got this sorted out with the first part, this part may not work at all, and it will be a lot more tedious if it does. So, at this point something happened which indicates /mmcblk0p23 really did lose the data, so we'll just copy the whole thing and explore that copy in linux to extract what data you can.
With the phone in recovery, and a command prompt in an adb shell:
Code:
dd if=/dev/block/mmcblk0p23 of=/tmp/userdata.ext4
This may take a REALLY long time. When it is done, enter:
Code:
exit
adb pull /tmp/userdata.ext4
This will take just as long or longer. Transfer userdata.ext4 to your removable media device. And boot to your linux setup. Open a terminal window in the directory with userdata.ext4 enter:
Code:
sudo mkdir userdata
sudo mount -o loop userdata.ext4 userdata
cd userdata
ls
Now if any of your data still exist in a form I'd be able to help you recover, it will be in this directory, userdata. If you see something that you recognize, or that you know you need, copy it and save it to the removable media. After that you can reboot your system.
Go ahead and flash your new ROM now, let it fully book, and then copy back whatever you managed to save.
I kinda lost steam there toward the end, sorry, it's 0316 here. If anything is unclear ask away. Good luck.

[Q] ZTE Open backing up user partition using ADB

I have a ZTE Open (US Ebay edition - with root permissions).
I am trying to use ADB to backup the user data partition from the device (either via dd in the shell or ADB "pull" commands). I have also stopped b2g before commencing a "pull" command, without any luck.
Each time I manage to get some data off the device but the user partition is incomplete (i.e. the YAFFS2 file system is corrupted). The size of the partition is accurate (as reported from the shell) but the header of the file system appears to be truncated with random bits of data.
Does anyone know of a way to back up these partitions using ADB or dd in the shell?
I don't want to install CWM.
Thanks

[Solution] Customize or update the factory image for stock recovery

The stock recovery on the Nook Simple Touch has a routine to restore the device to factory state, wiping everything in the process. It is initiated on the 8th unsuccessful boot (unsuccessful := interrupted before the boot counter could be reset). The image is stored on the "/misc" partition, /dev/block/mmcblk0p3, as /factory.zip. On my device, it's version 1.0.1 (file size: 108460423, MD5 sum: 3ae0d4d9869330dec639a7da9c50fa72). Not very useful. So, how about customizing it? Or at least upgrading it to stock 1.2.1?
When restoring to factory state, the /cache and /data partitions are wiped independently by the stock recovery. As for the files inside the ZIP, there is no difference between the factory image and the OTA (over-the-air) update (nook_*_update.zip). The format of both files is the standard Edify ("updater-script") style. If you have your own script you can put it there for easy restoration. If you don't, you can at least upgrade the factory image there to 1.2.1, the latest version. The example is for the latter case, but all the steps will be the same, except the first one.
Please do not follow these instructions blindly. Instead, read them critically and adjust to your situation, adding extra steps such as backups where necessary. Make sure that you don't mind if everything from your device is erased in the process.
Remove B&N cruft from the ZIP update header
Start with the file nook_1_2_update.zip (get it here from B&N). Make sure you have the right file: size 121323347, MD5 sum: 30822c2927482380c325a47dc060daee. Note that while a well-formed ZIP file starts with the letters "PK" (from the initials of Phil Katz, the original developer of the ZIP format), the B&N ZIP has some proprietary gibberish at the beginning:
Code:
...............'1.2.1.24.carbon1_2.gossamer.rrdp.s70455.......XOLBsPWsxv0saXev7rdGBBrQLzdM74ai2CM4h6oD/D3S9xeKq8eFYW7j0+MgLohN4x/3tyIYaZV6YiLEi7gLXq+7XjvWV4KaTGvNw0wM6x11IPOEzYwmHryagnY91XjkfKTjwKR8XC3SkSRu4TT01DZ6lfqsw6MZO18AFz48GEjXcxKy8SQZyhA++kobYWlcC8jNa/EmkGgVJien7QJ4LvR8N5Bftk11WRTOy6+BSQQgdBh4K/i2WI0TqfpH7JC+6vNp5rb61KTXpZIMLHGyZloYca68mnn4rmr1SKqodpffgSmYI+f7DPt7RgBEkXGz20x+3kKA+OcPbd1QKvIwd+A==.........;=.
First 418 bytes of nook_1_2_update.zip. Unprintable characters replaced with dots.
Unzip and other unpackers will get through this just fine so you might not even notice it but it will prevent the file from working as factory image for the stock recovery, so let's start by getting rid of the cruft. There are at least three options here: (1) use dd(1) (UNIX shell or Windows CLI), (2) use Free Hex Editor (Windows GUI), (3) unzip and repack again. The dd command if you're lucky to have a recent version is:
Code:
dd if=nook_1_2_update.zip of=factory.zip skip=418bytes
- or -
Code:
dd if=nook_1_2_update.zip of=factory.zip iflag=skip_bytes skip=418
Option (3) will break the B&N signature on the ZIP. Theoretically, if the signature is preserved, the file should work as-is as the new factory image as it matches the key stored in the recovery). It didn't work for me but I didn't try too hard because what I want to do is to use a custom image anyway so feel free to check for yourself (skip to the last step).
Otherwise, if you are using the stock update file that you want to sign again, you need to remove the signature that is already there. Supposing your soon-to-be new factory image file is called factory.zip, the way to do it is:
Code:
zip -d -q factory.zip META-INF\CERT.SF META-INF\CERT.RSA META-INF\MANIFEST.MF
Insert your key into stock recovery RAM disk image
For customized factory.zip signed with your own key, we need to tweak the recovery image a bit.
Extract the image from the update ZIP:
Code:
unzip -j nook_1_2_update.zip ramdisk-recovery.img
Replace the file res/keys (see attachment) in the image, using XDA user Renate NST's bootutil.exe tool:
Code:
bootutil /r ramdisk-recovery.img res\keys
You can also leave the old key in place and append the new one, just make sure there is nothing in between them (not even whitespace). And here are the alternative steps to unpack and repack the image using just the standard tools, which might come handy on UNIX:
Unpack:
Code:
dd if=ramdisk-recovery.img bs=64 skip=1 | gzip -cd | cpio -id
Repack:
Code:
find . -not -name ramdisk-recovery.img | cpio -oc | gzip -c9 | mkimage -A arm -O linux -T ramdisk -C gzip -a 0 -e 0 -d - ramdisk-recovery.new.img
Now the image just needs to be installed:
Code:
adb shell mkdir /data/boot
adb shell mount -t vfat /dev/block/mmcblk0p1 /data/boot
adb push ramdisk-recovery.img /data/boot/uRecRam
adb shell umount /data/boot
adb shell rm /data/boot
Sign and install the customized factory image ZIP
Suppose our new factory image is called factory.zip. Then to sign it:
Code:
java -jar signapk.jar [B]-w[/B] testkey.x509.pem testkey.pk8 factory.zip factory.signed.zip
See the attachment below for the necessary files. Note the -w switch, which is particularly important in this case.
Now just for the installation part:
Code:
adb shell mkdir /data/factory
adb shell mount -t ext2 /dev/block/mmcblk0p3 /data/factory
adb push -p factory.signed.zip /data/factory/factory.zip
adb umount /data/factory
adb rm /data/factory
Restore to factory image to check if it works
For an easy alternative to the power button marathon:
Code:
adb shell
echo -n -e "\x08\x00\x00\x00" >/rom/devconf/BootCnt
reboot
Warning: this wipes everything, all your data on the device will be lost.
Bonus: What if you want to use your own key?
The testkey.{pk8,x509.pem} is one of these ubiquitous Android debug keys, used all around. Apparently, it was good enough for B&N as well, as they used a version of it too for their OTAs (see /system/etc/security/otacert.zip). If it's not good enough for you though, and you have your own key, the attached keys file will not work for you; instead, you need to generate the key dump in the right format for yourself using the dumpkey utility also provided in the attachment:
Code:
java -jar dumpkey.jar testkey.x509.pem >>res/keys
Replace the references to testkey with the name of your key throughout the examples. If you're doing this on Windows, remember to convert the line ending to UNIX format (CR+LF to LF), not doing so might make the key not work.
General note: If at any stage you need to debug why a key is rejected, there is a log being saved by the stock recovery under /cache/recovery/log.
Disclaimer: Please do not follow these instructions blindly, but instead adjust them to your situation. This is the minimal set of necessary actions, with any optional steps removed for the clarity of illustration. I don't do it this way myself: personally, I'd make a backup here and there, verify MD5 sums after copying large files, etc. In any case, if something goes wrong, you will have to boot from SD card and restore your device. If everything goes right, you will lose all the data on the device. These instructions are provided on an "as is" basis. I will not provide support if anything doesn't work as expected for you. Anything you decide to do based on the above instructions is your sole responsibility.

dumpkey.jar really helped, thanks for that. Had to make exponent 3 type android key else it gets rejected, if you compiled the class, can you remove that check? Out of thanks for today.

Just a short note:
"bootutil" is now called "imgutil" and can be found in the signature.
There are more options than before, but I forget which ones.

[Help] fix the Corrupted EFS on 900P

Hi mates, thank you for helping!
Really a complicated story mine, had on this phone already issues with baseband (when I bought it had LL 5.01) when I upgraded it to RR 7.1.2, then I figured out I needed to upload the latest stock 6.0.1 G900PVPS3CQD1 to have it working, I also PITted the phone before, it worked for 5-6 monts, then the signal went off.
I've tried different solutions:
1) in TWRP typed in its terminal the commands I've found here:
dd if=/dev/zero of=/dev/block/bootdevice/by-name/modemst1
dd if=/dev/zero of=/dev/block/bootdevice/by-name/modemst2
It said "not enough space" but it looks in the end it copied around 3MB. Rebbited but no changes
2) Again thr TWRP:
dd if=/dev/block/platform/msm_sdcc.1/by-name/efs of=efs.bak
dd if=/dev/block/bootdevice/by-name/modemst1 of=modemst1.bak bs=4096
dd if=/dev/block/bootdevice/by-name/modemst2 of=modemst2.bak bs=4096
find /efs -exec ls -l {} \; > efs-permissions
nothing changed
3) updated to lineage 15.1, it says "no sim card" (the sim works fine in another 900V) with rooted ADB shell tried the "dd if=/dev/zero of=/dev/block/bootdevice/by-name/modemst1" but no such file. Then I decided to flash stock LL 5.01 BOK but like in stock 6.01 says "invalid sim card".
4) I run in adb:
adb shell
mount
and can't see /stl4 /efs so this is why I assume that efs is corrupted.
Somebody says to flash (under Odin PDA) EFS-Fix-regalstreak.tar.md5, but I won't risk to flash other phones data on my phone, including its IMEI.
Someone else says I have to backup EFS (I suppose this is possibile because when I executed adb commands it never said me that the files don't exist) and reflash it to fix the corruption. How this is possible to do? Thank you!
PS: I attached the backupof EFS made by TWRP, seems all good (not corrupted), why sim doesn't work?

I'm now on stock LL BOK, using in adb mount I have this
/dev/block/platform/msm_sdcc.1/by-name/efs /efs ext4 rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,data=ordered 0 0