Database Develop

Tattoo Custom Recovery Image

I'm starting this thread to document the work on creating a custom recovery image for the Tattoo.
The main goal is to provide a recovery image that will serve as the launchpad for flashing custom roms.
The Tattoo Custom Recovery Image will provide:
1) A way to use an update.zip signed with test-keys (already accomplished);
2) A way to perform a full backup of mtd2,mtd3,mtd4 and mtd5 (boot,system,cache and data).
3) A way to perform a full restore of the backup achieved by 2);
4) Adb support (already accomplished);
4.1) Adb shell support.
I'm open to input about using nandroid. Right now, without a S-OFF/ENG SPL this looks useless.
Also, if you have any other special need for recovery, please feel free to express it

Alpha release
Tattoo's Custom Recovery Image, Alpha Release
This first release includes:
- ADB enabled recovery
- ADB enabled root shell
- Accept update.zip signed with test keys
- All partitions mounted
- Custom recovery program (the last two options are stubs, not really working yet)
- Included in /sbin: busybox, flash_image and BART
- I've not used BART and, at the moment, cannot attest if it works or not.
- Backup script in /sbin/backup.sh
- Restore script in /sbin/restore.sh
With this custom recovery you can now do a full backup of your unit, by dumping the mtd block devices to your sdcard. Afterwards, you can use flash_image to recover your Tattoo to it's previous state.
I'm releasing this image as is. This is not a point-and-click recovery tool. If you don't know what you're doing, you can seriously damage your unit. The only reason I'm releasing this is in an effort to provide other devs with a way to easily recover their units, back to day-to-day configuration, while experimenting with them.
To flash:
Copy TCRI.alpha.img to /sdcard.
Run "flash_image recovery /sdcard/TCRI.alpha.img"
To reboot into recovery (quickest way)
adb reboot recovery
Please comment

thanks for you work

i try to flahs and get permission denied, do you know why?

flash_image: permission denied

chusen said:
i try to flahs and get permission denied, do you know why?
Click to expand...
Click to collapse
Partition remounted writeable from a fresh rebooted system with the tattoo-hack.ko module inserted??
But I'm sure you did that before because of:
I'm releasing this image as is. This is not a point-and-click recovery tool. If you don't know what you're doing...
Click to expand...
Click to collapse
;-)
-bm-

Thank you very much for your excellent job

Someone could install custom alpha recovery?
thx

@-bm-:yes I will try that way since the beginning. i mount with rw permissions /system and /data. i know is not a point-and-click recovery tool but i think i need more permissions but where?

Where did you guys get your flash_image binary from ?
The error you're getting is from flash_image, not from my recovery image.
I'll attach the flash_image I've been using to this post.
Please tell me if this solves your problem. You need tattoo-hack.ko module inserted, if you're using a release kernel.
Edit: You have the correct permissions in your flash_image binary, right ? After pushing it to the device, don't forget to chmod 755

It works I like drawing, jejeje.
Backup and Restore functionality appears to have no further
The adb root shell is perfect
Very good Work
for when the beta version? and the final version? lol

I try to dump the system userdata and boot.img and when i try to extract with unyasffs and i get this when i try to extract system.img
Code:
4 [main] unyaffs 3940 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
644 [main] unyaffs 3940 open_stackdumpfile: Dumping stack trace to unyaffs.exe.stackdump
and this with others
Code:
broken image file

Code:
[email protected]:~/Tattoo/images/boot/1$ ../../unpack.pl ./boot.1.img
Page size: 2048 (0x00000800)
Kernel size: 1899580 (0x001cfc3c)
Ramdisk size: 160952 (0x000274b8)
Second size: 0 (0x00000000)
Board name:
Command line: no_console_suspend=1 console=null
Writing boot.1.img-kernel ... complete.
Writing boot.1.img-ramdisk.gz ... complete.
528 blocks
[ boot.1.img-ramdisk.gz decompressed to boot.img-ramdisk ]
My image dumping script is OK
Take a look here: http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images
The boot.img is not a yaffs2 image. It's a special format, comprised by a 2k header, a kernel image and a ramdisk.
The system.img is a yaffs2 image. From unyaffs's homepage: "Unyaffs is a program to extract files from a yaffs file system image. Now it can only extract images created by mkyaffs2image."
Chusen, I think it would be better to create a new thread for this, since it doesn't concern the custom recovery image directly.

Thank god for custom recovery!
Now we can really start cooking ROMs... gonna break out the tools tonight and get Android 1.6/2.1 sources ready to compile.

leon1984 said:
for when the beta version? and the final version? lol
Click to expand...
Click to collapse
You tell me
Next in line is to tie the backup/restore scripts to the UI, which won't be too hard.
Later, I may mess around with nandroid and bart, to see if they provide something more than my scripts.
Afterwards, when we have some custom roms available, I may create a downloader/updater option, to make it easier to install those.
Also, I'm taking requests for new features

suggestions about scripts
Excellent work, mainfram3. Thank you.
I have extracted the img file, and check backup.sh and restore.sh scripts. The code for checking sdcard remaining space is done. Here it is:
Code:
## TEST: Check free space in sdcard
NEED_KB="200000"
REM_KB=`du /sdcard | awk '{print $6}'`
if [ ${REM_KB%K} -lt $NEED_KB ]; then echo "Not enough space in /sdcard, exiting"; exit; fi
backup space min set to 200MB.
There is another suggestion about restore.sh. Because of backing up img to /sdcard/Backup, $1 might not be needed, right?

mainfram3 said:
Code:
[email protected]:~/Tattoo/images/boot/1$ ../../unpack.pl ./boot.1.img
Page size: 2048 (0x00000800)
Kernel size: 1899580 (0x001cfc3c)
Ramdisk size: 160952 (0x000274b8)
Second size: 0 (0x00000000)
Board name:
Command line: no_console_suspend=1 console=null
Writing boot.1.img-kernel ... complete.
Writing boot.1.img-ramdisk.gz ... complete.
528 blocks
[ boot.1.img-ramdisk.gz decompressed to boot.img-ramdisk ]
My image dumping script is OK
Take a look here: http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images
The boot.img is not a yaffs2 image. It's a special format, comprised by a 2k header, a kernel image and a ramdisk.
The system.img is a yaffs2 image. From unyaffs's homepage: "Unyaffs is a program to extract files from a yaffs file system image. Now it can only extract images created by mkyaffs2image."
Chusen, I think it would be better to create a new thread for this, since it doesn't concern the custom recovery image directly.
Click to expand...
Click to collapse
and if you want to extract the boot.img here are the two scripts you need to fully extract the kernel(zImage) and ramdisk
split_bootimg.pl
and
extract-ramdisk.sh
they are attached below

jamezelle:
extract-ramdisk.sh missed #!, and the ramdisk zip file should be passed to $1 of this script.

mainfram3 said:
1) A way to use an update.zip signed with test-keys (already accomplished);
Click to expand...
Click to collapse
Hi mainfram3,
I don't want to jack your thread - could you add a little elaboration on this point, or provide a URL so I can learn a little more? The SPL on the phone (oem-78 or fastboot mode) accepts updates signed with the test key from the SDK? (Or some other key?) (On the Eris, the "rom.zip" files unpacked by the RUU are prepended with a mystery blob of 256 bytes - s'pose it could be a mic/sig, but if that's what it is, it don't appear to be in a standard DSA/RSA format, and those .zip files are not signed using the .apk/.jar manifest-signing method)
FYI here's an entertaining story of an epic fail in a related area. After reviewing the fastboot sources from the android tree, I decided that I wanted to spy on the (Windows) RUU update program by sniffing the USB bus - in particular to see if it was explicitly passing signatures in .sig files. (That's an undocumented command-line behavior in fastboot.)
Turns out that recent versions of libpcap and Wireshark allow for USB bus capture on Linux - and using the "usbmon" kernel module in Ubuntu 8.04 LTS, sniffing the USB (5k packet size) seems to work without hitch, even at USB 2.0 speeds. So I took it one step further, and installed WIn Xp SP3 in a QEMU VM on the Ubuntu machine, with the intention of running the RUU updater inside the Xp VM and sniffing the USB bus in the host OS (Linux) machine.
The result? QEMU/Win Xp VM can talk to the phone in either fastboot or adb mode, but bluescreens as soon as you start to move data at any appreciable rate. Doesn't seem to be dependent on whether monitoring is taking place. I might try putting the phone behind a cheapo USB 1.1 hub, and see if that helps, but for the moment I am stopped out on this hack.
bftb0

cn.fyodor said:
jamezelle:
extract-ramdisk.sh missed #!, and the ramdisk zip file should be passed to $1 of this script.
Click to expand...
Click to collapse
it works yea sorry about the
#/bin/sh
i didnt write the scripts btw

[Q] How to mount SD partitions from eMMC?

In case it's unclear, I have CM7 on eMMC and am setting up a Honeycomb/Phiremod dual-boot on SD, and would like all three ROMs to use the storage partition (7th in this case) on the card. The following post suggests to me that it's possible:
racks11479 said:
No need to root your stock nook. If you have a CM7 sdcard, root explorer or file expert(free from market), and a terminal emulator app. Which you should have with cm7. Try the following steps.
-using root explorer or file expert. Mount system as R/W
-open up a terminal emulator and run the following commands
Code:
$ su
# mkdir /mnt/nooksys
# mount /dev/block/mmcblk0p5 /mnt/nooksys
-now exit out of terminal emulator
-open up root explorer/file expert
-navigate to /mnt/nooksys
-you should now be able to see the stock nook system partition
-open up the /etc directory
-long press the vold.fstab file.
-it should give you an option to open with text editor
-change the line where it mounts the /sdcard from auto to 4
-exit out of root explorer
-reboot to stock
-it should now mount the 4th partition of your sdcard
Click to expand...
Click to collapse
The file path specified, however, did not work, and I don't know enough about linux in general or the specific file structures to figure out the necessary changes. The system I want to redirect is the CM7.1 beta running dalingren's 5/13 OC kernel.
I also don't know for sure whether the above works for redirecting a stock 1.2 install.

[HOWTO][CWM][4.2] Synchronizing clockworkmod Directory

Update 11-26-2012
The issue that this procedure was designed to overcome has been resolved in the latest version of CWM (6.0.1.9 or newer). Please view http://forum.xda-developers.com/showthread.php?t=1781899 for details and download links. If you do not want to upgrade to the latest CWM the directions below will still work but you should really just update.
Background
Due to the multi-user support capabilities of Android 4.2(+) the clockworkmod directory created by ClockworkMod and used to store downloads and backups is being created in /data/media. Unfortunately this directory is not accessible to individual users and therefore backups created in recovery can not be viewed or modified by ROM Manager and vice versa. ROM Manager will look for the directory /data/media/<user number> (e.g. /data/media/0) to which /sdcard is mounted when you are logged in as the user whose number is <user number> (e.g. 0).
Requirements
ClockworkMod Recovery installed and functioning
ROM Manager
ADB installed on your computer and functioning
Willingness to accept that you are on your own and I am not responsible if you mess something up!
Solution
1. Boot into CWM recovery
2. Attach your Nexus 7 to your computers USB port
3. Open an ADB shell using a console from your computer
Code:
adb shell
4. Confirm that you have a clockworkmod directory at /sdcard/clockworkmod (I am using user number 0 for the rest of this procedure, if you wish to use a different user substitute 0 with your user number)
Code:
cd /data/media/0
ls
4a. If you do not see a clockworkmod directory create one with the command below, otherwise proceed to step 5
Code:
mkdir /data/media/0/clockworkmod
5. See if you have a clockworkmod directory at /data/media
Code:
cd /data/media
ls
5a. If you see a clockworkmod directory type the command below, otherwise proceed to step 6
Code:
mv clockworkmod clockworkmod_bak
6. Create the symbolic link
Code:
ln -s /data/media/0/clockworkmod/ clockworkmod
7. If you already had backups in clockworkmod (now clockworkmod_bak) you can move them to the new folder by executing the following command
Code:
mv clockworkmod_bak/backup/ clockworkmod/
mv clockworkmod_bak/blobs/ clockworkmod/
mv clockworkmod_bak/download/ clockworkmod/
WARNING: I tested a backup from recovery and verified the backup was in ROM Manager, renamed the backup in ROM Manager, and confirmed the backup was renamed in recovery. Due to time constraints I did not restore the backup though I can't imagine why it would fail. As mentioned above do this at your own risk. If you do not have a unix/linux experience I would suggest that you wait for someone with experience to follow these steps (I wrote them after I did the procedure so they haven't been vetted) before you attempt it yourself.

Very helpful, i was wondering what they did to mess up clockwork mod
been trying to undo 4.2 for hours as i dont quite like it

truehybridx said:
Very helpful, i was wondering what they did to mess up clockwork mod
been trying to undo 4.2 for hours as i dont quite like it
Click to expand...
Click to collapse
I am on the fence about 4.2 myself and when I couldn't see my 4.1.2 backup I had a panic moment. I have to admit that either 4.2 is growing on me or I am already forgetting how good 4.1.2 was .

sandnap said:
I am on the fence about 4.2 myself and when I couldn't see my 4.1.2 backup I had a panic moment..
Click to expand...
Click to collapse
+1! Panic indeed! LOL

Great tutorial. Thanks and have a happy thanksgiving

Is there a way to do this without using adb? I don't know how to get it working.
It looks like you are just moving all the files from one location to another, right? If thats the case can I just move them with a file explorer? Also where are the back-ups from pre 4.2 stored, I thought it was sdcard/clockworkmod/ Can I move the back-ups from there to a data/media/clockworkmod folder?

StarOrc said:
Is there a way to do this without using adb? I don't know how to get it working.
It looks like you are just moving all the files from one location to another, right? If thats the case can I just move them with a file explorer? Also where are the back-ups from pre 4.2 stored, I thought it was sdcard/clockworkmod/ Can I move the back-ups from there to a data/media/clockworkmod folder?
Click to expand...
Click to collapse
Please see my update to the original post. Once you update to the latest CWM you can copy any existing backups to the new backup and blobs folders under /data/media/clocworkmod. This is discussed in more detail in the thread I linked to.

Code:
mv clockworkmod_bak/backup/ clockworkmod/
mv clockworkmod_bak/blobs/ clockworkmod/
mv clockworkmod_bak/download/ clockworkmod/
This is me just being nit picky, but this looks better:
Code:
mv clockworkmod_bak/* clockworkmod/
I guess for people not confident in their linux abilities that '*' misplaced could be deadly though...anyway thanks for the simple and great workaround/explanation.

Wiping/ Factory resets (in CWM or TWRP) don't erase this data folder? Are we confident in this?

255|[email protected]:/data/media/clockworkmod # mv backup/ /sdcard/clockworkmod/
failed on 'backup/' - Cross-device link
How are you able to move the directories?

This seriously annoys me. Despite the recent surge of newer android devices not containing any sd card slots for secure file storage away from ROM flashing, everything is now embedded. I have had several accidental internal storage deletions containing backups and roms and no the clockworkmod is even harder to locate and backup conveniently through usb/ftp. Thanks for the tut.

TheAtheistReverend said:
Wiping/ Factory resets (in CWM or TWRP) don't erase this data folder? Are we confident in this?
Click to expand...
Click to collapse
Yeah i am wondering that too.it doesnt feel safe for me that the backups are in the system but not in sdcard.

nexus file locations
On the nexus devices (certainly the 7, which has no external sdcard), the only real mounted portions are cache, system and data. Locations like /sdcard/ /storage/emulated/0 etc. are all fuse mounted from /data/media
Supposedly most of the data portion will survive flashing new ROMs and recoveries, everything except unlocking the boot loader, which wipes data f to meet the android security model.
Doesn't feel very safe, though.

amp said:
This seriously annoys me. Despite the recent surge of newer android devices not containing any sd card slots for secure file storage away from ROM flashing, everything is now embedded. I have had several accidental internal storage deletions containing backups and roms and no the clockworkmod is even harder to locate and backup conveniently through usb/ftp. Thanks for the tut.
Click to expand...
Click to collapse
I would use TWRP. I have switched and never looked back. It has quite a few more advanced options that I didn't see with clockworkmod, and overall has be MUCH more reliable.
The clockworkmod recovery issue stated in this thread does not affect TWRP at all.

Thanx for this, it seems to work even for the latest CWM.
Sent with desire from My One

angusc said:
Thanx for this, it seems to work even for the latest CWM.
Sent with desire from My One
Click to expand...
Click to collapse
Iget an error: Read-only File system :crying:

fokus said:
Iget an error: Read-only File system :crying:
Click to expand...
Click to collapse
If doing commands with adb did you remember to use
adb shell
And check that your command line starts with #......
Sent with desire from My One

angusc said:
If doing commands with adb did you remember to use
adb shell
And check that your command line starts with #......
Sent with desire from My One
Click to expand...
Click to collapse
Yes, that is exactly what i did.
I am on ARHD 11.0
S-off
ElementalX 2.2

I'm on ARHD 11.0 as well.
Strange, I followed the OP from step 1 to 6. I couldn't get step 7 to work so I just used my root explorer to copy the directory contents across in to the newly created clockworkmod folder, then deleted the clockworkmod.bak directory and all was good.
Tip: copy and paste each cmd from the OP in to your adb commands window......
Sent with desire from My One

angusc said:
I'm on ARHD 11.0 as well.
Strange, I followed the OP from step 1 to 6. I couldn't get step 7 to work so I just used my root explorer to copy the directory contents across in to the newly created clockworkmod folder, then deleted the clockworkmod.bak directory and all was good.
Tip: copy and paste each cmd from the OP in to your adb commands window......
Sent with desire from My One
Click to expand...
Click to collapse
THX. That is what i did. I also tried it via Terminal on the device - same error: System read only... hmmm
EDIT: Works fine now after e vew reboots. THX

[Q][TIPS]Nvflash, extracted system partition - gain root

Hi all,
is it possibile to modify the content of the files fills with the content of the partitions read from the Tegra of my LG P990 with nvflash?
I had read the partition from the board with
Code:
nvflash -r --read <-partitionID-> my_partition.img
Unix's command file said to me that the output file is data:
Code:
$ file my_partition.img
my_partition.img: data
But if the correct img file is provided to 'file', for example the file that nvflash returned when we asked it to read the partition 23, the APP partition, 'file' said:
Code:
23_APP.img: Linux rev 1.0 ext4 filesystem data, UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (needs journal recovery) (extents) (large files)
How i can mount this type of image file ?
Easily with the 'mount' Linux utility
Code:
mount ./my_partition.img ./tmp_directory
Now, if I add the su binary of chains_dd compiled for my platform in the system partition image file and after,
reflash the image file on my O2X I should able to get root, right?
It seems too easy...
Any help is appreciated.
Thanks!

Yes, it is "easy" like that. I made similar staff (extract partition image from official update, mount, extract selected files).
Edit: Only I remember that I need to specify mount parameters related to partition format and mounting access.

Have you really gain root access only by copyng (and launching ) su binary in xbin directory?

tryin said:
Have you really gain root access only by copyng (and launching ) su binary in xbin directory?
Click to expand...
Click to collapse
Y E S . . .
Indeed, if you only want a root prompt, chains_dd's binary is too much...

tryin said:
Y E S . . .
Indeed, if you only want a root prompt, chains_dd's binary is too much...
Click to expand...
Click to collapse
Take a look at this...
http://forum.xda-developers.com/showthread.php?t=2280447

Bootloop after installing Xposed framework

Hello,
I am hoping someone can assist with interpreting my log file or provide suggestions on how to convert my backups into a usable format that can be flashed back to the phone thus recovering it to a usable state. I have a logcat and dmesg in a text log file. I have put the file up on Google drive, the link is here-
https://drive.google.com/file/d/0B9e...ew?usp=sharing
I also spent time reading and studying the post about using logcat and dmesg posted here-
http://forum.xda-developers.com/showthread.php?t=2274119
I believe the last operation I tried before softbricking was installing the Xposed framework module for my device (running Lollipop 5.1.1).
I have tried one solution so far, go into recovery, clear cache and reboot.
To recover from this issue I think I have two basic options-
#1 restore from backup
#2 locate the problem that is causing the system to hang at startup in the first place
At the end of the day I am trying to find the simplest, quickest method to get back up and running. Both methods are acceptable to me. I am not worried about losing any data.
My phone is a BLU Studio C 5+5 LTE and therefore can't use TWRP or CWM (At least that is my assumption, maybe someone knows different). Before getting into the softbrick state I took 3 different types of backups in the hopes that one of them could be used in case it was needed. (like this)
Type 1 - I did an ADB shell backup from a completely stock device (unrooted). I used this command-
adb backup -apk -all -f fullbackup.adb
For this method I followed this guide here-
https://linuxiswonderful.wordpress.com/2015/04/04/full-backup-of-nonrooted-android/
Type 2 - I used Titanium backup and performed a complete system and application backup
Type 3 - I rooted the phone and backed up all partitions using dd after reviewing the partition layout of the device. For example, to backup the system partition I did the following at an ADB shell-
dd if=/dev/block/mmcblk0p21 of=/storage/sdcard1/firmware-img/system.img
I am able to still communicate to my device using ADB and I can get an ADB shell or enter fastboot mode.
My challenge/sticking point is how to turn my backups into a usable format to get me back on track or understand the boot process enough to get out of the boot loop. I am familiar with how Linux boots as I am a SysAdmin. I know Android is similar but just different enough to make me research this further.
The first thing I tried was mounting my raw image files created from the dd process. I followed this guide-
https://samindaw.wordpress.com/2012/03/21/mounting-a-file-as-a-file-system-in-linux/
I ran these commands-
#losetup /dev/loop0 /path/to/my/system.img
# mkfs -t ext3 -m 1 -v /dev/loop0
# mount -t ext3 /dev/loop0 /mnt
# cd /mnt
# ls
The various image files I created all seemed to mount "ok" OK meaning that the loopback mount process worked but it appears there is nothing but a lost+found folder in the mounted image. (I'm not sure why that is.)
I am still researching methods to turn my other backups into something usable for recovery purposes.
For using the adb backup file I created, this is what my understanding is-
Adb backup uses a type of compression (don’t remember what kind). I would need to uncompress the file first. After uncompressing and being able to view the file contents I would think I should be able to put together a flashable zip file of some sort.
I think the process for Titanium backup would generally be the same- uncompress/convert file format, create/assemble a flashable zip file
If there is any other info you need to see, please let me know. I made a lot of notes about the system architecture, partition layout, etc.
Many Thanks in Advance for your Advice!

Found my answer. Used ADB shell and mounted /system in RW mode. Changed /system/bin/dex2oat filename and the device booted normally. Issue solved!