Related
I've just installed the last porting of the cyanogen for my Magic 32a. I'm enjoining the idea behind the script fix_permissions. But, observing the structure of the files/folders in my /data/data/, I can see that it is not perfect.
It does chown the folders /data/data/NAME-OF-PACKAGE/ and the subfolders 'databases' and 'shared_prefs'.
Observing the typical contents of my /data/data/ I can see that some applications has further folders and some times also single files in /data/data/NAME-OF-PACKAGE/ that need a touch of chown.
For example:
/data/data/com.htc.android.mail/
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 app_config
drwxrwxrwx 1 10021 10021 2048 Aug 18 09:00 app_mail_eas
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 app_mail_temp
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 app_temp
-rw------- 1 10021 10021 1048576 Aug 18 09:00 bufferFileForMailAP
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 databases
drwxr-xr-x 1 1000 1000 2048 Aug 18 08:41 lib
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 shared_prefs
You can test on your system by yourself:
for APP in /data/data/* ; do echo -e "\n$APP" ; ls -l $APP ; done | more
I'm attaching an improved version that should fix the permissions on all the subfolders different than 'lib' and also on the single files.
I hope it works for you and that it can be included in the future firmwares.
UPDATE: in this thread, several users are making contributions to the original script (with a fast increasing version number ). There is also a report in the Cyanogen bug system: http://code.google.com/p/cyanogenmo...ID Type Status Priority Version Owner Summary
You should find there the last revision. Thanks to all for the contributions.
ankn said:
I've just installed the last porting of the cyanogen for my Magic 32a. I'm enjoining the idea behind the script fix_permissions. But, observing the structure of the files/folders in my /data/data/, I can see that it is not perfect.
It does chown the folders /data/data/NAME-OF-PACKAGE/ and the subfolders 'databases' and 'shared_prefs'.
Observing the typical contents of my /data/data/ I can see that some applications has further folders and some times also single files in /data/data/NAME-OF-PACKAGE/ that need a touch of chown.
For example:
/data/data/com.htc.android.mail/
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 app_config
drwxrwxrwx 1 10021 10021 2048 Aug 18 09:00 app_mail_eas
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 app_mail_temp
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 app_temp
-rw------- 1 10021 10021 1048576 Aug 18 09:00 bufferFileForMailAP
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 databases
drwxr-xr-x 1 1000 1000 2048 Aug 18 08:41 lib
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 shared_prefs
You can test on your system by yourself:
for APP in /data/data/* ; do echo -e "\n$APP" ; ls -l $APP ; done | more
I'm attaching an improved version that should fix the permissions on all the subfolders different than 'lib' and also on the single files.
I hope it works for you and that it can be included in the future firmwares.
Click to expand...
Click to collapse
Btw, I was wondering why we fix only userId and not also sharedUserId
as I'm quite sure I've seen them messed up sometimes after some of my to
ambitious experiments. Shouldn't be difficult to add support for that if there
is some evidence that it is a Good Thing(tm).
farmatito said:
Btw, I was wondering why we fix only userId and not also sharedUserId
Click to expand...
Click to collapse
I don't understand the meaning of the parameter "sharedUserId". Some packages in packages.xml use the parameter "UserId", others the "sharedUserId" one. What's the difference?
ankn said:
I don't understand the meaning of the parameter "sharedUserId". Some packages in packages.xml use the parameter "UserId", others the "sharedUserId" one. What's the difference?
Click to expand...
Click to collapse
shared user id is for the case when you have a program extended by another installable program in order to run in the same process:
http://developer.android.com/reference/android/R.attr.html#sharedUserId
Another improvement could be to fix the file modes as well. I have noticed that sometimes the user permissions on files and directories in /data/data get removed.
Then you get FCs with an sqlite error like below:
Code:
sqlite3_open_v2("/data/data/com.xta.foodmkt/databases/Hungry.db", &handle, 6, NULL) failed
The below commands fixes the access errors:
Code:
find /data/data -type d -exec busybox chmod u+rwx {} \;
find /data/data -type f -exec busybox chmod u+rw {} \;
farmatito said:
Btw, I was wondering why we fix only userId and not also sharedUserId
as I'm quite sure I've seen them messed up sometimes after some of my to
ambitious experiments. Shouldn't be difficult to add support for that if there
is some evidence that it is a Good Thing(tm).
Click to expand...
Click to collapse
I'm attaching another version with support to packages with sharedUserId; fixed the remount mechanism that doesn't work on the other firmware that I'm actually using (HoFo).
smeat said:
The below commands fixes the access errors:
Code:
find /data/data -type d -exec busybox chmod u+rwx {} \;
find /data/data -type f -exec busybox chmod u+rw {} \;
Click to expand...
Click to collapse
This code should fixes all the permission-related problems but it is too risky from the security point-of-view.
ankn said:
This code should fixes all the permission-related problems but it is too risky from the security point-of-view.
Click to expand...
Click to collapse
Why risky, if i understand it right:
directory: 700 (owner only can read, write or enter directory)
files: 600 (owner only can read or write file)
Where is the risk?
You can also use:
chmod 700 directory
chmod 600 files
farmatito said:
Why risky, if i understand it right:
directory: 700 (owner only can read, write or enter directory)
files: 600 (owner only can read or write file)
Where is the risk?
You can also use:
chmod 700 directory
chmod 600 files
Click to expand...
Click to collapse
It doesn't even go that far, it ADDS the owner to the permissions, not reset them to just the owner having permissions.
smeat said:
It doesn't even go that far, it ADDS the owner to the permissions, not reset them to just the owner having permissions.
Click to expand...
Click to collapse
This in my opinion is far more risky than doing
a chmod for the owner only at least in the case
that the permissions are messed up for whatever
reason as some insecure settings will not be corrected
that way, e.g.:
permissions are wrongly set to 666 or 777
than you do chmod +urwx file and the result
will continue to be an insecure setting 666 or
677 that doesn't enforce isolation between apps.
BTW, by looking at ls of /data/data it seems to
me that all folders have 755 permissions so
chmod 755 folder should be safe. For the deeper level:
Code:
/data/data/app 755
/data/data/app/files 700
/data/data/app/lib 755
/data/data/app/shared_prefs 771
but I have not the time right now to check all subfolders
to see if there are exceptions to this default settings.
smeat said:
It doesn't even go that far, it ADDS the owner to the permissions, not reset them to just the owner having permissions.
Click to expand...
Click to collapse
This is true. Sorry!
farmatito said:
This in my opinion is far more risky than doing
a chmod for the owner only at least in the case
that the permissions are messed up for whatever
reason as some insecure settings will not be corrected
that way, e.g.:
permissions are wrongly set to 666 or 777
than you do chmod +urwx file and the result
will continue to be an insecure setting 666 or
677 that doesn't enforce isolation between apps.
BTW, by looking at ls of /data/data it seems to
me that all folders have 755 permissions so
chmod 755 folder should be safe. For the deeper level:
Code:
/data/data/app 755
/data/data/app/files 700
/data/data/app/lib 755
/data/data/app/shared_prefs 771
but I have not the time right now to check all subfolders
to see if there are exceptions to this default settings.
Click to expand...
Click to collapse
fix_permissions is not about removing permissions and never has been from what I can tell. Currently it just goes through the /data/system/packages.xml and finds the listed owner of the /data/data files and then changes ownership of the files and directories.
I am talking about adding an additional chmod to make it so that file and directory owners are added as being able to read/write to the files they own. I have seen an issue were running something made it so that a ton of my application sqlite databases had file permissions of 060. When this happens you get the error I posted originally: sqlite3_open_v2("/data/data/com.xta.foodmkt/databases/Hungry.db", &handle, 6, NULL) failed. Even though the group write and read bit are set and the group is correct the error above happens. Adding the owner back as having read/write permissions fixes this error.
Again, adding permissions to only the user/owner of the files and directories does not open the files up to being written by other processes on the phone.
Again, adding permissions to only the user/owner of the files and directories does not open the files up to being written by other processes on the phone.
Click to expand...
Click to collapse
I know. I was trying to improve the concept of fix permission as you can not know
in advance how the permissions could have been messed up. So it would be better
to enforce some sane defaults rather than to add some hacks to fix a specific problem.
This obviously is only possible if there are some patterns in file and folder permissions of /data/data.
That is what i will try to find out.
farmatito said:
I know. I was trying to improve the concept of fix permission as you can not know
in advance how the permissions could have been messed up. So it would be better
to enforce some sane defaults rather than to add some hacks to fix a specific problem.
This obviously is only possible if there are some patterns in file and folder permissions of /data/data.
That is what i will try to find out.
Click to expand...
Click to collapse
Ahhh, sorry I misunderstood what you were getting at.
If you run:
Code:
find /data/data -type f -exec ls -l {} \;
Will tell you what all the files are currently set to.
A run of:
Code:
find /data/data -type d -exec ls -ld {} \;
Will list the current directory permissions.
What I can find is that any /sslcache directory is 700, /lib 755 and owned by 1000:1000, /database 771, /shared_prefs 771, But I have some apps with 700 directories for everything.
Here is a table for /data/data/app, format: directory/file, permissions, ownership
Directories:
/database 771 appuser:appgroup
/lib 755 1000:1000
/shared_prefs 771 appuser:appgroup
/sslcache 700 appuser:appgroup
/anythingelse 771 appuser:appgroup
Files:
/database/* 660 appuser:appgroup
/lib/* ??? ??????, never seen any files in these directories.
/sslcache/* 600 appuser:appgroup
/shared_prefs/* 660 appuser:appgroup
/anythingelse/* 660 appuser:appgroup
Does this align with what you are seeing? If so we can adjust the script to apply these permissions to the files and directories more selectively.
I was actually wondering about this very thing yesterday. Is there some reason why the initial script only changed the permissions of databases and shared_prefs?
I'm trying to think of a scenario in which you wouldn't just want a recursive chown, but especially in the case of wiping and then copying back data directories, having ALL the subdirectories owned by the app's uid seems preferable to having any of them owned by the wrong uid.
smeat said:
Ahhh, sorry I misunderstood what you were getting at.
If you run:
Code:
find /data/data -type f -exec ls -l {} \;
Will tell you what all the files are currently set to.
A run of:
Code:
find /data/data -type d -exec ls -ld {} \;
Will list the current directory permissions.
What I can find is that any /sslcache directory is 700, /lib 755 and owned by 1000:1000, /database 771, /shared_prefs 771, But I have some apps with 700 directories for everything.
Here is a table for /data/data/app, format: directory/file, permissions, ownership
Directories:
/database 771 appuser:appgroup
/lib 755 1000:1000
/shared_prefs 771 appuser:appgroup
/sslcache 770 appuser:appgroup
/anythingelse 771 appuser:appgroup
Files:
/database/* 660 appuser:appgroup
/lib/* ??? ??????, never seen any files in these directories.
/sslcache/* 600 appuser:appgroup
/shared_prefs/* 660 appuser:appgroup
/anythingelse/* 660 appuser:appgroup
Does this align with what you are seeing? If so we can adjust the script to apply these permissions to the files and directories more selectively.
Click to expand...
Click to collapse
So far this is what i've found:
Code:
/data/data/pkgdir uid/gid 755
/data/data/pkgdir/lib system/system 755
/data/data/pkgdir/databases uid/gid 771
/data/data/pkgdir/databases/*.db uid/gid 660
/data/data/pkgdir/shared_prefs uid/gid 771
/data/data/pkgdir/shared_prefs/*.xml uid/gid 660
/data/data/pkgdir/cache uid/gid 771
/data/data/pkgdir/cache/* uid/gid 771
The only differences are in the anythingelse part wher I have found
all possible combinations of permissions, but I suspect that these files
and dirs are setup by the apk at runtime as no reference could be found
for them in the apk package nor in the installd source code.
So i think it would be a big improvement to try to fix this standard dirs and their
contents with ownership and permissions as shown above.
This could save a lot of headaches to users and devs. Single apps with
exotic permissions could always be reinstalled or fixed manually.
In script 1.3 you should change:
cat /data/system/packages.xml | grep "^<package" | grep userId
to
cat /data/system/packages.xml | grep "^<package" | grep serId
as else no packages with sharedUserId will be found
farmatito said:
So far this is what i've found:
Code:
/data/data/pkgdir uid/gid 755
/data/data/pkgdir/lib system/system 755
/data/data/pkgdir/databases uid/gid 771
/data/data/pkgdir/databases/*.db uid/gid 660
/data/data/pkgdir/shared_prefs uid/gid 771
/data/data/pkgdir/shared_prefs/*.xml uid/gid 660
/data/data/pkgdir/cache uid/gid 771
/data/data/pkgdir/cache/* uid/gid 771
The only differences are in the anythingelse part wher I have found
all possible combinations of permissions, but I suspect that these files
and dirs are setup by the apk at runtime as no reference could be found
for them in the apk package nor in the installd source code.
So i think it would be a big improvement to try to fix this standard dirs and their
contents with ownership and permissions as shown above.
This could save a lot of headaches to users and devs. Single apps with
exotic permissions could always be reinstalled or fixed manually.
Click to expand...
Click to collapse
Yeah, I was assuming on the /anythingelse.
Alright here is my shot at this modification. Not much of a coder... so be gentle.
I created an issue for this on the code.google.com cyanogenmod site. thenefield posted some changes and I have integrated them into a new script.
smeat said:
I created an issue for this on the code.google.com cyanogenmod site. thenefield posted some changes and I have integrated them into a new script.
Click to expand...
Click to collapse
In your rewrite of the script, you forgot to apply the chown to the subfolders that are different than 'databases' and 'shared_prefs' as well as to the single files in the application-root. Look at my first post in this thread: these cases exist and we have to deal with them. In other words: you reverted my changes.
Desire S
Hboot 2.00.2002 o-on rl dev->unlocked
instaled = rooted stock RUU_SAGA_ICS_35_S_HTC_EU_14.01.401.2_20.76.30.0835_3831.19.00.110_275068
when i replace boot.img ...from ---> .V7.1 STABLE FOR SENSE 4 | EXPERIMENTAL FOR SENSE 3.6/MIUIv4
I only got black screen and reboot to recovery (after some time)
flashing org boot.img from ruu zip ... restores phone operation again
Why is this kernel not working .. because of hboot???
(installed busybox 1.20.2 with busysbox installer from market)... ?
Thanks for HELP!
Hboot 2.00.2002 is ENG S-OFF
Yours probably is 2.02.0002. Be more careful about such things.
You have to modify one number in the zip before flash. Read the kernel thread again
Sent from my HTC Desire S
amidabuddha said:
Hboot 2.00.2002 is ENG S-OFF
Yours probably is 2.02.0002. Be more careful about such things.
You have to modify one number in the zip before flash. Read the kernel thread again
Sent from my HTC Desire S
Click to expand...
Click to collapse
ok! mine is is 2.02.0002. ----- > S-ON Rl (****unlocked****)
"
mount("ext4", "EMMC", "/dev/block/mmcblk0p29", "/system/lib"); --- The line is totaly missing from "updater-script" in Tweaked3_7.1-Sense3.6-bcm4329.zip
adding mount line with 28 or 29 does not solve the issue :/ .... but 29 should be the right one.. as i looked up mount command in terminal... and system/lib is --> dev/block/mmcblk0p29
Flashing ZIP with 4ext recovery (latest)...
Obviously you dont like to read instructions.
Sense3.6 is for custom ROMs not for Stock
Anyway there is a new installer - use it
Sent from my HTC Desire S
amidabuddha said:
Obviously you dont like to read instructions.
Sense3.6 is for custom ROMa not for Stock
Anyway there is a new installer use it
Sent from my HTC Desire S
Click to expand...
Click to collapse
ok. New installer works.
oTeMpLo said:
ok. New installer works.
Click to expand...
Click to collapse
stock ics rom.
8.0 installer fails to create init.d folder !!!! /system/etc/init.d .. after manualy creating it .. it copies scripts to init.d folder,,
after that ficing permissions with fix_perm.bat .. as some init.d scrips have wring pemissions..
but modules still don't get loaded.
lsmod --> only wifidriver listed.
no zram ---> ecet...
free returns ---> swap 0 0 0
manualy starting ./51-zram works!!!
just init.d scripts dont get processed.
oTeMpLo said:
stock ics rom.
8.0 installer fails to create init.d folder !!!! /system/etc/init.d .. after manualy creating it .. it copies scripts to init.d folder,,
after that ficing permissions with fix_perm.bat .. as some init.d scrips have wring pemissions..
but modules still don't get loaded.
lsmod --> only wifidriver listed.
no zram ---> ecet...
free returns ---> swap 0 0 0
manualy starting ./51-zram works!!!
just init.d scripts dont get processed.
Click to expand...
Click to collapse
Code:
adb shell chmod 750 /system/etc/init.d/{scriptname}
adb shell chown 0.2000 /system/etc/init.d/{scriptname}
reboot
amidabuddha said:
Code:
adb shell chmod 750 /system/etc/init.d/{scriptname}
adb shell chown 0.2000 /system/etc/init.d/{scriptname}
reboot
Click to expand...
Click to collapse
yes i run fix_perm.bat
[email protected]:/system/etc/init.d # ls -l
ls -l
-rwxr-x--- root shell 157 2012-10-02 21:31 50-s2wEB
-rwxr-x--- root shell 68 2012-10-02 21:31 52-cifs
-rwxr-x--- root shell 107 2012-10-02 21:31 54-ntfs
-rwxr-x--- root shell 80 2012-10-02 21:31 53-kineto_gan
-rwxr-x--- root shell 117 2012-10-02 21:31 51-zram
[email protected]:/system/etc/init.d #
[email protected]:/system/lib/modules # ls -l
ls -l
-rw-r--r-- root root 320724 2008-08-01 14:00 bcm4329.ko
-rw-r--r-- root root 3118416 2012-10-02 21:31 cifs.ko
-rw-r--r-- root root 2262132 2012-10-02 21:31 ntfs.ko
-rw-r--r-- root root 29536 2012-10-02 21:31 nls_utf8.ko
-rw-r--r-- root root 175844 2012-10-02 21:31 kineto_gan.ko
-rw-r--r-- root root 218212 2012-10-02 21:31 zram.ko
[email protected]:/system/lib/modules #
Any other idea?
installed busybox 1.20.2 in /system/xbin ... some comands are still inked to "toolbox" ?!?
Thanks for help!
Check if /system/xbin/run-parts is there
amidabuddha said:
Check if /system/xbin/run-parts is there
Click to expand...
Click to collapse
[email protected]:/system/xbin # ls -l run*
ls -l run*
lrwxrwxrwx root root 2012-10-02 21:08 run-parts -> /system/xbin/busybox
[email protected]:/system/xbin #
[email protected]:/system/xbin # ls -l busy*
ls -l busy*
-rwxr-xr-x root root 863436 2012-10-02 21:08 busybox
[email protected]:/system/xbin #
oTeMpLo said:
[email protected]:/system/xbin # ls -l run*
ls -l run*
lrwxrwxrwx root root 2012-10-02 21:08 run-parts -> /system/xbin/busybox
[email protected]:/system/xbin #
[email protected]:/system/xbin # ls -l busy*
ls -l busy*
-rwxr-xr-x root root 863436 2012-10-02 21:08 busybox
[email protected]:/system/xbin #
Click to expand...
Click to collapse
.. ok now it works.... reboot afer remove in new install of busybox.....
tanks for Patiens with me!!! ....
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! ; )
This NOT a Q&A thread. Only people working out the problem are welcome.
okay , so as of flashing even supersu beta version BETA-SuperSU-v2.49 this is the issue i'm guessing for our device
for reference the firmware release api in question is Android 5.1 , API Level 22
Code:
[email protected]:/# adb logcat -d | grep F/
F/appproc ( 305): Error changing dalvik-cache ownership : Permission denied
F/libc ( 305): Fatal signal 6 (SIGABRT), code -6 in tid 305 (app_process32_o)
F/appproc ( 1026): Error changing dalvik-cache ownership : Permission denied
F/libc ( 1026): Fatal signal 6 (SIGABRT), code -6 in tid 1026 (app_process32_o)
F/appproc ( 1389): Error changing dalvik-cache ownership : Permission denied
F/libc ( 1389): Fatal signal 6 (SIGABRT), code -6 in tid 1389 (app_process32_o)
F/appproc ( 1758): Error changing dalvik-cache ownership : Permission denied
F/libc ( 1758): Fatal signal 6 (SIGABRT), code -6 in tid 1758 (app_process32_o)
F/appproc ( 2123): Error changing dalvik-cache ownership : Permission denied
F/libc ( 2123): Fatal signal 6 (SIGABRT), code -6 in tid 2123 (app_process32_o)
F/appproc ( 2482): Error changing dalvik-cache ownership : Permission denied
F/libc ( 2482): Fatal signal 6 (SIGABRT), code -6 in tid 2482 (app_process32_o)
[email protected]:/#
after looking at the script i ran and got this
Code:
[email protected]:/# adb shell ls -al /system/bin/app*
[COLOR="Red"]lrwxrwxrwx root root 2014-03-07 10:19 app_process -> /system/xbin/daemonsu
lrwxrwxrwx root root 2014-03-07 10:19 app_process32 -> /system/xbin/daemonsu
-rwxr-xr-x root shell 13588 2015-07-02 14:29 app_process32_original[/COLOR]
-rwxr-xr-x root shell 13588 2014-03-07 10:19 app_process_init
-rwxr-xr-x root shell 57688 2015-07-02 14:29 applypatch
-rwxr-xr-x root shell 213 2015-07-02 14:29 appops
-rwxr-xr-x root shell 215 2015-07-02 14:29 appwidget
undoing that with this
Code:
rm -f app_process app_process32
ln -sf /system/bin/app_process32_original /system/bin/app_process
"resolved" the "error" so if you flashed supersu thinking YAY ROOT ! and ended up with what you got you need to run what i did to
regain what you had.
SO, linking daemonsu in a different way is probably the thing but, how?
so far selinux is still alive i am trying out a patch @RunasSudo suggested here
http://forum.xda-developers.com/goo...orrect-to-compile-permissive-selinux-t3074761
also i am trying to figure out how app_process works
@thisisapoorusernamechoice
sorry for hijacking your thread. m
Okay, so with a modified adbd in /sbin i achieve a root prompt through adb
Note - at this point i do have full control over the system. yay!
but at the cost of blank display and no functions of hardware input [no touch hard buttons] awww (frowny face)
interesting note, the stock adbd has root access/privelege when executing adb reboot recovery.
does anyone have a lead on how to bind a block device to a tcp port ?
something like this, but that works, and as a service maybe?
cat /dev/whatever | nc -l 2345
okay if i'm seeing this right...,
Code:
F/appproc ( 305): Error changing dalvik-cache ownership : [COLOR="Red"]Permission denied[/COLOR]
F/libc ( 305): Fatal signal 6 (SIGABRT), code -6 in [COLOR="Red"]tid[/COLOR] 305 (app_process32_o)
my gues would be selinux denial based on wrong/incorrect type id
from file contexts
Code:
/system/bin/app_process32 u:object_r:[COLOR="Red"]zygote_exec[/COLOR]:s0
from zygote.te
Code:
# zygote
[COLOR="Red"]type[/COLOR] zygote, domain;
type [COLOR="Red"]zygote_exec[/COLOR], exec_type, file_type;
soooooo when the shuffling around of app_process* happens and /system/xbin/daemonsu is linked to /system/bin/app_process
should daemonsu instead of being [from supersu installer script]
Code:
/system/xbin/daemonsu 0755 u:object_r:system_file:s0
be
Code:
/system/xbin/daemonsu 0755 u:object_r:zygote_exec:s0
?
i don't think it sepolicy version 26, same as sm-t530nu, i'm also using the sm-t53nu's LL kernel source release for my sm-t330nu LP kernel build, so it's not the knox ****ery in the kernel source. so it's the actual policy itself ?
I'm going to do an experiment by flashing/writing the system.img.ext4 from the sm-t530nu LP release with a modified boot.img
to the sm-t330nu [post LP release flash]
If it works it would effectively be a downgrade to 5.0.X
This has worked with @sub77 's LP builds for sm-t530nu to "port" them to sm-t330nu soooo
more to come ?
okay, sooooo
now that my sm-t330nu has the official LP release installed, i CAN flash the system.img from the official sm-t530nu to it and boot successfully,
so i was right about the tied to firmware thing.
Now after a few different tests i am unable to "downgrade" my boot.img to match the sm-t530nu release version wise, policy and all
and remain at android 5.1.1 NNNYYYAAAAAHHHHHHHHH ! [WHEW okay , glad to get that out.. ]
SO, i flashed supersu to see what would happen and got the same result as before BUT, totally sepolicy contexts
Without restoring system or doing the meatball surgery from the previous post, i instead manually changed the policy context
of /system/xbin/daemonsu through adb in recovery
[note- you must enbale dev-options--->debugging
Code:
adb reboot recovery
adb shell mount /system
adb shell
chcon u:object_r:zygote_exec:s0 /system/xbin/daemonsu
chattr +i /system/xbin/daemonsu
reboot
SHINY ! no root. but boots
Code:
[email protected]:/system/bin/.ext $ ls -Z /system/xbin/daemonsu
-rwxr-xr-x root root u:object_r:zygote_exec:s0 daemonsu
Okay so now we need to know proper context for
/system/xbin/su
/system/bin/.ext/.su
hmmmm... i am going outside to play.
Nature sucks, the resolution is terrible ! xD
okay android 5.1.1 samsung policy context for system libraries is
Code:
u:object_r:system_library_file:s0
okay so far nutz..,
i found this for setool utility [setools-android-sepolicy-inject] project by @Mikos
http://forum.xda-developers.com/android/software/setools-android-sepolicy-inject-t2977563
i've forked his sources https://github.com/xmikos/setools-android
adjusted for api, and will try this method.
Android NDK
wget https://dl.google.com/android/ndk/android-ndk-r10e-linux-x86.bin
m
okay,
got Miko's toolkit compiled, this is the output of seinfo
Code:
\[email protected]:/ $ seinfo
Statistics for policy file: /sepolicy
Policy Version & Type: v.26 (binary, mls)
Classes: 86 Permissions: 271
Common classes: 5
Sensitivities: 1 Categories: 1024
Types: 1169 Attributes: 162
Users: 1 Roles: 2
Booleans: 0 Cond. Expr.: 0
Allow: 14802 Neverallow: 0
Auditallow: 0 Dontaudit: 401
Type_trans: 458 Type_change: 0
Type_member: 0 Role allow: 0
Role_trans: 0 Range_trans: 0
Constraints: 59 Validatetrans: 0
Initial SIDs: 27 Fs_use: 19
Genfscon: 43 Portcon: 0
Netifcon: 0 Nodecon: 0
Permissives: 0 Polcap: 2
[email protected]:/ $
i'm looking for someone who can run me through how sepolicy injection works specifically.
I don't know enough to interpret a generic example.
what i can understand right now is daemonsu disguised as app_process cannot access/change what it needs to in dalvik-cache due to incorrect/wrong -tid if that's the right way to say it.
this again
Code:
F/appproc ( 305): Error changing dalvik-cache ownership : Permission denied
F/libc ( 305): Fatal signal 6 (SIGABRT), code -6 in tid 305 (app_process32_o)
Mikos said the following as to command line syntax
Mikos said:
Hello, the syntax is simple, if you want comparison with supolicy, here is one example (taken from my SnooperStopper app):
Code:
supolicy --live 'allow vdc init fifo_file {read write getattr}'
is equivalent to:
Code:
sepolicy-inject -s vdc -t init -c fifo_file -p read,write,getattr -l
Click to expand...
Click to collapse
m
so how much progress you have done so far? need any help?
jazzespresso said:
so how much progress you have done so far? need any help?
Click to expand...
Click to collapse
Jazz,
have you ever done any work with sepolicy, setools ?
is there a way or do you know the right way to do the policy injection part of what Mikos described for
su and daemonsu ?
when i run strings on the sepolicy binary i do find su_exec.
so i'm still at daemonsu being the culprit. @Chainfire does make it clear the there is a hijack of app_process going on
and i do believe it works for other devices running a "state sanctioned" 5.1.1 so this is/has to be a dicky samsung move.
also how to determine the correct tid if that is indeed what i'm looking for. [see OP]
m
Will look into that, not sure how much differences between android 5.0.X and 5.1.1..
jazzespresso said:
Will look into that, not sure how much differences between android 5.0.X and 5.1.1..
Click to expand...
Click to collapse
It seems to be all sepolicy, i had to adblock and put in my usual apps minus root apps via adb push.
Swapping policy from the 5.0 boot.img reseults in no visuals or input but at adb/terminal i have access,
It just occured to me that i have not yet tried the policy swap and then applied root, hmm.
After i unscrew my system, i upgraded but forgot to change from sid so now wifi is totally boned, xD
I'll try that out, i figure it's something with ueventd.?
On disabling the policy it's complete no go so far.
In spite of modding init.rc
To disab;e sepolicy reload, to write to sys/fs/selinux/enable/0 and trying kernel cmdline edits for enforce=0 androidboot.selinux=0 etc, results
In bogus disable or no boot and dead adbd. Fun fun fun !
this is a copy/paste from my earlier sepolicy trip from galaxy tab 3 forum, putting here for reference
On-Device Policy Files
/sepolicy: Kernel binary policy
/file_contexts: File security contexts
/property_contexts: Property security contexts
/seapp_contexts: App security contexts
/system/etc/security/mac_permissions.xml: App certificate to seinfo mapping
On mac_permissions.xml
●At build time, mac_permissions.xml signature tag names (e.g. @platform) are rewritten to the actual
certificate value extracted from .pem file specified by external/sepolicy/keys.conf
.●build/tools/releasetools/sign_target_files_apks rewrites mac_permissions.xml with updated certificate values for new keys.
System Apps by Certificate
●mac_permissions.xml:
<signer signature= @platform" >
<seinfo value="platform" />
</signer>
●
seapp_contexts:
user=_app seinfo=platform domain=platform_app
type= app_data_file
---------------------------------------------------
Okay so what is this _u _r _t suffix stuff?
• _u – SELinux user
eg: system_u – used for running system services
• _r – SELinux role
eg: system_r – for daemons and background processes
• _t – SELinux type / domain
eg:httpd_t
you can change a single domain to permissive mode
-------------------------------------
the original thread is here, i forgot all about mac_permissions.xml when swapping policy
http://forum.xda-developers.com/galaxy-tab-3/general/se-linux-policy-information-thread-t2865457
moonbutt74 said:
It seems to be all sepolicy, i had to adblock and put in my usual apps minus root apps via adb push.
Swapping policy from the 5.0 boot.img reseults in no visuals or input but at adb/terminal i have access,
It just occured to me that i have not yet tried the policy swap and then applied root, hmm.
After i unscrew my system, i upgraded but forgot to change from sid so now wifi is totally boned, xD
I'll try that out, i figure it's something with ueventd.?
On disabling the policy it's complete no go so far.
In spite of modding init.rc
To disab;e sepolicy reload, to write to sys/fs/selinux/enable/0 and trying kernel cmdline edits for enforce=0 androidboot.selinux=0 etc, results
In bogus disable or no boot and dead adbd. Fun fun fun !
Click to expand...
Click to collapse
I was thinking about getting policy from the 5.0 boot.img and try and see...not sure if it would work - you may try and let me know your results
1) 5.0 sepolicy file.
2) initrd.img current one
3) initrd.img current one
It has been long time man I worked on it or dig this stuff......hmmm....hmmm....Galaxy S6 developers got root on 5.1.1, so this should be not so hard.....
okay so the sesearch string looks something like this , yielding the following output
Code:
[email protected]:/storage/AIK-Linux/ramdisk# sesearch -A -s shell -t system [COLOR="Red"]-c file[/COLOR] sepolicy
Found 3 semantic av rules:
allow shell newAttr33 : file { ioctl read write getattr lock open } ;
allow newAttr7 newAttr33 : file { ioctl read write getattr lock open } ;
allow appdomain newAttr33 : file { ioctl read write getattr lock open } ;
but if i leave out the -c [class=name] option it works sort of like a wild-card and i get this
Code:
[email protected]:/storage/AIK-Linux/ramdisk# sesearch -A -s shell -t system sepolicy
Found 20 semantic av rules:
allow shell system_server : process { transition siginh rlimitinh } ;
allow shell newAttr33 : process getattr ;
allow shell newAttr33 : file { ioctl read write getattr lock open } ;
allow shell newAttr33 : dir { ioctl read getattr search open } ;
[COLOR="Red"]allow shell newAttr33 : lnk_file { ioctl read getattr lock open } ;[/COLOR]
allow appdomain domain : process getattr ;
allow domain system_server : fd use ;
allow newAttr7 newAttr33 : file { ioctl read write getattr lock open } ;
allow newAttr7 newAttr33 : dir { ioctl read getattr search open } ;
[COLOR="Red"] allow newAttr7 newAttr33 : lnk_file { ioctl read getattr lock open } ; [/COLOR]
allow newAttr1 binderservicedomain : fd use ;
allow newAttr1 binderservicedomain : binder { call transfer } ;
allow appdomain system_server : fd use ;
allow appdomain system_server : fifo_file { ioctl read write getattr lock append open } ;
allow appdomain system_server : tcp_socket { read write getattr getopt shutdown } ;
allow appdomain system_server : unix_stream_socket { read write getattr getopt setopt shutdown } ;
allow appdomain newAttr33 : file { ioctl read write getattr lock open } ;
allow appdomain newAttr33 : dir { read getattr search open } ;
allow appdomain newAttr33 : lnk_file { read write getattr open } ;
allow appdomain system_server : binder { call transfer } ;
the lnk_file ones seem interesing, i'm not sure if write is the correct perm or if it's readwrite
using sepolicy inject i've been adding to that list like so
Code:
sepolicy-inject -s appdomain -t newAttr33 -c lnk_file -p write -P sepolicy -o sepolicy-UNdead
but nothing yet, as i go further i will learn more, i think it's finding out what need to be made permissive, getting a read on audit and allow rules don't seem to work, i'm using debian's sepolicy dev tools, as well as Miko's set, and the originating source for sepolicy-inject as well.
finding the permissions/av denial connected to daemonsu being prevented from changing dalvik-cache ownership is what i think i'm looking for
but i'm not 100% on that, though when i
Code:
chcon u:object_r:su_exec:s0 su
, i do get a denial in terminal when i reboot and run su, so i'm still uncertain if su is the culprit.
what makes you think su is the culprit, it is because 5.1.1?
jazzespresso said:
what makes you think su is the culprit, it is because 5.1.1?
Click to expand...
Click to collapse
well, su runs the daemon right the daemon and supolicy need root privelege to run and load
for the portion of the logcat, changing ownership in dalvik-cache fails because damonsu hijacks the app_process/32
changing ownership is the function of chown which needs root priveleges, that particular function happens after the init process,
the init process work with root privelege for the beginning stages of the boot process then lock down and throws over to the system,
without the system's su functioning that process of changing dalvik cache ownership fails and sigabrt , the system hangs.
the reason i'm not 100% sure it's su is because when i chcon app_process/32 -> /xbin/daemonsu to ubject_r:zygote_exec
then the process goes through so...
moonbutt74 said:
well, su runs the daemon right the daemon and supolicy need root privelege to run and load
for the portion of the logcat, changing ownership in dalvik-cache fails because damonsu hijacks the app_process/32
changing ownership is the function of chown which needs root priveleges, that particular function happens after the init process,
the init process work with root privelege for the beginning stages of the boot process then lock down and throws over to the system,
without the system's su functioning that process of changing dalvik cache ownership fails and sigabrt , the system hangs.
the reason i'm not 100% sure it's su is because when i chcon app_process/32 -> /xbin/daemonsu to ubject_r:zygote_exec
then the process goes through so...
Click to expand...
Click to collapse
re-moved
Jazz,
what i am actually going to say is;
pingpong root is a fail, i tried it a few days ago.
dumping general links into this thread is not help.
Linking DIRECTLY to kernel patches/mods etc., is better.
I am looking at the s6 source from the thread you linked to.
I don't think kernel version will make too much of a difference.
The interest, MY interest is in how to mod the default sepolicy to unbreak root.
I do NOT want permissive, i want enforcing with root functioning correctly.
I am getting a better hang of the sepolicy tools but have yet to find what needs changing adjusting
I did manage to disable [set permissive] the policy AND achieve root BUT with display,touch,input broken as before. [grumble]
In the furture please remove quoted text when you reply to post. Thanks.
m
moonbutt74 said:
Jazz,
what i am actually going to say is;
pingpong root is a fail, i tried it a few days ago.
dumping general links into this thread is not help.
Linking DIRECTLY to kernel patches/mods etc., is better.
I am looking at the s6 source from the thread you linked to.
I don't think kernel version will make too much of a difference.
The interest, MY interest is in how to mod the default sepolicy to unbreak root.
I do NOT want permissive, i want enforcing with root functioning correctly.
I am getting a better hang of the sepolicy tools but have yet to find what needs changing adjusting
I did manage to disable [set permissive] the policy AND achieve root BUT with display,touch,input broken as before. [grumble]
In the furture please remove quoted text when you reply to post. Thanks.
m
Click to expand...
Click to collapse
sorry....removed the links and references on my previous post....
jazzespresso said:
sorry....removed the links and references on my previous post....
Click to expand...
Click to collapse
Jazz,
security: SELinux: Avoid enabling enforcing by conventional flag
as to this https://github.com/djvoleur/V_925R4_BOF7/commit/3e33f1fb5538fb2f0f055e9035fe8885a3471322
i'll give it a try and see what happens, but i still want sepolicy enforcing.
@jazzespresso
EDIT - okay i tried it out straight and no-go, but looking at the diff between our selinuxfs.c
and the one you linked to i see that we have a compile/build flag
#ifdef CONFIG_ALWAYS_ENFORCE
//If build is user build and enforce option is set, selinux is always enforcing
new_value = 1;
[blah blah blah]
selinux_enforcing = new_value;
there's some more but i think you get the idea of where i'm going with this.
the new_value change has been used before to success so it will work with our kernel source,
it's just a matter of getting it right. =]
Here is a little tutorial for disabling LG RCT (Root Checker Tool), this currently has not much use for the avg. user since it does not impact performance as far as i know, but this might help other Developers. This Requires the System Partition to be writable, e.g. with SystemRW tool.
Required:
Unlocked Bootloader (Obviously)
SystemRW Mod
Disable DM-Verity (AVB) (Will be disabled by the SystemRW Mod)
Part 1:
1. adb shell, pm uninstall -k --user 0 com.lge.rctprovider
2. adb reboot bootloader, Fastboot erase rct
Reboot to System
3. adb shell, pm uninstall -k --user 0 com.lge.srtc
4. Edit /system_ext/etc/init/init.lge.system_ext.service.rc (copy to storage, rename to txt and remove that completely:
########################################
# LG RCT(Rooting Check Tool)
########################################
service rctd /system_ext/bin/rctd
class late_start
user root
group root
seclabel u:r:rctd:s0
)
5. Remove .txt extension and copy back to original place (Keep old permissions on file: rw-r--r--) and reboot
Now the RCT Service is stopped.
--------------------------------
Part 2:
1. Delete /system/system_ext/app/RctProvider Folder and /system/system_ext/bin/rctd file
2. Delete /mnt/Product/Persist-LG/RCT Folder
Done, how to check if it is disabled? "Adb shell", "su" and "getprop | grep rct". If it shows nothing as output that means the service is not running. After that check the service menu *#546368#*600# > SVC Menu > LG RCT (Has to say Disabled)
Credits to Th3-Hunter333 (ps3hacker3 on XDA) and Leronex (Leronex_1 on XDA)
how to do
怎么弄
Thanks a lot for the guide!
I don't have a linux workstation around and decided to edit the init.lge.system_ext.services.rc file and copy it back using Total Commander. Total Commander can remount the file system as r/w, but for whatever reason any file I create in /system/etc/init has "0" size. I tried to save init.lge.system_ext.services.rc under a different name in the same folder and it became empty. I can delete or create a new file but all my files have zero size.
I also tried to remount the /system as r/w using "mount -o rw,remount /" command from adb shell. It sort of works, I can change the permissions for files and folders but again, I can't edit files. I even tried vi editor from the adb shell (busybox vi ...) and while it doesn't complain about the r/o file I still can't add anything to it.
Here is a result of the "ls -la" command after I changed permissions to 777 for init.lge.system_ext.services.rc
-rw-r--r-- 1 root root 0 2008-12-31 16:00 init.lge.system.on_post_fs.rc
-rw-r--r-- 1 root root 429 2008-12-31 16:00 init.lge.system.on_post_fs_data.rc
-rw-r--r-- 1 root root 260 2008-12-31 16:00 init.lge.system.on_property.rc
-rwxrwxrwx 1 root root 0 2021-12-07 16:19 init.lge.system.services.rc
-rw-r--r-- 1 root root 4674 2008-12-31 16:00 installd.rc
-rw-r--r-- 1 root root 1104 2008-12-31 16:00 iorapd.rc
Just wondering if anyone have a solution to that. Thank you.
G0bl1n said:
Thanks a lot for the guide!
I don't have a linux workstation around and decided to edit the init.lge.system_ext.services.rc file and copy it back using Total Commander. Total Commander can remount the file system as r/w, but for whatever reason any file I create in /system/etc/init has "0" size. I tried to save init.lge.system_ext.services.rc under a different name in the same folder and it became empty. I can delete or create a new file but all my files have zero size.
I also tried to remount the /system as r/w using "mount -o rw,remount /" command from adb shell. It sort of works, I can change the permissions for files and folders but again, I can't edit files. I even tried vi editor from the adb shell (busybox vi ...) and while it doesn't complain about the r/o file I still can't add anything to it.
Here is a result of the "ls -la" command after I changed permissions to 777 for init.lge.system_ext.services.rc
-rw-r--r-- 1 root root 0 2008-12-31 16:00 init.lge.system.on_post_fs.rc
-rw-r--r-- 1 root root 429 2008-12-31 16:00 init.lge.system.on_post_fs_data.rc
-rw-r--r-- 1 root root 260 2008-12-31 16:00 init.lge.system.on_property.rc
-rwxrwxrwx 1 root root 0 2021-12-07 16:19 init.lge.system.services.rc
-rw-r--r-- 1 root root 4674 2008-12-31 16:00 installd.rc
-rw-r--r-- 1 root root 1104 2008-12-31 16:00 iorapd.rc
Just wondering if anyone have a solution to that. Thank you.
Click to expand...
Click to collapse
You didn't read the tutorial, the system NEEDS to be R/W before you do it.
Leronex_1 said:
You didn't read the tutorial, the system NEEDS to be R/W before you do it.
Click to expand...
Click to collapse
Oh I did read it, just was wondering if I can find a way around.
But from the file system perspective I don't understand how I can create an empty file or delete it but in the same time can't update the content.
What I did actually killed the RCT service, while it also killed a couple of other (useful) services listed in the services.rc. file. The phone works OK so far, I don't see anything strange though. I do have a copy of the original file and will copy it back once I have a linux setup on my PC.
Can someone upload the text for init.lge.system_ext.services.rc I accidentally deleted the whole thing when I saved.
I don't have com.lge.srtc
is it different on the verizon version?
Assasinx54 said:
Can someone upload the text for init.lge.system_ext.services.rc I accidentally deleted the whole thing when I saved.
Click to expand...
Click to collapse
here's mine
Code:
########################################
# CAPP_NFS
########################################
service nfsserversetup /system/bin/nfsserversetup
class late_start
user root
oneshot
########################################
# CAPP_MPROFILER
########################################
service lgprofd /system/bin/lgprofd
socket lgprofd stream 666
########################################
# CAPP_NFS
########################################
service nfskill /system/bin/nfskillprocess
disabled
oneshot
user root
on property:vold.decrypt=trigger_shutdown_framework
start nfskill
########################################
# bugreport is triggered by holding down volume down, volume up and power
########################################
service bugreport /system/bin/dumpstate -d -p -B -z \
-o /data/user_de/0/com.android.shell/files/bugreports/bugreport
class main
disabled
oneshot
keycodes 114 115 116
########################################
# LG RCT(Rooting Check Tool)
########################################
service rctd /system_ext/bin/rctd
class late_start
user root
group root
seclabel u:r:rctd:s0
########################################
# [email protected] fota
########################################
service uncrypt-fota /system/bin/uncrypt --fota
class main
socket uncrypt stream 600 system system
disabled
oneshot
service uncrypt-lcdoff /system/bin/uncrypt --lcdoff
class main
socket uncrypt stream 600 system system
disabled
oneshot
########################################
# LGP_DATA_DSQN
########################################
service dsqn /system_ext/bin/dsqn
disabled
user root
on property:persist.product.lge.data.dsqn=1
start dsqn
on property:persist.product.lge.data.dsqn=0
stop dsqn
########################################
# LGP_DATA_TCPIP_MPTCP
########################################
service socks /system_ext/bin/redsocks -c /system_ext/etc/redsocks.conf
disabled
user root
on property:product.lge.data.mptcp.enabled=1
start socks
on property:product.lge.data.mptcp.enabled=0
stop socks
service socks-v6 /system_ext/bin/redsocks-v6 -c /system_ext/etc/redsocks_v6.conf
disabled
user root
on property:product.lge.data.mptcp.enabled=1
start socks-v6
on property:product.lge.data.mptcp.enabled=0
stop socks-v6
########################################
# [email protected] ModemBSP
########################################
#LGE_CHANGE_S, Advanced MOCA, [email protected]
service moca_service /system_ext/bin/advanced_moca -s
class late_start
user root
group system sdcard_r sdcard_rw radio misc bluetooth
disabled
oneshot
socket Full.MOCA.port stream 660 system system
on property:persist.product.lge.service.moca.enable=1
start moca_service
on property:persist.product.lge.service.moca.enable=0
stop moca_service
#LGE_CHANGE_E, Advanced MOCA, [email protected]
Thanks dude I ended up reflashing the stock rom and rerooting. The problem was my device doesnt have R/W access. Im working with the guy that made the r/w script to get it working on the verizon v60
Assasinx54 said:
Thanks dude I ended up reflashing the stock rom and rerooting. The problem was my device doesnt have R/W access. Im working with the guy that made the r/w script to get it working on the verizon v60
Click to expand...
Click to collapse
are you getting
Code:
systemrw: Error! failed to create super_fixed.img file. Error code: 73
Yes error 73 is normal. I actually have created a better tutorial for this and I'll be updating it today.
I don't have a /system_ext
I do have a /system/etc/init
but I don't have init.lge.system_ext.service.rc
On v60_TMO that was crossflashed from v60_AM, I did the system_rw mod.
I was trying to follow the instructions here and ran the uninstall.sh from here, but that didn't work for me either.
*Edit: I found that the file for mine is /system/etc/init/init.lge.system.services.rc
I also don't have the directories from part 2, but part 1 seems to have *stopped the rct service.
deathglass said:
I don't have a /system_ext
I do have a /system/etc/init
but I don't have init.lge.system_ext.service.rc
On v60_TMO that was crossflashed from v60_AM, I did the system_rw mod.
I was trying to follow the instructions here and ran the uninstall.sh from here, but that didn't work for me either.
Click to expand...
Click to collapse
The uninstall.sh script in that repo is for removing the Magisk module. Does the Magisk module not work?
null-dev said:
The uninstall.sh script in that repo is for removing the Magisk module. Does the Magisk module not work?
Click to expand...
Click to collapse
I have no idea what the script was supposed to do (as far as rct goes), was just trying to follow the instructions. It said "Download and install the Magisk module (with a link to your disable magisk script), then reboot phone"
deathglass said:
I have no idea what the script was supposed to do, was just trying to follow the instructions.
Click to expand...
Click to collapse
The instructions say to install a Magisk module though, did you do that and it still didn't work?
null-dev said:
The instructions say to install a Magisk module though, did you do that and it still didn't work?
Click to expand...
Click to collapse
Oh, I didn't realize that magisk module meant through the Magisk app. I installed it and everything seems to be working, thank you.
Step-by-step worked for me, but local banking app still detecting root
dangtoi1993 said:
Step-by-step worked for me, but local banking app still detecting root
Click to expand...
Click to collapse
This is not how you bypass that
Leronex_1 said:
This is not how you bypass that
Click to expand...
Click to collapse
So there is anyway to pass safetynet while keeping root?
dangtoi1993 said:
So there is anyway to pass safetynet while keeping root?
Click to expand...
Click to collapse
Google "bypass safetynet root"