Database Info

[Q] NOOKcolor uRamdisk /init.rc changes, on a Mac?

Having run the AutoNooter 3.0.0 on my NOOKcolor, I find that the default settings for some system properties are rather undesirable. After a bit of digging, I find that they stem from commands in the /init.rc file. I can change that file, but since it is replaced on boot from a ramdisk image, I can't make a meaningful permanent boot change.
I understand the theory of using cpio to pack and unpack such an image, but (1) the uRamdisk image in AutoNooter includes lots of /dev nodes and I am leery of working with them in userland on my Mac and screwing it up for the final image, and (2) don't have a u-boot toolset to repack a new uRamdisk file.
Okay, the changes I want to make:
[A] Turn off USB Auto Mount:
- setprop persist.service.mount.umsauto 1
+ setprop persist.service.mount.umsauto 0
If both USB Mount and USB Debugging are enabled, then the first time the device is swiped, the USB Mount kicks in. Twice, for some reason on my 1.1.0 device. If the USB Mount is disabled, then ADB works fine and the user can always fiddle with these settings manually.
Make a non-uRamdisk hook for init.rc!
Have the /init.rc file call another /system resident script at the end, so that additional boot-time changes can be made by lowly tinkerers without fully recreating a whole new uRamdisk file every time.
Or am I missing something obvious I can already do, to avoid changing /init.rc file but still execute boot-time commands?

debug dsi request help (debug)

hi
i discovered a repeatable way to crash my phone.
i am curious if that is just my phone, or every xt720 behave the same.
the step to crash the phone (the phone will just harmless reboot) are:
1. obtain root access to the phone shell (suggested way is via "adb shell" )
2. mount the debugfs:
Code:
busybox mount -t debugfs debugfs /d
as d is symbolic link to /sys/kernel/debug the debug directory will be populated
3. (optional) make the screen off (e.g. tick on the power button, to make the phone sleep)
4. cat a dsi file:
Code:
cat /sys/kernel/debug/omapdss/dsi
the phone (at least my one) will reboot.
interesting is that, if the screen is on when issuing the cat command, the phone will survive
i am very curious if that is just my phone, so please, if and when you can, please test and give feedback.

peshovec said:
hi
i discovered a repeatable way to crash my phone.
i am curious if that is just my phone, or every xt720 behave the same.
the step to crash the phone (the phone will just harmless reboot) are:
1. obtain root access to the phone shell (suggested way is via "adb shell" )
2. mount the debugfs:
Code:
busybox mount -t debugfs debugfs /d
as d is symbolic link to /sys/kernel/debug the debug directory will be populated
3. (optional) make the screen off (e.g. tick on the power button, to make the phone sleep)
4. cat a dsi file:
Code:
cat /sys/kernel/debug/omapdss/dsi
the phone (at least my one) will reboot.
interesting is that, if the screen is on when issuing the cat command, the phone will survive
i am very curious if that is just my phone, so please, if and when you can, please test and give feedback.
Click to expand...
Click to collapse
Screen off, and issuing the command: phone rebooted
Screen on, and issuing the command: A list of parameters is spit out.
Looks as though it's not just your phone

nadlabak has been working on dsi fixes for A853. I've ported an older version of symsearch.ko, but dateno1 said the dsi-fix module didn't work. I don't understand the DSI stuff so I've been trying to port the overclock modules to use symsearch for our kernels. http://forum.xda-developers.com/showthread.php?t=1210819 Maybe nadlabak would know if this bug is related.

as I know, the dsi errors are "visible"in the dmesg output. I never saw such on my phone, and as I have regulars reboot, I watch for traces...
Sent from my Milestone XT720 using Tapatalk

[LINUX ONLY][ADB] ADB via USB for Trekstor Ventos 8

Hi,
finally I made it to get adb working on Linux without having to struggle with Moborobo
This will be of use only for a really SMALL part of the tablet users, but anyways - it is better to share every piece of knowledge than forgetting it without having told anyone...
So, this only works on Linux (who knows why not on Windows, but the tablets of Nook have the same problem):
You need a working connection to the internet for this! Also you need to be superuser for getting adb to work correctly
1. Download the android SDK for Linux: http://dl.google.com/android/android-sdk_r21-linux.tgz
2. Unpack it and go into your terminal
3. cd into the unpacked directory into the tools folder and type
Code:
$ su
# cd ./android
4. A new window opens. Wait until it updates what it needs to update. Then check only "platform-tools" and download it. When it finished, you can close the window
5. Then type:
Code:
# cd ../platform-tools/
# cp adb /bin/adb
# echo 0x4E22 > /root/.android/adb_usb.ini
# echo 0x1E68 >> /root/.android/adb_usb.ini
# adb kill-server
# adb start-server
# adb devices
And then you should see your device
Way better than doing adb over wifi (for file transmissions, too)
This should work also for many other devices which refuse to get working on Windows machines, the only difference is that you need to get the correct vendor ID from your device (connect it and then type lsusb. The result should be like yyyy:zzzz, to be sure, just add both values in UPPERCASE into adb_usb.ini:
Code:
# echo 0xyyyy > /root/.android/adb_usb.ini
# echo 0xzzzz >> /root/.android/adb_usb.ini
I know, it's a little noobish, but the important thing is that it works
Hope this helps anyone!
Regards

How to setup MTP under Ubuntu

This guide was created using information taken from:
http://bernaerts.dyndns.org/linux/247-ubuntu-automount-nexus7-mtp
http://www.webupd8.org/2012/12/how-to-mount-android-40-ubuntu-go-mtpfs.html
http://blog.itsbilal.com/index.php/...d-4-0-phonetablet-to-ubuntu-the-reliable-way/
and others. They show you how to determoine all the id information required to set up mtp mounting. This guide will just focus in on what you need to get your Asus TF700 connected.
Background:
Latest Android devices are using 2 different USB connexion modes : PTP and MTP.
With PTP mode, the tablet is seen as a digital camera. This is working Out Of The Box under Ubuntu 12.04. But, you can only access DCIM directory of your device.
With MTP mode, the tablet is seen as a multimedia device where you can access the complete exported filesystem. But it doesn't work Out Of The Box under Ubuntu. It needs some setup and configuration to work.
Note: Gvfs has been updated in Ubuntu 13.04 Raring Ringtail, bringing a new MTP backend which allows users to access Android 4.0 devices which do not support the USB Mass Storage. So this should work out of the box with Raring.
Even if you can access easily a MTP device thru a program called gmtp, it is not as convenient as a conventional USB mass storage, accessible directly from Nautilus.
This guide explains how to configure your Ubuntu computer to directly access your Asus TF700, exported filesystem in MTP mode as soon as you plug it to a USB port.
Thanks to some udev rules, your tablet will automatically mount when device is plugged in & unmount when device is unplugged.
This guide has been done for Asus TF700, but it should work with any other MTP device (Android phone or tablet, MP4 player, ...) if you adapt the Udev rules according to your device.
The Basic steps are:
1) Allow non root users to access root mounted filesystems
2) Install go_mtpfs
3) Configure udev rules to mount and unmount Android filesystems
Configuring FUSE:
Ubuntu doens't allow normal users to access fuse configuration file. This is a bug, which is quite easy to correct by giving read attribute to /etc/fuse.conf.
By default, fuse does not allow mounted filesystems to be accessed by anybody else that the user who has mounted it. As MTP filesystem will be mounted by root to be used by any user, we need to modify fuse default behaviour to allow it. This is configured by uncommenting the user_allow_other key in /etc/fuse.conf.
Code:
# sudo chmod a+r /etc/fuse.conf
# sudo gedit /etc/fuse.conf
Code:
/etc/fuse.conf
...
# Allow non-root users to specify the 'allow_other' or 'allow_root' mount options.
user_allow_other
Install go-mtpfs:
There are various programs to add support for mtp to Ubuntu. After trying a number of them I have found go-mtpfs works best for me. You certainly could install a different program and just adjust the guide to suit. Go-mtpfs is available in the WebUpd8 Unstable PPA, for Ubuntu 13.04, 12.10 and 12.04. Add the PPA and install it using the following commands:
Code:
# sudo add-apt-repository ppa:webupd8team/unstable
# sudo apt-get update
# sudo apt-get install go-mtpfs
If you are not happy with installing prebuild binaries from repositories, you can easily get the source from github and build it yourself.
Once that is done you need to create a mount point for your Android filesystems. I have chosen TF700 under /media. This mount point should be accessible by anybody as you will later mount the device using your user account.
Code:
# sudo mkdir /media/TF700
# sudo chmod 777 /media/TF700
Add the udev rules:
This is the core of making the auto mounting work. The first link I reference has all the information on how you discover the Vendor and Product ids. While it is interesting reading, I have just skipped over all that and supplied the TF700 specific values. If you are trying to setup another device you WILL NEED TO read it and get the appropriate values, as they are device specific.
Code:
# sudo gedit /etc/udev/rules.d/51-android.rules
Code:
# Asus TF700
SUBSYSTEM=="usb", SYSFS{idVendor}=="0b05", ATTR{idProduct}=="4c91", MODE="0666" #MTP media, USB debug on
# Asus TF700 MTP mode under JB 4.2+ : automatic mount & umount when plugged (USB debug on & off)
ENV{ID_MODEL}=="ASUS_Transformer_Pad_TF700T", ENV{ID_MODEL_ID}=="4c91", ACTION=="add", RUN+="/usr/bin/sudo -b -u YOUR_LOGIN /usr/bin/go-mtpfs -allow-other=true /media/TF700"
ENV{ID_MODEL}=="ASUS_Transformer_Pad_TF700T", ENV{ID_MODEL_ID}=="4c91", ACTION=="remove", RUN+="/bin/umount /media/TF700"
You need to change "YOUR_LOGIN" to your username.
Last thing is to restart udev for the new rules to become operationnal.
Code:
# sudo service udev restart
Declaration in /etc/fstab:
At this stage, you are able to automatically mount and unmount your TF700. Your device should appear after few seconds in Nautilus computer section.
You can now browse your device straight from Nautilus. You can copy files from and to your TF700, you can rename files, ...
You have to know that you will face some limitations as MTP is not a real filesystem protocol :
* you can not copy files bigger than 2 Gb,
* you can not create empty files,
* you can not move file within the phone with drag & drop
* you cannot open files in write mode directly from TF700
Another problem is that you can not unmount your TF700 straight from Nautilus. If you click on the Eject button, you will get an error message saying :
umount: /media/TF700 is not in the fstab (and you are not root)
To solve that, it has to be declared in /etc/fstab with its fuse caracteristics.
As /etc/fstab is using SPACE as a separator and as our TF700 fuse caracteristics include SPACE caracter, we have to convert them to its octal escape code \040.
Code:
# sudo gedit /etc/fstab
Code:
/etc/fstab
...
DeviceFs(ASUS\040Transf) /media/TF700 fuse.DeviceFs(ASUS\040Transf) allow_other,rw,user,noauto 0 0
When you will remount it in MTP mode, your TF700 will be seen as a device. In Nautilus, it appears in the device section and you are now able to Eject it ...

Thanks wery good info
ʞןɐʇɐdɐʇ on tf300t

with 13.04, i hear where now have native support. i installed 13.04 last night, but did not test it out. i will try it tonight.

timrock said:
with 13.04, i hear where now have native support. i installed 13.04 last night, but did not test it out. i will try it tonight.
Click to expand...
Click to collapse
Didn't work for me on my Droid Razr HD but the OPs tutorial was pretty useful.
Few questions though:
1. you can not create empty files,
2. you can not move file within the phone with drag & drop
Click to expand...
Click to collapse
1. Does this apply to folders as well?
2. What about cut and paste? I swear it worked for me.

Xplorer4x4 said:
Didn't work for me on my Droid Razr HD but the OPs tutorial was pretty useful.
Few questions though:
1. Does this apply to folders as well?
2. What about cut and paste? I swear it worked for me.
Click to expand...
Click to collapse
worked fine with my tf700, galaxy nexus, nexus 7 and my daughter samsung galaxy tab 2

As some extra help. I hate to see the device always present in Nautilus even if it's not mounted, because of fstab. So as a workaround (which is not the best way I imagine) I modified the udev rules file and the fstab file.
bjtheone said:
Code:
# sudo gedit /etc/udev/rules.d/51-android.rules
Code:
# Asus TF700 MTP mode under JB 4.2+ : automatic mount & umount when plugged (USB debug on & off)
ENV{ID_MODEL}=="ASUS_Transformer_Pad_TF700T", ENV{ID_MODEL_ID}=="4c91", ACTION=="add", RUN+="/usr/bin/sudo -b -u YOUR_LOGIN /usr/bin/go-mtpfs -allow-other=true /media/TF700"
ENV{ID_MODEL}=="ASUS_Transformer_Pad_TF700T", ENV{ID_MODEL_ID}=="4c91", ACTION=="remove", RUN+="/bin/umount /media/TF700"
Click to expand...
Click to collapse
I changed it as follows:
Code:
# Asus TF700 MTP mode under JB 4.2+ : automatic mount & umount when plugged (USB debug on & off)
ENV{ID_MODEL}=="ASUS_Transformer_Pad_TF700T", ENV{ID_MODEL_ID}=="4c91", ACTION=="add", RUN+="/path/to/mount_script.sh"
ENV{ID_MODEL}=="ASUS_Transformer_Pad_TF700T", ENV{ID_MODEL_ID}=="4c91", ACTION=="remove", RUN+="/path/to/unmount_script.sh"
The mount_script.sh contains:
Code:
#!/bin/sh
/bin/sed -i 's|#DeviceFs(ASUS\040Transf)|DeviceFs(ASUS\040Transf)|' /etc/fstab
/usr/bin/sudo -b -u YOUR_LOGIN /usr/bin/go-mtpfs -allow-other=true /media/TF700
and the unmount_script.sh:
Code:
#!/bin/sh
/bin/sed -i 's|DeviceFs(ASUS\040Transf)|#DeviceFs(ASUS\040Transf)|' /etc/fstab
/bin/umount /media/TF700
Now to make sense of the previous scripts, the fstab file has to change just a little. The extra line previously added has to be commented. That way the mount script will uncomment that line, making your device unmountable by the user and showing under the devices section, and when removed the unmount script will comment the same line so it won't show in that section any more.
Just to be sure, here's how the fstab looks (note the #[/B in front of the line)]:
Code:
/etc/fstab
...
#DeviceFs(ASUS\040Transf) /media/TF700 fuse.DeviceFs(ASUS\040Transf) allow_other,rw,user,noauto 0 0
Make sure you restart your udev so the new scripts can work, using with
Code:
# sudo service udev restart

Great tutorial but go-mtpfs is buggy
How come there are files that don't show up when I mount the go-mtpfs directory? For instance, when I navigate to SD Card/DCIM/Camera over the go-mtpfs mount,there is nothing there. if I connect to a shell over adb, I can see the files are clearly there. I thought it may be filesystem corruption however issuing adb pull of the Camera directory does indeed retrieve the correct files.

phh's SuperUser/ OpenSource SELinux-capable SuperUser

Hi,
IT MIGHT BRICK YOUR DEVICE.
Always ensure you have a way back.
Here is a thread about my fork of Koush's Superuser, to handle SELinux: https://github.com/seSuperuser/Superuser
So I would like your help to make this SuperUser a proud opensource SU app!
If you have an application that requires root, and which needs specific SELinux configuration please ask!
Build bot: https://superuser.phh.me/
Currently, four flavors of su are available on the build-bot:
- "eng" which puts "su" in permissive mode. This is the most compatible mode, but you should trust the apps you give root to. This does NOT put SELinux in permissive mode.
- "noverity" is eng and dm-verity disabled
- "nocrypt" is eng, dm-verity and dm-crypt disabled
- "user" is meant to give a safe su. su-apps won't be able to access to your Android Pay (for instance) informations, or keep persistent su access without your consent
Please note that user is in heavy development and isn't up to its promises at the moment.
I setup a build bot, which generates boot.img based on my solution, and pushes them to https://superuser.phh.me/
I did this build bot in a way so it is easy to add new ROMs, so don't hesitate asking for new ROM/devices support.
Supporting new devices might mean some additional work on http://github.com/seSuperuser/super-bootimg/ if they are using non-standard boot.img format, but the aim is to support as many devices as possible.
You need to install the APK from PlayStore afterwards: https://play.google.com/store/apps/details?id=me.phh.superuser
Bot-supported devices
Here are some devices, but there are many more !
- A *lot* of Archos devices
- All Nexus-es, including Pixel C (if some Nexus is missing, just ask!)
- nVidia Shield TV
- nVidia Shield Tablet
- Fairphone 2
update.zip format
The zip is available at https://superuser.phh.me/superuser.zip
It should be able to root any device supported by super-bootimg from TWRP (and possibly other custom recoverys)
You still need to install the APK afterwards. https://play.google.com/store/apps/details?id=me.phh.superuser https://f-droid.org/repository/brow...lob/master/known-imgs/nexus/hammerhead/MRA58N describes a firmware, nothing device-specific). This only requires to do some PRs to add a device, or on updated firmwares
- Testers
- UI designer: The current UI dates back from 4.1...? It is really ugly and not really usable.
- Testers
- Root-related devs: SELinux policies are still being written
- Testers
- Security reviewers
- Testers
Bug report
If some app doesn't work, please ask me, not the dev.
I consider I have to fix support for other apps, not the other way around.
ChangeLog
2016-01-31 r170: superuser.zip can be included in other update.zip
2016-01-27 r166: Add support for Viper4Android
2016-01-15 r162: Add su --bind and su --init commands
2016-01-10 r154: Files are no longer copied multiple times. Fixes MultiROM, and multiple install for update.
2016-01-06 r152: Fix support for ChromeOS-like format (Pixel C)
2016-01-01 r144: Detect chromeos-style signature, and don't try to resign it in that case
2015-12-30 r143: Improved compatibility with apps.
2015-12-28 r142: Changed naming convention to include device name and release
2015-12-28: Added "nocrypt" target
2015-12-13: Added "noverity" target to buildbot
2015-12-13: Add options for noencrypt, noverity
2015-12-03: Fix TitaniumBackup
2015-11-24: mount --bind to /system/xbin/su if it exists to override ROM's su
2015-11-23: Fix CF.Lumen
2015-11-14: Add super-bootimg's version in boot.img, several network/firewall-related permissions
2015-11-11: Access to Android's services
2015-11-10: Recursive su access
2015-11-09: Fix pm disable command

Do you mean that latest galaxy s5 neo sm-g903f might be rooted soon ?
(Exynos5 & Mali T-720)

It seems like many people still haven't understood the purpose of apps like SuperSu and Superuser. They are no exploits and don't gain your root access. What they do is they manage the root access and enable you to select which apps to grant root access, otherwise every single application on your device would have it. They are root managers. So this project won't help you in getting root for your device as long as there's no method (exploit) to gain it.

Not much activity here, but a lot on my side.
Android 6.0 is now out, with its new SELinux policy, which makes it impossible to update the policy after the boot, and dm-verity becomes mandatory (so no /system change without boot.img)
I'm thus totally retargetting my work:
- I've created https://github.com/phhusson/super-bootimg which will edit boot.img (the complicated part, because it needs A LOT of testing across many devices)
- change sepolicy
- Add su in /sbin/su
- Enable su daemon
With various options to disable dm-verity, encryption, etc. (please note that this is NOT required, since only boot.img is changed)

dude - you should kickstarter this. SuperSu is pretty much a mandatory install for every rooted device. this is big for the XDA community and we would love to support you.

Cannot express enough how much i want this project to succeed
And, at least for myself
"I also wonder about displaying an user-understandable SELinux policy, so that root applications can be "more secure
Would anyone be interested in such a feature?"
......Hell yeah, that most certainly does interest me.........controllable levels of su right?
Obviously, if its possible to do........even if android denies this possibility, an open source su is most assuredly welcome from this neck of the woods
I wish this project major luck
Edit
"(I'm thinking that I'm trying to be even more secure than "standard" non-rooted ROMs, that's perhaps a bit optimistic.)"
I love that mentality, and im enjoying immensley your discussions on github with lbdroid........i love that your taking security more seriously then most...love where your coming from on this.....major props

To better test on shell of recovery without making an update.zip , I modified the sepolicy-inject.c so that the usage() no longer blocks the "booting.sh"
on sepolicy-inject.c:377, insert a line "if ( NULL == optarg ) break;", as in my shell there will be a parameter value with null on last entry of "char** arguv", which will trigger the default switching case and exit the sepolicy-inject unexpectedly.
......
while ((ch = getopt_long(argc, argv, "a:f:g:s:t:c:Z:z:n", long_options, NULL)) != -1) {
if ( NULL == optarg ) break;
switch (ch) {
......

kennylam said:
To better test on shell of recovery without making an update.zip , I modified the sepolicy-inject.c so that the usage() no longer blocks the "booting.sh"
on sepolicy-inject.c:377, insert a line "if ( NULL == optarg ) break;", as in my shell there will be a parameter value with null on last entry of "char** arguv", which will trigger the default switching case and exit the sepolicy-inject unexpectedly.
......
while ((ch = getopt_long(argc, argv, "a:f:g:s:t:c:Z:z:n", long_options, NULL)) != -1) {
if ( NULL == optarg ) break;
switch (ch) {
......
Click to expand...
Click to collapse
I'm not sure I understand...
When calling what command do you need this?

phhusson said:
Hi,
IT MIGHT BRICK YOUR DEVICE.
Always ensure you have a way back.
I'm the author of a fork of Koush's Superuser, to handle SELinux: https://github.com/phhusson/Superuser
It is in early-stage, but thanks to recent events related to SuperSU, it got some spotlight.
So I would like your help to make this SuperUser a proud opensource SU app!
I have mostly two sides of things left to do:
- Device compatiblity/update.zip
- Application compatbility
I've tested my Superuser on Qualcomm/CAF 5.1 devices, on MTK 5.1 devices, on CAF 6.0, on Nexus 5/9 6.0, and I believe it should work on most devices which are close enough to AOSP.
I have missing steps to be compatible with SuperSU (see https://github.com/phhusson/Superuser#todo-list ).
I'd like to have feedback from app developers about which features they need the most.
If you have an application that requires root, and which needs specific SELinux configuration please ask!
There are main two types of builds, and some sub-types in it:
- @doitright did an integration in an AOSP tree, to make it suitable for ROM integration, https://github.com/lbdroid/AOSP-SU-PATCH/
- I did http://github.com/phhusson/super-bootimg/ which integrates su in a binary boot.img, and outputs a root-ed boot.img
@doitright's source solution currently has one SELinux policy, which is fully enforcing, and currently works in most cases.
My solution currently has two different policies, one which has su permissive, meaning it can do anything, which is not as safe as source-based s solution, and one which is WIP (basically unusable, because almost nothing is allowed to root).
I setup a build bot, which generates boot.img based on my solution, and pushes them to https://superuser.phh.me/
I did this build bot in a way so it is easy to add new ROMs, so don't hesitate asking for new ROM/devices support.
Supporting new devices might mean some additional work on http://github.com/phhusson/super-bootimg/ if they are using non-standard boot.img format, but the aim is to support as many devices as possible.
The plan is to have a third method for rooting:
super-bootimg will work from a recovery, so that you can root any ROM from recovery.
Thanks !
Click to expand...
Click to collapse
my question is how to change a file label to u: object_r:system_file:s0
i modify system.img to add some additional apps into /system/app/ directory i did modification then build a new system.img after flashing phone with new system.img the app was appear in menu but once i am trying to open it gives me error (com.xxxxxx.andriod) stopped working then i execute ls -Z command in /system/app/ directory to see the different and i realize that the new app i copied in system/app/ directory it has a different label than others
so i tried to change .apk file label to (u: object_r:system_file:s0) using chcon command but failed
chcon: Could not label u: object_r:system_file:s0
can you please guide me how to do it ?

zameer_yus said:
my question is how to change a file label to u: object_r:system_file:s0
i modify system.img to add some additional apps into /system/app/ directory i did modification then build a new system.img after flashing phone with new system.img the app was appear in menu but once i am trying to open it gives me error (com.xxxxxx.andriod) stopped working then i execute ls -Z command in /system/app/ directory to see the different and i realize that the new app i copied in system/app/ directory it has a different label than others
so i tried to change .apk file label to (u: object_r:system_file:s0) using chcon command but failed
chcon: Could not label u: object_r:system_file:s0
can you please guide me how to do it ?
Click to expand...
Click to collapse
Can you check in audit log?
How did you put the file?
Don't you have any other message?

Maybe in your intro you can eloborate on the naming convention of your bot built .img’s?
one which has su permissive (power?), meaning it can do anything, which is not as safe as source-based s solution (user?), and one which is WIP (eng?)
Your HTTPS link to superuser.phh.me is refusing connections?:
This webpage is not available
ERR_CONNECTION_REFUSED
ReloadHide details
Google Chrome's connection attempt to superuser.phh.me was rejected. The website may be down, or your network may not be properly configured.
Check your Internet connection
Check any cables and reboot any routers, modems, or other network devices you may be using.
Allow Chrome to access the network in your firewall or antivirus settings.
If it is already listed as a program allowed to access the network, try removing it from the list and adding it again.
If you use a proxy server...
Check your proxy settings or contact your network administrator to make sure the proxy server is working.
If I do a flash-all.sh of mra58r, reboot to bootloader, fastboot flash boot your-boot.img, would you expect this to boot fine?
Can you detail which phones can take a custom keystore?

For https, I know it is a must, but i'm waiting for let's encrypt.
For naming convention, I have to rethink those, and i'll update first post.
Anyway it's user < power < eng.
User has only safe permissions, power has all known permissions, eng is permissive. There is nothing source based.
For custom keystore, at the moment I have only seen CAF 5.1/6.0 bootloader with verity enabled to work, and it doesn't display key ID, so it is useless everywhere.
I should get a hand on a Nexus 5X soon, to test properly and get screenshots if it works as advertised.
For your last question, yes. I always work with factory image's partitions, and only change boot.img
I welcome any suggestion about naming convention.

Some times I dont know where to post, here or the Nexus 6 doitright thread. Anyway, I found this interesting.
http://events.linuxfoundation.org/sites/events/files/slides/ABS Lollipop MR1 Verified Boot.pdf
"• We relax some security policies in eng/userdebug loaders to make life less annoying for development • Persistent Data Block ignored, device always unlockable"
If this is true of the boot.img's you build, the only one we could trust is user or are they talking bootloader? Maybe the factory bootloader (user) that google is distributing does not have the verification functionality? Is the bootloader AOSP? If so, what would prevent someone from creating a bootloader, boot.img and /system that circumvents all the verification?

I used your bot built mra58r.
Unfortunately, if forced encryption is on, local.prop does not get parsed and I dont get my custom LCD. This means unless you offer variants of the auto built boot.img with forced encryption off or the ability to pass a noencrypt parameter to the update.zip or build.sh for modifying fstab, I will be forced to modify source and build myself. As for mount -o bind /data/local/tmp/hosts /system/etc, as long as the custom hosts has chcon ubject_r:system_file:s0, things work great.
I still like idea of having the ability to establish a trust between boot.img and a config file in /data/ that do things like custom hosts file, lcd density, iptables (one of my favorites: iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 8.8.8.8:53; iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 8.8.8.8:53)

havealoha said:
Some times I dont know where to post, here or the Nexus 6 doitright thread. Anyway, I found this interesting.
http://events.linuxfoundation.org/sites/events/files/slides/ABS Lollipop MR1 Verified Boot.pdf
"• We relax some security policies in eng/userdebug loaders to make life less annoying for development • Persistent Data Block ignored, device always unlockable"
If this is true of the boot.img's you build, the only one we could trust is user or are they talking bootloader? Maybe the factory bootloader (user) that google is distributing does not have the verification functionality? Is the bootloader AOSP? If so, what would prevent someone from creating a bootloader, boot.img and /system that circumvents all the verification?
Click to expand...
Click to collapse
They are talking about the bootloader, but as it is built in the Android build system, they are using Android build system flags.
I know the Nexus 6/9 doesn't have this functionnality. I'm waiting to get a Nexus 5X in my hands to say for 5X/6P.
Either way, we can't circumvent the verification, all we can do is have a YELLOW state instead of ORANGE, which displays the fingerprint of the keystore.
I forgot this presentation from Intel, so I thought I'd give it a try on Nexus Player. Intel has a proper implementation of the bootloader of Google's recommendation, it sounds logical the Nexus Player would implement it.
Oh wait. Google's logic striked again. No they didn't implement it on Nexus Player.
There is no AOSP bootloader... Or there are three (there are two LK and one u-boot), but neither of them are supported, and neither of them support the different verified boot states.
CAF bootloader handles the four states, but doesn't display them. Thanks to you I checked Intel reference bootloader, and it DOES implement the full spec \o/. Though I have no device to test. But basically, there is no opensource arm bootloader implementing it, and that makes me rant a lot against Google.
havealoha said:
I used your bot built mra58r.
Unfortunately, if forced encryption is on, local.prop does not get parsed and I dont get my custom LCD. This means unless you offer variants of the auto built boot.img with forced encryption off or the ability to pass a noencrypt parameter to the update.zip or build.sh for modifying fstab, I will be forced to modify source and build myself. As for mount -o bind /data/local/tmp/hosts /system/etc, as long as the custom hosts has chcon ubject_r:system_file:s0, things work great.
Click to expand...
Click to collapse
Two sides:
1. For LCD density, have you tried just doing adb shell wm density? Possibly it doesn't even break SafeNet
2. My plan on the matter is to keep my current builds as is, but add a configuration file, and when I'll make an update.zip, the user will be able to change the config file directly in the update.zip
I still like idea of having the ability to establish a trust between boot.img and a config file in /data/ that do things like custom hosts file, lcd density, iptables (one of my favorites: iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 8.8.8.8:53; iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 8.8.8.8:53)
Click to expand...
Click to collapse
Well for iptables, I put it in standard su permission. Well ATM because of some bugs it's only in "power", but I expect it to get into "user" when a bug concerning pts is fixed.

phhusson said:
Two sides:
1. For LCD density, have you tried just doing adb shell wm density? Possibly it doesn't even break SafeNet
Click to expand...
Click to collapse
Yay! As su in Terminal Emulator, wm density 360 worked. The launcher didn't work until #am start -c android.intent.category.HOME -a android.intent.action.MAIN and other apps also needed to be killed before they would display at the new density like lock screen and existing notifications. There are a few issues with the status bar and nav buttons depending on what app you try to run. I assume that if you set this early enough with a hook from init.rc, (nudge nudge) say a trusted file from /data/ that there would be no problem.
LCD density set from setprop, local.prop and wm density all break SafeNet. Even worse, SafeNet now checks /sbin/ for su, requiring a mount bind to a copy of sbin without su. Next thing you know, it will check for bind mounts!
How about a build of SuperSU, su in a random directory with random names? I know, name it the hash of boot.img or the public key from the user generated keystore.
Dont read on, I fixed it , the /data/setlcd.sh 560 needed quotes around it.
I created a Terminal Emulator widget in an attempt to make it easy to switch between resolutions. Interestingly, when set with #wm density 360 and then #am restart, the density sticks across reboots, I was not expecting that!
Ive tried the widget with different combinations of explicit paths for su with options like --context and -c with wm density and am restart and even with a /data/setlcd.sh that is chmod 750 and chcon ubject_r:system_file:s0. Any tricks to accomplish this? I would expect the widget to prompt for root permission and then run my setlcd.sh taking the DPI as argument $1 I am envisioning one main .sh that has a function for each of my customizations, wm density, hosts, iptables and mount bind to a /sbin that has no su. I dont want to keep building boot.img's with special init.rc's.
The closest I have gotten is a widget with command /sbin/su with the arguments -c /data/setlcd.sh 560
This results in a terminal launching that asks for su permission and then:
$"/sbin/su" -c /data/setlcd.sh 560
sh: /data/setlcd.sh: can't execute: Permission denied
nothing in dmesg
Click to expand...
Click to collapse

So I made a test of verified boot feature here: http://forum.xda-developers.com/and...rified-boot-disk-encryption-testings-t3248161
The tl;dr is that verified boot is IMO a great feature of 5X/6P, and we have to find a way to have su enabled with this feature.
But this requires to have working OTA.

I have finally gotten the functionality I need with the exception of iptables which I understand you are working on adding. I am testing with shamu mra58r and the boot-su-power.img.
Here is my setup that features:
custom hosts file for browsing without advertisements
set the LCD density to tablet mode
quickly disable su and revert density when I want to use Android Pay
As root, I created a script in /data/android.sh and set the context to system via chcon ubject_r:system_file:s0 and chmod 700 here are its contents:
Code:
#!/system/bin/sh
#bind mounts transcend am restarts
#wm density transcends reboots
function lcd
{
/system/bin/wm density $density
/system/bin/sleep 3
/system/bin/am restart
}
function hosts
{
mount -o bind /data/hosts /system/etc/hosts
}
function nosu
{
/system/bin/wm density 560
cp /sbin /data/sbin -r
rm -f /data/sbin/su
mount -o bind /data/sbin /sbin
/system/bin/am restart
}
function dns
{
#not working yet in phh
iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 8.8.8.8:53
iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 8.8.8.8:53
}
density=$2
case "$1" in
lcd) lcd ;;
hosts) hosts ;;
nosu) nosu ;;
dns) dns ;;
esac
The hosts file was copied from http://winhelp2002.mvps.org/hosts.txt and placed in /data, its context was also set chcon ubject_r:system_file:s0 and chmod 644. The local host entries were modified to match those found in /system/etc/hosts. It was important that the contents of this file were terminated on each line and with a blank line at the end.
The tricky part was creating launchers on a home screen using the Terminal Emulator Widget. It seemed that you could not just type in /sbin/su, instead you had to browse to it. Screenshot of widget config attached.
I learned a few interesting things during testing.
Using a /data/local.prop with an encrypted disk resulted in the local.prop not being read during init.
Once wm density is set, it is persistent.
Using mount -o bind gives persistent mounts if you reboot using am restart from the terminal
SafetyNet now checks for su in /sbin
SafetyNet for AndroidPay checks for LCD density regardless of setting it via local.prop (if unencrypted), setprop or wm density
This will be easy for me to reproduce across all my devices without granting persistent root to any app and without adding any app but superuser and terminal emulator.

Thanks for your test! It's really interesting.
You must be the first user of something other than eng
iptables does work for me (in adb shell). Looking back, it should have been fixed by https://github.com/phhusson/super-bootimg/commit/31d3a635eea4fe66071346e05913acfb00d60144
That made me realize that if I don't do releases, I still need to know what users are using, so I added /super-bootimg which contains the git version of super-bootimg repo
For local.prop I'm happy to see you don't need it. I really feel like user shouldn't be allowed to change it (but I'm thinking only about some properties which are in /default.prop so it can't be overriden. perhaps local.prop is safe enough)
am restart is not a reboot, so it's normal mount bind stays
I think you could just mount bind an empty folder to /sbin. The only risks are if adbd/ueventd/watchdogd/healthd restarts, but they shouldn't

Any idea why busybox nslookup is not working?
[email protected]:/data # ls -Z nslookup busybox-android.bin
lrwxrwxrwx root root ubject_r:system_data_file:s0 nslookup -> busybox-android.bin
-rwxr-xr-x root shell ubject_r:system_file:s0 busybox-android.bin
[email protected]:/data # ./nslookup superuser.phh.me 8.8.8.8
Server: 8.8.8.8
Address 1: 8.8.8.8
nslookup: can't resolve 'superuser.phh.me'
1|[email protected]:/data # dmesg
[39764.686702] healthd: battery l=91 v=4144 t=28.1 h=2 st=3 c=-439 chg=
[email protected]:/data #