Related
@Cpasjuste,
In the image headers I noticed that the ramdisk and tag addresses have changed.
ramdisk addr: 0x02000000 -> 0x01000000
tags addr: 0x01e00000 -> 0x00000100
Please correct me if I'm wrong...
The bootloader (lk) loads the ramdisk and kernel tags (device tree) at these physical RAM locations.
@ggow
Yes i saw that but it have no effect. I'm focusing on the .dt part because I found a few things :
- The DT images can correctly be extracted with a tool named "mkboot".
- When using the DT image from kk kernel, the bootloader complains about DT not found (fastboot boot boot.img)
- Opened both DT image in hex editor, noticed some differences in the headers. I switched kk DT headers by jb DT headers, the bootloader don't complain
anymore so I guess it can now found it. But the kernel will just hang immediately.
- The DT syntax seems to have changed (arch/arm/boot/dts/thor.dtsi), this may be the problem for our old bootloader ?!
- Now I'd like to use compiled dt from kk kernel, but has you may have noticed the DT compilation fail about "fb_mem" not declared. I think I need to fix this, then maybe use old jb tools ( $KERNEL_OUT/scripts/dtc/dtc -p 2048 -O dtb -o thor-v1.dtb arch/arm/boot/dts/thor-v1.dts) to compile them, unlike kk kernel which now compile them with the kernel.
From what iv read dt, kernels and bootloaders are linked together, so there is also maybe some changes to be done in the dt sources. But this start to be out of my knowledge.
I asked to hashcode for that but I guess he is very busy.
Cpasjuste said:
@ggow
Yes i saw that but it have no effect. I'm focusing on the .dt part because I found a few things :
- The DT images can correctly be extracted with a tool named "mkboot".
- When using the DT image from kk kernel, the bootloader complains about DT not found (fastboot boot boot.img)
- Opened both DT image in hex editor, noticed some differences in the headers. I switched kk DT headers by jb DT headers, the bootloader don't complain
anymore so I guess it can now found it. But the kernel will just hang immediately.
- Now I'd like to use compiled dt from kk kernel, but has you may have noticed the DT compilation fail about "fb_mem" not declared. I think I need to fix this, then maybe use old jb tools ( $KERNEL_OUT/scripts/dtc/dtc -p 2048 -O dtb -o thor-v1.dtb arch/arm/boot/dts/thor-v1.dts) to compile them, unlike kk kernel which now compile them with the kernel.
From what iv read dt and kernels are linked together, so there is also maybe some changes to be done in the dt sources. But this start to be out of my knowledge.
Click to expand...
Click to collapse
I noticed the "fb_mem" not declared error and couldn't find any reference to it anywhere. I switched the dt.img header also and got to the point where the kernel was not dumping out to fastboot any more, but instead bootloops.
I have messaged amazon once again to post the source code for apollo and thor for update .4.1.1 .
Hehe we are at the same point it seems (nowhere)
Today I did spent a lot of time on this. After a lot of dt hacks/test I'm unable to resolve this problem for now. So I had another idea and started to port kexec hardboot for our device. I'm at the point where is successfully load kernel and DT (something is different for our device, the msm_id struct, which I solved) and reboot but will hang or restart just after a few seconds of the reboot. I think I'm almost there but I may have some problem to find correct memory addresses which are not overwritten by the boot loader. Let me know if you want to take a look I'll upload patches. But well even if we succeed we may still encounter the same DT problem.
In the "dt.img" there is 3 dtb files in, which are scanned by the bootloader for the correct hw revision. I did find that our device use the "thor-v2-apq.dts/.dtb" dt file for booting (not the thor-v1 nor v2) which correspond to our hardware revision. This is in correlation to the 4.1 kernel which only compile this dtb.
When loading the 4.1 dt image with kexec I was able to debug and see that while the header of each dtb parts have changed, there's still the correct hw revision included (of course!?). This one is correctly loaded by kexec and so probably by the bootloader (but in the new dt.img we still need to modify the img header for our bootloader to find it). By the way, I wonder how this final dt.img is built !?
I just don't know yet what is the thor.dtsi file in the 4.1 kernel, the one missing the fb_mem def. This is not included in the dt.img so should it be modified to match our old thor-v2-apq.dts instead the new one ?
By the way manual compilation (and decompilation!) does work with the dtc utility (apt-get install device-tree-compiler).
Yes, upload the the patches for kexec. Definitely interested in taking a look. I have configured a kernel last night with kexec config enabled (great minds think alike)
This DT problem is troubling me. Perhaps not everything is included in this kernel for Apollo or Thor to boot.
I received a reply from amazon, they said they will post the missing source for the last 3 updates very soon (no idea of time frame).
Sent from my Full Android on C6603 using Tapatalk
I don't think the sources are the problem as we have it on stock 4.1 boot.img. I'll upload the patches tomorrow with a little briefing.
@ggow : 4.1.1 kernel booted (not from sources. As you noted this sources may be incomplete).
I'll post the kernel this night, with a clean 4.1.1 system if i have the time.
Cpasjuste said:
@ggow : 4.1.1 kernel booted (not from sources. As you noted this sources may be incomplete).
I'll post the kernel this night, with a clean 4.1.1 system if i have the time.
Click to expand...
Click to collapse
Good News, well done
ggow said:
Good News, well done
Click to expand...
Click to collapse
Finally, sorry for the delay So here is the modded 4.1.1 boot image. In short : binary extract correct dts from 4.1.1 stock dt image and happend it to 4.1.1 stock zImage.
Didn't had the time to finish my gapps rom based on 4.1.1 but should not be too long
http://android.mydedibox.fr/hdx/boot-4.1.1.img
Cpasjuste said:
Finally, sorry for the delay So here is the modded 4.1.1 boot image. In short : binary extract correct dts from 4.1.1 stock dt image and happend it to 4.1.1 stock zImage.
Didn't had the time to finish my gapps rom based on 4.1.1 but should not be too long
http://android.mydedibox.fr/hdx/boot-4.1.1.img
Click to expand...
Click to collapse
Good work looking forward to testing it out.
Sent from my Optimus G using XDA Free mobile app
cdub50 said:
Good work looking forward to testing it out.
Sent from my Optimus G using XDA Free mobile app
Click to expand...
Click to collapse
This is a wip for you. You need to wait for a root exploit on 4.1.1 for using it !
Cpasjuste said:
This is a wip for you. You need to wait for a root exploit on 4.1.1 for using it !
Click to expand...
Click to collapse
Ah gotcha. Hopefully that will be sooner than later.
Sent from my Optimus G using XDA Free mobile app
Cpasjuste said:
Finally, sorry for the delay So here is the modded 4.1.1 boot image. In short : binary extract correct dts from 4.1.1 stock dt image and happend it to 4.1.1 stock zImage.
Didn't had the time to finish my gapps rom based on 4.1.1 but should not be too long
http://android.mydedibox.fr/hdx/boot-4.1.1.img
Click to expand...
Click to collapse
Thanks for that
Which number dts is the correct one (there are 3). I need to do the same for Apollo...
ggow said:
Thanks for that
Which number dts is the correct one (there are 3). I need to do the same for Apollo...
Click to expand...
Click to collapse
From what i remember this is the third (which is thor-v2-apq.dtb)
Well, cm is still a ***** to get ported :/, tree days on it without success.
Else the new odex framework is not deodexable by baksmali. If you ever have a solution let me know (You may not need that but I'm in a dead end).
So @ggow, did you made some progress on resurecting your device ?
In the meantime i did get msm aosp up and running ! (but no wifi, qcmediaplayer not found for no apparernt reason which prevent some audio to work, slow ui transitions and probably more stuff to fix).
Cpasjuste said:
So @ggow, did you made some progress on resurecting your device ?
In the meantime i did get msm aosp up and running ! (but no wifi, qcmediaplayer not found for no apparernt reason which prevent some audio to work, slow ui transitions and probably more stuff to fix).
Click to expand...
Click to collapse
So far no...
What I think could have happenned is the synaptic dsx firmware and configuration has been updated or corrupted by the new kernel.
I am in the process trying to figure out exactly what I need to do to fix it. I have found a utility which can be used to force an update to an older version of synaptic firmware.
I might have to write a utility to extract the firmware and configuration area from a working device.
Will let you know what I find.
Sent from my Kindle Fire HDX 7 using Tapatalk
ggow said:
So far no...
What I think could have happenned is the synaptic dsx firmware and configuration has been updated or corrupted by the new kernel.
I am in the process trying to figure out exactly what I need to do to fix it. I have found a utility which can be used to force an update to an older version of synaptic firmware.
I might have to write a utility to extract the firmware and configuration area from a working device.
Will let you know what I find.
Sent from my Kindle Fire HDX 7 using Tapatalk
Click to expand...
Click to collapse
Yep i was just going to talk you about this. I'm trying to fix wifi on the aosp build and discovered this lines in dmesg :
<6>[ 6.404807] synaptics_dsx_i2c 2-0020: fwu_start_reflash: Requesting firmware image Synaptics.3.B.thor.img
<6>[ 6.414184] synaptics_dsx_i2c 2-0020: Firwmare size 45056, config size 512
<6>[ 6.421216] synaptics_dsx_i2c 2-0020: Device firmware id 1509905.
<6>[ 6.427045] synaptics_dsx_i2c 2-0020: Device config ID 0x13, 0x07, 0x00, 0x02
<6>[ 6.434233] synaptics_dsx_i2c 2-0020: .img config ID 0x13, 0x07, 0x00, 0x02
<6>[ 6.441127] synaptics_dsx_i2c 2-0020: Nothing needs to be updated
<6>[ 6.447230] synaptics_dsx_i2c 2-0020: fwu_start_reflash: No need to do reflash.
Click to expand...
Click to collapse
Thank you for your work! I hope your problem will spill over into different firmware for our device. With the support of LTE I hope.
After a bit of tinkering and some insight from Chainfire and imoseyon i was finally able to get SuperSU working on AOSP roms without being permissive or having to use Chainfire's prebuilt sepolicy
sepolicy patch is here: https://github.com/PureNexusProject...mmit/0f5072de4580a5db7348917e77e4c1c35d3e3c1a
Stickied.
sorry to be that guy, but how does this affect the average joe?
does it mean theres going to be a new version of supersu with this or does this mean that custom rom makers can use this patch to make there roms not need the the custom boot.img?
WarningHPB said:
sorry to be that guy, but how does this affect the average joe?
Click to expand...
Click to collapse
It doesn't, this is for ROM devs only, they know what to do with this.
Chainfire said:
It doesn't, this is for ROM devs only, they know what to do with this.
Click to expand...
Click to collapse
Welcome back! Hope you had a good break.
Chainfire said:
Stickied.
Click to expand...
Click to collapse
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
BeansTown106 said:
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
Click to expand...
Click to collapse
There is no such thing now as "all current root apps working".
If SuperSU's deamon can be launched, and it can in turn launch the supolicy tool, most of the rules from the diff will be modified by SuperSU as needed.
What your patch needs to do (and you have already done) is make sure SuperSU can be launched in the right context, and can modify the sepolicy. You do not need to implement those 300+ additions - it will be done at boot automagically.
As for those additions themselves, they are primarily needed to:
- make sure SuperSU can work, internal communications between the different processes and such
- make processes running as the "init" context (where root apps run by default) as powerful as possible
- specifically "allow" a number of things that would otherwise still work, but would be logged (everything that starts with "allow init" or "allow recovery")
Now, even with the above, still not everything works out of the box. Everything that goes from "init" to "non-init" context should already work, but going from "non-init" context to "init" may not. In your example case, we go from "logd" to "init", which isn't specifically allowed. Often apps can be fixed to work around an issue such as this.
Generally speaking, the solution is not to fix the source sepolicy or the supolicy tool, the solution is for the "logcat extreme" app to run the following at launch (as documented in How-To SU):
Code:
supolicy --live "allow logd init fifo_file { read write }"
In this specific case, maybe it could be added to supolicy, it depends on what exactly generates the audit. If it's a simple logcat command, it's a candidate for inclusion. The problem might even be solved by switching contexts rather than modifying any SELinux policies. But that is something for the app developer to figure out.
In either case, it is not something you need to fix in the AOSP patches. Those already do what they need to do.
Since they started doing SELinux Enforcing though, the policies in AOSP have generally been a tad stricter than on retail devices (this was specifically the case during 4.4 days). This may lead to you sometimes having to add/remove a rule manually somewhere that was not added to SuperSU yet. It could happen, but it's unlikely, probably temporary, and it probably should not go into this AOSP patch.
A note on pof's sediff, I'm not sure it was done cleanly, as I see some modifications in there that are not done by supolicy. Either way, such a post is informative, not leading, as supolicy may do more or less modifications depending on various runtime variables (such as Android version). Additionally, due to context names and availabilities changing between Android versions, any rule modification referencing a context not available in the to-be-patched sepolicy will not be applied, and thus will not show up in an sediff.
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Chainfire said:
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Click to expand...
Click to collapse
thanks for the description above now i understand. have never developed a root app so i had not read that part of how to su, but it makes perfect sense that the root apps would handle the denials live via your supolicy
as for system less root i have not tried that yet but i will give it a shot tonight, and report back, i know some people in my ROM thread have used system less root. but i am not sure if you had packaged your sepolicy in the install script for 2.61+ and if it is overwriting mine in the kernel, if that is the case i will modify the installation to not patch the sepolicy and see if it works with my pre compiled one based on the source above
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Chainfire said:
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
Click to expand...
Click to collapse
will build and test with only load policy enabled, is this for system, and systemless root?
danieldmm said:
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Click to expand...
Click to collapse
updated link, so your saying systemless supersu works with no selinux modifications?
BeansTown106 said:
updated link, so your saying systemless supersu works with no selinux modifications?
Click to expand...
Click to collapse
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
danieldmm said:
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
Click to expand...
Click to collapse
that is why, these patchs are to allow you to run in enforcing
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Garzla said:
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Click to expand...
Click to collapse
Try the following. It works for me when needed...
http://forum.xda-developers.com/showthread.php?t=3574688
Thank you for your work!
Link in OP its no longer working...
Is there any actual guide how to add SU directly to AOSP build. I have found bits and pieces but those are mainly 4.x releases.
I'm using Android M release and quite much struggling to get it working.
I have tried to make SU default on AOSP 6.0 by using this guide.
http://forum.khadas.com/t/gapps-and-su-on-soc/118/3
I'm using user build and enabled selinux permissive on that.
i have made also ro.secure=0 ro.debuggable=1 and security.perf_harden=0 (Not sure if needed)
I have also modified to change the su permissions in fs_config.c
I managed to get this work so that when flashing rom SuperSu ask for updating su binary and after that su works.
but i then cleaned work area to verify build by deleting out dir and recompiled. No go anymore.
Why it's so hard to add su by default on AOSP rom. I woud like to have it by default so i would not need to do any tricks everytime i flash new rom.
It reminds me of Korean dramas ,
THIS THREAD IS FOR DEVELOPERS ONLY. IF YOU ARE NOT A DEVELOPER (or very tech-savvy and well-versed), MOST LIKELY YOU SHOULD NOT POST HERE.
By request, I am creating this thread for developer discussion. This is the place for developers to ask questions about how to handle/implement/embed SuperSU, discuss the operation of SuperSU, suggest improvements to compatibility, etc.
This thread hopefully reduces important developer related matters from being buried in the more user-oriented threads.
Please always include the version number of SuperSU you are referring to, even if it's the latest version right now. If applicable, also include information about phone and firmware you are testing with.
Chainfire said:
The stop-gap solution is to disable this caching completely, which is what the 000000deepsleep script does, which you can find mentioned or quoted in many posts around the forum. From SuperSU 2.66 onwards, that script is automatically installed on Samsung devices when systemless root is used.
Click to expand...
Click to collapse
Please forgive me for posting (in a cf-auto-root thread) and digging afterwards. I had thought I'd just dump the info and forget about it, but I couldn't stop digging...
...which led me to the quoted material.
Digging in the supersu 2.66 update-scriptbinary, I see that you're detecting "samsung" in the build fingerprint, and if true, doing a systemless install AND applying a deepsleep fix. This works for Galaxy S6 devices, but not for some other similar platform devices. In particular, the Note5 has THREE devices that need caching disabled in order for deep sleep to function. (0:0:0:3 as well as :2 and :1.)
My first question is: does the SGS6 even have a file named "/sys/class/scsi_disk/0:0:0:3/cache_type"? If not, just write to all three files and don't worry about it. The third write would fail on the SGS6 and all would be good. It'd be no worse of a work-around than already exists (and I think it's a bad work-around.)
If that file DOES exist in the SGS6, then something would have caching turned off that really shouldn't. Of course, existing or not, automatically tossing in this deepsleep patch for every single device that has "samsung" in the build fingerprint would seem likely break proper caching in some yet unknown samsung device. Perhaps the SGS7 will change things up so that :1 should be left cache flushable, and :2 would be the only one that should block cache flushing.
As well, it's also possible that Samsung will pull in the kernel fix to resolve this issue before they release Android M. (Okay, perhaps it'd be more likely for Samsung to open source touchwiz... but we can always have fantasies.)
My problem with the work-around is expressed above: it can break something in the future (and cause a support headache when some ONE exynos7420 device is fixed, but the rest aren't.) As well, it sets precedent of having platform specific hacks in the generic update.zip (but only allowing for a single platform and not in an easily expandable way.)
Obviously, it would be a maintenance nightmare to have different "00000deepsleep" files for every different device model. (if 'zerolte.*', SGS6. If 'nobellte.*', Note5, etc.)...
In keeping with what I tell other people, I feel I now have an obligation to suggest A Better Way. (a person shouldn't complain about something unless they can make a reasonable suggestion on how it'd be better.)
So, here's my slightly convoluted (but expandable) suggestion:
You currently use /data/.supersu to read certain variables that modify the supersu.zip installer script. Perhaps those "platform specific lines" could be added to that file, and the installer script would put them in place. So, I could do the following in a recovery root shell before installing supersu.zip:
Code:
echo PLATFORMSTARTUP='echo "temporary none" > /sys/class/scsi_disk/0:0:0:1/cache_type' >> /data/.supersu
(I'd have included both (or all three) needed lines for samsung deep sleep, but I forget how to include CR in a shell cmdline.. )
Then, the supersu installer script would just read PLATFORMSTARTUP and write it's contents to /su/su.d/00000platformstartup (and set perms.)
Given this type of thing, the existing 000000deepsleep hack would be removed. Then, individual devs could easily create simplistic "pre-installers" for supersu for specific platforms that need changes. Those "pre" installers would just write the needed PLATFORMSTARTUP lines to /data/.supersu...
... and then supersu.zip no longer needs platform specific hacks.
Some random XDA developer could then generate a simple "SGS6-supersu.zip" would only contain an edify script to mount /data and add/edit the .supersu file's PLATFORMSTARTUP variable to contain the two lines needed for deep sleep (and another dev could write a Note5 for the 3 lines needed on that platform... and so on..)
Take care
Gary
garyd9 said:
You currently use /data/.supersu to read certain variables that modify the supersu.zip installer script. Perhaps those "platform specific lines" could be added to that file, and the installer script would put them in place. So, I could do the following in a recovery root shell before installing supersu.zip:
...
Click to expand...
Click to collapse
The only problem with that is that it requires users to have two brain cells to rub together. We've seen time and time again on these forums that you can't assume this is always the case.
I think that Chainfire is doing pretty much the right thing here. At worst, disabling write-back caching will make I/O a bit slower, but that's better than not having deep sleep. The only suggestion I'd have is to add more devices (maybe up to 5), and to check for their existence before writing to them.
NZgeek said:
The only problem with that is that it requires users to have two brain cells to rub together. We've seen time and time again on these forums that you can't assume this is always the case.
I think that Chainfire is doing pretty much the right thing here. At worst, disabling write-back caching will make I/O a bit slower, but that's better than not having deep sleep.
Click to expand...
Click to collapse
The problems with the existing solution are:
1. It blindly alters the system kernel behavior for every single device samsung manufactures.
2. It only actually does any good for a single one of the dozens of devices from that sam manufacturer.
3. It completely ignores every OTHER device that might need a bit of help (and potentially does more harm than good for those devices.)
4. It encourages device developers (users on XDA) to download SuperSU.zip and re-package it to have device specific hacks in the .zip archive (creating a mess.)
Actually, I don't think I need to explain all the problems with the existing hack. I'd imagine (hope) that it was done as something quick to test out an idea, and was never intended to be left in place in it's current form.
NZgeek said:
The only suggestion I'd have is to add more devices (maybe up to 5), and to check for their existence before writing to them.
Click to expand...
Click to collapse
Which 5 devices? Who maintains that list? Who updates it for each firmware change that might require an update? Will there be a new "SuperSU.zip" package each time a firmware change on a device requires that one of those 5 be changed? Who deals with the support nightmare of saying "use SuperSU v a.bc for device X firmwawre Y" and "superSU v d.ef for device X firmware Z", etc?
My proposed solution takes all the device-specific stuff completely out of the SuperSU package. It changes it from a device-specific solution to be a more generic and expandable solution that requires LESS support from SuperSU and places the device specific burden outside.
Instead of encouraging device developers to repackage supersu to device specific packages, it encourages device developers to package something else alongside supersu that would work with the existing (and unaltered) supersu.zip (and would be future compatible.)
Take care
Gary
spiral777 said:
would there be a way to get kexec/ multirom working with systemless root?
and would flashing a modified boot image to a rom also effect the kexec hardboot partch of the kernel?
Click to expand...
Click to collapse
1- the current versions of systemless root make changes/additions to the kernel, but you're not "flashing a modified boot img", so kexec is not broken, since the kernel is in essence the same as before
2- yes it is possible for systemless root (tested with 2.65) to get it working on multirom, however some changes were needed; we're still debugging the problem to try to narrow down the issue, to get it to work with as little changes as possible
EDIT: I'll just mention the problems encountered in case @Chainfire wants to be aware of them
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
c) the setprop sukernel.mount 1 (in launch_daemonsu.sh) doesn't trigger the mount properly, workaround was to mount it in the launch_daemonsu.sh using "mount -t ext4 -o loop /data/su.img /su" instead of the setprop
EDIT2: thanks @Captain_Throwback for the reminder
d) the attempted remount read-only, will cause a bootloop; workaround: had to comment that out
just FYI, but I'll check more thoroughly when I get a chance
@garyd9 @NZgeek
Some good points are raised. I am not going to go into them all individually.
There is one core point of disagreement though. While I do not think device-specific patches generally have a place in the SuperSU ZIP installer, the deep sleep issue affects so many million users it is too big to ignore. (By the way, as far as I know this issue affects all recent high-end Samsungs).
While I don't disagree with your ideal of custom pre/post installers, in reality most users will never discover the issue, and just blame SuperSU for suddenly bad battery life. This leads to many support emails, thread posts, bad rep, etc.
Contrast this to for example the LG G3 compatibility patch, which requires the user to indeed write a file to /data or use a pre-installer that does that, the device will simply not boot, which forces the user to either go back to stock, or search for and discover the fix.
Either way, you are right, the patch doesn't even work right for Note users. Thank you for pointing that out - nobody else ever did. I have come up with the following improved script. If for the moment, we put aside our differences regarding the inclusion of any device-specific fixes, what do you think of the following?
It will perform the cache_type change for any scsi_disk, but will skip the ones not set to write protected. This should catch the problem with devices that have a different disk layout, and prevent accidental reduced I/O speed for devices that are not affected.
Note that it is my understanding that the write protection mode cannot be reset without a flash chip power cycle, and as the protection is set by the bootloader long before our check, checking once at boot should suffice.
I would be grateful if you gave that a shot on an affected Note/Edge+ and report back. It successfully sets the cache_type for :1 and :2 on my S6.
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
fi
done
Chainfire said:
I would be grateful if you gave that a shot on an affected Note/Edge+ and report back. It successfully sets the cache_type for :1 and :2 on my S6.
Click to expand...
Click to collapse
I won't be able to properly test this until at least tomorrow (Wed) evening... However, in the meantime, the following screenshots suggest that it'd also work on the Note5:
https://goo.gl/photos/61JWzoA5ir3PcDNr9
(This is with a custom kernel, however. I'll post a query in the Note 5 section asking people who are running a stock kernel to run similar commands to post the output here: http://forum.xda-developers.com/showpost.php?p=64773152&postcount=138 - I'll relay the results.)
Let me know when you'd like to debate on if SuperSU should fix (non-root related) bugs in only specific devices, all devices, no devices, or if it should just support a hook to allow third parties to fix both current and future/past devices. (Please don't get the wrong impression from that statement. SuperSU is your product, not mine... However you implement things is up to you.)
Please do let me know if I can be of further assistance to fix compatibility.
nkk71 said:
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
Click to expand...
Click to collapse
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
Click to expand...
Click to collapse
Complete guesswork, but the backing file may need to be released for the loop device.
c) the setprop sukernel.mount 1 (in launch_daemonsu.sh) doesn't trigger the mount properly, workaround was to mount it in the launch_daemonsu.sh using "mount -t ext4 -o loop /data/su.img /su" instead of the setprop
Click to expand...
Click to collapse
Any idea why?
I'm specifically using the setprop / init.rc way because mount -o loop doesn't work on many firmwares.
d) the attempted remount read-only, will cause a bootloop; workaround: had to comment that out
Click to expand...
Click to collapse
Where is this?
Chainfire said:
Please do let me know if I can be of further assistance to fix compatibility.
Click to expand...
Click to collapse
Thank you, I will let you know once I've had a chance to properly debug further
I initially only wanted to get systemless root to work, which using the workarounds (even though not ideal), was proof it can be done
(at the time it was SuperSU v2.65)
Chainfire said:
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
Click to expand...
Click to collapse
No need to take double symlinks into account, only the real one is changed as follows:
the real one is renamed with a "-orig" extension, and a symlink is created to an imaginary normal file:
Code:
cd [B][COLOR="Blue"]/dev/block[/COLOR][/B]
ls -l
...
brw------- 1 root root 259, 24 Jan 12 18:18 mmcblk0p40
brw------- 1 root root 259, 25 Jan 12 18:18 mmcblk0p41
[B]lrwxrwxrwx 1 root root 67 Jan 12 18:19 mmcblk0p42 -> /realdata/media/0/multirom/roms/HTC_One_M8_GPe_Marshmallo1/boot.img[/B]
[B]brw------- 1 root root 259, 26 Jan 12 18:18 mmcblk0p42-orig[/B]
brw------- 1 root root 259, 27 Jan 12 18:18 mmcblk0p43
...
all other symlinks to the block device remain as is:
Code:
cd[B][COLOR="Blue"] /dev/block/platform/msm_sdcc.1/by-name[/COLOR][/B]
ls -l
...
lrwxrwxrwx 1 root root 21 Jan 12 18:18 adsp -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 20 Jan 12 18:18 board_info -> /dev/block/mmcblk0p3
[B]lrwxrwxrwx 1 root root 21 Jan 12 18:18 boot -> /dev/block/mmcblk0p42[/B]
lrwxrwxrwx 1 root root 21 Jan 12 18:18 cache -> /dev/block/mmcblk0p46
...
Chainfire said:
Complete guesswork, but the backing file may need to be released for the loop device.
Click to expand...
Click to collapse
Will check, thanks.
Chainfire said:
Any idea why?
I'm specifically using the setprop / init.rc way because mount -o loop doesn't work on many firmwares.
Click to expand...
Click to collapse
Not really, everything else in init.rc get's executed properly; (and obviously the in launch_daemonsu.sh as well)
Chainfire said:
Where is this?
Click to expand...
Click to collapse
at the beginning of launch_daemonsu.sh:
Code:
if [ ! -d "/su/bin" ]; then
# if we fstab'd system/vendor/oem to rw, remount them ro here
remount_ro /system
remount_ro /vendor
remount_ro /oem
^^ I commented all three of them out, which worked out fine.
MultiROM's secondary ROMs always have system mounted rw, and the above remount_ro will force an immediate reboot
I need to do further testing on these issues, as soon as I come up with something more concrete, I will report back.
EDIT: forgot to mention, can confirm this for the HTC One M7, M8 and M9
garyd9 said:
I'll post a query in the Note 5 section asking people who are running a stock kernel to run similar commands to post the output here: http://forum.xda-developers.com/showpost.php?p=64773152&postcount=138 - I'll relay the results.)
Click to expand...
Click to collapse
So, two replies. I've edited the results to just show the device and value of write_protect. The first one is a KNOX tripped device with completely stock firmware/kernel (no root):
Code:
scsi_disk/0:0:0:0 0
scsi_disk/0:0:0:1 1
scsi_disk/0:0:0:2 1
scsi_disk/0:0:0:3 1
The second is from a stock device where KNOX has never been tripped (the results are expected, but nice for confirmation):
Code:
scsi_disk/0:0:0:0 0
scsi_disk/0:0:0:1 0
scsi_disk/0:0:0:2 0
scsi_disk/0:0:0:3 0
So far, all indications are that the change suggested would work.
Can I have your permission to modify the superSU 2.66 archive to change the deepsleep script to use the script above and forward it to a couple people to validate? (Or, I can just wait until tomorrow night and do it on my own device.)
garyd9 said:
So far, all indications are that the change suggested would work.
Can I have your permission to modify the superSU 2.66 archive to change the deepsleep script to use the script above and forward it to a couple people to validate? (Or, I can just wait until tomorrow night and do it on my own device.)
Click to expand...
Click to collapse
Knock yourself out. I'm not in a rush though. I don't expect to release another update for another few days at least.
Chainfire said:
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
fi
done
Click to expand...
Click to collapse
Confirmed working for all cache_types 1,2 and 3 but sorry I have patched kernel myself to fix so I have tested reverse just to prevent kernel swap.
Code:
echo 'write back' > /sys/class/scsi_disk/$i/cache_type
and it was write back for all 3. Indeed four including cache_type 0.0.0.0 as well)
So if i had test with
Code:
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
then 0000 also get cached right?
It shouldn't be problem right? Just references to this post last line.
Regards
dr.ketan said:
Confirmed working for all cache_types 1,2 and 3 but sorry I have patched kernel myself to fix so I have tested reverse just to prevent kernel swap.
Code:
echo 'write back' > /sys/class/scsi_disk/$i/cache_type
and it was write back for all 3. Indeed four including cache_type 0.0.0.0 as well)
So if i had test with
Code:
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
then 0000 also get cached right?
It shouldn't be problem right? Just references to this post last line.
Regards
Click to expand...
Click to collapse
I don't know, since you changed it up, and your statement is a bit confusing.
Try this:
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo Write protected: $i
else
echo Write enabled: $i
fi
done
Copy/paste the output.
No problem. I will go to office in couple of hrs. Remove deep sleep fix from kernel and then test script as per said.
dr.ketan said:
No problem. I will go to office in couple of hrs. Remove deep sleep fix from kernel and then test script as per said.
Click to expand...
Click to collapse
That's not needed, just run the other script I pasted above. It'll show what we need to know regardless of your kernel being patched or not.
[email protected]lelte:/ $ su
[email protected]:/ # ls -l /sys/class/scsi_disk/
lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:0 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:1 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:1/scsi_disk/0:0:0:1lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:2 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:2/scsi_disk/0:0:0:2lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:3 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:3/scsi_disk/0:0:0:[email protected]:/ # cat /sys/class/scsi_disk/*/write_protect
0
1
1
1
[email protected]:/ #
dr.ketan said:
...
Click to expand...
Click to collapse
Seems fine!
I had some time to check a few things, so please find below my findings / possibly solutions
Chainfire said:
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
Click to expand...
Click to collapse
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
Click to expand...
Click to collapse
Fixed it by using the following code (perhaps the readlink -f is redundant, but it worked fine)
(at line 1199 of SuperSU 2.66 updater-binary):
Code:
if [ -b `readlink -f $BOOTIMAGE` ]; then
dd if=/dev/zero of=$BOOTIMAGE bs=4096
fi
Chainfire said:
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
Click to expand...
Click to collapse
Complete guesswork, but the backing file may need to be released for the loop device.
Click to expand...
Click to collapse
Turns out the loop device was in fact the problem; after umount /su, it still showed:
Code:
~ # [6n[B]losetup -a[/B]
losetup -a
/dev/block/loop0: 0 /data/su.img
so I just used/added (at line 1218 of SuperSU 2.66 updater-binary)
Code:
umount /su
[B]losetup -d /dev/block/loop0[/B]
I know it was on loop0 so I didnt need to account for anything else, but maybe using
Code:
LOOPDEVICE=`losetup -f`
or something similar, and continuing from there could be an option
Haven't tried checking on the other issues, but will report back when I have something on those
@Chainfire, early results on the deep sleep script change are 100% positive for both the Note5 and the edge+ devices.
nkk71 said:
I had some time to check a few things, so please find below my findings / possibly solutions
Click to expand...
Click to collapse
Thanks for the update. I'll have a look at those commands. losetup -f is specifically not used because I have already encountered devices/recoveries where the built-in losetup does not support this flag. So just loop0 and loop1 are tried, on failure, too bad (guess that could use improvement, hehe). The same goes for the -b test for if, and the -f flag for readlink. While I have not specifically tested the block device test, I know the symlink test fails on some devices. So I need to do some testing.
This is why some things in the ZIP are done is such weird ways instead of just using standard command, they're all work-arounds for encounted recovery versions that didn't support command X or flag Y ...
garyd9 said:
@Chainfire, early results on the deep sleep script change are 100% positive for both the Note5 and the edge+ devices.
Click to expand...
Click to collapse
Good news, as expected.
Any ideas how this could happen?
Update: Android attest key is lost when persist.sin partition is flashed.
Here is a screenshot of Service Menu -> Service tests -> Security soon after the XZ1c was bought. It reads:
Code:
Android Attest Key PROVISIONED
But now I have it like this (screenshot also attached):
Code:
Android Attest Key NOT PROVISIONED
Does it mean that my phone is no longer considered as unique and google play would consider it as a custom firmware not to be trusted or something like that?
Update: it can be used by a third party (for example play store) to check if your phone is still locked, without any chance to fake that due to use of cryptographic signatures and certificate chains in Trust Zone.
Please see post#98 for a "howto truly verify Android Attest Key working presence" including patched Auditor app that uses the key and following posts #99 till #102 showing various results including a trial to change something in a signed response, with conclusion in post#103:
j4nn said:
A phone with lost attestation key cannot be used by Auditor app as there is an exception right at start - documented already in post#30 in this thread.
And as discovered by @pbarrette (see post#13 here, thanks) the Android Attestation Key status in the service tests security screen can be made provisioned by simply creating of 5 empty files in keymaster64 directory - but that would not make the key working obviously.
Conclusion:
Android attest key might only be useful if bootloader is still locked to provide cryptographic proof of still locked verified boot untouched stocked firmware running on the phone.
If bootloader is unlocked, that key may be used by external party (play store for example) to easily detect unlocked state without any possibility to fake that due to certificate chains leading to google's root certificate, so they can easily check (outside of the phone) all the signatures of from the phone retrieved hw backed attestation data.
Click to expand...
Click to collapse
Please note, I did not unlock the bootloader (as documented by a current screenshot too).
It does not help to do a full factory reset.
It does not help to flash full firmware, not even the version which the phone was bought with (tried even keeping all files including all .ta for flashing with newflasher).
Does it mean my XZ1c lost (something like a drm) key from "hardware-backed key storage"?
Some details about the use seems to be here https://source.android.com/security/keystore/attestation.
This would be quite unfortunate to lose some keys even without unlocking
Done only few sony stock fw flashing via newflasher (I have attached log of the first flashing done for downgrade and a log of the last one trying to restore original fw fully) and some testing of user space apps via adb as described in this thread.
As a final restore attempt I let a FOTA system upgrade to run, it upgraded to 12.34 version, did a factory reset after that, but the attest key is still not provisioned there.
Any ideas what went wrong?
Particularly opinion of @munjeni would be interesting to me as his newflasher was used and the logs are available.
Could it be caused by something in the early fw to which the phone was flashed to (even though .ta files were skipped when flashing it)?
Or some issue with flashing procedure? At the first attempt I tried the initial prompt to backup ta, not sure, if it was safe (also visible in the log).
Thanks.
-- edit, added on 2018-10-28 --
There might be a chance to recover the Android Attest Key from a phone (xz1 compact or xz1) which still runs 47.1.A.8.49 or older fw.
Is here anybody with such phone? Still locked? With the Android Attest Key still PROVISIONED?
It may be possible to recover it from TA partition backup.
Anybody with such phone, contact me please, if willing to help me to test that.
Thanks.
You will need to backup your phone before the test - it would involve a downgrade of fw.
More info here please:
[DEVONLY][XZ1c] exploits for temp root to backup drm keys development
-- edit end, strike added on 2018-11-18 --
hello you have test flash reset .ta partition with flashtool ?
j4nn said:
Does it mean that my phone is no longer considered as unique and google play would consider it as a custom firmware not to be trusted or something like that?
Click to expand...
Click to collapse
No, loosing your TA partition only effects your Sony software, like the stock camera and a few higher functions.
It won't effect your Play store.
You can 'fix' the phone to think that it has the DRM keys (on the TA partition) and everything works as normal. You can even root your phone and still use android pay.
Yes, you've broken a part of your phone and you'll never ever get that back, but you're part of XDA and we're here to help you and fix it.
So what are the possible consequences of losing Android attest key provisioning? I'm interested because a method to backup the TA partition before unlocking bootloader might be coming soon, but it will require downgrading firmware and losing Attest key provision (read https://forum.xda-developers.com/xp...-exploits-temp-root-to-backup-t3795510/page20 )
Could it in any way cause the system to not pass SafetyNet?
I've lost my attest key when debranded my xz1,
Safety net check pass, I'm able to use Android pay and Pokemon go, also ota update still work
Sent from Italy by my xz1
I didn't realize the OP of this thread is the awesome developer of fw exploit trying to backup TA partition in the thread i linked. I'm totally going to donate to you j4nn, once the backup method is publicly released in detail. I'm just worried about this Attest key issue... I hope we all get an exhaustive answer!
In my case, I'm using a Xperia XA2 with locked bootloader, and changed my firmware customization... I changed from US to GEL and what is different is that SOMC Fido key is not provisioned.
@Meloferz, that is very surprising.
Just wondering, what does GEL customization stand for?
Could it be that for GEL region FIDO feature is not supported?
Maybe if you flash back to US the key might re-appear (if it was just disabled for GEL)?
j4nn said:
@Meloferz, that is very surprising.
Just wondering, what does GEL customization stand for?
Could it be that for GEL region FIDO feature is not supported?
Maybe if you flash back to US the key might re-appear (if it was just disabled for GEL)?
Click to expand...
Click to collapse
The GEL customization is for my region (Latin America), and is the first customization to get updates and with not US bloatware.
Maybe is not supported in my customization because we don't use contact less payments (at least in Paraguay, maybe in other countries of latam too I think?).
Didn't checked before I flashed the GEL customization, and didn't know on that time about FIDO, and others authentications
As updated the first post:
It would be great if there is anybody with a still locked XZ1c running 47.1.A.8.49 fw or any older and still having the Android Attest key in "provisioned" state. That is your either did not accept any OTA updates on purpose or you just bought the phone (and that fw version is pre-installed) - watch out not to accept any update in that case please.
Anybody please?
Hi @j4nn,
From what I can tell, the /vendor/bin/secd binary is making calls to QSEECOM via the tzxflattest TrustZone applet in order to determine the key provisioning status.
Additionally, it's looking in the /persist/data/keymaster64 directory for something. My keys are gone from my BL unlock, so I don't know what's supposed to be in there.
It's also getting the persist.keyprovd.attest.prov property to determine if it's set to true.
I haven't yet found where that property is getting set.
Hi @pbarrette, can you differentiate if that concerns Android Attest Key or just the two SOMC keys?
I've also looked into that secd, but I am not sure.
Anyway, it may be possible that at least those two SOMC keys are not erased from Trust Zone with unlock.
Instead it could be that they are just disabled with 'unlocked' flag, secd ignoring them, even though they may be available with restored device master key in TA.
This is something I would like to test currently with @tramtrist.
With Android Attest key it might be different as it is not connected to unlock.
j4nn said:
Hi @pbarrette, can you differentiate if that concerns Android Attest Key or just the two SOMC keys?
I've also looked into that secd, but I am not sure.
Anyway, it may be possible that at least those two SOMC keys are not erased from Trust Zone with unlock.
Instead it could be that they are just disabled with 'unlocked' flag, secd ignoring them, even though they may be available with restored device master key in TA.
This is something I would like to test currently with @tramtrist.
With Android Attest key it might be different as it is not connected to unlock.
Click to expand...
Click to collapse
Looking closer, the Android Attest key is looked up in the devsec_get_debugmenu_report() function.
The call looks like this:
Code:
LODWORD(reference_Var) = 1
int_AndroidAttestKey_Result = devsec_get_key_prov_status(3LL, &reference_Var);
android_PushString((__int64)&string_Stream, (__int64)" Android Attest Key", 20LL);
if ( !int_AndroidAttestKey_Result )
{
if ( (_DWORD)reference_Var )
{
str_ProvisionedText = "\tNOT PROVISIONED\n";
int_Result = 17LL;
}
else
{
str_ProvisionedText = "\tPROVISIONED\n";
int_Result = 13LL;
}
android_PushString((__int64)&string_Stream, (__int64)str_ProvisionedText, int_Result);
}
So it's calling the devsec_get_key_prov_status() function with param1=3 and param2=refVar.
That status function looks like this (condensed to the appropriate parts):
Code:
devsec_get_key_prov_status(__int64 result, _DWORD *a2)
v2 = a2;
case 3:
intptr_DirStream = opendir("/persist/data/keymaster64");
if ( intptr_DirStream )
{
int_LoopCounter = 0;
while ( 1 )
{
intptr_DirEntry = readdir(intptr_DirStream);
if ( !intptr_DirEntry )
break;
v28 = intptr_DirEntry + 19;
if ( (unsigned int)strcmp(intptr_DirEntry + 19, ".") && (unsigned int)strcmp(v28, "..") )
++int_LoopCounter;
}
result = closedir(intptr_DirStream);
if ( int_LoopCounter >= 5 )
goto LABEL_22;
}
else
{
v29 = "vendor/semc/system/core/libasb/security_daemon/backend/device_security/get_key_prov_status.cpp";
v30 = __strrchr_chk("vendor/semc/system/core/libasb/security_daemon/backend/device_security/get_key_prov_status.cpp", 47LL, 95LL);
if ( v30 )
{
v30 = __strrchr_chk("vendor/semc/system/core/libasb/security_daemon/backend/device_security/get_key_prov_status.cpp", 47LL, 95LL);
v29 = (const char *)(v30 + 1);
}
v31 = (unsigned int *)__errno(v30);
v32 = strerror(*v31);
result = androidLog2((__int64)"secd", 1, (__int64)v29, 0x4Fu, "failed to open %s dir, error %s", v33, v34, v35, v36, v37, v38, v39, v40, "/persist/data/keymaster64", v32);
}
break;
LABEL_22:
v15 = 0;
*v2 = 0;
goto LABEL_27;
LABEL_27:
result = v15;
return result;
The devsec_get_key_prov_status() function also handles cases 1 and 2, which do a property_get on persist.keyprovd.attest.prov (SOMC Attest Key) and persist.keyprovd.fido.prov (SOMC FIDO Key).
So the android attestation key report is related to having at least 5 files in /persist/data/keymaster64/.
I just tested that by creating a keymaster64 directory, creating 5x 0-byte files in that directory named 1, 2, 3, 4, and 5.
Now, if I go to the debug menu, it shows "Android Attest Key: PROVISIONED".
Obviously, that's not a very robust check for the debug menu to be making, so there must be files placed there by some other process and those files probably have some valid purpose.
That /persist mount looks interesting.
But not sure if the content is not generated somehow from TrustZone.
There are following directories in case of my xz1c:
Code:
/persist/data/tzattest/
/persist/data/fidocrypto/
/persist/data/wv/
The last one probably concerns widevine.
I am missing the /persist/data/keymaster64/ directory.
But if valid content from that directory would suffice to make the attest key available and usable, that would be another reason to try to retrieve those files from 47.1.A.8.49 fw or older via exploit.
With the help of Notepad++ and 7zip I searched for "attestation" and "keymaster64" in the firmware of my xz1 (downloaded with xperifirm).
There are reference to keymaster64 and key attestation inside keymaster_X_BOOT_MSM8998_LA1_1_O_82.mbn.
Looking better, probably this file contains the code that compares osVersion and osPatchLevel from tee with the osVersion and osPatchLevel from system image and read or write /persist/data/rsa_attest_key and /persist/data/ecc_attest_key
In system I found this file: https://gist.github.com/HandyMenny/a623cdcaf89c0aee7b3a91ed12c8dc4a
Here is another reference to key attestation: https://android.googlesource.com/pl.../master/keymaster/3.0/IKeymasterDevice.hal#42 and googling I found this log: https://pastebin.com/cRyYEtf2
Hoping to be helpful
j4nn said:
That /persist mount looks interesting.
But not sure if the content is not generated somehow from TrustZone.
There are following directories in case of my xz1c:
Code:
/persist/data/tzattest/
/persist/data/fidocrypto/
/persist/data/wv/
Click to expand...
Click to collapse
Can you check how it's mounted (/proc/mounts)? Is it a proper flash partition, not tmpfs or something like that?
I suppose anyone downgrading a virgin device should try avoiding to flash persist_*.sin (this .sin is small so probably just an empty fs), maybe the missing files are just placed there in the factory?
It is a proper flash it seems:
Code:
G8441:/data/local/tmp # mount | grep persist
/dev/block/sda33 on /persist type ext4 (rw,seclabel,nosuid,nodev,noatime,data=ordered)
G8441:/data/local/tmp # mount | grep ' /data'
/dev/block/sda66 on /data type ext4 (rw,seclabel,nosuid,nodev,noatime,discard,noauto_da_alloc,data=ordered)
G8441:/data/local/tmp # mount | grep ' /cache'
/dev/block/sda53 on /cache type ext4 (rw,seclabel,nosuid,nodev,noatime,discard,data=ordered)
But if it is part of fw package, would not it be flashed also with upgrade? Erasing /persist in all full firmware flash attempts?
That might rather indicate that the content may be generated if not yet existent (possibly from TZ).
Maybe we can check if it gets created new (aka binary different) with factory reset.
@pbarrette, that think with keymaster64 dir containing 5 empty files is nice, works on my locked xz1c too.
Nice find, still, definitely that would not make the key do what it should do. The question is if the android attest key is tied to device or not. But with this test we won't find out. Any idea for a better test?
If can be useful I have created an virtual image of from a Xperia companion firmware..., With all partition that can be mounted, but I don't remember what was in persists partion
You can do this by writing the partion file inside partion zip to a 64 gb image(created with truncate ) then this image can be mounted with losetup (Whit 4k sector size from kernel 4.18+)..
Then I restored every partition extracted from Sim to the virtual partion...
(PS. I know that you are aware of these command,but If you need to know what's inside a file use file and binwalk)
Sent from Italy by my xz1
j4nn said:
@pbarrette, that think with keymaster64 dir containing 5 empty files is nice, works on my locked xz1c too.
Nice find, still, definitely that would not make the key do what it should do. The question is if the android attest key is tied to device or not. But with this test we won't find out. Any idea for a better test?
Click to expand...
Click to collapse
I think this is all tied to Android Verified Boot.
The bootloader is apparently validating hashes in the cryptographically signed /dev/block/platform/soc/1da4000.ufshc/by-name/vbmeta (or /dev/block/sda57) partition.
I haven't had enough time to read through all the documentation. Most of it talks about using the vbmeta partition for rollback protection. The idea being that the bootloader can prevent boot completion if a rollback is detected. But I'm wondering if the vbmeta partition can be used for rollback detection and subsequent invalidation of the device attestation state, because Sony obviously isn't preventing rollback, or stopping the boot process.
Here's the main document from google.
Honestly, I'm not sure how important the SOMC FIDO/Attest and Android Attest keys are.
Google Pay seems to work. Fingerprint logins seem to work. Etc.
First, the details:
Phone: Samsung Galaxy S7 Sprint - Eng boot image flashed - Bootloader v4
The problem:
I have a script that I can hijack at boot, using the eng boot image allows me to have a root adb shell. I can place all necessary files needed for root and have done so. I can chcon the root files to match what they need to be.
I add the following to the boot script that the kernel runs:
Code:
./system/xbin/supolicy --live --sdk=26 > /dev/kmsg 2>&1 <---- This is where the errors happen.
./system/xbin/daemonsu --auto-daemon&
Everything runs but supolicy cannot open the target file. I know it exists because of the output from ls -l
I also know I am a root user in the script due to whoami returning root.
Code:
[ 82.936270] WHOAMI
[ 83.009546] ss_platform_log: [email protected]: Data SVC is acquired
[ 83.215499] root
[ 83.860941] -r--r--r-- 1 0 0 0 Jan 1 1970 /sys/fs/selinux/policy
[ 83.947108] supolicy v2.82 (ndk:arm64-v8a) - Copyright (C) 2014-2017 - Chainfire & CCMT\x0a
[ 83.947856] File [/sys/fs/selinux/policy] does not exist!
I can successfully use the adb shell with root access to execute supolicy and it works. So I have no idea what is going on. My only guess is selinux is preventing supolicy from accessing the file. But I thought changing contexts with chcon would fix that? EDIT: Current context of the hijacked script at boot: context=u:r:qti_init_shell:s0
If anyone can give me pointers, I sure would love that.
PS: I know I can root with the eng boot, but my attempt is to have supolicy working so I can flash the original boot img back due to eng boot consuming abhorrent amounts of ram. I also want stock kernel with supolicy working to allow viper4android to run.
elesbb said:
First, the details: Phone: Samsung Galaxy S7 Sprint - Eng boot image flashed - Bootloader v4..........
Click to expand...
Click to collapse
It looks like you may just need a Custom Kernel that's SEAndroid Capable which allows for the Sepolicy to be freely changed.
I don't have this device nor this Kernel but, it looks like the following thread may be helpful for what you need.
Note the phrase on the OP "Set SELinux to Permissive or Enforcing". Don't be afraid to ask for some member guidance within it.
https://forum.xda-developers.com/showthread.php?t=3462897
Good Luck!
~~~~~~~~~~~~~~~
UNLESS asked to do so, PLEASE don't PM me regarding support. Sent using The ClaRetoX Forum App on my Enigma Machine {aenigma = Latin for "Riddle"}.
Ibuprophen said:
It looks like you may just need a Custom Kernel that's SEAndroid Capable which allows for the Sepolicy to be freely changed.
I don't have this device nor this Kernel but, it looks like the following thread may be helpful for what you need.
Note the phrase on the OP "Set SELinux to Permissive or Enforcing". Don't be afraid to ask for some member guidance within it.
https://forum.xda-developers.com/showthread.php?t=3462897
Good Luck!
~~~~~~~~~~~~~~~
UNLESS asked to do so, PLEASE don't PM me regarding support. Sent using The ClaRetoX Forum App on my Enigma Machine {aenigma = Latin for "Riddle"}.
Click to expand...
Click to collapse
Hey! Thanks for the reply. Sadly I am on Sprint with the Sprint variant S7. This has a locked boot loader and I cannot use custom kernels. If so, I would have zero issues with root or selinux lol.
But, I did figure out it IS the context that the script I am hijacking is using that prevents the supolicy from finding the necessary file for patching. So, either I need to find another script, or I need to give up :crying:
elesbb said:
Hey! Thanks for the reply. Sadly I am on Sprint with the Sprint variant S7..........
Click to expand...
Click to collapse
I can't state anything that's device specific but, your situation is pretty much "in general terms" that applies to many/most devices in regards to what your trying to do.
The unfortunate situation you're in regarding the Locked Bootloader and such does prevent the ability for what your trying to do.
It's one thing to manually change to and from Enforcing and Permissive...
It's another thing for the ability to access the devices SEAndroid Policy freely in a type of "R/W Permission" (Modifiable) way.
Currently you are able to Change the SELinux State but, this is only a Temporary Change since it'll immediately default back when your device has rebooted.
As of right now, to my knowledge, you can't do what you are looking to do (unless there's something I'm missing or don't know about) but, you seem to have been pretty clear with the information that you had provided.
I hope that I had explained this okay via text...
Sorry for the bad news...
I do wish you the best of luck!
~~~~~~~~~~~~~~~
UNLESS asked to do so, PLEASE don't PM me regarding support. Sent using The ClaRetoX Forum App on my Enigma Machine {aenigma = Latin for "Riddle"}.
Hi,
try to switch selinux in permissive mode before you run your script.
So , you can log all the Selinux denied.