Tattoo Custom Recovery Image

Search This thread

mainfram3

Senior Member
Mar 5, 2006
184
3
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 :)
 

mainfram3

Senior Member
Mar 5, 2006
184
3
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 :)
 

Attachments

  • TCRI.alpha.zip
    2.7 MB · Views: 2,513

chusen

Senior Member
Dec 20, 2009
76
0
@-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?
 

mainfram3

Senior Member
Mar 5, 2006
184
3
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 :)
 

Attachments

  • flash_image.zip
    27.8 KB · Views: 2,062
Last edited:

leon1984

Member
Feb 4, 2010
35
0
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
 

chusen

Senior Member
Dec 20, 2009
76
0
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
 

mainfram3

Senior Member
Mar 5, 2006
184
3
Code:
mainfram3@cardbox:~/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 :D
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.
 
Last edited:

mainfram3

Senior Member
Mar 5, 2006
184
3
for when the beta version? and the final version? lol

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 :)
 

cn.fyodor

Senior Member
Dec 31, 2009
336
507
Nanjing
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. :D

There is another suggestion about restore.sh. Because of backing up img to /sdcard/Backup, $1 might not be needed, right?
 

jamezelle

Retired Forum Mod / Retired Recognized Developer
Nov 4, 2007
1,712
100
Ohio
www.jamezelle.com
Code:
mainfram3@cardbox:~/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 :D
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.

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
 

Attachments

  • boot-img-scripts.zip
    2.1 KB · Views: 81

cn.fyodor

Senior Member
Dec 31, 2009
336
507
Nanjing
jamezelle:
extract-ramdisk.sh missed #!, and the ramdisk zip file should be passed to $1 of this script. :)
 
Last edited:

bftb0

Senior Member
Feb 5, 2010
2,594
1,041
1) A way to use an update.zip signed with test-keys (already accomplished);

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