Related
So I've finally kind of figured out several files in partition mmcblk0p1. Files named custom, init, and recovery are actually kernel and initramfs packed with 256 header. Information at offset 0x94 is length of kernel + header (256 bytes) and offset 0x98 is length of initramfs. Except of file init, contain additional size which I'm not actually understood.
By extracting init file, and modifying extracted initramfs, I can boot to android system with rooted state.
I've experimenting using unionfs got from somewhere in this forum and added files su and superuser.apk. I've added in init file inside initramfs.
Actually analyzing recovery files, we can get information regarding recovery program which mostly in bash script.
I've include my kernel and initramfs extracted from file init in mmcblk0p1. You can try for yourself only in Developer Edition, where you can flash your own kernel and initramfs.
Beware, I don't guarantee it will succeed... try for yourself
*Sorry, bad english...
Hi,
Is it not pointless to work on this squashfs, when we can use plain file/device partition on SDE (like Angstrom demo)? I guess (it's still theory - since I've just installed SDE) it's enough to create rootfs with copied everything from squashfs and /data - to make it fully writeable and rootable - and boot on it as /.
I'll give it a try later...
No methods are pointless. Stop saying that. It's a progress to what we can do with the device.
Anyway, were you able to make that root work on the main OS, dogma?
MoonPhantasm said:
No methods are pointless. Stop saying that. It's a progress to what we can do with the device.
Click to expand...
Click to collapse
Ehh ok - but it makes thinks complicated, while we should straight everything up - to make upgrading smooth and easy
MoonPhantasm said:
Anyway, were you able to make that root work on the main OS, dogma?
Click to expand...
Click to collapse
As far as I can see in files - it should work.
Here's a diff of those init files (what was added)
out# diff init init.old
53,54d52
< CP=/bin/cp
< CHMOD=/bin/chmod
122,130d119
<
< # Create tempfs on /rootfs/home and unionfs with /rootfs/system
< $MOUNT -t tmpfs tmpfs $rootfs_path/home
< $INSMOD /lib/modules/unionfs.ko
< $MOUNT -t unionfs -o dirs=$rootfs_path/home=rw:$rootfs_path/system=ro unionfs $rootfs_path/system
< $CP /home/su $rootfs_path/system/bin/
< $CP /home/superuser.apk $rootfs_path/system/app/
< $CHMOD 6755 $rootfs_path/system/bin/su
< $CHMOD 755 $rootfs_path/system/app/superuser.apk
Booting from normal ext3 device requires some more changes - but gives us no 300MB (or similar) limit, allows to change boot parameters after kernel boots up (now on squashfs partition) etc. etc.
Yeah.. I'm able to get root with kernel and initramfs I've attached...
I am very excited about the prospects with SDE. Hopefully with some more poking and prodding and with Archos Froyo source released we will see some nice custom ROMs coming down w/ full root and a re-mapped file system in the coming months. I for one am hopeful that the dev community embraces the Gen8's w/ SDE and bakes up a nice serving of Gingerbread!
I was thinking that in recovery there's tool to flash initramfs and kernel which formed in file custom in mmcblk0p1. If we can replace destination to init (not custom). I think we can force booting to our new change, without entering to recovery mode first.
But, I still don't want to break anything in partition mmcblk0p1 .
Also, if we can modifying squashfs file with new one, without script checking the file (I think is on cramfschecker program); we can have custom rootfs itself replacing androidmerged.squashfs.secure....
Just the thought...
Keep up the good work guys!
just copied the content of the squashfs in an ext3 image and modified the init and mountpoints.
will report later after some testing
Heh.. I've just did the same - but on ext3 partition of sd card. Not luck yet to full boot... yet...
me neither. don't have time for more testing today and tomorrow, but soon I have a lot of spare time
edit: currently running kernel and initramfs of dogmaphobia, works great so far
Let me know when you guys news beer on your break, its on me.
Keep up the good work.
its too bad i am too dumb to understand all of what you are saying.
Does this mean rhe archos can be booted with root?
is it then rooted on the normal android firmware i use at the moment or on something else?
If yes how exactly do i get this to work and will there be a easier version for people like me who dont know that much about that kind of things.
and sorry again if my questions are dumb,i just want to try to get it.
nimrodity said:
Does this mean rhe archos can be booted with root?
Click to expand...
Click to collapse
Yes - but with SDE installed (and voided warranty - unless Archos claims so)
nimrodity said:
is it then rooted on the normal android firmware i use at the moment or on something else?
Click to expand...
Click to collapse
We are trying to boot oryginal Archos-Android on writtable disk (then it will be fully rooted - on OS level at least). dogmaphobia prepared initrd (first stage boot - lets say) that mounts part of original dir tree as RW and installs SU (switch to root) tool.
nimrodity said:
If yes how exactly do i get this to work and will there be a easier version for people like me who dont know that much about that kind of things.
Click to expand...
Click to collapse
Probably yes, this one is not so hard either - but it's really just a first step, so I recommend to wait.
This is freaking awesome. Since 2.0.71 disabled temproot I haven't been using my 101 very much other than poking around in Angstrom.
I voided the warranty on every other Android device I own for root, and I sure don't mind doing it on my 101 either.
@$aur0n
thx for the explanation.
Since i am please ight now ho the archos works,i ca wait a while till something new comes up.
so no hurry,we all saw how achos handled that with an unfinished bugged fimware
this is great news, im so looking forward to the future with a fully rooted device. And all the benefits that comes with that,maybe some custom roms maybe even cyanogen mod, A2SD, custom kernels and Gingerbread. If this comes thru it blows this wide open. Keep up the good work
@dogmaphobia you've written kernel size was at 0x94 and initramfs size at 0x98 but I don't get it. 2byte value (db70) at 0x94 results in 56176 and (db700021) ist far too much for kernel size. same weird result for initramfs.
how did you extract initramfs and kernel from this mmcblk0p1/init file? may post a shell script?
I've checked my "custom" file - on pos. 94 i have unsigned 32bit (8 bits) value "2218864" - witch might be ok, since 2218864-256=2218608 - and that's exactly the size of kernel that dogmaphobia send (and it's bootable).
On pos. 98 I have value "833767" (8 bit stream like before) - that's look also quite ok.
ps. and you should be able to extract it with dd (dd if=custom of=whatever bs=1 skip=245 count=2218608) - it's slow with bs=1 but...
Heym I mounted the rootfs.img as loop, put the two files from dogmaphobia in /boot and copied the image back to internal memory, but wasn't able to boot from this image. Any tips?
I live in Japan and after more than 6 months I have successfully and permanently rooted both my Sharp 003 SH Galapagos and the 005SH Galapagos (Softbank not Docomo). My next concern is how to SIM unlock. I have been reading the posts about hacking the nv_bin file. I have searched through all of the the files (Root FTP thank you!) but there was no such file. I am happy to send along any screenshots or data files if that helps.
Thanks in advance.
Search Sharp 003SH Root Success and Sharp 005SH Root success on Youtube for more info
Can't really help you. Don't know anything about it. But I would like to know how you ended up rooting this phone of ours.
Its not a file on the filesystem. The sim locking in these phones is in the radio image; which can be accessed when you use the custom build kernel thats in the latest rootkit (I assume thats what you are using).
See the 2ch root/ROM thread for more details, but basically it is done through ADB, manually backing up the "_modem" partition; stripping the spare/ECC bytes and then extracting the radio OS using QualcommDumpAnalyser
I have managed to extract this image, but no idea where to go from there. None of the other device info seems to apply to this (HTC, Samsung, LG, any other Android that has had its sim-lock discovered in the radio)
Advice i got from the guys on 2ch: "Qualcomm's NAND code is neither difficult, nor unique, so if you know what you are looking for its not hard"
003SH 005SH Sim unlock
Thanks very much for giving me a new direction. I'll get started on it right away and let you know how it progresses.
It just sucks that the guys who know how to unlock it are staying quiet, saying its "taboo"
FYI, stripping the Spare/ECC bytes can be done manually (i wrote a C program to do it), but there is an option in the RevSkills app to do it all for you - i recommend doing that.
Of course we face another issue once we find the actual unlock - recalculating the ECC bytes after making the change; the only way to access the radio is with raw data access.
P.S. hope you have warranty on your phones - this is very likely to brick at least one phone until we get it right
---------- Post added at 12:30 PM ---------- Previous post was at 12:24 PM ----------
In the spirit of open cooperation, here are the instructions i was given, translated and simplified
In ADB Shell, type su to get the # prompt, then:
cat /proc/mtd <Enter>
Confirm that you have the "_modem" partition available. If not, you need to reflash with the custom build kernel
Dump the image to file with the following command:
dump_image -r -D -F _modem /sdcard/backupimages/modem.img
Access this with anything as "raw dump" and all blocks will get read as ECC error, so definitely dont do this
ECC positioning is different to Linux, so take care
The following maps out how 512bytes of data and 10 bytes of ECC info are stored in a 528 byte block:
0000 - 01CF (0-463): Data
01D0 - 01D1 (464-465): Unused (0xff)
01D2 - 0201 (466-513): Data
0202 - 020B (514-523): ECC
020C - 020F (524-527): Unused (0xff)
Use RevSkills application to extract the data portions:
Menu⇒Calculators/Generators⇒Android MTD Nand remove Spare and ECC
Extract all of the Data only portions out of the raw dump, and then use QualcommDumpAnalyser to read it and split up the various parts. I did notice that i wasnt able to get the AMSS block out with QualcommDumpAnalyser - i copied that out manually by calculating the byte positions shown in QDA.
003SH bootloader key sequence?
Eternalardor,
I'd be happy to swap information. Perhaps you could shed some light on the question of the bootloader for the Sharp 003SH and 005SH? There seems to be no discernible key sequence (Power+home+Volume up etc.) to access the bootloader. I feel like I've tried them all. Can you tell me this critical piece of information?
Is a form of the USB Jig necessary to access it?
Looking forward to your response.
003SH SIM unlock
Dominik,
Here are the results of the original /proc/mtd (before rooting)
boot
cache
misc
recovery
ipl
system
persist
log
battlog
calllog
ldb
userdata
I don't see the _modem partition. Should I?
I have also included a screenshot of the results showing size. I have most of them backed up as .img files too.
FYI: .img backed up sizes. Perhaps this will help you to ponder where the _modem partition may have gone. Maybe it's been renamed?
boot 11,264KB
cache 3,072KB
misc 1,024KB
recovery 11,264KB
ipl 15,360KB
system 419,840KB
persist 30,720KB
ldb 45,056KB
userdata 405,120KB
There is no bootloader menu AFAIK. If you install the custom kernel, you will have the option of a quasi-recovery mode, by pressing the home button between 7-12 seconds after the Galapagos logo is seen (or was that the Softbank logo)
Anyway, looking at the screenshots, it seems you do not have the custom kernel.
How did you achieve root on your phone?
To do this, you need to use the "003sh_005sh_dm009sh-rootkit" from at least 5/27 (recommend _0614); which is available on the 2ch forums. This includes 2 possible ways of achieving root:
1. A modified standard kernel (boot image), which, when flashed gives you regular root access
2. A custom compiled kernel, which has full root, a bunch of power profiles, and heaps more features (inc that quasi recovery), as well as access to the "_modem" image.
Judging from your youtube videos, you speak some Japanese, so the Japanese menus in the rootkit shouldnt be much trouble.
http://www1.axfc.net/uploader/Si/so/142435
This is what i used.
Go here for help/instructions http://anago.2ch.net/test/read.cgi/android/1337845757/
And dont even think about typing in English on there, or you will be ignored and/or told to go away
This all looks familiar. I have been using the root kit (5/27) to get where I am now - step by blessed step. It was pretty straight forward BUT I have never seen the option to write to the system partition. It is in all the instructions but the only option I have with respect to the system partition is to back it up. I'm confused as to why it doesn't seem to show up for me. I am using a Japanese machine so all the characters are displayed and I can read the instructions but I can't find help anywhere as to why I don't have that particular (and critical) option. I can see a lot of new and cool options in the 6/14 release. I'm excited and would like to get it installed.
I'll let you know how it goes. Thanks for your help .... keep it coming!
And another thing
Could you explain a little more about "having" the custom kernel? Using the root kit, I wrote to the Recovery partition then the Boot partition then rebooted from the Recovery partition and all seemed well. As I said above, I have never been able to write to the System partition despite it appearing in all the instructions. I suspect that is what is holding me back from the latest and greatest custom kernel. Still, I am enjoying all the same functionality that everyone else seems to be enjoying in root. What am I missing?
Eep, you wrote to the boot partition before trying the recovery? Brave!
The steps should be:
Write image to recovery partition;
Then reboot to recovery partition (from the menu) and confirm it all works without errors.
Then write image to boot partition
And then turn off the phone, and reboot (the last part is only my instructions - you could just select "reboot to boot partition" from the menu)
You are doing this on your 005SH right? It should be the same for the 003SH, but i only have the 005SH. In the rootkit there is 2 options when you say "burn custom image":
1 カスタムビルドrootedカーネル（リカバリーキット機能付き）
2 S4080 標準rootedカーネル（簡易リカバリー機能付き）
Q 中止してメインメニューへ戻る
You must do the first one, the CUSTOM rooted kernel, to get any of the really cool features. The second option is only if you just want root access for a particular app or something. AFAIK the second option doesnt even disable MIYABI LSM, which prevents you from mounting the system dir as R/W
But either way, writing to the System dir is not important for what we are doing. You need the Custom kernel, which gives you access to the "_modem"
Edit, i just noticed in your screenshots above, you didnt even get root in ADB shell?
Type
ADB Shell<Enter>
Then type
su<enter>
The cursor should change to a #, this means root. You may get a prompt on the phone from Superuser asking you to give root access to "shell". Once you have this try the cat /proc/mtd again
jcroot003sh,
can you tell me how to root 003sh?
Use the link i provided in my previous post
http://forum.xda-developers.com/showpost.php?p=27989085&postcount=8
You can use a translator if you dont understand Japanese, but the general instructions are in the post above yours
I translated it for a friend, but that is at work, so wont be able to put it up until monday.
DominikB said:
Use the link i provided in my previous post
http://forum.xda-developers.com/showpost.php?p=27989085&postcount=8
You can use a translator if you dont understand Japanese, but the general instructions are in the post above yours
I translated it for a friend, but that is at work, so wont be able to put it up until monday.
Click to expand...
Click to collapse
Thank you for your replying. I will wait for your translated version. You are really a good person.
Progress
I have successfully found and dumped the "_modem" image. Exactly as you stated - forgot the "su" command in ADB. Thanks. The next problem is editing out the code. I am way above my head here so I will do some research before bugging you for a step-by-step for that.
Also, the bootloader worked. I didn't realize how to do it until I read the notes in the 6/14 release. I successfully put a previously dead phone back on it's feet EXACTLY to the point of my current phone simply by backing up and then restoring partitions through the bootloader. Very slick and easy.
Will get to work. I'll be in contact soon with my progress on the SIM unlock.
I have spent a bit of time looking at it, it certainly isnt easy (Certainly isnt a "lock=yes" section). I assume the actual locking portion is encrypted/compressed/or just compiled, because it would be too easy otherwise (be happy to be proven wrong). For starters, i cannot even find my IMEI number in the dump file... I think that this dump only includes the radio code, not the NV RAM which contains the IMEI and SIM Lock status. If that is the case then the solution should be to change the portion of the radio code that queries the NV RAM, so that it doesnt care if the SIM lock is supposed to be applied.
Extracting the spare/ECC bits out should be done with the RevSkills app; extracting the relevant portions, that is a bit of a cludge; QualcommDumpAnalyser can show the start/end positions, but doesnt extract the AMSS part (AFAIK thats where the code will be). You need to use a hex editor to cut that part out manually... And i am still not 100% sure what the block size is on this NAND.
Good luck!
And if there *are* any experienced hackers out there willing to help out, i can offer some monetary help (as will a few of my fellow Japanese smartphone owning friends) as this will be valuable for not just these 2 phones (there is an army of 007SH owners waiting on this unlock)
Shall we give the 007/009 a shot?
I can see mountains of the 007SH on the auction (mostly pink). Perhaps I should pick one up and take it for a spin. I am happy to try to do something to help out for all the help I am receiving.
Or perhaps the 009SH?
How hard would it be to crack the 007? The 009SH looks like it is supported in the latest release kit.
Thoughts?
Currently, the 003/005SH are going to be the easiest, because they have the custom kernel which allows access to the "_modem" image. To do it on the 007SH we need to build a custom kernel (compiled from the sources available on the ktai-dev site), and add the modem access code (this is in the src directory of the rootkit). Not impossible, but i dont have a Linux machine to compile the sources.
However i think that the code will be fairly universal. Once we find it on the 005SH we will know what we are looking for on the 007SH as well. That will make many people happy
Anyway, my 005SH is under warranty/anshin plan so i dont mind if it gets bricked (especially now that we can take nand backups).
First things first though - examining the 005SH modem image. Does anyone know whether the NAND is a 16kb or 128kb block size? Or is it something completely different?
P.S. The DM009SH is just the Disney Mobile version of the 003SH
Linux machine no problem
I have a Linux server running 24/7 so compiling the kernel is easy. Don't let that be the holdup. I'll keep working on the 003SH _modem image.
DominikB,
I can't open this site [anago.2ch.net/test/read.cgi/smartphone/1319287551/] on channel2 for free. This site had been moved to the past-log storehouse. So.... I even can't look at Japanese version for rooting 003sh. It is very helpful if you can show me the steps for rooting 003sh.
Hi
I've done a bit of searching but can't find anything too specific to what I'm trying to do. Basically we have 10 Android tablets, and I want to make them all standardised e.g. have the same Apps on, configured in the same way (e.g. enterprise wireless network added).
Now the thing is if anyone messes around with them I want a really easy way to restore them to the original config which I've done.
One way I thought was to configure one fully, install Titanium Backup on it, do a full backup of apps/system data etc, and put the backup onto an SD card. Then I already have the base ROM on an SD card so if theres any problems, I can just flash the ROM over it again, install TB, and restore all the data. Would this be suitable to do to duplicate the data onto 10 tablets, and also restore the data if required?
The other thing I looked into was customising a ROM myself, don't want to do anything too tricky it'll just be a case of removing all the preinstalled crap I don't want, preloading the Apps we do want, and if possible preloading the wireless key and getting rid of the first boot initial set up wizard.
PS I've looked at installing CWM and doing whole image backups, but supposedly the tablet isnt supported (its an Ainol Novo 7 Elf 2)
Any advice would be great, hopefully theres some fairly straight forward way of managing this
Thanks
One of the reasons I integrated a full blown GNU/Linux on my devices, was the need to run full and automated backups. If you are looking into the possibility making a custom ROM, this might be a solution for you as well. I'm using BackuPC to run backups nightly, backing them up as any other GNU/Linux machine (using tar over ssh).
See the link in my signature for more information about this.
kuisma said:
One of the reasons I integrated a full blown GNU/Linux on my devices, was the need to run full and automated backups. If you are looking into the possibility making a custom ROM, this might be a solution for you as well. I'm using BackuPC to run backups nightly, backing them up as any other GNU/Linux machine (using tar over ssh).
See the link in my signature for more information about this.
Click to expand...
Click to collapse
Hi
Thanks for the reply, not too sure this would be the right option for us. I don't really need to take nightly backups, I just need to make a backup of a preconfigured image, and then put that image onto 10 other devices. Then I want to keep the original backup and have an easy way to restore it onto any devices which have been messed up. Sort of like image cloning for PCs, I want to prepare a base image, and then flash it over all the devices.
fro5tie said:
Hi
Thanks for the reply, not too sure this would be the right option for us. I don't really need to take nightly backups, I just need to make a backup of a preconfigured image, and then put that image onto 10 other devices. Then I want to keep the original backup and have an easy way to restore it onto any devices which have been messed up. Sort of like image cloning for PCs, I want to prepare a base image, and then flash it over all the devices.
Click to expand...
Click to collapse
Ok, I see. Compile the image to you likings (boot image and system partition), and then flash it using fastboot onto you devices.
Hi
Does anyone have any more thoughts on this?
I have experimented with Titanium Backup and this seems to work quite well. I have installed a ROM, and customised it e.g. installed the apps I need and configured the apps, wireless settings and home screens etc. Then I do a full apps + system backup in TB to my SD card.
Then the plan is, I can reflash the ROM onto the other device, install TB and then restore this backup. This saves my user state and wireless settings etc.
Only problems is when I flash the ROM, I have to go through all the initial set up again and also remove some preinstalled apps which I dont want. Any ways around this?
There must be something I'm missing. Why don't you install the device, walk through the setup, remove the bloatware you don't want and then dumps the disk partitions into images you flash the other devices with using fastboot? This way you'll get'em cloned, isn't it this you want..?
Of course there's still some tinkering needed once restored/cloned, such as giving them individual Google accounts etc, but you can easily fix this without re-running the setup wizard.
kuisma said:
There must be something I'm missing. Why don't you install the device, walk through the setup, remove the bloatware you don't want and then dumps the disk partitions into images you flash the other devices with using fastboot? This way you'll get'em cloned, isn't it this you want..?
Of course there's still some tinkering needed once restored/cloned, such as giving them individual Google accounts etc, but you can easily fix this without re-running the setup wizard.
Click to expand...
Click to collapse
Hi
Yes that's what I want to do! How would I go about dumping the disk into an image and then flashing?
fro5tie said:
Hi
Yes that's what I want to do! How would I go about dumping the disk into an image and then flashing?
Click to expand...
Click to collapse
There are several methods. Some boot loaders (such as nvflash for tegra based devices) can actually read back the disk partitions to a computer via the USB port. You can also on the tablet read the raw mtd device with busybox/dd. I assume you've unlocked the bootloader and gain root access to the device, since this is a requirement for flashing them as well. A third alternative is using busybox/tar, and then recreate the filesystem image using mkyaffs (or if ext3/ext4 even easier, just loopback mount an image on you linux maching to unpack the tar archive to). Once you got the images (system and userdata partitions), you flash the devices with "fastboot flash system system.img" and "fastboot flash userdata data.img". I don't believe you'll need to tamper with the other partitions.
kuisma said:
There are several methods. Some boot loaders (such as nvflash for tegra based devices) can actually read back the disk partitions to a computer via the USB port. You can also on the tablet read the raw mtd device with busybox/dd. I assume you've unlocked the bootloader and gain root access to the device, since this is a requirement for flashing them as well. A third alternative is using busybox/tar, and then recreate the filesystem image using mkyaffs (or if ext3/ext4 even easier, just loopback mount an image on you linux maching to unpack the tar archive to). Once you got the images (system and userdata partitions), you flash the devices with "fastboot flash system system.img" and "fastboot flash userdata data.img". I don't believe you'll need to tamper with the other partitions.
Click to expand...
Click to collapse
Hi
Thanks for the quick reply, much appreciated.
Unfortunately you've lost me a bit here!
Yes the device is rooted, I dont have a linux machine though.
Any chance you'd be able to provide some more specific instructions? The device is a chinese tablet from manufacturer Ainol, the model is a Novo 7 Elf 2. Unfortunately there isn't much discussion on these online so specific help is hard to find!
fro5tie said:
Any chance you'd be able to provide some more specific instructions? The device is a chinese tablet from manufacturer Ainol, the model is a Novo 7 Elf 2. Unfortunately there isn't much discussion on these online so specific help is hard to find!
Click to expand...
Click to collapse
I can provide you specific answers to specific questions, but I have no experience of the tablet in question, so you'll have to do some digging yourself first. Make sure it supports fastboot, investigate what the proprietary bootloader is capable of, see how/if you can obtain an original image etc.
One maybe easier solution, especially if you plan to restore the tablets on a regular basis, is to only make a new boot image to reflash the devices with. The only modification done is that you change the /init.rc script to mount /data and /system from the SDcard instead of from the internal nand disk device.
Once this is done, you'll power up and run the installation wizard and everything on your master tablet. Then power it down, and clone the SDcard. This SDcard now contains everything, so you'll simply restore a device by replacing its SDcard with a copy of this master card. I guess it's easier to clone a SDcard than reflashing several internal partitions. Easier to make the master as well - you don't need to dd or tar them, they are already in "image" format. If you can get hold of the original firmware, this should be quite easy without the need to preserving data from the device itself.
fro5tie said:
Any chance you'd be able to provide some more specific instructions?
Click to expand...
Click to collapse
Issue the commands "cat /proc/mtd" and "mount" on your device at command prompt (e.g. via "adb shell" or the "ConnectBot" terminal app). This shows you if the device allows you to copy the boot image from it. Paste in the output into this thread. If you believe the "clone the tablet via the SDcard" is a good solution for you, the process is in short terms something as below;
Copy the boot image to the sdcard:
# dd if=/dev/mtd/mtd2ro of=/mnt/sdcard/boot.img bs=2048 (device dependent of contents of /proc/mtd)
Remove the sdcard, insert into a computer, split the boot image info kernel + initramfs. Read http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images for instructions about how to work with the boot.img file. I really recommend a GNU/Linux environment for this.
Then edit /init.rc replacing the "mount yaffs2 [email protected] /system" with "mount ext3 /dev/block/mmcblk0p2 /system" for system and data (use p3 for data partition, the device name may be different on your tablet, see mount output).
Create an SDcard with three partitions: #1 vfat (standard), #2 and #3 ext3. Insert into you device and boot it up again.
# mount -t ext3 /dev/block/mmcblk0p2 /root
# cd /system
# tar cf - . | (cd /root ; tar xf - )
# umount /root
# mount -t ext3 /dev/block/mmcblk0p3 /root
# cd /data
# tar cf - . | (cd /root ; tar xf - )
# umount /root
This copies your partitions to the SDcard. Shutdown the tablet again.
Make a new boot.img using the instructions in the link above, using the edited init.rc script.
Now you can non-destrutive give this a try.
Place you tablet in fastboot mode (often vol-up (or vol-down) during power on).
$ fastboot devices
This vill verify the tablet is in fastboot mode. It should be listed. Then:
$ fastboot boot boot.img
Note here, only BOOT the tablet, do NOT use the "flash" keyword. This in case of the image isn't working, you'll just have to restart you tablet, and no harm's done.
Look around. Do a "mount" command. Everything works? Mount shows /data and /system from sdcard? Perfect. Now you can reflash it. Shutdown and flash:
$ fastboot flash boot boot.img
Now the device will use /data and /system from the SDcard every time. Customize your device, and then clone your SDcard and try it in tablet #2 you'll booting with your new boot.img and the cloned SDcard. Verify that #tablet #2 is a perfect clone of tablet #1. It is? Now you can flash the boot,img into all your tablets.
--------------------
But don't forget, there may be other solutions as well, maybe more suitable. This you'll have to investigate yourself.
And the usual disclaimer - you can probably not follow above by the letter. There sure is some obstacle you'll have to overcome, something non-standard, etc.
Also keep the original boot.img file for safekeeping in the case you want to restore the device's boot image some day.
Wow! Thanks for the info! This is really helpful, I need to set aside a bit of time to work through this and have a look. Thanks again its really appreciated, I'll be back with info once I've had chance to give it a go!
I certainly can't offer more detailed info than the fellow from Sweden who seems to really know his stuff...but what about making a nandroid backup of your fully configured reference tablet (I'm assuming all tablets are rooted). Ensure all your tabs have CWM recovery and copy your nandroid file to each one.
If any of your fleet get 'corrupted' you can simply restore the original, fully configured ROM.
In fact that sounds too obvious..likely I missed something about your scenario which precludes this option from consideration!
Good luck mate.
tweeny80 said:
I certainly can't offer more detailed info than the fellow from Sweden who seems to really know his stuff...but what about making a nandroid backup of your fully configured reference tablet (I'm assuming all tablets are rooted). Ensure all your tabs have CWM recovery and copy your nandroid file to each one.
If any of your fleet get 'corrupted' you can simply restore the original, fully configured ROM.
In fact that sounds too obvious..likely I missed something about your scenario which precludes this option from consideration!
Good luck mate.
Click to expand...
Click to collapse
Hi
Yes that was my first thought as well, tablets are rooted yes but there is no CWM for the tablet. Its an obscure Chinese branded tablet.
Unless there is another way to do nandroid backups?
hmm tricky situation. Catch 22 ! From what I know, your best bet is to backup all possible things through Titanium Backup given that you don't have the use of Nandroid backups. You can include wifi settings, messages etc but it's modular & not systemic.
I did a quick google search with no luck - time to upgrade your fleet dude :-0
Best of luck.
Some background:
I own a rooted asus transformer pad 300T. Being a big linux (Linux as in GNU/linux) fan, I wanted to install arch linux on it. This does however require an unlocked bootloader. Out of the box, the bootloader is locked, although it can be unlocked with an app provided by Asus. Unlocking does however void the warranty on the tablet and this is unacceptable for me and many other users.
This is why, over the past few weeks, I have been searching around XDA and the web to find alternative ways of flashing custom roms, leaving the bootloader locked and keeping my precious warranty. On of the first things I bumped into was Kexec. Although perfectly suited for my needs, Kexec is problematic in combination with the tegra 3 SoC: It freezes in the process of switching kernels, the cause for this unknown and very hard to debug. To overcome this, kexec-hardboot was created: A variant of kexec involving a cold reboot. Kexec-hardboot is, however, not suitable for locked bootloaders: It requires flashing a custom kernel which isn't an option in this situation.
The Idea:
Although it appears impossible to boot an alternative kernel, I figured it might be possible to switch to a different root partition, leaving the kernel unharmed. This my plan to achieve this:
After successfully booting stock android, an app/script performs the following operations:
Activitymanager, bluetooth and radio are shut down (This is what happens when normally shutting down android, before filesystems are unmounted)
rootfs is remounted readwrite and directory '/tmproot' is created
an instance of tmpfs is mounted on /tmproot, an initramfs-like structure is created with static busybox and a special script 'init'
'/system','/data', '/cache' and similar partitions are unmounted (This should be equivalent to shutting down the mount service)
android's init process is instructed to run 'exec /tmproot/busybox switch_root /tmproot init', /tmproot becomes '/' and the 'init' script is executed
The 'init' script mounts the partition/image file containing the arch linux filesystem and performs another 'exec switch_root', making the archlinux fs '/' and starting systemd (arch linux's alternative to init) as PID 1
Systemd follows it's normal startup sequence: Arch linux is succesfully booted!
The actions Question:
Although this is currently nothing but a fantasy, I believe this idea should work. There is only one thing I have not yet found the solution to: The process calling 'exec switch_root' must be PID 1. This means the android 'init' process had to directly run the command. The obvious thing to do here would of course be to modify init.rc to execute this when told to, but as init.rc lives in the initramfs, I can't make any modifications that would survive a reboot.
So to cut things short: How do I make init run a custom command on runtime?
Thanks in advance,
An android hacking noob
Hello,
I am new to xda, but with what I would say a good understanding of computers in general, and good knowledge of c programming (if that matters)
I am structuring a guide for myself to be as foolproof as possible when attempting flashing my new phone. Please fill in any voids, comment, or answer questions if you can. This should prove useful to other users as well as it's not so model-specific.
1) It appears that the custom recovery of choice in most situations and for the time being is TWRP (correct?).
2) If I can get a backup of EVERY partition on my stock phone (as it came from the factory) using TWRP, could I conceivably restore ALL of them and be in a factory default setting? Excluding stuff like eFuse and similar mechanisms.
3) If the phone supports fastboot, unlocked bootloader and there is a compatible TWRP for it, would it be possible to boot the TWRP recovery through fastboot (without flashing that particular partition to phone), open a shell and take backups of all partitions on the phone? That should give us a file for each partition.
4) If one accomplishes step 3 successfully, in what scenarios would he/she NOT be able to bring the phone back to life after software bricking?
Minor questions:
a) "To have root" on a phone, is basically the same as having a root account on a BOOTED OS partition (like the admin accoun on a booted windows machine, or a root account on a linux machine)? If that's the case, booting a different partition (for example the recovery partition) could also give you root priviledges without affecting the booted partition, correct?
b) Why do some custom ROMs require a certain version of the stock/OEM rom to be installed PRIOR to flashing, since they are going to replace those partitions anyway?
c) How is Xiaomi's Anti Roll Back (ARB) feature implemented, if one restores all partitions to stock from step (3) ? There must be some other places of storing of information on the phone, besides internal memory, correct?