• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[2017.10.01] suhide-lite v1.09 [EXPERIMENTAL/UNSUPPORTED]

Search This thread

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,442
87,717
www.chainfire.eu
suhide-lite is an experimental (and officially unsupported) mod for SuperSU that can selectively hide root (the su binary) from other applications. It can also toggle visibility of packages (such as SuperSU).

SafetyNet verified passing on 2017.08.10.

This is ultimately a losing game (see the next post). suhide may stop working at any time.

Requirements
- SuperSU v2.82 SR2 or newer (link)
- SuperSU installed in SBIN mode (default on O+)
- Android 6.0 or newer
- TWRP (3.0.2 or newer with access to /data), FlashFire is not (yet) supported.

Xposed
Not supported.

CyanogenMod/LineageOS
Not currently tested or supported. Might work, might not.

Custom kernels/ROMs
If they changed build props, they will probably fail SafetyNet check (for now).

Installation

First make sure you are using SuperSU in SBIN mode on Android 6.x and 7.x
- Boot into TWRP
--- adb shell: echo "BINDSBIN=true">/data/.supersu
--- OR: flash SuperSU Config and select Systemless SBIN mode
- Reflash SuperSU v2.82 SR2 or newer
- Reboot into Android at least once

With SuperSU in SBIN mode
- Flash the suhide ZIP in TWRP
- Reboot into Android

If your TWRP does not fully decrypt /data, reflashing the SuperSU ZIP and immediately flashing the suhide ZIP without rebooting in between may sometimes allow suhide to be installed as well where it would otherwise throw an error.

Usage

The suhide GUI available from your app drawer should be fairly self-explanatory. The About tab lists further instructions.

Advanced usage

You can manually add/remove/list entries to suhide's blacklist by using these commands:

/sbin/supersu/suhide/add UID-or-processname
/sbin/supersu/suhide/rm UID-or-processname
/sbin/supersu/suhide/list

App package names are usually the same as the process name, but not always. Using the UID is safer. You can find the UID by running 'ps -n' (6.x/7.x) or 'ps -An' (8.x). The UID is the first column, and is a 5-digit number starting with 10: 10xxx.

Uninstall

Remove /data/adb/su/suhide folder in TWRP's file manager. You can uninstall the suhide app through Android's settings.

Download

UPDATE-suhide-v1.09-20171001222116.zip

In case that bootloops, try the old v1.00 version, and let me know your device and firmware:
UPDATE-suhide-v1.00-20170809130405.zip

Sauce @ https://github.com/Chainfire/suhide-lite
 
Last edited:

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,442
87,717
www.chainfire.eu
Hiding root: a losing game - rant du jour

Quoting myself from the OP of the old suhide thread:

Most apps that detect root fall into the payment, banking/investing, corporate security, or (anit cheating) gaming category.

While a lot of apps have their custom root detection routines, with the introduction of SafetyNet the situation for power users has become worse, as developers of those apps can now use a single API to check if the device is not obviously compromised.

SafetyNet is of course developed by Google, which means they can do some tricks that others may not be able to easily do, as they have better platform access and control. In its current incarnation, ultimately the detection routines still run as an unprivileged user and do not yet use information from expected-to-be-secure components such as the bootloader or TPM. In other words, even though they have slightly more access than a 3rd party app, they still have less access than a root app does.

Following from this is that as long as there is someone who is willing to put in the time and effort - and this can become very complex and time consuming very quickly - and SafetyNet keeps their detection routines in the same class, there will in theory always be a way to beat these detections.

While reading that may initially make some of you rejoice, this is in truth a bad thing. As an Android security engineer in Google's employ has stated, they need to "make sure that Android Pay is running on a device that has a well documented set of API’s and a well understood security model".

The problem is that with a rooted device, it is ultimately not possible to guarantee said security model with the current class of SafetyNet tamper detection routines. The cat and mouse game currently being played out - SafetyNet detecting root, someone bypassing it, SafetyNet detecting it again, repeat - only serves to emphasize this point. The more we push this, the more obvious this becomes to all players involved, and the quicker SafetyNet (and similar solutions) will grow beyond their current limitations.

Ultimately, information will be provided and verified by bootloaders/TrustZone/SecureBoot/TIMA/TEE/TPM etc. (Samsung is already doing this with their KNOX/TIMA solutions). Parts of the device we cannot easily reach or patch, and thus there will come a time when these detection bypasses may no longer viable. This will happen regardless of our efforts, as you can be sure malware authors are working on this as well. What we power-users do may well influence the time-frame, however. If a bypass attains critical mass, it will be patched quickly.

More security requires more locking down. Ultimately these security features are about money - unbelievably large amounts of money. This while our precious unlocked bootloaders and root solutions are more of a developer and enthusiast thing. While we're all generally fond of shaking our fists at the likes of Google, Samsung, HTC, etc, it should be noted that there are people in all these companies actively lobbying to keep unlocked/unlockable devices available for us to play with, with the only limitation being that some financial/corporate stuff may not work if we play too hard.

It would be much easier (and safer from their perspective) for all these parties to simply plug that hole and fully lock down the platform (beyond 3rd party apps using only the normal APIs). Bypassing root checks en masse is nothing less than poking the bear.

Nevertheless, users want to hide their roots (so do malware authors...) and at least this implementation of suhide is a simple one. I still think it's a bad idea to do it. Then again, I think it's a bad idea to do anything financial related on Android smartphone that isn't completely clean, but that's just me.

Note that I have intentionally left out any debate on whether SafetyNet/AndroidPay/etc need to be this perfectly secure (most people do their banking on virus ridden Windows installations after all), who should get to decide which risk is worth taking, or even if Google and cohorts would be able to design the systems more robustly so the main app processor would not need to be trusted at all. (the latter could be done for Android Pay, but wouldn't necessarily solve anything for Random Banking App). While those are very interesting discussion points, ultimately it is Google who decides how they want this system to work, regardless of our opinions on the matter - and they want to secure it.

I still stand behind this statement I made a year ago.

I will add to this another concern that I've posted before: on the A/B layout devices such as the Google Pixel (XL), it is possible to detect the device is rooted with a handful of lines of code, and I do not see any way to beat this detection aside from custom kernels. As soon as this detection is added to SafetyNet, it is pretty much game over. Frankly I'm surprised it hasn't been added yet.
 
Last edited:

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,442
87,717
www.chainfire.eu
The new suhide-lite vs the old suhide

The old suhide was completely different under the hood. It proxied zygote and created two different process trees for the real zygote and descendants (apps), one with root and one without, and multiplexed app instantiation calls between them. The new suhide-lite uses a completely different mechanism to achieve a similar outcome (some apps with and some apps without root).

One thing the old suhide had and the new suhide-lite version does not, is full binder interception. It could listen to and change most API calls and responses between apps and the Android system dynamically. While this may not sound like a big deal to some, from a malware-perspective this is almost a holy-grail class hack. suhide only used it to hide application packages (such as SuperSU) from apps selectively, so for example the launcher could still find it, but to some games it was completely invisible.

The binder interception code was the part that really interested me and the desire to get that working was the driving force behind the old suhide implementation. The security measures in Android's November 2016 security update blocked the old mechanism and with it the binder interceptor. Of course, I have actually written the code to bypass those (naive) protections in turn, but since that implementation of suhide was possible to detect in other ways, I kept that patch private. It may still prove useful in other projects, so it didn't make any sense to burn those work-arounds.

It may be possible to port the interceptor to the new mechanism, but it would be a lot of work and I don't think I'll be doing it any time soon, if ever. The lack of this intercepter is what makes the new suhide lite. The new suhide is able to hide packages such as SuperSU from other apps and games, but it does so via a toggle mechanism (3x alternating volup/voldown) that hides and unhides them, rather than handling the whole thing transparently.
 
Last edited:

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,442
87,717
www.chainfire.eu
Changelogs

2017.10.01 - v1.09
- Remove ODM and OEM mounts
- Setpropex: set multiple properties
- Cleanup: remove /boot

2017.08.15 - v1.08
- Fix a process freeze issue
- Fix framework restart survival (stop && start)
- Fix double free crash

2017.08.11 - v1.07
- Startup: Fix parallelism

2017.08.10 - v1.06
- Startup: Disable parallelism (temporary?), causes things to break sometimes

2017.08.10 - v1.05
- GUI: Synchronize changing items with the same UID
- GUI: Hide system apps (UID < 10000)
- GUI: Fix UID / package display line to ellipsize instead of wrap
- Properties: Adjust various build, adb, debug and security properties
- Startup: Improve performance by running operations in parallel
- ZIP: Allow flashing directly after SuperSU switch from image to SBIN mode, without reboot in between

2017.08.09 - v1.00
- Initial release of new code
- For old code, see https://forum.xda-developers.com/apps/supersu/suhide-t3450396
 
Last edited:

Ch3vr0n

Senior Member
May 6, 2009
1,693
668
38
FIRST! new suhide yay. My 6p is currently running N 7.1.2. STOCK ANDROID, NO customisation whatsoever. Will 2.82 SR2 automatically update the root to sbin mode? If yes is the echo command still needed then?

Sent from my Nexus 6P with Tapatalk
 
Last edited:

gverma1

Senior Member
Feb 7, 2012
889
278
New Delhi
Cool. I was avoiding using Magisk so far and was without root to be able to use certain apps like Netflix. I have a Pixel XL. Will SuperSU 2.82 SR2 alongwith suhide-lite work on my phone? Will I have to give the commands in TWRP as given in op? I intend to flash August security patch and try this during that update process. Currently I am stock (no root) with ElementalX kernel which I intend to continue using to be able to hide bootloader unlocked status.
 

junioramboy

Senior Member
Nov 15, 2015
188
102
Wow.. this works!
02ad7f79b32894838c2c28f3ad4665c5.jpg


Shamusent
 

rocky78

Senior Member
Feb 6, 2015
471
111
43
@Chainfire
hi,
maybe you can do something about this :crying:

i'm on nougat 7.1.2 (July security patch) been trying for long time to get this to work on citrix secure hub (by zenprise- formally known as worx)
attaching my logs and pics.
this is what i found from the logs attached:
Code:
"com.citrix.work.MAM.PolicyCheck:Found an APK requiring rooted device: eu.chainfire.supersu"
"com.citrix.work.MAM.PolicyCheck:BuildTag Test advisory ----- > is probably rooted"
SuperUser APKs Test advisory ---- > is probably rooted
the only one thing it didnt find:
Code:
D/"SecureHub"(16939): su In Path Test --- > is NOT rooted

i manged to pass safety net as you can see.
please if you can help.
 

Attachments

  • Screenshot_20170809-164953.png
    Screenshot_20170809-164953.png
    196.4 KB · Views: 4,536
  • Screenshot_20170809-165808.jpg
    Screenshot_20170809-165808.jpg
    193.6 KB · Views: 4,466
  • logcat.log
    44.8 KB · Views: 416

TR2N

Senior Member
Apr 19, 2012
415
88
Hamburg
Hi all and Chainfire. Thank you for this app! I tested it with a search if the Netflix app in the Playstore, but it wasn't found. I hided Playstore app in the list. Is there something I have overseen?

Otherwise I am also passing Safety Net. Thank you Chainfire!
 
  • Like
Reactions: Kinan-Kun

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,442
87,717
www.chainfire.eu
@Chainfire
hi,
maybe you can do something about this :crying:

i'm on nougat 7.1.2 (July security patch) been trying for long time to get this to work on citrix secure hub (by zenprise- formally known as worx)
attaching my logs and pics.
this is what i found from the logs attached:
Code:
"com.citrix.work.MAM.PolicyCheck:Found an APK requiring rooted device: eu.chainfire.supersu"
"com.citrix.work.MAM.PolicyCheck:BuildTag Test advisory ----- > is probably rooted"
SuperUser APKs Test advisory ---- > is probably rooted
the only one thing it didnt find:
Code:
D/"SecureHub"(16939): su In Path Test --- > is NOT rooted

i manged to pass safety net as you can see.
please if you can help.

Does citrix secure hub run constantly in the background, or do you just need it now and then ?

Have you read the instructions in the About screen as stated ?

Have you tried hiding the SuperSU GUI ? (3x volup/voldown alternate) Because that is what it's detecting.

It's not detecting the su binary, I assume you already hid root from the hub ?

Hi all and Chainfire. Thank you for this app! I tested it with a search if the Netflix app in the Playstore, but it wasn't found. I hided Playstore app in the list. Is there something I have overseen?

Otherwise I am also passing Safety Net. Thank you Chainfire!

Try clear Google Play Store and Google Play Services app data.

Netflix shows for me on a freshly installed device.
 

rocky78

Senior Member
Feb 6, 2015
471
111
43
Does citrix secure hub run constantly in the background, or do you just need it now and then ?

Have you read the instructions in the About screen as stated ?

Have you tried hiding the SuperSU GUI ? (3x volup/voldown alternate) Because that is what it's detecting.

It's not detecting the su binary, I assume you already hid root from the hub ?

1. i can use it how ever i want (background or now and then). this is an email from my company.
2. yes. tried that.
3. yes i did. i attached a pic for you to see in the previous replay.
 

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,442
87,717
www.chainfire.eu
1. i can use it how ever i want (background or now and then). this is an email from my company.
2. yes. tried that.
3. yes i did. i attached a pic for you to see in the previous replay.

But is SuperSU still available from the app drawer? Did you actually press the volume button as instructed? The screenshot does not (can cannot) show that.
 

rocky78

Senior Member
Feb 6, 2015
471
111
43
But is SuperSU still available from the app drawer? Did you actually press the volume button as instructed? The screenshot does not (can cannot) show that.
no.
When im pressing in the right order its hidden from app drawer. Also some other apps gets hidden.

p.s.
from the log i uploaded before it looks like "they" are running a search of supersu.apk in my device and mannage to find that.
is there a way to hide/stop that?
 

Attachments

  • Screenshot_20170809-181338.jpg
    Screenshot_20170809-181338.jpg
    199.8 KB · Views: 1,224
  • Screenshot_20170809-181419.jpg
    Screenshot_20170809-181419.jpg
    211.5 KB · Views: 1,213
Last edited:

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,442
87,717
www.chainfire.eu
no.
When im pressing in the right order its hidden from app drawer. Also some other apps gets hidden.

p.s.
from the log i uploaded before it looks like "they" are running a search of supersu.apk in my device and mannage to find that.
is there a way to hide/stop that?

In that case I don't know what's going on. They shouldn't be able to iterate over APKs either. But it's all just guess work on my end at this point.

EDIT: actually I do know of a way they could still detect this even when hidden... but really the only way around that is to uninstall the SuperSU APK.
 
Last edited:

rocky78

Senior Member
Feb 6, 2015
471
111
43
In that case I don't know what's going on. They shouldn't be able to iterate over APKs either. But it's all just guess work on my end at this point.

EDIT: actually I do know of a way they could still detect this even when hidden... but really the only way around that is to uninstall the SuperSU APK.
do you mean if i clean flash my rom (custom) without root i will be able to use it?
And if so... Wft? No way! The hell with them.
 

rocky78

Senior Member
Feb 6, 2015
471
111
43
No, just uninstall the SuperSU app from Android settings. Your apps will still have root access, you just wont have any way to manage it.

look at this....
Do you see in the log-pic? After hiding from app drawer took a log file and suhide worked.
Only one more thing left to hide.
wtf is build tag? is it related to ro.build.tags in props?
 

Attachments

  • Screenshot_20170809-185738.jpg
    Screenshot_20170809-185738.jpg
    309.2 KB · Views: 1,281

Top Liked Posts

  • There are no posts matching your filters.
  • 159
    suhide-lite is an experimental (and officially unsupported) mod for SuperSU that can selectively hide root (the su binary) from other applications. It can also toggle visibility of packages (such as SuperSU).

    SafetyNet verified passing on 2017.08.10.

    This is ultimately a losing game (see the next post). suhide may stop working at any time.

    Requirements
    - SuperSU v2.82 SR2 or newer (link)
    - SuperSU installed in SBIN mode (default on O+)
    - Android 6.0 or newer
    - TWRP (3.0.2 or newer with access to /data), FlashFire is not (yet) supported.

    Xposed
    Not supported.

    CyanogenMod/LineageOS
    Not currently tested or supported. Might work, might not.

    Custom kernels/ROMs
    If they changed build props, they will probably fail SafetyNet check (for now).

    Installation

    First make sure you are using SuperSU in SBIN mode on Android 6.x and 7.x
    - Boot into TWRP
    --- adb shell: echo "BINDSBIN=true">/data/.supersu
    --- OR: flash SuperSU Config and select Systemless SBIN mode
    - Reflash SuperSU v2.82 SR2 or newer
    - Reboot into Android at least once

    With SuperSU in SBIN mode
    - Flash the suhide ZIP in TWRP
    - Reboot into Android

    If your TWRP does not fully decrypt /data, reflashing the SuperSU ZIP and immediately flashing the suhide ZIP without rebooting in between may sometimes allow suhide to be installed as well where it would otherwise throw an error.

    Usage

    The suhide GUI available from your app drawer should be fairly self-explanatory. The About tab lists further instructions.

    Advanced usage

    You can manually add/remove/list entries to suhide's blacklist by using these commands:

    /sbin/supersu/suhide/add UID-or-processname
    /sbin/supersu/suhide/rm UID-or-processname
    /sbin/supersu/suhide/list

    App package names are usually the same as the process name, but not always. Using the UID is safer. You can find the UID by running 'ps -n' (6.x/7.x) or 'ps -An' (8.x). The UID is the first column, and is a 5-digit number starting with 10: 10xxx.

    Uninstall

    Remove /data/adb/su/suhide folder in TWRP's file manager. You can uninstall the suhide app through Android's settings.

    Download

    UPDATE-suhide-v1.09-20171001222116.zip

    In case that bootloops, try the old v1.00 version, and let me know your device and firmware:
    UPDATE-suhide-v1.00-20170809130405.zip

    Sauce @ https://github.com/Chainfire/suhide-lite
    54
    Hiding root: a losing game - rant du jour

    Quoting myself from the OP of the old suhide thread:

    Most apps that detect root fall into the payment, banking/investing, corporate security, or (anit cheating) gaming category.

    While a lot of apps have their custom root detection routines, with the introduction of SafetyNet the situation for power users has become worse, as developers of those apps can now use a single API to check if the device is not obviously compromised.

    SafetyNet is of course developed by Google, which means they can do some tricks that others may not be able to easily do, as they have better platform access and control. In its current incarnation, ultimately the detection routines still run as an unprivileged user and do not yet use information from expected-to-be-secure components such as the bootloader or TPM. In other words, even though they have slightly more access than a 3rd party app, they still have less access than a root app does.

    Following from this is that as long as there is someone who is willing to put in the time and effort - and this can become very complex and time consuming very quickly - and SafetyNet keeps their detection routines in the same class, there will in theory always be a way to beat these detections.

    While reading that may initially make some of you rejoice, this is in truth a bad thing. As an Android security engineer in Google's employ has stated, they need to "make sure that Android Pay is running on a device that has a well documented set of API’s and a well understood security model".

    The problem is that with a rooted device, it is ultimately not possible to guarantee said security model with the current class of SafetyNet tamper detection routines. The cat and mouse game currently being played out - SafetyNet detecting root, someone bypassing it, SafetyNet detecting it again, repeat - only serves to emphasize this point. The more we push this, the more obvious this becomes to all players involved, and the quicker SafetyNet (and similar solutions) will grow beyond their current limitations.

    Ultimately, information will be provided and verified by bootloaders/TrustZone/SecureBoot/TIMA/TEE/TPM etc. (Samsung is already doing this with their KNOX/TIMA solutions). Parts of the device we cannot easily reach or patch, and thus there will come a time when these detection bypasses may no longer viable. This will happen regardless of our efforts, as you can be sure malware authors are working on this as well. What we power-users do may well influence the time-frame, however. If a bypass attains critical mass, it will be patched quickly.

    More security requires more locking down. Ultimately these security features are about money - unbelievably large amounts of money. This while our precious unlocked bootloaders and root solutions are more of a developer and enthusiast thing. While we're all generally fond of shaking our fists at the likes of Google, Samsung, HTC, etc, it should be noted that there are people in all these companies actively lobbying to keep unlocked/unlockable devices available for us to play with, with the only limitation being that some financial/corporate stuff may not work if we play too hard.

    It would be much easier (and safer from their perspective) for all these parties to simply plug that hole and fully lock down the platform (beyond 3rd party apps using only the normal APIs). Bypassing root checks en masse is nothing less than poking the bear.

    Nevertheless, users want to hide their roots (so do malware authors...) and at least this implementation of suhide is a simple one. I still think it's a bad idea to do it. Then again, I think it's a bad idea to do anything financial related on Android smartphone that isn't completely clean, but that's just me.

    Note that I have intentionally left out any debate on whether SafetyNet/AndroidPay/etc need to be this perfectly secure (most people do their banking on virus ridden Windows installations after all), who should get to decide which risk is worth taking, or even if Google and cohorts would be able to design the systems more robustly so the main app processor would not need to be trusted at all. (the latter could be done for Android Pay, but wouldn't necessarily solve anything for Random Banking App). While those are very interesting discussion points, ultimately it is Google who decides how they want this system to work, regardless of our opinions on the matter - and they want to secure it.

    I still stand behind this statement I made a year ago.

    I will add to this another concern that I've posted before: on the A/B layout devices such as the Google Pixel (XL), it is possible to detect the device is rooted with a handful of lines of code, and I do not see any way to beat this detection aside from custom kernels. As soon as this detection is added to SafetyNet, it is pretty much game over. Frankly I'm surprised it hasn't been added yet.
    47
    The new suhide-lite vs the old suhide

    The old suhide was completely different under the hood. It proxied zygote and created two different process trees for the real zygote and descendants (apps), one with root and one without, and multiplexed app instantiation calls between them. The new suhide-lite uses a completely different mechanism to achieve a similar outcome (some apps with and some apps without root).

    One thing the old suhide had and the new suhide-lite version does not, is full binder interception. It could listen to and change most API calls and responses between apps and the Android system dynamically. While this may not sound like a big deal to some, from a malware-perspective this is almost a holy-grail class hack. suhide only used it to hide application packages (such as SuperSU) from apps selectively, so for example the launcher could still find it, but to some games it was completely invisible.

    The binder interception code was the part that really interested me and the desire to get that working was the driving force behind the old suhide implementation. The security measures in Android's November 2016 security update blocked the old mechanism and with it the binder interceptor. Of course, I have actually written the code to bypass those (naive) protections in turn, but since that implementation of suhide was possible to detect in other ways, I kept that patch private. It may still prove useful in other projects, so it didn't make any sense to burn those work-arounds.

    It may be possible to port the interceptor to the new mechanism, but it would be a lot of work and I don't think I'll be doing it any time soon, if ever. The lack of this intercepter is what makes the new suhide lite. The new suhide is able to hide packages such as SuperSU from other apps and games, but it does so via a toggle mechanism (3x alternating volup/voldown) that hides and unhides them, rather than handling the whole thing transparently.
    38
    Changelogs

    2017.10.01 - v1.09
    - Remove ODM and OEM mounts
    - Setpropex: set multiple properties
    - Cleanup: remove /boot

    2017.08.15 - v1.08
    - Fix a process freeze issue
    - Fix framework restart survival (stop && start)
    - Fix double free crash

    2017.08.11 - v1.07
    - Startup: Fix parallelism

    2017.08.10 - v1.06
    - Startup: Disable parallelism (temporary?), causes things to break sometimes

    2017.08.10 - v1.05
    - GUI: Synchronize changing items with the same UID
    - GUI: Hide system apps (UID < 10000)
    - GUI: Fix UID / package display line to ellipsize instead of wrap
    - Properties: Adjust various build, adb, debug and security properties
    - Startup: Improve performance by running operations in parallel
    - ZIP: Allow flashing directly after SuperSU switch from image to SBIN mode, without reboot in between

    2017.08.09 - v1.00
    - Initial release of new code
    - For old code, see https://forum.xda-developers.com/apps/supersu/suhide-t3450396
    26
    v1.08 released

    v1.08 is now available from the opening post of this thread ( https://forum.xda-developers.com/apps/supersu/suhide-lite-t3653855 )

    This will hopefully fix the freezing issue some have been seeing. I've had a couple of devices run the boot-sequence and monkey-testing apps for a few minute in a loop, and fixed all the freezes I could find that way. Hopefully that includes the ones that have been reported here.