Related
This thread is meant for ROM developers and the not the general public. Please don't comment asking questions unless you are a ROM developer planning on implementing this in your ROM.
I've taken the existing init.d framework and taken it to the next level.
Changes made:
Added a global scripts log directory so we can consolidate where we put our log files and help clean the system clean. It's located in /data/scriptlogs
Added logging to each init file which has its own individual logfile
Each init will set the following properties once it has completed. init.name_of_initfile.status & init.name_of_initfile.completed so we have record of its exit status and whether it finished running.
Wrote a shell script named bootstatus that will output a summary of the init scripts exist statuses.
If the phone is not booting or having issues you can verify init completed successfully by using bootstatus. If an init script failed it will tell you the location to the logfile containing a more descriptive log that should help explain why it failed. No more guessing game
Wrote a script to dump the stats from compcache. Previously this was done with rzscontrol, that no longer works on compcache 0.5 and up. The script is named ccstat
Lines to add to init.rc
Code:
start sysinit
on property:init.complete=1
class_start default
service sysinit /system/xbin/busybox run-parts /system/etc/init.d
disabled
oneshot
Output from bootstatus
Code:
# bootstatus
-----------------------------------------
| SCRIPT | STATUS | DETAILS
-----------------------------------------
sysctl PASS
firstboot PASS
a2sd PASS
userinit PASS
compcache PASS
linuxswap PASS
cpu PASS
virtualmem PASS
Properties that got set after init.d finished
Code:
[init.sysctl.complete]: [1]
[init.firstboot.complete]: [1]
[init.a2sd.complete]: [1]
[init.userinit.complete]: [1]
[init.compcache.complete]: [1]
[init.linuxswap.complete]: [1]
[init.complete]: [1]
[init.sysctl.status]: [PASS]
[init.firstboot.status]: [PASS]
[init.a2sd.status]: [PASS]
[init.linuxswap.status]: [PASS]
Output from ccstat
Code:
DiskSize: 32768 kB
NumReads: 245
NumWrites: 2063
FailedReads: 0
FailedWrites: 0
InvalidIO: 0
NotifyFree: 0
ZeroPages: 787
GoodCompress: 70 %
NoCompress: 4 %
PagesStored: 1276
PagesUsed: 457
OrigDataSize: 5104 kB
ComprDataSize: 1783 kB
MemUsedTotal: 1828 kB
Snapshot of the logs directory, /data/scriptlogs
Code:
# ls -l
-rw-rw-rw- root root 71 2010-02-02 20:43 09virtualmem.log
-rw-r--r-- root root 105 2010-02-02 13:48 06compcache.log
-rw-r--r-- root root 64 2010-02-02 20:42 08cpu.log
-rw-r--r-- root root 70 2010-02-02 20:30 07linuxswap.log
-rw-r--r-- root root 67 2010-02-02 13:48 05userinit.log
-rw-r--r-- root root 462 2010-02-02 13:48 04a2sd.log
-rw-r--r-- root root 66 2010-02-02 13:48 03firstboot.log
-rw-r--r-- root root 92 2010-02-02 13:48 01sysctl.log
-rw-r--r-- root root 102 2010-02-02 13:48 init.log
Snippet from a2sd logfile
Code:
04a2sd Starting: 13:48 02/02/2010
Running fsck on ext partition: Done
Mounting /system/sd Done
Clean old symlinks, create data directories:
------------------------
------------------------
Done
Copying /data/dalvik-cache contents to /system/sd/dalvik-cache
Removing /data/dalvik-cache directory
Binding /system/sd/dalvik-cache to /data/dalvik-cache: Done
Removing any .odex files in /system/sd/app: Done
Finished at 13:48 02/02/2010
Ok I finished up my changes and they are attached to this post now.
EDIT
Going to release in King's Eclair ROM and give it a test first. If mods want to delete this thread for now that's fine. I'll recreate later
Ok the files have been attached to the first post. Enjoy.
This should make the init process more stable and easier to debug from a user & developer standpoint.
Holy heck I wish I had found this before!!! You have answered so many questions for me about the new Eclair builds. Between this post and the King Eclair post in your sig you have answered many many ROM building questions I've had for weeks.
One last question -- Do you know if it matters where in init.rc I put start sysinit ?
EDIT: Well, I'm doing something wrong because it gave me init: invalid command 'start'
EDIT2: start sysinit needs to be added as a subcommand of 'on boot', cyanogen has it after setprop net.tcp.buffersize
Thanks again, fellow ROM builder
polyrhythmic said:
Holy heck I wish I had found this before!!! You have answered so many questions for me about the new Eclair builds. Between this post and the King Eclair post in your sig you have answered many many ROM building questions I've had for weeks.
One last question -- Do you know if it matters where in init.rc I put start sysinit ?
Thanks again, fellow ROM builder
Click to expand...
Click to collapse
No problem glad I could help. You can put the start sysinit right before the service definitions. Here is a larger snippit in init.rc so you can see where I placed it
Code:
setprop net.tcp.buffersize.edge 4093,26280,35040,4096,16384,35040
setprop net.tcp.buffersize.gprs 4092,8760,11680,4096,8760,11680
start sysinit
on property:init.complete=1
class_start default
## Daemon processes to be run by init.
##
service console /system/bin/sh
console
I'm seeing it all now... thanks again!
shafty023 said:
EDIT
Going to release in King's Eclair ROM and give it a test first. If mods want to delete this thread for now that's fine. I'll recreate later
Click to expand...
Click to collapse
And where i can find this script ?
Bladyle said:
And where i can find this script ?
Click to expand...
Click to collapse
FEBUARY....................7 months ago............
FEBUARY....................7 months ago............
Click to expand...
Click to collapse
so what
shafty023 said:
Ok the files have been attached to the first post. Enjoy.
This should make the init process more stable and easier to debug from a user & developer standpoint.
Click to expand...
Click to collapse
Ok, I'll admit it, for a lot of things, especially system administration, I prefer the command line.
Is there a reason why I would not use tar to do "full backup" of data (as opposed to TiBackup or the like)?
One advantage is that I can extract a tar on another box and, for example, check it in to a VC system.
Admittedly, busybox tar isn't the most full-featured implementation (no one-file-system option, for example), but I believe it does have an exclude-from-file option that works.
I may be wrong, but I don't think tar on our phones can save ownership and permissions (too lazy to try it out right now). I suppose it wouldn't be too hard to write a script to save any info that tar would not preserve into a properties file and then have a restore script that would read the properties file and chown and chmod every file after extracting.
xviiivx said:
I may be wrong, but I don't think tar on our phones can save ownership and permissions
Click to expand...
Click to collapse
busybox tar appears to work like "any" tar, at least for non-extended attributes (I don't know if the kernel supports xattrs )
Code:
$ tar tvf test.tar | head -n 10
drwxr-xr-x 0/0 0 2011-02-07 20:58 system/etc/
-rw-r--r-- 0/0 15346 2011-02-07 20:58 system/etc/apns-conf.xml
-rw-r--r-- 0/0 25 2011-02-07 20:58 system/etc/hosts
-rw-r--r-- 0/0 99026 2011-02-07 20:58 system/etc/NOTICE.html.gz
-r-xr-x--- 0/2000 1200 2011-02-07 20:58 system/etc/init.goldfish.sh
-rw-r--r-- 0/0 1707 2011-02-07 20:58 system/etc/vold.fstab
-rw-r--r-- 0/0 195 2011-02-07 20:58 system/etc/gps.conf
drwxr-xr-x 0/0 0 2011-02-07 20:58 system/etc/security/
-rw-r--r-- 0/0 91755 2011-02-07 20:58 system/etc/security/cacerts.bks
drwxr-xr-x 0/0 0 2011-02-07 20:58 system/etc/security/drm/
and does appear to preserve links as well
Code:
$ tar tvf test2.tar | head -n 10
lrwxrwxrwx 0/0 0 2011-03-15 12:09 etc -> /system/etc
These were created using busybox tar from /system/etc and of /etc, adb pull-ed, and extracted on another system (Cygwin, in this case).
If you look in the TitaniumBackup directory on the sdcard, each app has 3 files:
appname.apk.gz- I didn't check, but obviously is probably just a backup of the apk
appname.tar.gz (looks like a tar of the /data/data/app dir)
appname.properties- looks like it includes a huge chuck of data for the icon and some misc information, a lot of which appears to be... market information?
I don't know how important the third file is, but it looks like Titanium is using tar. You could download a junk app and try it with that app and see if it works.
Just a guess, but I bet untarring may not be enough, you'll probably have to run the command "pm install" on each apk.
Thanks Fubuya!
That leads me to two useful "conclusions"
tar probably works just fine
TiBackup files are likely extractable on a POSIX box
Yeah, on linux, one is just text and I extracted the other two just fine (tar -zxvf for one and gunzip for the other). It's probably just a matter of finding out if there are any extra tricks you need to know about. Looks like Tibackup has a forum here, if you run into problems maybe they'd be nice enough to translate what's happening on the backend of their backup process.
I modified the new stock kernel with the ramdisk features from CleanROM:
- insecure adbd
- init.d support
Flashable ZIP:
View attachment kernel-10.4.4.25-insecure.zip
Update 2013-01-21: Here is a version that does not set lcd_density, so that custom dpi set in /system/build.prop work. Verified to work with CROMI 3.2.
View attachment kernel-10.4.4.25-insecure-nodpi.zip
Working fine here with a mix of CleanROM 2.3, custom mods and some cherry-picked changes from CROMI. This kernel should be compatible with any stock ROM since 10.4.4.18 or CleanROM/Inheritance since 2.3.
My MicroSD card (Sandisk Mobile Ultra UHS-1) seems to work more stable now - will try All2SD tomorrow.
For the tutorial how to unpack and repack a kernel, see post #4.
Update 2013-01-21: Updated with info how to unlock DPI.
_that said:
I modified the new stock kernel with the ramdisk features from CleanROM:
- insecure adbd
- init.d support
Flashable ZIP:
View attachment 1657033
Working fine here with a mix of CleanROM 2.3, custom mods and some cherry-picked changes from CROMI. This kernel should be compatible with any stock ROM since 10.4.4.18 or CleanROM/Inheritance since 2.3.
My MicroSD card (Sandisk Mobile Ultra UHS-1) seems to work more stable now - will try All2SD tomorrow.
Click to expand...
Click to collapse
Nice work!!:good:
_that said:
I modified the new stock kernel with the ramdisk features from CleanROM:
- insecure adbd
- init.d support
Flashable ZIP:
View attachment 1657033
Working fine here with a mix of CleanROM 2.3, custom mods and some cherry-picked changes from CROMI. This kernel should be compatible with any stock ROM since 10.4.4.18 or CleanROM/Inheritance since 2.3.
My MicroSD card (Sandisk Mobile Ultra UHS-1) seems to work more stable now - will try All2SD tomorrow.
Click to expand...
Click to collapse
Many thanks - I've been struggling with linux to unpack the blob.LNX file. Blob tools isn't working for me for some reason as ./blobunpack blob.LNX says unrecognised blob format.
What is the secret to get it working?
sbdags said:
Many thanks - I've been struggling with linux to unpack the blob.LNX file. Blob tools isn't working for me for some reason as ./blobunpack blob.LNX says unrecognised blob format.
What is the secret to get it working?
Click to expand...
Click to collapse
I firmly believe that this should not be a secret, so I'll explain in detail how to do it and not only give you steps but also a lot of background info. Many steps in the following tutorial are optional and useful for learning, for checking things and for troubleshooting - I don't want you to blindly follow a recipe without understanding what you are doing.
Unpacking the blob
We start with the full firmware, unpacked once - in this case, WW_epad-user-10.4.4.25.zip. First extract the blob from the zip:
Code:
[email protected] ~/android/tf700/kernel $ unzip WW_epad-user-10.4.4.25.zip blob
Archive: WW_epad-user-10.4.4.25.zip
signed by SignApk
inflating: blob
This is a signed blob. It begins with "-SIGNED-BY-SIGNBLOB-". You can check this with hexdump (this step is completely optional, just for illustration):
Code:
[email protected] ~/android/tf700/kernel $ hexdump -C -n 48 blob
00000000 2d 53 49 47 4e 45 44 2d 42 59 2d 53 49 47 4e 42 |-SIGNED-BY-SIGNB|
00000010 4c 4f 42 2d e9 1a d7 30 00 01 00 00 4d 53 4d 2d |LOB-...0....MSM-|
00000020 52 41 44 49 4f 2d 55 50 44 41 54 45 00 00 01 00 |RADIO-UPDATE....|
00000030
Also note the MSM-RADIO-UPDATE after the signature header - it is the start of an unsigned blob.
But what exactly is a blob? In database terminology, it stands for "binary large object" - a bunch of data that is just stored with no further interpretation by the database.The blobs for flashing NVIDIA Tegra devices have a specific structure - they contain one or more raw images to be flashed to one or more partitions on the device.
The full firmware blob for the TF700 contains images for 5 partitions, which we will now extract from the blob. If you don't have blobunpack, get the sources from https://github.com/AndroidRoot/BlobTools - how to do that and how to compile them may be part of another tutorial. I also assume you have blobunpack somewhere in your $PATH.
Code:
[email protected] ~/android/tf700/kernel $ blobunpack blob
Header size: 60
5 partitions starting at offset 0x3C
Blob version: 65536
Partition 0
Name: PT
Offset: 140 (0x8C)
Size: 524288 (0x80000)
Writing file blob.PT (524288 bytes)
Partition 1
Name: EBT
Offset: 524428 (0x8008C)
Size: 1566813 (0x17E85D)
Writing file blob.EBT (1566813 bytes)
Partition 2
Name: SOS
Offset: 2091241 (0x1FE8E9)
Size: 6410496 (0x61D100)
Writing file blob.SOS (6410496 bytes)
Partition 3
Name: LNX
Offset: 8501737 (0x81B9E9)
Size: 5595392 (0x556100)
Writing file blob.LNX (5595392 bytes)
Partition 4
Name: APP
Offset: 14097129 (0xD71AE9)
Size: 805306368 (0x30000000)
Writing file blob.APP (805306368 bytes)
OK, now we have separate files for each partition. The next step is again optional, just to illustrate what happened:
Code:
[email protected] ~/android/tf700/kernel $ ls -l
total 2059512
-rw-rw-r-- 1 that users 468028852 28. Dez 12:33 WW_epad-user-10.4.4.25.zip
-rw-r--r-- 1 that users 819403781 22. Mär 2011 blob
-rw-r--r-- 1 that users 805306368 19. Jän 19:39 blob.APP
-rw-r--r-- 1 that users 1566813 19. Jän 19:39 blob.EBT
-rw-r--r-- 1 that users 5595392 19. Jän 19:39 blob.LNX
-rw-r--r-- 1 that users 524288 19. Jän 19:39 blob.PT
-rw-r--r-- 1 that users 6410496 19. Jän 19:39 blob.SOS
What's inside a firmware blob
blob.APP is a raw image of a Linux ext4 partition. If you are interested in the contents, you can loop mount this file and access all files inside directly on your Linux computer. This is the filesystem that is mounted as /system - the ROM as you all know it.
blob.EBT is the bootloader.
blob.LNX is the boot image - the Linux kernel and the ramdisk, which is later seen as "/". This is the one we are after.
blob.PT is the Tegra partition table. This is a proprietary format, not a PC-compatible partition table.
blob.SOS is the recovery boot image - another Linux kernel and another ramdisk, but this ramdisk contains the stock recovery (incl. the dreaded "dead android").
The boot image
Now, what's actually a boot image, and how do we recognize one if we see one? As usual, the best answer is: look inside! (again - optional, just to learn something)
Code:
[email protected] ~/android/tf700/kernel $ hexdump -C -n 16 blob.LNX
00000000 41 4e 44 52 4f 49 44 21 58 0c 4e 00 00 80 00 10 |ANDROID!X.N.....|
00000010
An Android boot image begins with the text "ANDROID!". Easy.
(maybe sbdags now starts to smack his head and realizes why blobunpack does not work here - and if anyone is still in doubt - a boot image is not a blob)
Splitting a boot image
Good, but how do we crack this thing open? Fortunately there are two small perl scripts I extracted from dsixda's Android kitchen (they are in tools/extract_boot_files):
Code:
[email protected] ~/android/tf700/kernel $ extract-kernel.pl blob.LNX
[email protected] ~/android/tf700/kernel $ extract-ramdisk.pl blob.LNX
1932 blocks
OK, what happened?
Code:
[email protected] ~/android/tf700/kernel $ ls -l
total 2064524
-rw-rw-r-- 1 that users 468028852 28. Dez 12:33 WW_epad-user-10.4.4.25.zip
-rw-r--r-- 1 that users 819403781 22. Mär 2011 blob
-rw-r--r-- 1 that users 805306368 19. Jän 19:39 blob.APP
-rw-r--r-- 1 that users 1566813 19. Jän 19:39 blob.EBT
-rw-r--r-- 1 that users 5595392 19. Jän 19:39 blob.LNX
drwxr-xr-x 8 that users 4096 19. Jän 19:59 blob.LNX-ramdisk
-rw-r--r-- 1 that users 524288 19. Jän 19:39 blob.PT
-rw-r--r-- 1 that users 6410496 19. Jän 19:39 blob.SOS
-rw-r--r-- 1 that users 5114968 19. Jän 19:58 zImage
We got a new file (zImage) and a directory (blob.LNX-ramdisk)!
zImage is the kernel image. It is the result of compiling a kernel from sources. Today, we will not compile a new kernel, just repack this image with our modified ramdisk.
What blob.LNX-ramdisk contains should be obvious.
Modifying the ramdisk
Now we can start modifying the ramdisk. A CleanROM ramdisk differs from a stock ramdisk in only 3 files:
- sbin/adbd
- default.prop
- init.rc
sbin/adbd is the adb daemon - the program that handles the tablet's side of the adb protocol. The stock version runs under the "shell" user account, which has limited permissions and cannot access all files on the tablet. The CleanROM version of adbd runs as "root", so "adb push" and "adb pull" can write or read any file on the device, and "adb shell" goes directly to a root prompt.
I don't know where scrosler got this binary from, I just copied it from his CleanROM kernel's ramdisk. You can do the same - now you already know how to extract a ramdisk, so just do the same with the CleanROM kernel in another directory.
default.prop contains only a few lines. Here is the already modified CleanROM version:
Code:
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=1
persist.sys.usb.config=mtp,adb
In the original file, ro.secure=1 (which would limit adb to the "shell" account again), ro.debuggable=0 (I'd have to look up what exactly this does), and persist.sys.usb.config=mtp without adb (I think this modification is what automatically enables "USB debugging" at boot time).
Finally, init.rc has a few additional lines to enable init.d support. This means the boot sequence will run any scripts in /etc/init.d - this a simplified version of a usual convention for desktop Linux systems. CleanROM uses it to set up various tweaks (look into /system/etc/init.d on your device).
To illustrate the changes in init.rc, I use the "diff" command (and you can too, if you want - just use the correct paths for your setup instead of mine):
Code:
[email protected] ~/android/tf700/kernel $ diff -u blob.LNX-ramdisk/init.rc ~/android/tf700/cleanrom/blob.LNX-ramdisk/init.rc
--- blob.LNX-ramdisk/init.rc 2013-01-19 19:59:03.000000000 +0100
+++ /home/that/android/tf700/cleanrom/blob.LNX-ramdisk/init.rc 2013-01-19 01:24:43.000000000 +0100
@@ -309,6 +309,8 @@
# Set this property so surfaceflinger is not started by system_init
setprop system_init.startsurfaceflinger 0
+ start sysinit
+
class_start core
class_start main
@@ -413,6 +415,10 @@
user drm
group drm system inet drmrpc sdcard_r
+service sysinit /system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/init.d
+ disabled
+ oneshot
+
service media /system/bin/mediaserver
class main
user media
If you have never read a diff before (also called a patch), here a quick guide:
- Lines beginning with "---" and "+++" identify the two files that were compared.
- Lines beginning with "@@" specify line numbers in the two files. -309,6 +309,8 means: The next block contains 6 lines starting with line 309 from file 1 (---), and 8 lines starting with line 309 in file 2 (+++). In other words, this means that two lines were inserted there.
- The following lines start with a blank - they are context lines. These lines are common in both files and only used to see some context around the change.
- Lines beginning with "+" exist only in file 2 (+++). You can easily remember all this if you know that a diff describes how to edit file 1 to be identical to file 2 - you delete lines marked with "-" and insert lines marked with "+". With only these two operations, you can transform any text file to any other - in the worst case you will delete all lines of the original file and insert all lines of the new file.
The second block works like the first one - here we insert 4 lines near line 413 (which has become line 415 after our first insertion).
You have the following options to apply this change:
1. Simply copy over the changed version from the previous CleanROM kernel. Do a diff before to verify that Asus didn't change anything, otherwise you will undo Asus' changes.
2. Use the "patch" tool to apply the diff file from above. This will automatically perform the edit steps in the diff file and it also has some tolerance if something changed in other sections of the file.
3. Use a text editor and perform the changes manually. If you copy lines from the diff (and not the original init.rc), make sure you don't accidentally copy the leading "+" - this is only for the diff and should not part of the file.
Update 2013-01-21 Start
Unlocking DPI
As usual I don't just tell you how to do it, but some background info first:
There is a read-only system property in Android named "lcd_density" that specifies the display resolution. This is done to ensure that the approximate size of display items is kept consistent across the wide range of devices Android runs on.
For normal users this is great, because they don't have to buy a magnifying glass and a pointed stylus just to use their super-hires-devices, but users here on xda-developers of course see a setting that can be modified and therefore it *must* be modified. Smaller values produce smaller icons and text (and thus more visible content at once); bigger values produce bigger icons and text.
The ASUS stock firmware is not only used on the TF700, but also for several other Transformers. The file /system/build.prop sets ro.sf.lcd_density=160, which means 160 dpi. This is good for the majority of tablets that have 1280*800 displays, but the TF700's display has a resolution of 224 pixels per inch, and with a setting of 160 dpi everything would be very tiny.
The bootloader passes an important parameter to the kernel: "androidboot.productid=0x04", This value depends on the Transformer model, and it is 4 for the TF700. If you look into the ramdisk, there are several files named init.00.rc to init.0d.rc. These are device-specific, and you guessed right if you think that init.04.rc is for the TF700. This file sets lcd_density to 240 dpi, and since it is a read-only property, it keeps its value even if the system's build.prop (which is read later) tries to set lcd_density to 160.
So how do we unlock dpi? Delete the line that says "setprop ro.sf.lcd_density 240" in init.04.rc! Of course this requires you to set the desired dpi value in /system/build.prop. If you install CleanROM Inheritance, you can choose this value in the installer. If you run this kernel with the stock ROM, everything will become very tiny, and now you know why.
Update 2013-01-21 End
Re-packing the boot image
OK, phew, we finally have a modified ramdisk - now we need to repack everything, basically the reverse of the first few steps. For this I use a self-written shell script. First let's just run it:
Code:
[email protected] ~/android/tf700/kernel $ repack-kernel.sh
Found 1 partitions as commandline arguments
Partname: LNX Filename: blob.LNX
Size: 60
1 partitions starting at offset 0x3C
Offset: 76
8+0 records in
8+0 records out
8 bytes (8 B) copied, 0,000136275 s, 58,7 kB/
OK, what happened here? Since I wrote this script myself, I can explain it line by line:
Code:
[email protected] ~/android/tf700/kernel $ cat ~/bin/repack-kernel.sh
#!/bin/bash
~/android/Android-Kitchen/tools/mkboot/mkbootfs blob.LNX-ramdisk | gzip > ramdisk.gz
~/android/Android-Kitchen/tools/mkboot/mkbootimg --kernel zImage --ramdisk ramdisk.gz -o blob.LNX
blobpack blobtmp LNX blob.LNX
echo -n "-SIGNED-BY-SIGNBLOB-" > blob
dd if=/dev/zero bs=1 count=8 >> blob
cat blobtmp >> blob
The ramdisk is repacked and zipped again. This creates ramdisk.gz.
The kernel is merged with the ramdisk to a new boot image, to create blob.LNX. If you paid attention before, yes, this will overwrite the old blob.LNX. If you want, you can check again with hexdump that it is really a boot image (it begins with "ANDROID!").
Re-packing a blob
Now we pack the boot image into a blob. However, the "original" version of blobtools does not create a signed blob. See:
Code:
[email protected] ~/android/tf700/kernel $ hexdump -C -n 16 blobtmp
00000000 4d 53 4d 2d 52 41 44 49 4f 2d 55 50 44 41 54 45 |MSM-RADIO-UPDATE|
00000010
That was the blob format for the TF101. For later Transformers, we need to prepend a signature header. As we don't have Asus' cryptographic keys, we cannot create a valid signature - but fortunately, since we have an unlocked bootloader, we don't actually need to add a proper signature - the header is enough. There are two ways to create this header - there is a modified version of blobtools in circulation that has a command line option for it, but I do it "manually" with echo and dd.
The final output is again simply called "blob" - this is the new blob that now contains only the kernel. (It overwrites the original blob, which is not really intended, but I just didn't care).
For comparison, now we have this:
Code:
[email protected] ~/android/tf700/kernel $ ls -l
total 1274980
-rw-rw-r-- 1 that users 468028852 28. Dez 12:33 WW_epad-user-10.4.4.25.zip
-rw-r--r-- 1 that users 5599336 19. Jän 20:35 blob
-rw-r--r-- 1 that users 805306368 19. Jän 19:39 blob.APP
-rw-r--r-- 1 that users 1566813 19. Jän 19:39 blob.EBT
-rw-r--r-- 1 that users 5599232 19. Jän 20:35 blob.LNX
drwxr-xr-x 8 that users 4096 19. Jän 19:59 blob.LNX-ramdisk
-rw-r--r-- 1 that users 524288 19. Jän 19:39 blob.PT
-rw-r--r-- 1 that users 6410496 19. Jän 19:39 blob.SOS
-rw-r--r-- 1 that users 5599308 19. Jän 20:35 blobtmp
-rw-r--r-- 1 that users 479752 19. Jän 20:35 ramdisk.gz
-rw-r--r-- 1 that users 5114968 19. Jän 19:58 zImage
Congratulations, you have a flashable blob with your new kernel. But how do you get it onto your device?
Installation
Again, there are two ways:
Installing the blob directly with dd
The first option is to copy the blob to your tablet's staging partition manually and reboot:
Code:
[email protected] ~/android/tf700/kernel $ adb push blob /sdcard/kernel-10.4.4.25.blob
1324 KB/s (5599336 bytes in 4.128s)
[email protected] ~/android/tf700/kernel $ adb shell
sh-3.2# dd if=/sdcard/kernel-10.4.4.25.blob of=/dev/block/mmcblk0p4
10936+1 records in
10936+1 records out
5599336 bytes transferred in 0.129 secs (43405705 bytes/sec)
Be very careful with the dd command and double-check that you didn't swap "if" and "of", and that you specified the correct target partition *before* you hit Enter.
Now reboot your tablet, and the bootloader will flash your new kernel from the blob to the actual kernel partition (notice the progress bar on the boot screen with the slightly broken graphics, as usual). The tablet will reboot again automatically, and if you did everything right, your shiny new kernel will be running!
Creating a zip for flashing in the recovery
OK, now to option 2 - pack the blob into a flashable zip that you can flash in the recovery. The easiest way to do this is to reuse the original firmware zip. Just replace the blob inside the big firmware zip, and that's it - you have a recovery-flashable zip!
Code:
[email protected] ~/android/tf700/kernel $ mv WW_epad-user-10.4.4.25.zip kernel-10.4.4.25.zip
[email protected] ~/android/tf700/kernel $ zip -d kernel-10.4.4.25.zip blob
deleting: blob
[email protected] ~/android/tf700/kernel $ zip kernel-10.4.4.25.zip blob
adding: blob (deflated 1%)
This would not be a good tutorial if I didn't explain how and why this actually works. Let's look inside!
Code:
[email protected] ~/android/tf700/kernel $ unzip kernel-10.4.4.25.zip META-INF/*
Archive: kernel-10.4.4.25.zip
signed by SignApk
inflating: META-INF/com/google/android/resource
inflating: META-INF/com/google/android/rule
inflating: META-INF/com/google/android/update-binary
inflating: META-INF/com/google/android/updater-script
inflating: META-INF/com/android/otacert
inflating: META-INF/MANIFEST.MF
inflating: META-INF/CERT.SF
inflating: META-INF/CERT.RSA
The core of a flashable zip is the updater-script. For a full firmware, it is very short:
Code:
[email protected] ~/android/tf700/kernel $ cat META-INF/com/google/android/updater-script
assert(package_extract_file("blob", "/tmp/blob"), write_raw_image("/tmp/blob", "staging"),delete("/tmp/blob"));
This line instructs the recovery to extract the blob from the zip file to /tmp/blob and then copy it to the staging partition - essentially it is exactly the same as we did manually in option #1 above!
OK, now the secret is fully disclosed - I hope you learned something. If you have further questions, or if you need help compiling some of the mentioned binaries, don't hesitate to ask (if it's not something like "how do I use the Linux command line" ).
uh huh, uh huh, What?
I think I need to go to blob school....:silly:
_that said:
I firmly believe that this should not be a secret, so I'll explain in detail how to do it and not only give you steps but also a lot of background info. Many steps in the following tutorial are optional and useful for learning, for checking things and for troubleshooting - I don't want you to blindly follow a recipe without understanding what you are doing.
We start with the full firmware, unpacked once - in this case, WW_epad-user-10.4.4.25.zip. First extract the blob from the zip:
Code:
[email protected] ~/android/tf700/kernel $ unzip WW_epad-user-10.4.4.25.zip blob
Archive: WW_epad-user-10.4.4.25.zip
signed by SignApk
inflating: blob
This is a signed blob. It begins with "-SIGNED-BY-SIGNBLOB-". You can check this with hexdump (this step is completely optional, just for illustration):
Code:
[email protected] ~/android/tf700/kernel $ hexdump -C -n 48 blob
00000000 2d 53 49 47 4e 45 44 2d 42 59 2d 53 49 47 4e 42 |-SIGNED-BY-SIGNB|
00000010 4c 4f 42 2d e9 1a d7 30 00 01 00 00 4d 53 4d 2d |LOB-...0....MSM-|
00000020 52 41 44 49 4f 2d 55 50 44 41 54 45 00 00 01 00 |RADIO-UPDATE....|
00000030
Also note the MSM-RADIO-UPDATE after the signature header - it is the start of an unsigned blob.
But what exactly is a blob? In database terminology, it stands for "binary large object" - a bunch of data that is just stored with no further interpretation by the database.The blobs for flashing NVIDIA Tegra devices have a specific structure - they contain one or more raw images to be flashed to one or more partitions on the device.
The full firmware blob for the TF700 contains images for 5 partitions, which we will now extract from the blob. If you don't have blobunpack, get the sources from https://github.com/AndroidRoot/BlobTools - how to do that and how to compile them may be part of another tutorial. I also assume you have blobunpack somewhere in your $PATH.
Code:
[email protected] ~/android/tf700/kernel $ blobunpack blob
Header size: 60
5 partitions starting at offset 0x3C
Blob version: 65536
Partition 0
Name: PT
Offset: 140 (0x8C)
Size: 524288 (0x80000)
Writing file blob.PT (524288 bytes)
Partition 1
Name: EBT
Offset: 524428 (0x8008C)
Size: 1566813 (0x17E85D)
Writing file blob.EBT (1566813 bytes)
Partition 2
Name: SOS
Offset: 2091241 (0x1FE8E9)
Size: 6410496 (0x61D100)
Writing file blob.SOS (6410496 bytes)
Partition 3
Name: LNX
Offset: 8501737 (0x81B9E9)
Size: 5595392 (0x556100)
Writing file blob.LNX (5595392 bytes)
Partition 4
Name: APP
Offset: 14097129 (0xD71AE9)
Size: 805306368 (0x30000000)
Writing file blob.APP (805306368 bytes)
OK, now we have separate files for each partition. The next step is again optional, just to illustrate what happened:
Code:
[email protected] ~/android/tf700/kernel $ ls -l
total 2059512
-rw-rw-r-- 1 that users 468028852 28. Dez 12:33 WW_epad-user-10.4.4.25.zip
-rw-r--r-- 1 that users 819403781 22. Mär 2011 blob
-rw-r--r-- 1 that users 805306368 19. Jän 19:39 blob.APP
-rw-r--r-- 1 that users 1566813 19. Jän 19:39 blob.EBT
-rw-r--r-- 1 that users 5595392 19. Jän 19:39 blob.LNX
-rw-r--r-- 1 that users 524288 19. Jän 19:39 blob.PT
-rw-r--r-- 1 that users 6410496 19. Jän 19:39 blob.SOS
blob.APP is a raw image of a Linux ext4 partition. If you are interested in the contents, you can loop mount this file and access all files inside directly on your Linux computer. This is the filesystem that is mounted as /system - the ROM as you all know it.
blob.EBT is the bootloader.
blob.LNX is the boot image - the Linux kernel and the ramdisk, which is later seen as "/". This is the one we are after.
blob.PT is the Tegra partition table. This is a proprietary format, not a PC-compatible partition table.
blob.SOS is the recovery boot image - another Linux kernel and another ramdisk, but this ramdisk contains the stock recovery (incl. the dreaded "dead android").
Now, what's actually a boot image, and how do we recognize one if we see one? As usual, the best answer is: look inside! (again - optional, just to learn something)
Code:
[email protected] ~/android/tf700/kernel $ hexdump -C -n 16 blob.LNX
00000000 41 4e 44 52 4f 49 44 21 58 0c 4e 00 00 80 00 10 |ANDROID!X.N.....|
00000010
An Android boot image begins with the text "ANDROID!". Easy.
(maybe sbdags now starts to smack his head and realizes why blobunpack does not work here - and if anyone is still in doubt - a boot image is not a blob)
Good, but how do we crack this thing open? Fortunately there are two small perl scripts I extracted from dsixda's Android kitchen (they are in tools/extract_boot_files):
Code:
[email protected] ~/android/tf700/kernel $ extract-kernel.pl blob.LNX
[email protected] ~/android/tf700/kernel $ extract-ramdisk.pl blob.LNX
1932 blocks
OK, what happened?
Code:
[email protected] ~/android/tf700/kernel $ ls -l
total 2064524
-rw-rw-r-- 1 that users 468028852 28. Dez 12:33 WW_epad-user-10.4.4.25.zip
-rw-r--r-- 1 that users 819403781 22. Mär 2011 blob
-rw-r--r-- 1 that users 805306368 19. Jän 19:39 blob.APP
-rw-r--r-- 1 that users 1566813 19. Jän 19:39 blob.EBT
-rw-r--r-- 1 that users 5595392 19. Jän 19:39 blob.LNX
drwxr-xr-x 8 that users 4096 19. Jän 19:59 blob.LNX-ramdisk
-rw-r--r-- 1 that users 524288 19. Jän 19:39 blob.PT
-rw-r--r-- 1 that users 6410496 19. Jän 19:39 blob.SOS
-rw-r--r-- 1 that users 5114968 19. Jän 19:58 zImage
We got a new file (zImage) and a directory (blob.LNX-ramdisk)!
zImage is the kernel image. It is the result of compiling a kernel from sources. Today, we will not compile a new kernel, just repack this image with our modified ramdisk.
What blob.LNX-ramdisk contains should be obvious.
Now we can start modifying the ramdisk. A CleanROM ramdisk differs from a stock ramdisk in only 3 files:
- sbin/adbd
- default.prop
- init.rc
sbin/adbd is the adb daemon - the program that handles the tablet's side of the adb protocol. The stock version runs under the "shell" user account, which has limited permissions and cannot access all files on the tablet. The CleanROM version of adbd runs as "root", so "adb push" and "adb pull" can write or read any file on the device, and "adb shell" goes directly to a root prompt.
I don't know where scrosler got this binary from, I just copied it from his CleanROM kernel's ramdisk. You can do the same - now you already know how to extract a ramdisk, so just do the same with the CleanROM kernel in another directory.
default.prop contains only a few lines. Here is the already modified CleanROM version:
Code:
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=1
persist.sys.usb.config=mtp,adb
In the original file, ro.secure=1 (which would limit adb to the "shell" account again), ro.debuggable=0 (I'd have to look up what exactly this does), and persist.sys.usb.config=mtp without adb (I think this modification is what automatically enables "USB debugging" at boot time).
Finally, init.rc has a few additional lines to enable init.d support. This means the boot sequence will run any scripts in /etc/init.d - this a simplified version of a usual convention for desktop Linux systems. CleanROM uses it to set up various tweaks (look into /system/etc/init.d on your device).
To illustrate the changes in init.rc, I use the "diff" command (and you can too, if you want - just use the correct paths for your setup instead of mine):
Code:
[email protected] ~/android/tf700/kernel $ diff -u blob.LNX-ramdisk/init.rc ~/android/tf700/cleanrom/blob.LNX-ramdisk/init.rc
--- blob.LNX-ramdisk/init.rc 2013-01-19 19:59:03.000000000 +0100
+++ /home/that/android/tf700/cleanrom/blob.LNX-ramdisk/init.rc 2013-01-19 01:24:43.000000000 +0100
@@ -309,6 +309,8 @@
# Set this property so surfaceflinger is not started by system_init
setprop system_init.startsurfaceflinger 0
+ start sysinit
+
class_start core
class_start main
@@ -413,6 +415,10 @@
user drm
group drm system inet drmrpc sdcard_r
+service sysinit /system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/init.d
+ disabled
+ oneshot
+
service media /system/bin/mediaserver
class main
user media
If you have never read a diff before (also called a patch), here a quick guide:
- Lines beginning with "---" and "+++" identify the two files that were compared.
- Lines beginning with "@@" specify line numbers in the two files. -309,6 +309,8 means: The next block contains 6 lines starting with line 309 from file 1 (---), and 8 lines starting with line 309 in file 2 (+++). In other words, this means that two lines were inserted there.
- The following lines start with a blank - they are context lines. These lines are common in both files and only used to see some context around the change.
- Lines beginning with "+" exist only in file 2 (+++). You can easily remember all this if you know that a diff describes how to edit file 1 to be identical to file 2 - you delete lines marked with "-" and insert lines marked with "+". With only these two operations, you can transform any text file to any other - in the worst case you will delete all lines of the original file and insert all lines of the new file.
The second block works like the first one - here we insert 4 lines near line 413 (which has become line 415 after our first insertion).
You have the following options to apply this change:
1. Simply copy over the changed version from the previous CleanROM kernel. Do a diff before to verify that Asus didn't change anything, otherwise you will undo Asus' changes.
2. Use the "patch" tool to apply the diff file from above. This will automatically perform the edit steps in the diff file and it also has some tolerance if something changed in other sections of the file.
3. Use a text editor and perform the changes manually. If you copy lines from the diff (and not the original init.rc), make sure you don't accidentally copy the leading "+" - this is only for the diff and should not part of the file.
OK, phew, we finally have a modified ramdisk - now we need to repack everything, basically the reverse of the first few steps. For this I use a self-written shell script. First let's just run it:
Code:
[email protected] ~/android/tf700/kernel $ repack-kernel.sh
Found 1 partitions as commandline arguments
Partname: LNX Filename: blob.LNX
Size: 60
1 partitions starting at offset 0x3C
Offset: 76
8+0 records in
8+0 records out
8 bytes (8 B) copied, 0,000136275 s, 58,7 kB/
OK, what happened here? Since I wrote this script myself, I can explain it line by line:
Code:
[email protected] ~/android/tf700/kernel $ cat ~/bin/repack-kernel.sh
#!/bin/bash
~/android/Android-Kitchen/tools/mkboot/mkbootfs blob.LNX-ramdisk | gzip > ramdisk.gz
~/android/Android-Kitchen/tools/mkboot/mkbootimg --kernel zImage --ramdisk ramdisk.gz -o blob.LNX
blobpack blobtmp LNX blob.LNX
echo -n "-SIGNED-BY-SIGNBLOB-" > blob
dd if=/dev/zero bs=1 count=8 >> blob
cat blobtmp >> blob
The ramdisk is repacked and zipped again. This creates ramdisk.gz.
The kernel is merged with the ramdisk to a new boot image, to create blob.LNX. If you paid attention before, yes, this will overwrite the old blob.LNX. If you want, you can check again with hexdump that it is really a boot image (it begins with "ANDROID!").
Now we pack the boot image into a blob. However, the "original" version of blobtools does not create a signed blob. See:
Code:
[email protected] ~/android/tf700/kernel $ hexdump -C -n 16 blobtmp
00000000 4d 53 4d 2d 52 41 44 49 4f 2d 55 50 44 41 54 45 |MSM-RADIO-UPDATE|
00000010
That was the blob format for the TF101. For later Transformers, we need to prepend a signature header. As we don't have Asus' cryptographic keys, we cannot create a valid signature - but fortunately, since we have an unlocked bootloader, we don't actually need to add a proper signature - the header is enough. There are two ways to create this header - there is a modified version of blobtools in circulation that has a command line option for it, but I do it "manually" with echo and dd.
The final output is again simply called "blob" - this is the new blob that now contains only the kernel. (It overwrites the original blob, which is not really intended, but I just didn't care).
For comparison, now we have this:
Code:
[email protected] ~/android/tf700/kernel $ ls -l
total 1274980
-rw-rw-r-- 1 that users 468028852 28. Dez 12:33 WW_epad-user-10.4.4.25.zip
-rw-r--r-- 1 that users 5599336 19. Jän 20:35 blob
-rw-r--r-- 1 that users 805306368 19. Jän 19:39 blob.APP
-rw-r--r-- 1 that users 1566813 19. Jän 19:39 blob.EBT
-rw-r--r-- 1 that users 5599232 19. Jän 20:35 blob.LNX
drwxr-xr-x 8 that users 4096 19. Jän 19:59 blob.LNX-ramdisk
-rw-r--r-- 1 that users 524288 19. Jän 19:39 blob.PT
-rw-r--r-- 1 that users 6410496 19. Jän 19:39 blob.SOS
-rw-r--r-- 1 that users 5599308 19. Jän 20:35 blobtmp
-rw-r--r-- 1 that users 479752 19. Jän 20:35 ramdisk.gz
-rw-r--r-- 1 that users 5114968 19. Jän 19:58 zImage
Congratulations, you have a flashable blob with your new kernel. But how do you get it onto your device?
Again, there are two ways:
The first option is to copy the blob to your tablet's staging partition manually and reboot:
Code:
[email protected] ~/android/tf700/kernel $ adb push blob /sdcard/kernel-10.4.4.25.blob
1324 KB/s (5599336 bytes in 4.128s)
[email protected] ~/android/tf700/kernel $ adb shell
sh-3.2# dd if=/sdcard/kernel-10.4.4.25.blob of=/dev/block/mmcblk0p4
10936+1 records in
10936+1 records out
5599336 bytes transferred in 0.129 secs (43405705 bytes/sec)
Be very careful with the dd command and double-check that you didn't swap "if" and "of", and that you specified the correct target partition *before* you hit Enter.
Now reboot your tablet, and the bootloader will flash your new kernel from the blob to the actual kernel partition (notice the progress bar on the boot screen with the slightly broken graphics, as usual). The tablet will reboot again automatically, and if you did everything right, your shiny new kernel will be running!
OK, now to option 2 - pack the blob into a flashable zip that you can flash in the recovery. The easiest way to do this is to reuse the original firmware zip. Just replace the blob inside the big firmware zip, and that's it - you have a recovery-flashable zip!
Code:
[email protected] ~/android/tf700/kernel $ mv WW_epad-user-10.4.4.25.zip kernel-10.4.4.25.zip
[email protected] ~/android/tf700/kernel $ zip -d kernel-10.4.4.25.zip blob
deleting: blob
[email protected] ~/android/tf700/kernel $ zip kernel-10.4.4.25.zip blob
adding: blob (deflated 1%)
This would not be a good tutorial if I didn't explain how and why this actually works. Let's look inside!
Code:
[email protected] ~/android/tf700/kernel $ unzip kernel-10.4.4.25.zip META-INF/*
Archive: kernel-10.4.4.25.zip
signed by SignApk
inflating: META-INF/com/google/android/resource
inflating: META-INF/com/google/android/rule
inflating: META-INF/com/google/android/update-binary
inflating: META-INF/com/google/android/updater-script
inflating: META-INF/com/android/otacert
inflating: META-INF/MANIFEST.MF
inflating: META-INF/CERT.SF
inflating: META-INF/CERT.RSA
The core of a flashable zip is the updater-script. For a full firmware, it is very short:
Code:
[email protected] ~/android/tf700/kernel $ cat META-INF/com/google/android/updater-script
assert(package_extract_file("blob", "/tmp/blob"), write_raw_image("/tmp/blob", "staging"),delete("/tmp/blob"));
This line instructs the recovery to extract the blob from the zip file to /tmp/blob and then copy it to the staging partition - essentially it is exactly the same as we did manually in option #1 above!
OK, now the secret is fully disclosed - I hope you learned something. If you have further questions, or if you need help compiling some of the mentioned binaries, don't hesitate to ask (if it's not something like "how do I use the Linux command line" ).
Click to expand...
Click to collapse
Wow! Many thanks! :victory:
Will digest this tomorrow but yes I recognised my smack head moment! :laugh:
Hmmm, my extreme pro 16gb seems to work fine with this kernel. Using/testing it as an external storage, formatted as fat32. Before it wasen't even recognized when inserted. In recovery (twrp) the card is still not recognized but in android (cleanrom 3.1) it works fine.
New kernel from _that so bad,this kernel dont have OC and voltage control,DPI and most important for me balance power mode 1600...performance power mode do nothing.
But i still want asus changes from new kernel.I hope someone create normal kernel like was Clemsyn's kernel or may be _that do this?
But still thanks for your work and sorry if it's all sounds not very good...
Blue cat said:
New kernel from _that so bad,this kernel dont have OC and voltage control,DPI and most important for me balance power mode 1600...performance power mode do nothing.
But i still want asus changes from new kernel.I hope someone create normal kernel like was Clemsyn's kernel or may be _that do this?
Click to expand...
Click to collapse
That's a bit harsh don't you think.
sbdags said:
That's a bit harsh don't you think.
Click to expand...
Click to collapse
Yes,sorry if it's sounds harsh,forgot add in my post gratitude for his work,cant edit next 5 min.I just very want OC and new kernel.
Blue cat said:
Yes,sorry if it's sounds harsh,forgot add in my post gratitude for his work,cant edit next 5 min.I just very want OC and new kernel.
Click to expand...
Click to collapse
_that has only worked on the Asus Stock kernel, for which I am extremely grateful. It gives those users who don't want to OC anything the ability to have a custom rom on the new kernel. From my testing it works better than the old kernel and is very stable.
I will be looking at the Clemsyn kernels in the mean time to see if I can bring them onto the new kernel base and the benefits they bring.
Please be patient, these are not 5 minute jobs. It can take many hours to unpack, decompile, edit, recompile, repack a kernel into a working flashable package. Then we have to test it and live with bootloops and soft bricks if we get it wrong. I can not tell you how many times I have had to restore my Infinity due to one line of code wrong or a badly compiled apk. It's all so you don't have to.
Anyway I'm sure you understand :good: Why don't you read the guides and have a go yourself? Always good to have more people able to do this type of work
sbdags said:
Why don't you read the guides and have a go yourself?
Click to expand...
Click to collapse
I tried to understand,but it's all very hard for me and ok i will be wait your new kernel with OC
Blue cat said:
New kernel from _that so bad,this kernel dont have OC and voltage control,DPI and most important for me balance power mode 1600...performance power mode do nothing.
But i still want asus changes from new kernel.I hope someone create normal kernel like was Clemsyn's kernel or may be _that do this?
Click to expand...
Click to collapse
This is a 100% stock kernel with just a custom ramdisk. Stock kernels never have any of the features you describe here.
Asus have not released their sources for 10.4.4.25 yet, and Clemsyn's kernel sources are a big mess. As soon as sources are released, it is possible to build a new kernel with OC features.
sbdags said:
I will be looking at the Clemsyn kernels in the mean time to see if I can bring them onto the new kernel base and the benefits they bring.
Click to expand...
Click to collapse
Do you have a clue how to build the kernels in your kernel installer from Clemsyn's sources?
sbdags said:
Please be patient, these are not 5 minute jobs.
Click to expand...
Click to collapse
Right, this kernel was more like 10 minutes work. Writing the tutorial took more than 2 hours.
_that said:
Do you have a clue how to build the kernels in your kernel installer from Clemsyn's sources?
/QUOTE]
Nope. Just unpacked yours and clemsyn's. Right, that's not going to happen anytime fast!
:laugh:
Click to expand...
Click to collapse
Great job, _that, you have my sincere thanks. I still cannot find the Thanks button on my screen because of all the blood and brain tissue that got on there when my head exploded. I'll take a walk over to the ED department to get that fixed with a printed plastic cranium, glue it shut, cover it up with a few bandages, get back to my own department and then clean up for a bit. When I finally regain something of a normal level of consciousness I'll try and step into the shadown you throw upon me, and press the damn button.
EDIT: button pressed. Speech still slurring a bit, minor tremor in the left hand and incontinent for both faeces and urine. Apart from that, I'm fine, thanks for asking.
Just kidding, obviously. I've read along, and I get most parts theoretically. Thanks for making me learn -- the most important mental facility we humans have.
Hey very good tutorial
I just unpacked your kernel and take a look inside the ramdisk and repacked the blob.
And it boots up normaly without problems.
Now I am waiting for Asus to release their latest kernel sources that I can modify the kernel itself, too and not only the ramdisk.
Thanks for helping me with that blob stuff!
blackmambazzz said:
Hey very good tutorial
I just unpacked your kernel and take a look inside the ramdisk and repacked the blob.
And it boots up normaly without problems.
Click to expand...
Click to collapse
:good: Great!
blackmambazzz said:
Now I am waiting for Asus to release their latest kernel sources that I can modify the kernel itself, too and not only the ramdisk.
Click to expand...
Click to collapse
Do you have any specific mods in mind?
_that said:
Do you have any specific mods in mind?
Click to expand...
Click to collapse
I think about this features but nothing for sure
more governors
more io-scheduler
compiled with linaro and -o3 optimizations
add fsync control
add oc (by this one i need help I think)
increase readahead
NODPI Update!
Excellent work _that! I will implement the nodpi kernel into the kernel flasher tomorrow and when the odex rom is finished I'll put it in instead of the one there now. :good::good::good:
Thank you, _that, for your hard work. Your kernel seems to be faster than Clemysn's, at least on first sight (scr** the benchmark hippies -- it feels faster, OK? ).
Flashing this was so fast, I thought I had accidentally pressed "reboot system now" instead of actually flashing your kernel. Off to testing a bit more! ; )
Thought id post today on how to set your SELinux to permissive on boot within your boot.img along with some other mods aswell
DISCLAIMER
Make sure you have at least basic knowledge decompiling boot.img & basic understanding of the files contained within, I will not be held responsible if you mess this up, following my instructions to the tee you will have no problems though,
PRE REQUISTES
* MTK extractor or similar program to decompile the boot.img
* Notepad ++
* A copy of your devices boot.img or BOOTIMG.file
* SP flash tool to flash boot.img to device
"alternatively you can add to a flashable zip if you have a custom recovery available for your device using android script generator here on xda-developers"
GUIDE
1. If your boot file is named BOOTIMG.file rename it to boot.img
2. Copy the boot.img to the program folder youll be using to decompile for this guide ill be using MTK extractor as it has a simple gui interface for all the newbs
3. MTK EXTRACTOR ONLY
Open mtk extractor application select the BOOT option from the left, in the bottom left you will see an off switch toggle it to ON
Click start at the top under unpack boot, in the mtk extractor folder will be your boot.img files
4. SETTING THE KERNEL TO PERMISSIVE
( PART 1 )
NOTE
Not all mtk devices are the same some can be set to permissive without the need for all the files using only some and some require all the files it depends on the kernel the device uses the extra files wont make a difference if anything will enforce the state even more
In this tutorial you will be using all the files to set the SELinux contexts to permissive to ensure it is enforced.
PART 1 - STEP 1.
open the INITRD folder then open your default.prop using notepad++
Set the following :
ro.secure=1 >
ro.secure=0
(This renders the boot.img insecure)
ro.selinux=0 >
ro.selinux=1
(NOTE) UBIFS MTK does not have this option
ro.security.perf_harden=1 > ro.security.perf_harden=0
(If you also want insecure adb)
ro.adb.secure=1 >
ro.adb.secure=0
(only newer mtk devices use this ro. Code )
ro.storage_manager.enabled=1 >
ro.storage_manager.enabled=0
Additionally if your device also has a low ram size you should add this to the default prop also to reduce the amount of ram usage while enabling high-end gfx also
# begin ram properties
# for low ram device to return true
ro.config.low_ram=true
# force high-end graphics in low ram mode
persist.sys.force_highendgfx=true
# ram inhaler
ro.HOME_APP_ADJ=1
# end ram properties
Now save and exit the default.prop
PART 1 - STEP 2.
Open your init.rc & init.charging.rc file with notepad++ scroll to the very bottom of the init.rc ( if you have init.target.rc add to this also)
Place this code exactly as shown
# SELinux
on property:/system/bin/setenforce $permissive u:r:kernel:s0
on property:selinux.echo $permissive > /sys/fs/selinux/enforce u:r:kernel:s0
on property:selinux.reload_policy=0
restart ueventd
restart installd
on property:selinux.setsebool debugfs 0
setenforce 0
setprop selinux.reload_policy 0
seclabel u:r:kernel:s0
Now save & exit the init.rc
PART 1 - STEP 3.
Open your fstab/s
To remove DM-Verity if present in your fstab look for the /system line & change to the following
/system ro wait,verify >
/system ro wait
Now look for /data then remove the force encryption of meta-data on data it will look something like this for exapmle
/dev/block/mmcblk0p2 /data ext4 nosuid,nodev,wait,forceencrypt=/dev/block/mmcblk0p3 ext4 /metadata >
/dev/block/mmcblk0p2 /data ext4 nosuid,nodev,wait
To remove encrypted footers from devices which use this instead of DM-Verity, change as follows using the example below,
/[email protected] /data ext4 noatime,nosuid wait,check,encryptable=footer >
/[email protected] /data ext4 noatime,nosuid, wait (check is optional & can be removed also if wanted)
PART 2 - STEP 1
( if you have init.target.rc already no need for this step)
open a new blank page in notepad++
On the first line add
On init
Space out 1 line so your now on line 3
Copy the #SELinux code we placed from init.rc to the new blank page, now save as init.target.rc
Do the above again but this time name it as init.kernel.rc
Now copy theese files to your INITRD folder
PART 2 - STEP 2.
open your init.rc & init.charging.rc once again
Add the following to the import section at the very top of the page,
import /init.kernel.rc
Import/init.target.rc
Save & exit now, your probably wondering why youve added so many files with the same code, on some devices it is necessary as i have found especially on NAND + UBIFS or JFFS2 devices.
PART 2 - STEP 3.
exit the INITRD Folder now open up the bootinfo.txt file
Change from the following
cmdline: >
cmdline: bootopt= androidboot.selinux=permissive
NOTE
FOR MT67**** 32 BIT DEVICES CHANGE FROM
cmdline: bootopt=64S3,32N2,32N2 >
TO
cmdline: bootopt=64S3,32N2,32N2 androidboot.selinux=permissive
FOR MT67**** 64 BIT DEVICES CHANGE FROM
cmdline: bootopt=64S3,32N2,64S3 >
TO
cmdline: bootopt=64S3,32N2,64S3 androidboot.selinux=permissive
Now save & exit the bootinfo.txt
PART 2 - STEP 4
open the cpiolist
Add the following at the bottom or add wherever dosent matter as long as its there
file init.kernel.rc initrd/init.kernel.rc 0750
file init.target.rc initrd/init.target.rc 0750
(Add this option only if you origninally didnt have the init.target.rc file)
Save & exit the cpiolist.
PART 2 - STEP 5
Recompile & flash if you did everything right youve now got an insecure boot.img without dm-verity encryption or data footer enceyption, with insecure adb & SElinux set as permissive,
To make sure its permissive go into settings and about device then scroll to bottom you should now see it,
If you found this useful you know where the thanks button is.
Matty1993 said:
Open your fstab/s
To remove DM-Verity if present in your fstab look for the /system line & change to the following
/system ro wait,verify >
/system ro wait
Now look for /data then remove the force encryption of meta-data on data it will look something like this for exapmle
/dev/block/mmcblk0p2 /data ext4 nosuid,nodev,wait,forceencrypt=/dev/block/mmcblk0p3 ext4 /metadata >
/dev/block/mmcblk0p2 /data ext4 nosuid,nodev,wait
To remove encrypted footers from devices which use this instead of DM-Verity, change as follows using the example below,
/[email protected] /data ext4 noatime,nosuid wait,check,encryptable=footer >
/[email protected] /data ext4 noatime,nosuid, wait (check is optional & can be removed also if wanted)
Click to expand...
Click to collapse
Hi Matty1993,
These are also in dtb of the kernel which I think may cause some issues if not removed. Magisk normally removes it from /system but on newer Android versions 8.0 > 8.1 /vendor is also wait,verify by default.
To edit these yourself you need a good hex editor and replace the ",verify" with zero bytes do not just delete it or type zero's or it will not boot.
I have not seen any forceencrypt in the dtb of the boot.img's I have seen as yet.
bigrammy said:
Hi Matty1993,
These are also in dtb of the kernel which I think may cause some issues if not removed. Magisk normally removes it from /system but on newer Android versions 8.0 > 8.1 /vendor is also wait,verify by default.
To edit these yourself you need a good hex editor and replace the ",verify" with zero bytes do not just delete it or type zero's or it will not boot.
I have not seen any forceencrypt in the dtb of the boot.img's I have seen as yet.
Click to expand...
Click to collapse
Wow i didnt even see this till now i need an assistant or something to organise and mark all my threads because im useless at it haha anyhow maybe could be a vendor related thing then as mine has all the info in dtb of kernel aswell as i was able to remove just "verify" from system and metadata completely and got it to boot.
I also found an easier way to get kernel permissive also as my first older method dosent seem to work with newer mtk models but my newer method works across most mtk platform from mt6572 up to mt6737m
What i did is decompiled my twrp i built for the same phone and copied the busybox applet from /sbin in the initrd then decompiled my boot.img added it to sbin gave it necessary permission of 04555 in the cpiolist whilst i had cpio list open i added below "file init initrd/init 0750"
"file init2 initrd/init2 0750" then went back to the initrd and changed the name of the "init" file to "init2" opened notepad++ to a new page and added the following
#!/sbin/busybox sh
cd/
/sbin/busybox mkdir /tmp
/sbin/busybox mount -t tmpfs tmpfs /tmp
/sbin/busybox mount -t proc proc /proc
/sbin/busybox sed -e 's/printk\.disable_uart\=1/printk\disable_uart\=1 androidboot\.selinux\=permissive/' /proc/cmdline > /tmp/cmdline
/sbin/busybox mount --bind -o -ro /tmp/cmdline /proc/cmdline
/sbin/busybox settings put global captive_portal_detection_enabled 0
/sbin/busybox chmod 755 /init2
/sbin/busybox mv /init2 /init
/bin/su settings put global captive_portal_detection_enabled 0
exec /init
All i did then was save it under the name .init to the bootimg directory then remove the "." from the file name so that it became init.file instead of .INIT format file
After that opened up the bootinfo.txt and added under cmd=bootopt=androidboot.selinux=permissive
Recompiled bootimg and had no dramas so thought id chuck it up here in case anyone else couldnt get there kernel to setenforce 0 through /bin/setenforce or any other way youve tried on these newer mtk models, do remember though results may vary this may or may not work for everyones device, no this will no permanently brick your device doing this if it dosent work you will simply still have an enforcing kernel. Have fun all
Help
tell me how to do selinux = permisive on my firmware and all permissions? Google search does not help. Doogee bl9000 Android 8.1 kernel 4.4.95+ Please help.
waryag said:
tell me how to do selinux = permisive on my firmware and all permissions? Google search does not help. Doogee bl9000 Android 8.1 kernel 4.4.95+ Please help.
Click to expand...
Click to collapse
Hey bud sorry for late reply,
What board make type is it running 6580, 6735/6737 or 6763/6737 depending on which it should be pretty straight forward to get you unlocked and what not as your BL will be by default locked down either way on 6580 or 67xx
I dont recommend you pushing permissive selinux on 8.1 however as this will compromise your security integrity what were you looking to do anyhow regarding permissive selinux,
Rooting or custom recovery ??
UPDATE: Changed the Topic as we are getting away from the original question in post 1 to the actual problem: figuring out how to fully root an Onyx Boox Poke3 e-reader running Android 10. "Fully" meaning including full r/w access to /system and /vendor - which isn't straight forward at the moment with "only" magisk-patching the stock boot.img
----------------------
Hi all,
possibly (probably) a "2^32 FAQ" but I can't g**gle it - everything search more or less leads to "how to patch boot img with magisk and flash it (in fastboot or twrp)".
So: Is there a tool (either on android or linux) to apply zips just like in twrp to a "boot.img" or "system.img" file, one after the other?
Why? I have a device for which there's no twrp (yet.... might look into that some day).
I have magisk-rooted it by patching the stock boot.img and then flashing that via fastboot. Rooted yes, Magisk yes, but still a "user-build" / "dm-verity" protected system, so tweaks modifying anything on /system or /vendor permanently aren't successful.
I guess there's a dozen solutions, but I just can't g**gle any (my g**gle foo isn't good enough...)
Anyone?
Disable dm-verity with adb.
You can modify build.prop and change ro.secure to 0 to get adb root.
Then disable dm-verity after that
I don't get to disable dm-verity, even with adb root (which I installed as a magisk module). Its a "user" build. Or - despite hours of reading and trying - I didn't find the right way to do it (or didn't understand). Or would it be as simple as using Android Image Kitchen to unpack (the patched boot.img), tweak build.prop, repack, re-flash? Now that I think of it...!?
But there's another odd thing here. Magisk App says I don't have a ramdisk. As I don't have the stock "recovery image" (and because I didn't really pay attention to this but followed in the steps of someone with a similar device) I patched the stock boot.img - where really I should have patched recovery.img. However, device behaves fine with the patched boot.img. If I then dd the /recovery partition, I do find ".magisk" stuff in the "ramdisk" folder. Also, in the initial magisk patching log when patching the boot.img, it says:
Code:
....
- Checking ramdisk status
- Stock boot image detected
- Patching ramdisk
Add entry [init] (0750)
Create directory [overlay.d] (0750)
Create directory [overlay.d/sbin] (0750)
Add entry [overlay.d/sbin/magisk32.xz] (0644)
Add entry [overlay.d/sbin/magisk64.xz] (0644)
Patch with flag KEEPVERITY=[true] KEEPFORCEENCRYPT=[true]
Create directory [.backup] (0000)
Add entry [.backup/.magisk] (0000)
....
SO, even though the device seems to have no ramdisk in stock boot.img (?) magisk patched it, and the device still runs from it....
Also, could I force magisk to set keepverity=false? In the app, there's no related tickbox available.
Will make all this into a proper howto in the end... a mess at the moment
If phone's bootloader is unlocked then you can disable AVB by means of Fastboot:
Code:
adb devices
adb reboot fastboot
fastboot reboot fastboot 2>nul
fastboot --disable-verification --disable-verity flash vbmeta vbmeta.img
fastboot reboot
@jwoegerbauer and @Kenora_I thanks for your responses.
Not sure if I'm on the right track here. I did a "dd" (from within the magisk rooted system via adb, dumping /dev/block/mmcblk0p46) to get the current (stock) vbmeta partition as a vbmeta.img to see what's in there "in stock state". avbtool.py says it doesn't look like vbmeta stuff, and I think it is right after looking at it with a hex editor: it's all zeroes. So, the information to protect /system and /vendor apparently does not come from vbmeta.
I had a look at the stock fimware update zip, unpacked it with superR's kitchen. In /vendor I have build.prop, but that does NOT contain "secure" at all. There is also a file default.prop, but can't see anything related to dm-verity in there, either.
Code:
#
# ADDITIONAL VENDOR DEFAULT PROPERTIES
#
ro.vndk.version=29
ro.adb.secure=1
ro.oem_unlock_supported=1
ro.zygote=zygote64_32
ro.logd.size.stats=64K
log.tag.stats_log=I
ro.logdumpd.enabled=0
ro.bionic.arch=arm64
ro.bionic.cpu_variant=generic
ro.bionic.2nd_arch=arm
ro.bionic.2nd_cpu_variant=cortex-a73
persist.sys.dalvik.vm.lib.2=libart.so
dalvik.vm.isa.arm64.variant=generic
dalvik.vm.isa.arm64.features=default
dalvik.vm.isa.arm.variant=cortex-a73
dalvik.vm.isa.arm.features=default
And then there is /vendor/etc/fstab - but it doesn't even list anything that would mount /vendor, only some sub-dirs mounted below that. It only contains "ro" for "/" - should I simply replace that with "rw", re-pack that stock vendor.img and flash it maybe!? With all that AVB/dm-verity stuff around it seems to simple - or not!?
Spoiler: /vendor/etc/fstab
Code:
# Non-A/B fstab.qcom variant
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/bootdevice/by-name/system / ext4 ro,barrier=1,discard wait
/dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard,noatime,lazytime wait,check,forceencrypt=footer,crashcheck,quota,reservedsize=128M
/devices/soc/c084000.sdhci/mmc_host* /storage/sdcard1 vfat nosuid,nodev wait,voldmanaged=sdcard1:auto,encryptable=footer
/dev/block/bootdevice/by-name/misc /misc emmc defaults defaults
/dev/block/bootdevice/by-name/modem /vendor/firmware_mnt vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337,context=u:object_r:firmware_file:s0 wait
/dev/block/bootdevice/by-name/bluetooth /vendor/bt_firmware vfat ro,shortname=lower,uid=1002,gid=3002,dmask=227,fmask=337,context=u:object_r:bt_firmware_file:s0 wait
/devices/soc/a800000.ssusb/a800000.dwc3/xhci-hcd.0.auto* /storage/usbotg vfat nosuid,nodev wait,voldmanaged=usbotg:auto
/dev/block/bootdevice/by-name/dsp /vendor/dsp ext4 ro,nosuid,nodev,barrier=1 wait
/dev/block/bootdevice/by-name/cache /cache ext4 nosuid,nodev,noatime,barrier=1 wait
/dev/block/bootdevice/by-name/persist /mnt/vendor/persist ext4 noatime,nosuid,nodev,barrier=1 wait
#/dev/block/bootdevice/by-name/onyxconfig /onyxconfig ext4 defaults defaults
Edit: device tree might be the keyword:
On pre-Oreo releases fstab was in ramdisk. With Treble it was moved to /vendor (or /system/vendor) while the fstab entries for system and vendor (and odm) are moved to Device Tree Blob (dtb). Kernel exports dtb fstab entries in device tree directory at /proc/device-tree/firmware/android
Click to expand...
Click to collapse
From: https://android.stackexchange.com/q...ty-on-android-with-user-build-type-rom/215907
Edit2:
/proc/device-tree/firmware/android/fstab/vendor/fsmgr_flags lists "wait,verify"
/proc/device-tree/firmware/android/fstab/vendor/mnt_flags lists "ro,barrier=1,discard"
SO... seems I have to patch the dtb. Tomorrow maybe...
ro.adb.secure=1
This should be 0 if you want adb root command to function properly.
It shouldnt say adbd cannot run in production builds anymore.
PokeRekoP said:
@jwoegerbauer and @Kenora_I thanks for your responses.
Not sure if I'm on the right track here. I did a "dd" (from within the magisk rooted system via adb, dumping /dev/block/mmcblk0p46) to get the current (stock) vbmeta partition as a vbmeta.img to see what's in there "in stock state". avbtool.py says it doesn't look like vbmeta stuff, and I think it is right after looking at it with a hex editor: it's all zeroes. So, the information to protect /system and /vendor apparently does not come from vbmeta.
I had a look at the stock fimware update zip, unpacked it with superR's kitchen. In /vendor I have build.prop, but that does NOT contain "secure" at all. There is also a file default.prop, but can't see anything related to dm-verity in there, either.
Code:
#
# ADDITIONAL VENDOR DEFAULT PROPERTIES
#
ro.vndk.version=29
ro.adb.secure=1
ro.oem_unlock_supported=1
ro.zygote=zygote64_32
ro.logd.size.stats=64K
log.tag.stats_log=I
ro.logdumpd.enabled=0
ro.bionic.arch=arm64
ro.bionic.cpu_variant=generic
ro.bionic.2nd_arch=arm
ro.bionic.2nd_cpu_variant=cortex-a73
persist.sys.dalvik.vm.lib.2=libart.so
dalvik.vm.isa.arm64.variant=generic
dalvik.vm.isa.arm64.features=default
dalvik.vm.isa.arm.variant=cortex-a73
dalvik.vm.isa.arm.features=default
And then there is /vendor/etc/fstab - but it doesn't even list anything that would mount /vendor, only some sub-dirs mounted below that. It only contains "ro" for "/" - should I simply replace that with "rw", re-pack that stock vendor.img and flash it maybe!? With all that AVB/dm-verity stuff around it seems to simple - or not!?
Spoiler: /vendor/etc/fstab
Code:
# Non-A/B fstab.qcom variant
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/bootdevice/by-name/system / ext4 ro,barrier=1,discard wait
/dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard,noatime,lazytime wait,check,forceencrypt=footer,crashcheck,quota,reservedsize=128M
/devices/soc/c084000.sdhci/mmc_host* /storage/sdcard1 vfat nosuid,nodev wait,voldmanaged=sdcard1:auto,encryptable=footer
/dev/block/bootdevice/by-name/misc /misc emmc defaults defaults
/dev/block/bootdevice/by-name/modem /vendor/firmware_mnt vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337,context=u:object_r:firmware_file:s0 wait
/dev/block/bootdevice/by-name/bluetooth /vendor/bt_firmware vfat ro,shortname=lower,uid=1002,gid=3002,dmask=227,fmask=337,context=u:object_r:bt_firmware_file:s0 wait
/devices/soc/a800000.ssusb/a800000.dwc3/xhci-hcd.0.auto* /storage/usbotg vfat nosuid,nodev wait,voldmanaged=usbotg:auto
/dev/block/bootdevice/by-name/dsp /vendor/dsp ext4 ro,nosuid,nodev,barrier=1 wait
/dev/block/bootdevice/by-name/cache /cache ext4 nosuid,nodev,noatime,barrier=1 wait
/dev/block/bootdevice/by-name/persist /mnt/vendor/persist ext4 noatime,nosuid,nodev,barrier=1 wait
#/dev/block/bootdevice/by-name/onyxconfig /onyxconfig ext4 defaults defaults
Edit: device tree might be the keyword:
From: https://android.stackexchange.com/q...ty-on-android-with-user-build-type-rom/215907
Edit2:
/proc/device-tree/firmware/android/fstab/vendor/fsmgr_flags lists "wait,verify"
/proc/device-tree/firmware/android/fstab/vendor/mnt_flags lists "ro,barrier=1,discard"
SO... seems I have to patch the dtb. Tomorrow maybe...
Click to expand...
Click to collapse
Replacing it with rw, yes would make it read-writeable
According to the changed thread's tite:
Rooting Android means nothing else then adding a matching SU-binary ( AKA root ) to it.
Since Android 6 every Android release comes with ( non-root ) Toybox. What you have to do is to replace this restricted version by a full ( root ) version like Toybox v0.8.5. You can achieve this by temporarily rooting Android, for example by means of copying rooted Busybox to /tmp.
jwoegerbauer said:
According to the changed thread's tite:
Rooting Android means nothing else then adding a matching SU-binary ( AKA root ) to it.
Since Android 6 every Android release comes with ( non-root ) Toybox. What you have to do is to replace this restricted version by a full ( root ) version like Toybox v0.8.5. You can achieve this by temporarily rooting Android, for example by means of copying rooted Busybox to /tmp.
Click to expand...
Click to collapse
Well ive been stumped trying to root my tv which is android 7.1.1 and ive tried the exploits everything.
Idk how easy it is too do that.
I can push files to /data/tmp though.
AFAIK both /tmp and /data/local/tmp are always present in any Android release. But I may err as always ...
Well i dont see an error but yeah android 7 is harder. Especially with the tv, /rootfa is ro and for some reason its mounted.
I guess i look through it but it dosent help me much.
I only kinda need a root shell and thats it
Its funny cause the chip seems to be hisilicon or smth.
Anyways what you said is right. He can just install the rooted version of busybox in tmp
For instructional purposes only: here a script ( what is part of an UPDATE.ZIP ) I wrote to upgrade Toybox to it's full - means containg SU - version with help of Busybox
Code:
#!/system/bin/sh
#
# Title: TOYBOX-UPDATER.SH
# Author: (c) 2021 [email protected]
# Version: 0.1
# License: BSD 2-Clause
#
busybox="/tmp/busybox" ;
tbpath="$($busybox getprop "toybox.location")";
if [ -z "$tbpath" ]; then
exit 1
fi;
tbdir="/$tbpath/bin";
if [ "$tbpath" == "system" ]; then
tbbin="toybox";
else
tbbin="toybox_vendor";
fi;
$busybox echo -e "Uninstalling actual TOYBOX";
for f in $($busybox find "$tbdir" -type l) ; do
$busybox rm "$f" ;
done
$busybox rm "$tbdir/$tbbin" ;
$busybox echo -e "Installing TOYBOX v0.8.5" ;
$busybox mv /tmp/toybox $tbdir/$tbbin ;
$busybox chmod +x $tbdir/$tbbin ;
$busybox chown root:shell $tbdir/$tbbin ;
$busybox echo -e "Adding symlink for each Toybox command to the $PATH" ;
tbcmds=(
acpi, arch, ascii, base64, basename, blkid, blockdev, bunzip2, bzcat, cal, cat,
catv, chattr, chgrp, chmod, chown, chroot, chrt, chvt, cksum, clear, cmp, comm,
count, cp, cpio, crc32, cut, date, devmem, df, dirname, dmesg, dnsdomainname,
dos2unix, du, echo, egrep, eject, env, expand, factor, fallocate, false, fgrep,
file, find, flock, fmt, free, freeramdisk, fsfreeze, fstype, fsync, ftpget,
ftpput, getconf, grep, groups, gunzip, halt, head, help, hexedit, hostname,
hwclock, i2cdetect, i2cdump, i2cget, i2cset, iconv, id, ifconfig, inotifyd,
insmod, install, ionice, iorenice, iotop, kill, killall, killall5, link, ln,
logger, login, logname, losetup, ls, lsattr, lsmod, lspci, lsusb, makedevs,
mcookie, md5sum, microcom, mix, mkdir, mkfifo, mknod, mkpasswd, mkswap, mktemp,
modinfo, mount, mountpoint, mv, nbd-client, nc, netcat, netstat, nice, nl, nohup,
nproc, nsenter, od, oneit, partprobe, passwd, paste, patch, pgrep, pidof, ping,
ping6, pivot_root, pkill, pmap, poweroff, printenv, printf, prlimit, ps, pwd,
pwdx, readahead, readlink, realpath, reboot, renice, reset, rev, rfkill, rm,
rmdir, rmmod, sed, seq, setfattr, setsid, sha1sum, shred, sleep, sntp, sort,
split, stat, strings, su, swapoff, swapon, switch_root, sync, sysctl, tac, tail
tar, taskset, tee, test, time, timeout, top, touch, true, truncate, tty, tunctl,
ulimit, umount, uname, uniq, unix2dos, unlink, unshare, uptime, usleep, uudecode,
uuencode, uuidgen, vconfig, vmstat, w, watch, wc, which, who, whoami, xargs,
xxd, yes, zcat
) ;
fs=$IFS ;
IFS=,
for cmd in "${tbcmds[@]}"; do
$busybox ln -s $tbdir/$tbbin $tbdir/"$cmd" ;
$busybox chmod +x $tbdir/"$cmd" ;
done
IFS=$fs ;
exit 0
So would that executable in a terminal emulator such as termux?
If script's permissions get set to 0755 then yes.
Oh thanks!
yes i can chmod 0755 the script.
cause adb in termux rocks when you work on a tv
But the thing wont it come up with access denied or smth like that in the thing.
I guess the tv would have loopholes but still
As said, the script is run by an updater-script where all the necessary partition-mounting is done: knowing this it should be clear that you run into errors when executing the script as printed above unless you add the necessary mounting stuff to it.
jwoegerbauer said:
As said, the script is run by an updater-script where all the necessary partition-mounting is done: knowing this it should be clear that you run into errors when executing the script as printed above unless you add the necessary mounting stuff to it.
Click to expand...
Click to collapse
Oh kk
small update: meanwhile managed to patch the
/proc/device-tree/firmware/android/fstab/vendor/fsmgr_flags from "wait,verify" to "wait"
using magiskboot binary. But it's a way too complicated for the "ordinary" guy. So still searching for an easier way.
I don't know.
I think that while we have Magisk it's easier/better to leave /system alone.
You retain the ability to do system updates.
Originally I took boot.img out of a decrypted update.upx
I extracted the kernel symbols then patched the kernel to be insecure.
I wrote a small executable that setuid/setguid to 0.
The kernel had been knee-capped to not check capabilities, it worked.
I then dd'ed recovery and fed it to Magisk.
Being able to su over ADB is all I really need; I don't like/need apps having root.
For me, being able to "pm disable com.onyx" is the bulk of what I need.
Later I discovered Qualcomm EDL mode which works just fine too.
Somebody asked me about p46 (vbmeta) and I see mine is 64K of zeroes.
@Renate : and here we meet again ;-) that somebody was me I guess