Modifying uRamdisk & bootutil - Nook Touch Android Development
There's a lot of fine-tuning you can do by modifying init.rc that is packed into uRamdisk in the boot partition.
In the Unix world to modify init.rc inside uRamdisk you would need to:
Use dd to strip the image header
Use gzip to expand the contents
Use cpio to separate it into files
Edit what you want in init.rc
Use cpio to combine the files
Use gzip to compress the contents
Use mkimage to wrap the contents
In the Windows world a command line utility simplifies this:
Code:
bootutil /v /x uRamdisk init.rc
Edit init.rc
Code:
bootutil /v /r uRamdisk init.rc
As always, be careful and make a backup.
Making a Clockwork Recovery update to restore the original uRamdisk might be a good idea.
Download bootutil.exe in the signature.
Renate NST said:
There's a lot of fine-tuning you can do by modifying init.rc that is packed into uRamdisk in the boot partition.
In the Unix world to modify init.rc inside uRamdisk you would need to:
Use dd to strip the image header
Use gzip to expand the contents
Use cpio to separate it into files
Edit what you want in init.rc
Use cpio to combine the files
Use gzip to compress the contents
Use mkimage to wrap the contents
In the Windows world a command line utility simplifies this:
Code:
bootutil /v /x uRamdisk init.rc
Edit init.rc
Code:
bootutil /v /r uRamdisk init.rc
As always, be careful and make a backup.
Making a Clockwork Recovery update to restore the original uRamdisk might be a good idea.
Download bootutil.exe in the signature.
Click to expand...
Click to collapse
Cool!
Now we will see real hard core modding! :highfive:
I've added delete to the operations of bootutil:
Code:
usage: bootutil image file [...]
/d delete files
/l list files
/r replace files
/x extract files
/v verbose
Here's some ideas of what you can do with bootutil.
Install adbd in /system/bin and chmod 755 it.
Delete both sbin and sbin/adbd from uRamdisk.
Change the start of adbd in init.rc from /sbin/adbd to /system/bin/adbd
Trim the cruft from PATH in init.rc and make it only /system/bin
Delete the whole secton in init.rc for the /data/media/B&N Downloads
Add a mount point for USB drives right before the root gets ro in init.rc
Delete all that stuff for /sys/devices/platform/omapdss
Where/when/what did that ever exist?
Renate, Thank you very much for your tool. I've been looking for a way to change mount point from /sdcard to /mnt/sdcard for a long time. With bootutil it's much easier.
How I did it:
1. Flash noogie.img to sdcard.
2. Boot from sdcard and connect NST to PC.
3. In partition manager assign letter to boot partition.(ex. MiniTool Partition Wizard)
4. Update mount points in init.rc at E:\uRamdisk with bootutil.(Don't forget to mkdir your mount points)
5. Remove letter from boot partition with partition manager.
6. Reboot NST.
7. Update mount points /system/etc/vold.conf
I've added more stuff and more flags to bootutil.exe
It won't make a lot of difference for modifying just init.rc,
but it will allow you to make your own ramdisks and insert files and symlinks.
Code:
usage: bootutil [flags] image file [file...]
/d delete files
/g group id
/i insert before
/l list files
/m file mode
/n new archive (name)
/r replace files
/s symlink (path)
/x extract files
/u user id
/v verbose
[b]# create 3 symlinks to busybox[/b]
bootutil /v uRamdisk /i /sbusybox date ls ps
[b]# insert adbd before stuff with chmod 755[/b]
bootutil /v uRamdisk /istuff system/bin/adbd /m755
Error Messages
Many thanks for bootutil! I'm trying to modify the init in uRamdisk and am getting the following errors messages:
GZip signature not found OR
Image signature not found.
Any suggestions?
Thanks!
dnordquest said:
Any suggestions?
Click to expand...
Click to collapse
Are you sure that what you have is a uRamdisk?
Try this:
Code:
C:\>bootutil /l /v uRamdisk
Read image, 11 files
drwxrwx--x data
-rw-r--r-- 89 2013-02-08 08:54 default.prop
drwxr-xr-x dev
-rw-r--r-- 324 env.txt
-rwxr-x--- 107344 2012-02-03 09:13 init
-rwxr-x--- 1677 init.goldfish.rc
-rwxr-x--- 19131 2013-02-08 08:54 init.rc
-rwxr-x--- 40205 initlogo.rle
drwxr-xr-x proc
drwxr-xr-x sys
drwxr-xr-x system
Then try:
Code:
C:\>bootutil /x /v uRamdisk init
"Are you sure that what you have is a uRamdisk?"
When I try bootutil.exe on the uRamdisk from my boot directory, I get "Gzip signature not found."
When I try it on the uRamdisk from the binaries.zip file you linked to as a source for a good init, I get what you say I should get. The uRamdisk from my 1.2.1 updated, rooted NST is 182K. The uRamdisk that works is 168k. Should I look for another?
Thanks.
I do have version 1.1, 1.1.2, 1.1.5, 1.2, 1.2.1 of the uRamdisk and they all work fine with bootutil.
Maybe whoever did your rooted uRamdisk did a sloppy job?
Get that file to me and I'll take a look.
Code:
E:\>bootutil /v /l E:\Nook11\ramdisk.img
Read image, 13 files
drwxrwx--x data
-rw-r--r-- 118 default.prop
drwxr-xr-x dev
-rw-r--r-- 324 env.txt
-rwxr-x--- 127964 init
-rwxr-x--- 1677 init.goldfish.rc
-rwxr-x--- 18728 init.rc
-rwxr-x--- 40205 initlogo.rle
drwxr-xr-x proc
drwxr-x--- sbin
-rwxr-x--- 134136 sbin/adbd
drwxr-xr-x sys
drwxr-xr-x system
E:\>bootutil /v /l E:\Nook112\ramdisk.img
Read image, 13 files
drwxrwx--x data
-rw-r--r-- 118 default.prop
drwxr-xr-x dev
-rw-r--r-- 324 env.txt
-rwxr-x--- 127964 init
-rwxr-x--- 1677 init.goldfish.rc
-rwxr-x--- 18728 init.rc
-rwxr-x--- 40205 initlogo.rle
drwxr-xr-x proc
drwxr-x--- sbin
-rwxr-x--- 134136 sbin/adbd
drwxr-xr-x sys
drwxr-xr-x system
E:\>bootutil /v /l E:\Nook115\ramdisk.img
Read image, 13 files
drwxrwx--x data
-rw-r--r-- 118 default.prop
drwxr-xr-x dev
-rw-r--r-- 324 env.txt
-rwxr-x--- 127964 init
-rwxr-x--- 1677 init.goldfish.rc
-rwxr-x--- 19067 init.rc
-rwxr-x--- 40205 initlogo.rle
drwxr-xr-x proc
drwxr-x--- sbin
-rwxr-x--- 134136 sbin/adbd
drwxr-xr-x sys
drwxr-xr-x system
E:\>bootutil /v /l E:\Nook12\ramdisk.img
Read image, 13 files
drwxrwx--x data
-rw-r--r-- 118 default.prop
drwxr-xr-x dev
-rw-r--r-- 324 env.txt
-rwxr-x--- 128000 init
-rwxr-x--- 1677 init.goldfish.rc
-rwxr-x--- 19259 init.rc
-rwxr-x--- 40205 initlogo.rle
drwxr-xr-x proc
drwxr-x--- sbin
-rwxr-x--- 134136 sbin/adbd
drwxr-xr-x sys
drwxr-xr-x system
E:\>bootutil /v /l E:\Nook121\ramdisk.img
Read image, 13 files
drwxrwx--x data
-rw-r--r-- 118 default.prop
drwxr-xr-x dev
-rw-r--r-- 324 env.txt
-rwxr-x--- 128000 init
-rwxr-x--- 1677 init.goldfish.rc
-rwxr-x--- 19259 init.rc
-rwxr-x--- 40205 initlogo.rle
drwxr-xr-x proc
drwxr-x--- sbin
-rwxr-x--- 134136 sbin/adbd
drwxr-xr-x sys
drwxr-xr-x system
So, mystery solved.
My bootutil.exe never addressed the possibility of name or comment fields on the internal GZip.
It does now, download in the signature.
See also: http://forum.xda-developers.com/showpost.php?p=38695314&postcount=137
Used new bootutil to replace init in uRamdisk and keyboard now working fine! On to audio!
Many thanks!
Dear Renate NST,
I used bootutil to modify uRamdisk , but i got "Image data CRC error".
batchaesir said:
i got "Image data CRC error".
Click to expand...
Click to collapse
The problem is that the CRC for the image data is wrong.
I don't know what tool made this file, but it's wrong.
The problem is that the "guts" of the file are 1/4 Meg but it's padded out to 1 Meg with zeroes.
Take your file and truncate it to 0x3d339 (250,681) in length.
There's a new bootutil.exe in the signature with less ambiguous error reporting.
Code:
C:\>bootutil /l ramdisk.uimg
Image data size error
C:\>modfile /t ramdisk.uimg 3d339
C:\>bootutil /l ramdisk.uimg
drwxrwx--x data
-rw-r--r-- 118 default.prop
...
Renate NST ,
Thanks so much. I used dd command. Problem is solved.
imgutil usage
Renate NST said:
There's a lot of fine-tuning you can do by modifying init.rc that is packed into uRamdisk in the boot partition.
In the Unix world to modify init.rc inside uRamdisk you would need to:
Use dd to strip the image header
Use gzip to expand the contents
Use cpio to separate it into files
Edit what you want in init.rc
Use cpio to combine the files
Use gzip to compress the contents
Use mkimage to wrap the contents
In the Windows world a command line utility simplifies this:
Code:
bootutil /v /x uRamdisk init.rc
Edit init.rc
Code:
bootutil /v /r uRamdisk init.rc
As always, be careful and make a backup.
Making a Clockwork Recovery update to restore the original uRamdisk might be a good idea.
Download bootutil.exe in the signature.
Click to expand...
Click to collapse
Hi Renate,
I was just wondering about the usage of imgutil commands.
In the command Usage: imgutil [flags] image [file...], I would like to modify init.rc on uRamdisk. Do I simply type uRamdisk like above? Or is there a path I need to specify?
On my system under /proc/partitions I have:
179 16 1024 mmcblk0boot1
179 8 1024 mmcblk0boot0
and under /proc/mtd I have nothing
Will this be a problem?
Cheers,
Stephan
First: As general information, this is now called imgutil, uses (mostly?) the same arguments and is available in the signature below.
It has had improvements to make it more robust and it can deal with images with garbage on the end.
It also supports DTB, the device tree blob used on some newer devices.
I use this on many non-B&N devices, including Marshmallow.
@stephangm
You first have to get the raw image.
Depending on your device, it might be a file in a partition or a raw partition.
A file always has an explicit size, a partition has an explicit size too, but it's usually bigger than the actual image.
For instance, the NST uses a uRamdisk file inside the FAT partiton mmcblk0p1
The Glow Plus uses a combined kernel/ramdisk that's in the raw (emmc) partition mmcblk0p1
To get this, you might do something like:
Code:
C:\> adb shell
# cat /dev/block/mmcblk0p1 > /sdcard/p1.img
# ^D
C:\> adb pull /sdcard/p1.img
C:\> dir p1.img
--- 12 Megs or something
C:\> imgutil /v /x p1.img init.rc
C:\> myeditor init.rc
C:\> imgutil /v /r p1.img init.rc
C:\> dir p1.img
--- 7 Megs or something
C:\> adb push p1.img /sdcard
C:\> adb shell
# cat /sdcard/p1.img > /dev/block/mmcblk0p1
Note that when you first copy the file it will be the full size of the partition, that is, the image plus useless stuff at the end.
Once imgutil has modified it, it will be truncated to the useful size.
As far as figuring out which partition the boot one is, there are multiple ways, including fdisk, /proc, by-name or in the sysfs uevent.
When i tried to use this command with imgutil (the new name for bootutil from Renate NST) on NST
"imgutil /l /v uRamdisk"
i received this message : Could not open uRamdisk ???
Secondly, copying this row of code :
"adb shell
# cat /dev/block/mmcblk0p1 > /sdcard/p1.img"
i get this answer:
"cannot create /sdcard/p1.img, read-only file system"
Why these commands don't work as intended ???
gsms said:
I received this message : Could not open uRamdisk ???
Click to expand...
Click to collapse
Probably because the file does not exist.
gsms said:
Secondly, copying this row of code :
"adb shell
# cat /dev/block/mmcblk0p1 > /sdcard/p1.img"
i get this answer:
"cannot create /sdcard/p1.img, read-only file system"
Click to expand...
Click to collapse
Those instruction were for the Glow Plus.
Since you haven't even copied over the uRamdisk from the NST, it makes the first part above even less sensible.
The NST has the uRamdisk as a file on the vfat on mmcblk0p1
There's a new version of imgutil.exe available in the signature.
The changes include the addition of the /a (append) flag and different behavior for the /i (insert) flag.
It no longer is necessary (or legal) to supply an argument to the /i flag.
/a puts all the files at the end of the archive in the order that they appear on the command line.
Code:
imgutil /a /v boot.img bats zebras cats
At the end of the archive would be bats, zebras, cats.
Code:
imgutil /i /v boot.img bats zebras cats
The three files would be inserted at the sorted position.
From a previous update, the /c flag allows you to change the command line that is fed to the kernel.
Related
NT: Build root filesystem
Extracting the N2 root filesystem and adding rc.local These instructions assume using a linux console. The root filesystem lives in a u-boot/PPCboot ramdisk. These instructions tell you how to extract it. Boot your nt with the "rooted forever" sdcard while connected with usb. Make a copy of the boot partition. After this you may reboot your nt normally. $ tar -cf boot.tar boot/ $ tar xvf boot.tar $ cd boot Extract the uRamdisk file. first 64 bytes is the u-boot header, we need to skip it. $ dd if=URamdisk bs=64 skip=1 of=ramdisk.gz ramdisk.gz now contains the root file system. Copy ramdisk.gz to a work directory, then extract it: gunzip -v ramdisk.gz cpio -iv < ramdisk The root file system will populate your work dir. Delete the ramdisk file. You can now make changes to the root file system. The change I'm going to make is a simple one: adding the ability to run an rc.local file at boot. edit the init.rc file in your work directory, adding at the bottom: Code: service rclocal /etc/rc.local enabled user root oneshot rebuilding the uRamdisk file is simple, once you know how (thanks to JesusFreke for pointing me in the right direction). cd into your working directory, issue these commands: Code: find . -regex "./.*"| cpio -ov -H newc | gzip > ../ramdisk.gz mkimage -A ARM -T RAMDisk -n Image -d ../ramdisk.gz ../uRamdisk A script with the the commands above is attached. Also attached is a rooted uRamdisk with the rc.local ability already build in. To replace the uRamdisk file, boot with your "Rooted Forever" sdcard, and copy the uRamdisk file to the nook's boot directory. What's this good for? That's up to you. I'm using it to automatically start dropbear so I can ssh in my Nooks and also use rsync to keep them synced with my ebook library. This is also one of the steps in building a kernel for the Nook ST.
jocala said: Extracting the N2 root filesystem and adding rc.local These instructions assume using a linux console. The root filesystem lives in a u-boot/PPCboot ramdisk. These instructions tell you how to extract it. Boot your nt with the "rooted forever" sdcard while connected with usb. Make a copy of the boot partition. After this you may reboot your nt normally. $ tar -cf boot.tar boot/ $ tar xvf boot.tar $ cd boot Extract the uRamdisk file. first 64 bytes is the u-boot header, we need to skip it. $ dd if=URamdisk bs=64 skip=1 of=ramdisk.gz ramdisk.gz now contains the root file system. Copy ramdisk.gz to a work directory, then extract it: gunzip -v ramdisk.gz cpio -iv < ramdisk The root file system will populate your work dir. Delete the ramdisk file. You can now make changes to the root file system. The change I'm going to make is a simple one: adding the ability to run an rc.local file at boot. edit the init.rc file in your work directory, adding at the bottom: Code: service rclocal /etc/rc.local enabled user root oneshot rebuilding the uRamdisk file is simple, once you know how (thanks to JesusFreke for pointing me in the right direction). cd into your working directory, issue these commands: Code: find . -regex "./.*"| cpio -ov -H newc | gzip > ../ramdisk.gz mkimage -A ARM -T RAMDisk -n Image -d ../ramdisk.gz ../uRamdisk A script with the the commands above is attached. Also attached is a rooted uRamdisk with the rc.local ability already build in. To replace the uRamdisk file, boot with your "Rooted Forever" sdcard, and copy the uRamdisk file to the nook's boot directory. What's this good for? That's up to you. I'm using it to automatically start dropbear so I can ssh in my Nooks and also use rsync to keep them synced with my ebook library. This is also one of the steps in building a kernel for the Nook ST. Click to expand... Click to collapse dd if=URamdisk bs=64 skip=1 of=ramdisk.gz Click to expand... Click to collapse "uRamdisk" instead of "URamdisk" Thanks again.
[Q] How to modify init.xxx.rc without rebuild boot.img ??
As everybody knows, Motorola and most of other android phones have locked the bootloader, so repacking boot.img will not boot. I see the init.xxx.rc files are modified in Cyanogenmod series ROMS, but I checked they did not repacked boot.img( files are not from boot.img) can somebody tell me how did they do that? I am making a programm that works like bootmenu but I don't want replace logwrapper, I wish I could add an exec command in the rc file
well, I saw there's 2nd-init. answered by myself.. ~ # ls -l /init.rc ls -l /init.rc -rw-r--r-- 1 root root 17507 Dec 14 14:26 /init.rc ~ # ls -l /system/bootmenu/2nd-init/init.rc ls -l /system/bootmenu/2nd-init/init.rc -rw-r--r-- 1 root root 17507 Aug 1 2008 /system/bootmenu/2nd-init/init.rc ~ # ======== seems I can't make easier than the way bootmenu does..
This really do not know，but deliberately over the top with your Google Translation。。。
[HOWTO][ROOT] Forget about Odin and Heimdall also does not increase counter
Background: Just purchased a Samsung Galaxy SIII i747 running 4.0.4, but alas I have only a mac and need to root + cwm without tripping the counter. I loved my original galaxy and hope this community continues to flourish. This was inspired by Noxious Ninja at http://forum.xda-developers.com/showthread.php?t=1790104 and miloj at http://forum.xda-developers.com/showthread.php?t=1704209 so give them some props :good:. Tools Required: clockworkmod Temporary su (found in attachment) debugfs (also found in attachment) adb (Found in Android SDK) optional: if you're using windows then you'll need extra drivers Note: The su and debugfs were not compiled by me however miloj does provide code for su in his post incase you're concerned they both deserve more props :good:. Now that you've collected all of the necessary tools it's time to get to work. You should type in lines that are black. The color green should be your response. If something is red it's important. STEP 1: push debug and su onto your device and locate relavent block devices create a symbolic link for our attack to /system Make sure usb debugging is enabled. First unarchive the attachment and if your path is correct simply. Code: macbook-pro:debugfs_su entropy$ adb push debugfs /data/local/ [COLOR="Lime"]2708 KB/s (1862336 bytes in 0.671s)[/COLOR] macbook-pro:debugfs_su entropy$ adb push su /data/local/ [COLOR="lime"]2795 KB/s (372006 bytes in 0.129s)[/COLOR] macbook-pro:debugfs_su entropy$ adb shell [email protected]:/ $ cd /data/local [email protected]:/data/local $ mv tmp tmp.back [email protected]:/data/local $ cd /dev/block/platform/msm_sdcc.1/by-name [email protected]:/dev/block/platform/msm_sdcc.1/by-name $ ls -al [COLOR="lime"]lrwxrwxrwx root root 1970-01-25 02:16 aboot -> /dev/block/mmcblk0p5 lrwxrwxrwx root root 1970-01-25 02:16 backup -> /dev/block/mmcblk0p20 lrwxrwxrwx root root 1970-01-25 02:16 boot -> /dev/block/mmcblk0p7 lrwxrwxrwx root root 1970-01-25 02:16 cache -> /dev/block/mmcblk0p17 lrwxrwxrwx root root 1970-01-25 02:16 efs -> /dev/block/mmcblk0p11 lrwxrwxrwx root root 1970-01-25 02:16 fota -> /dev/block/mmcblk0p19 lrwxrwxrwx root root 1970-01-25 02:16 fsg -> /dev/block/mmcblk0p21 lrwxrwxrwx root root 1970-01-25 02:16 grow -> /dev/block/mmcblk0p23 lrwxrwxrwx root root 1970-01-25 02:16 modem -> /dev/block/mmcblk0p1 lrwxrwxrwx root root 1970-01-25 02:16 modemst1 -> /dev/block/mmcblk0p12 lrwxrwxrwx root root 1970-01-25 02:16 modemst2 -> /dev/block/mmcblk0p13 lrwxrwxrwx root root 1970-01-25 02:16 pad -> /dev/block/mmcblk0p9 lrwxrwxrwx root root 1970-01-25 02:16 param -> /dev/block/mmcblk0p10 lrwxrwxrwx root root 1970-01-25 02:16 persist -> /dev/block/mmcblk0p16 [COLOR="Red"]lrwxrwxrwx root root 1970-01-25 02:16 recovery -> /dev/block/mmcblk0p18[/COLOR] lrwxrwxrwx root root 1970-01-25 02:16 rpm -> /dev/block/mmcblk0p6 lrwxrwxrwx root root 1970-01-25 02:16 sbl1 -> /dev/block/mmcblk0p2 lrwxrwxrwx root root 1970-01-25 02:16 sbl2 -> /dev/block/mmcblk0p3 lrwxrwxrwx root root 1970-01-25 02:16 sbl3 -> /dev/block/mmcblk0p4 lrwxrwxrwx root root 1970-01-25 02:16 ssd -> /dev/block/mmcblk0p22 [COLOR="red"]lrwxrwxrwx root root 1970-01-25 02:16 system -> /dev/block/mmcblk0p14[/COLOR] lrwxrwxrwx root root 1970-01-25 02:16 tz -> /dev/block/mmcblk0p8 lrwxrwxrwx root root 1970-01-25 02:16 userdata -> /dev/block/mmcblk0p15[/COLOR] [email protected]:/dev/block/platform/msm_sdcc.1/by-name $ cd /data/local [email protected]:/data/local $ ln -s /dev/block/mmcblk0p14 tmp #this comes from one of the red highlights specifically the symbolic link to system [email protected]:/data/local $ exit macbook-pro:debugfs_su entropy$ adb reboot STEP 2: perform the attack and clean up Code: macbook-pro:debugfs_su entropy$ adb shell [email protected]:/ $ cd /data/local [email protected]:/data/local $ toolbox chmod 755 /data/local/debugfs [email protected]:/data/local $ /data/local/debugfs -w /data/local/tmp [COLOR="Lime"]debugfs 1.42 (29-Nov-2011)[/COLOR] debugfs: cd xbin debugfs: rm su [COLOR="Red"]rm: File not found by ext2_lookup while trying to resolve filename[/COLOR] #don't worry about this debugfs: write /data/local/su su [COLOR="Lime"]Allocated inode: 533[/COLOR] debugfs: set_inode_field su mode 0106755 debugfs: set_inode_field su uid 0 debugfs: set_inode_field su gid 0 debugfs: quit [email protected]:/data/local $ rm tmp [email protected]:/data/local $ mv tmp.back tmp [email protected]:/data/local $ exit macbook-pro:debugfs_su entropy$ adb reboot STEP 3: Great success Code: macbook-pro:debugfs_su entropy$ adb shell [email protected]:/ $ /system/xbin/su [COLOR="lime"]Now we be 0:0 ![/COLOR] [email protected]:/ # id [COLOR="Lime"]uid=0(root) gid=0(root) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats)[/COLOR] [email protected]:/ # exit [email protected]:/ $ exit STEP 4: Immediately install superuser and force an upgrade to replace the unsecured su STEP 5: Install Clockwork Code: macbook-pro:Downloads entropy$ adb push recovery-clockwork-5.8.4.5-d2att.img /sdcard/ [COLOR="lime"]3660 KB/s (7170048 bytes in 1.912s) [/COLOR] macbook-pro:Downloads entropy$ adb shell [email protected]:/ $ su [email protected]:/ # id [COLOR="lime"]uid=0(root) gid=0(root) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats)[/COLOR] [email protected]:/ # dd if=recovery-clockwork-5.8.4.5-d2att.img of=/dev/block/mmcblk0p18 #this device file comes from step 1 and is for the recovery partition [COLOR="lime"]14004+0 records in 14004+0 records out 7170048 bytes transferred in 1.844 secs (3888312 bytes/sec)[/COLOR] [email protected]:/ # reboot recovery STEP 6: Celebrate and give yourself a pat on the back, because this will be fixed very quickly First post! Also, maybe the mods could move this to the appropriate forum.
Thanks for posting this so folks in this forum can see it. The link that you give at the top of your post for Noxious Ninja's thread goes directly to his instructions and, though those are in the Verizon forum, the method works for all US GS3 variants. Nice and easy way to root without having to flash anything in Odin, and it doesn't trip the flash counter. Noxious Ninja has also put a Windows batch script based tool together that automates this process (it would be easy enough to write a bash script for Linux to do the same thing). I just used the Windows based tool to root stock UCALG1, and it worked great. Here is the link to Noxious Ninja's automated tool.: http://forum.xda-developers.com/showthread.php?t=1792342
jscott30 said: Thanks for posting this so folks in this forum can see it. The link that you give at the top of your post for Noxious Ninja's thread goes directly to his instructions and, though those are in the Verizon forum, the method works for all US GS3 variants. Nice and easy way to root without having to flash anything in Odin, and it doesn't trip the flash counter. Noxious Ninja has also put a Windows batch script based tool together that automates this process (it would be easy enough to write a bash script for Linux to do the same thing). I just used the Windows based tool to root stock UCALG1, and it worked great. Here is the link to Noxious Ninja's automated tool.: http://forum.xda-developers.com/showthread.php?t=1792342 Click to expand... Click to collapse Yea, they did most of the work. My carrier is AT&T so I was just happy I could make some progress today with everything coming together despite so much segregation between carriers (I understand why). However, I am a little discouraged by the mysterious IMEI disappearances. I was about to flash cm9 and kt747, but am having second thoughts. I miss my captivate I only flashed it once.
arcadia3go said: Yea, they did most of the work. My carrier is AT&T so I was just happy I could make some progress today with everything coming together despite so much segregation between carriers (I understand why). However, I am a little discouraged by the mysterious IMEI disappearances. I was about to flash cm9 and kt747, but am having second thoughts. I miss my captivate I only flashed it once. Click to expand... Click to collapse IMEI problems have been solved. There are two threads with two slightly different backup methods and restoration methods. I recommend reading them both and backing up both ways. I know I did.
jscott30 said: Thanks for posting this so folks in this forum can see it. The link that you give at the top of your post for Noxious Ninja's thread goes directly to his instructions and, though those are in the Verizon forum, the method works for all US GS3 variants. Nice and easy way to root without having to flash anything in Odin, and it doesn't trip the flash counter. Noxious Ninja has also put a Windows batch script based tool together that automates this process (it would be easy enough to write a bash script for Linux to do the same thing). I just used the Windows based tool to root stock UCALG1, and it worked great. Here is the link to Noxious Ninja's automated tool.: http://forum.xda-developers.com/showthread.php?t=1792342 Click to expand... Click to collapse off topic but great to see you in the GS3 forums.Loved your roms for the Infuse4g
Woah! Odin seems much simpler lol
Not sure using debugfs on the file system is that great an idea. I posted on this exploit on the Full Disclosure mailing list, and here is what Dan Rosenberg had to say in reply to me. Note in particular his sentence: "Using debugfs to modify the filesystem is completely unnecessary and potentially destructive."
just want to point out that in my case i had to specify full path when installing CWM in step 5 from: dd if=recovery-clockwork-5.8.4.5-d2att.img of=/dev/block/mmcblk0p18 #this device file comes from step 1 and is for the recovery partition 14004+0 records in to: dd if=/sdcard/recovery-clockwork-5.8.4.5-d2att.img of=/dev/block/mmcblk0p18 #this device file comes from step 1 and is for the recovery partition 14004+0 records in
have some problems with CMW after root CMW worked after the immediate reboot, but somehow lost and the 3e Recovery as back. I initiated a post here: http://forum.xda-developers.com/showthread.php?p=30708262#post30708262
Now if only someone can figure out and on device root method.
OP, I think I love you! Thanks so much for this!
[Solved] How to make changes to /system stick? (rooted HTC One)
How can I change files in the /system partition on a rooted HTC One? I... 1. Mount /system as read-write 2. Rename a file and confirm that it has changed 3. Remount /system as read only The changes I made in step 2 have been forgotten. How can I get around this? C:\Program Files (x86)\HTC\HTC Sync Manager\HTC Sync>adb shell [email protected]:/ $ su su [email protected]:/ # cd system/app cd system/app 1|[email protected]:/system/app # ls -l GM* ls -l GM* -rw-r--r-- root root 5215731 2014-01-17 11:15 GMS_Maps.apk -rw-r--r-- root root 6884656 2008-08-01 22:00 GMS_Maps.odex [email protected]:/system/app # mv GMS_Maps.apk GMS_Maps.apk.old 255|[email protected]:/system/app # mount -o rw,remount /system mount -o rw,remount /system [email protected]:/system/app # mv GMS_Maps.apk GMS_Maps.apk.old mv GMS_Maps.apk GMS_Maps.apk.old [email protected]:/system/app # ls -l GM* ls -l GM* -rw-r--r-- root root 5215731 2014-01-17 11:15 GMS_Maps.apk.old -rw-r--r-- root root 6884656 2008-08-01 22:00 GMS_Maps.odex [email protected]:/system/app # mount -o ro,remount /system mount -o ro,remount /system [email protected]:/system/app # ls -l GMS* ls -l GMS* -rw-r--r-- root root 5215731 2014-01-17 11:15 GMS_Maps.apk -rw-r--r-- root root 6884656 2008-08-01 22:00 GMS_Maps.odex [email protected]:/system/app #
Solved... the stock kernel is write protected. You have to install a non-protected kernel, such as BulletProof. Make sure you choose the one that matches your Android and Sense versions. Copy the ZIP to your HTC One, boot into recovery, install zip and reboot... then use Root Explorer or ES File Explorer to delete /system/app/GMS_Maps.apk and /system/app/GMS_Maps.odex. No more Maps 7.x! Thanks nkk71 for the tip.
init.rc update twrp bootloop
EDIT I FIGURED IT OUT, after some head scratching and studying of magisk 15.3 zip.
Below is how I was able to edit the init.rc:
Required:
Magisk-v15.3.zip
- Magisk-v15.3/arm64/magiskboot
- Magisk-v15.3/chromeos/futility
- Magisk-v15.3/chromeos/kernel.keyblock
- Magisk-v15.3/chromeos/kernel_data_key.vbprivk
*I have to sudo adb, not sure how to have the permissions by default.*
Code:
adb push futility /sdcard/
adb push magiskboot /sdcard/
cp /sdcard/futility /system/bin/
chmod u+x /system/bin/futility
cp magiskboot /system/bin/
chmod u+x /system/bin/magiskboot
mkdir -p /sdcard/initrc
adb push kernel_data_key.vbprivk /sdcard/initrc/
adb push kernel.keyblock /sdcard/initrc/
Old guides on the interwebs tell you that lnx is the partition to unpack / repack flash however if you peek at Magisk-v15.3/common/util_functions.sh
Code:
find_boot_image() {
...
for BLOCK in boot_a kern-a android_boot kernel boot lnx bootimg; do
BOOTIMAGE=`find /dev/block -iname $BLOCK | head -n 1` 2>/dev/null
Because there's a kern-a that's the one you need to use. The above command gets me:
/dev/block/platform/700b0600.sdhci/by-name/KERN-A
The above command also is used to display: "Found boot image: /dev/block/mmcblk0p1" (cat /proc/partitions) during Magisk installation.
Now that I've figured out the boot partition, I'll use magiskboot to unpack it.
Code:
cd /sdcard/initrc
magiskboot --unpack /dev/block/platform/700b0600.sdhci/by-name/KERN-A
MagiskBoot v15.3(1531) (by topjohnwu) - Boot Image Modification Tool
Parsing boot image: [/dev/block/platform/700b0600.sdhci/by-name/KERN-A]
KERNEL [5481552] @ 0x10008000
RAMDISK [1876886] @ 0x11000000
SECOND [0] @ 0x10f00000
EXTRA [0] @ 0x10000100
PAGESIZE [2048]
OS_VERSION [8.1.0]
PATCH_LEVEL [2018-03]
NAME []
CMDLINE [buildvariant=userdebug]
DTB [5481552]
KERNEL_FMT [dtb]
RAMDISK_FMT [gzip]
The unpacking will create dtb, kernel, and ramdisk.cpio. I'll extract the ramdisk.cpio so I can add / edit files.
**NOTE** if you get a permission denied .backup / .subackup just run sudo
Code:
mkdir ramdisk
cd ramdisk
sudo cpio -i -d -m < ../ramdisk.cpio
I'm not sure how to fix this but I was getting:
cpio: bugreports: Operation not permitted
cpio: charger: Operation not permitted
cpio: d: Operation not permitted
cpio: etc: Operation not permitted
cpio: sbin/ueventd: Operation not permitted
cpio: sbin/watchdogd: Operation not permitted
cpio: sdcard: Operation not permitted
I was forced to copy ramdisk.cpio to my computer and extract it, update, and repack it there.
Once you're ready to repack and move the ramdisk back to the pixel c.
Code:
sudo find . | sudo cpio -R 0:0 -H newc -o > ../newramdisk.cpio
mv /sdcard/initrc/ramdisk.cpio /sdcard/initrc/ramdisk.cpio.orig
adb push newramdisk.cpio /sdcard/initrc/ramdisk.cpio
cd /sdcard/initrc && magiskboot --repack /dev/block/platform/700b0600.sdhci/by-name/KERN-A
MagiskBoot v15.3(1531) (by topjohnwu) - Boot Image Modification Tool
Parsing boot image: [/dev/block/platform/700b0600.sdhci/by-name/KERN-A]
KERNEL [5481552] @ 0x10008000
RAMDISK [1876886] @ 0x11000000
SECOND [0] @ 0x10f00000
EXTRA [0] @ 0x10000100
PAGESIZE [2048]
OS_VERSION [8.1.0]
PATCH_LEVEL [2018-03]
NAME []
CMDLINE [buildvariant=userdebug]
DTB [5481552]
KERNEL_FMT [dtb]
RAMDISK_FMT [gzip]
Repack to boot image: [new-boot.img]
KERNEL [5481552] @ 0x10008000
RAMDISK [1879383] @ 0x11000000
SECOND [0] @ 0x10f00000
EXTRA [0] @ 0x10000100
PAGESIZE [2048]
OS_VERSION [8.1.0]
PATCH_LEVEL [2018-03]
NAME []
CMDLINE [buildvariant=userdebug]
This will create "new-boot.img" file. Next we'll need to sign the image. If someone can explain why it's required that would be great.
Code:
cd /sdcard/initrc
echo > empty
futility vbutil_kernel --pack new-boot.img.signed --keyblock ./kernel.keyblock --signprivate ./kernel_data_key.vbprivk --version 1 --vmlinuz new-boot.img --config empty --arch arm --bootloader empty --flags 0x1
Finally flash the signed boot image and reboot
Code:
cat /sdcard/initrc/new-boot.img.signed | eval cat - | cat - /dev/zero 2>/dev/null | dd of=/dev/block/platform/700b0600.sdhci/by-name/KERN-A bs=4096
dd: /dev/block/platform/700b0600.sdhci/by-name/KERN-A: No space left on device
8193+0 records in
8192+0 records out
33554432 bytes transferred in 0.129 secs (260111875 bytes/sec)
---ORIGINAL POST---
Trying to edit init.rc (or anything really in the ramdisk) by unpacking / repacking and flashing but I get stuck in a TWRP 3.2.1-0 bootloop. I've been using the latest unofficial lineage March 8, 2018 from followmsi
I'm not sure if there's an easier way or I'm doing it wrong all the guides out there are from 2012-2014.
With github com/xiaolu/mkbootimg_tools was using the LNX partition but then noticed the SuperSu.zip when installing from TWRP was using KERN-A the mmcblk0p1.
Code:
Unpack & decompress ../boot.img to boot
kernel : kernel
ramdisk : ramdisk
page size : 2048
kernel size : 5463088
ramdisk size : 1594653
base : 0x10000000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
tags offset : 0x00000100
cmd line : buildvariant=userdebug
ramdisk is gzip format.
Unpack completed.
When flashing either of them I get stuck in the bootloop. I've tried fastboot flash boot new_boot.img, dd and cat > when updating the repacked boot image. I also tried fastboot flash:raw boot <kernel> [ <ramdisk> [ <second> ] ] create bootimage and flash it.
When booting the image without flashing via sudo fastboot boot new_boot.img I get stuck on the lineageOS logo before it reboots to recovery TWRP then I have to reboot again to get back into the rom.
I've also tried many other unpacking / packing script tools with no success just bootloops or complaints about invalid boot.img
I don't understand how supersu and magisk zip can have zips run from twrp that are able to edit the ramdisk? Are they running a compiled c program like this? github com/TeamWin/Team-Win-Recovery-Project/blob/8373cfe28cf1b5ad758faa1d502e21787c3665e4/injecttwrp/injecttwrp.c
Probably not relevant (disclaimer couldn't hex edit my way out of a paper bag) but noticed sometimes when repacking with different tools and peeking at the new boot image with ghex that the first line in the original boot was always CHROMEOS but the repacked would say ANDROID! and be just 5-7mb when the boot image backup would be 36mb in size.
Code:
APP -> /dev/block/mmcblk0p4
CAC -> /dev/block/mmcblk0p6
KERN-A -> /dev/block/mmcblk0p1
KERN-B -> /dev/block/mmcblk0p2
LNX -> /dev/block/mmcblk0p9
MD1 -> /dev/block/mmcblk0p8
MSC -> /dev/block/mmcblk0p10
PST -> /dev/block/mmcblk0p11
UDA -> /dev/block/mmcblk0p7
VNR -> /dev/block/mmcblk0p5
recovery -> /dev/block/mmcblk0p3
cat /proc/partitions
Code:
7 0 98304 loop0
254 0 520912 zram0
179 0 61071360 mmcblk0
179 1 32768 mmcblk0p1
179 2 32768 mmcblk0p2
179 3 32768 mmcblk0p3
179 4 3670016 mmcblk0p4
179 5 311296 mmcblk0p5
179 6 409600 mmcblk0p6
179 7 56470528 mmcblk0p7
179 8 65536 mmcblk0p8
179 9 32768 mmcblk0p9
179 10 4096 mmcblk0p10
179 11 512 mmcblk0p11
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 4096 mmcblk0boot0
253 0 56470528 dm-0