yashsingh1/xdaforums huggingface dataset:
[G3 Q&A, Help & Troubleshooting] CyberstormXo:
I know, InCallUi isn't working with LG, Sony etc. Roms.

This Zip isn't useful atm.
[G3 Q&A, Help & Troubleshooting] airflyer737:
Mhhh too bad :(
[G3 Q&A, Help & Troubleshooting] ryfly65:
Hey there! Any progress on getting this working again? I'm on fulmics rom, but it clashes pretty hard with the stock dialer. Also, the call settings force it to crash. Would love this over the stock rom!
[Sprint Galaxy S 5 Q&A, Help & Troubleshooting] mudflap2.0:
So i know the sprint and virgin mobile versions are identical models, but why cant i find any forums for the virgin mobile galaxy s5?, i know from my last phone experience that the raidios (aka modems) and bootloaders are different, assumingly, so why isnt there a virgin mobile thread? Im just asking becuase aparently android lolipop is available for the sprint version, but not on vm yet, but like with the vm gs3 will the updates be the same, that ill have to wait about a a week or few to get the update?
[Sprint Galaxy S 5 Q&A, Help & Troubleshooting] jdsingle76:
The 5.0 for Sprint is a leak, and not the "official" build released. I have Boost, and got the NK4 about a week or so after Sprint. Sammy is getting really good at getting them out to Boost/VM much faster than before. And yes, the updates for The S5 are the same, just like the GS3, just the boot animation and "tagging" are different.
[Nexus 6 Q&A, Help & Troubleshooting] Danish2980:
I would love to do this like you can via xposed on Kitkat.. Many feature packed KK roms is able to do this..

Is it easy to do or?

I really dislike the LTE icon ?

All help is extremely appreciated..
[Nexus 6 Q&A, Help & Troubleshooting] zephiK:
Just change the image in systemui apk. Not difficult to do at all.
[Nexus 6 Q&A, Help & Troubleshooting] Pilz:
Isn't 4G the same as H+ and H is 3G so LTE would be LTE of I'm not mistaken. I'm sure this could be changed easily if you know where to find the time and edit it.
[Nexus 6 Q&A, Help & Troubleshooting] zephiK:
H+ is advertised as 4G but its really 3.5G, its just all weird marketing terms. It is easily changed its in /res/xxhdpi, find _lte and replace it with the one with _4g. Easy to do.
[Nexus 6 Q&A, Help & Troubleshooting] Pilz:
I see, my H+ speeds are generally 20-30mb/s so that's not bad at all but not 4G thank you for clarifying that. Can you change it via a root explorer or do you need to pull apart the whole settingsUI?
[Nexus 6 Q&A, Help & Troubleshooting] Danish2980:
Would you mind explaining? Can't find it..
[Nexus 6 Q&A, Help & Troubleshooting] stumpy352:
You could create a ZipThemer theme for it if you had the images. Not difficult.

Interestingly my phone displays 4g resources, not LTE.
[Nexus 6 Q&A, Help & Troubleshooting] Danish2980:
Don't know how do that..

Mine does show 4G on stock and on some of the custom roms, but not all and since this is the xda forum I thought someone would know how to do this and would be kind enough to tell me :D
[Nexus 6 Q&A, Help & Troubleshooting] stumpy352:
A zipthemer theme replaces resources in your ROM & creates a flashable theme that you install from recovery. Its not difficult to create the theme & I may have time to make it for you in the next day or so.

I would need a copy of your SystemUI.apk though, for the image names.

EDIT: Sorry, actually this won't work, because the icons are in .xml now, not images. If it was images it would be easy.
[Nexus 6 Q&A, Help & Troubleshooting] Danish2980:
Thank you for your help and sorry for the late response..

If both 4G and LTE XML's are in the same folder could I just delete the LTE XML??
[Nexus 6 Q&A, Help & Troubleshooting] zephiK:
No, then it would give a error because its trying to find a LTE XML file and its not there.

You're better off just leaving it, its just cosmetics. Not that big of a deal than to go through the hassle.

I'd go look and find it for you but thats only for that particular set up that its not worth it.
[Nexus 6 Q&A, Help & Troubleshooting] Danish2980:
True.. Not worth it.. Thank you for your help :)
[Android Q&A, Help & Troubleshooting] Lanchon:
Implementation Ideas

Security is never trivial to implement, so I will accumulate some points here to guide the design of a solution. Fell free to contribute.

The passwords must be stored in an irreversible manner, using proven, properly salted cryptographic methods.

The password store (PS) should not be accessible to apps, or else they might attack it by brute-force. In /data/media devices, if the PS is stored in /data/media/0, it should be stored with restrictive permissions such that the fuse daemon will not reflect it into world readable /sdcard. Under kitkar (and even using a permission-less real fat32 /sdcard) files could be made inaccessible under folders in /Android i think. Otherwise the /data partition could work (ugly due interactions with nandroid backups). Also, bytes reserved in the /recovery partition itself could do the trick. NOTE: nandroid backups suffer the same problem: they are world readable copies of your passwords and auth tokens. It is imperative that general solution to this problem be found for TWRP. CM's recovery places the backup files outside of '0' in /data/media which is a good solution for /data/media devices. And going forward, this type of devices should be the norm.

adbd and mtpd should not start before the password is entered.

It is enough to ask for password once per boot.

adb on recovery is the data recovery method of choice when a screen is broken. it should be possible to enter the password via USB to enable adb and mtp with a broken screen. NOTE: by the same token, it should be possible to enter the phone encryption password via USB if any.

Both the recovery lockscreen/password and android lockscreen/password could be the same, since access to android's lockscreen data is needed for encryption support anyway and thus that code is already in place. But then, forget this one password and your phone is a brick!!!

If they are not the same, a way (an app) to change the password (or at least reset it) from root android should be provided.

There could be an official TWRP password manager app that stores the TWRP password in its private data in /data and TWRP could read it from there. (But the interaction with nandroid backups would kinda suck.)

To enter the password over USB, ideally a restricted adbd mode would ask for the password, then restart itself a la "adb root" switcheroo. So that standard adb can be used to enable adbd and another host tool is not needed.

There should be some throttling down of passwords tries both via the recovery popup keyboard and via adb. If the same password is used for android and recovery, then the throttling should not be less aggressive than android's.

Ideally the password hash in the PS should be stored in a way compatible with some proven challenge response authentication so that the data in the PS can support future unlock protocols that do not send the password in the clear.
[Android Q&A, Help & Troubleshooting] Lanchon:
kind invitation to read this thread:

[MENTION=912474]Dees_Troy[/MENTION]
[MENTION=2638973]bigbiff[/MENTION]

thanks!
[Android Q&A, Help & Troubleshooting] harddisk_wp:
All MediaTek SoCs can be considered compromised, for every single one of them allows the entire ROM to be read back and reflashed using spFlashTool, even with a "locked" 2nd stage bootloader. Furthermore, their source code quality can be considered as "rotten to the core", I would bet my behind on the Mediatek kernel customization containing more than one exploitable hole.
[Android Q&A, Help & Troubleshooting] Lanchon:
thank you for the contribution. it is good to know that all mediatek devices can be rooted and are effectively unbrickable.

it also seems that the opo is unbrickable: there seems to be a ColorOS leak that flashes the system by debug-booting the qualcomm soc.
[Android Q&A, Help & Troubleshooting] davru:
This is really important stuff… pitty how most people are more interested in skins than serious security issues. Hope it gets the attention it deserves.
[Android Q&A, Help & Troubleshooting] Lanchon:
i forgot to mention in the first post that Philz Touch Recovery does have password support. (i think they are actually PINs.) i haven't checked how the security is implemented in Philz though. regrettably that recovery has been discontinued so further investigation seemed useless.

TWRP is such a great piece of software that i simply can't imagine any competition will dare take on it again. that's exactly why it's important to get security merged in TWRP.
[Android Q&A, Help & Troubleshooting] bigbiff:
3 people in the entire world do a majority of the work for TWRP. We are welcome for contributions to the TWRP projcect at OMNI's gerrit for people who want to get this done.
[Android Q&A, Help & Troubleshooting] Lanchon:
i thought of that, but adding a feature like this to TWRP probably requires too much effort for somebody who doesnt know the codebase. i imagine that TWRP is sort of an app framework in itself. i chose to advocate for it instead of implementing, i just can't justify the effort it would take *me*. i also tried to help by centralizing ideas on how it should be implemented, if somebody chooses to.

anyway, it's great to know you are not opposing the idea and you would consider merging if somebody implements, that is a good start.

btw, there is a tangentially related issue i'd love to hear your opinion on:

i hear TWRP can mount encrypted partitions and there is a UI for entering PINs, passwords, patterns etc. but i dont have my phone encrypted because if i break my display with the phone encrypted then im toast: i cant extract my files from the device anymore.

would you consider implementing a way to enter the encryption password via usb? maybe some sort of adb shell command?
[Android Q&A, Help & Troubleshooting] Lanchon:
UPDATE: Added a third item to the OP...

3) Encryption is insecure unless the boot chain can be trusted.

An adversary that gains physical access to your phone can dump and save a copy of the encrypted partition(s) and plant a password sniffer that later forwards the password to them. You cannot trust your password to a non-tamper-evident device that can be trivially modified. The only way to protect the boot chain from tampering in today's phones is locking the bootloader and restricting access to the recovery.
[Android Q&A, Help & Troubleshooting] Xoib:
For instance, if we had a tool like https://play.google.com/store/apps/details?id=net.segv11.bootunlocker compatible with the OPO, it would be easy to have a pretty secure custom rom.

Scenario (encrypted of course) : unlocked bootloader, TWRP to flash some stuff, back to stock recovery then lock bootloader.

Each time you need back a custom recovery, you unlock the bootloader and to your stuff.

I always did that for the Nexus 4.
[Android Q&A, Help & Troubleshooting] Lanchon:
thanks!

no, it does not. android reference bootloaders (nexus, opo, etc) do not check kernel signatures when locked. they just disallow flash and boot commands. your point here is void.
[Android Q&A, Help & Troubleshooting] Lanchon:
personally i do not consider connecting the device to a host being any kind of bar raising at all. it is the realm of script kiddies and the standard way stolen phones are reset and/or returned to stock when they have a screen lock.

JTAG, on the other hand, is. it requires physically disassembling the phone and maybe modifying the board. it requires hardware and software tools that are not in the arsenal of the usual adversary. (i am not talking about the NSA!) i have JTAG hardware and use OpenOCD for hardware development but i have never attempted to JTAG a phone and probably never will. it is just too much trouble; not worth it.

modded phones will always be a minority. as long as mainstream phones do not need JTAG after being stolen, i predict modded phones that require JTAG to be recycled will not be recycled and will be sold for parts or maybe resold to the owner at a reduced price. (the "hey, i found this phone..." scenario.)
[Android Q&A, Help & Troubleshooting] Lanchon:
i do not. i do not encrypt my phone because i would not be able to access it with a broken screen. that proposition is unthinkable for me. i use software fallbacks such as keepass. this is a matter of priorities.

also, i dont consider the sdcard hack to be a valid alternative. i will answer to your thread here (but keep in mind that even if it were a valid alternative, this thread is about securing the recovery, not about other options):

-using an external encrypted sdcard with an untrusted boot chain leaves you vulnerable to all caveats of internal encryption, plus more. eg: wiping the phone to get control of its bootloader to plant an attack does not wipe the sdcard.

-the sdcard can be trivially dumped even with a trusted boot chain in place.

-many phones today, including my last 4 phones, do not even have sdcard slots (eg, most of the "free" phones: nexuses and the opo; some GPE phones do have slots) and you can expect the number keep falling down.

-sdcards are extremely slow compared to internal flash.

-sdcards tend to use much more power than internal flash.

-sdcards tend to be unreliable.

-the FTL in sdcards is not designed to handle the constant writing android will subject /data to. most FTLs do not provide good wear leveling, specially if cards are mostly full, and as a result the cards would probably fail soon.

-ASOP encryption of /data is all that is needed since the emulated "internal sdcard" is backed by storage in /data/media since reference android 4.0

-eMMCs in phones *do* provide secure erase commands! it has been a required part of the eMMC standard for years. commands are: SECURE ERASE and SECURE TRIM, and maybe later they added a SECURE DISCARD command, not sure. furthermore, reference android recovery does use these commands while wiping a phone.
[Android Q&A, Help & Troubleshooting] Lanchon:
this is not solution. you can do this with the opo. it is trivial to use adb shell or the terminal to unlock the bootloader.

but what if android does not boot for any reason? you loose access to your phone? this is not a valid alternative for me.
[Android Q&A, Help & Troubleshooting] Xoib:
How do you do that with adb/fastboot without wipe ? (I mean I know oem lock / unlock but unlock implied wiping right)

For your second point, even if I lost access to the android boot, I always get fastboot screen so for me it's a pretty good alternative.
[Android Q&A, Help & Troubleshooting] Lanchon:
you have to change one bit. you need to be root. there are threads that discuss how to, google them.
[Android Q&A, Help & Troubleshooting] Xoib:
Right, but adb don't use this trick.

That's why I said it will be cool when the bootunlocker app upgrade to handle OPO address bit.
[Android Q&A, Help & Troubleshooting] Defier525:
Thank you for these comments! But could you (re-)post the arguments concerning the fitness of sdcards for /data in the other thread, please? This way we could keep the discussion more focused.

JTAG vs. fastboot: I agree with you, JTAG is a much higher obstacle for a thief and probably most will not go this way while I guess most "bring back to stock" tools work over fastboot anyways. I was just considering a different scenario, e.g. you leave your phone unattended for some minutes on a party.

Data recovery in case of hardware failure: Well this is in conflict with getting more security, unless you additionally secure adb in Recovery like you proposed...

Internal sdcard in /data/media since AOSP 4.0: This was new to me, but it seems to be implemented this way in my Nexus S. I just wonder why my Xperia V does not handle it this way then?

eMMC and secure erase: Okay this was new to me as well. But afaik, TWRP does not use these commands for wiping, does it?

locked bootloader and password protected TWRP: What if an attacker would try to fastboot erase the data or recovery partition? Will a locked, properly implemented bootloader prevent that?

My sd hack in general: I agree, that if this hack only works with a unlocked bootloader (like probably on my Sony) it is less secure than having a locked bootloader even without encryption. Therefore, I was already considering re-locking the bootloader and disabling the hack, but using at least a non-stock userland. Yet, the stock kernel will probably not see any updates anymore and thus will be vulnerable to any upcoming threats.

Yet I think that we both agree in the point, that having password protected TWRP would enhance security. Since TWRP already has all means of a password-unlocker screen in place (for dealing with encrypted /data), it should be trivial to provide a patch which asks for a password before it lets you do anything in TWRP. Maybe if I find some time I can try to see what it would take to implement it, but I am quite busy these days.

Nevertheless, I am quite interested in discussing the security of locked bootloaders and any attack vectors over fastboot in general here.
[Android Q&A, Help & Troubleshooting] Defier525:
Out of curiosity, I tried the following on my Nexus-S:

- relock bootloader using "fastboot oem lock" (worked fine, shows status locked; trying to fast-boot another kernel is refused by the device)

- boot CM11 which was already there before re-locking using the locked bootloader (worked fine as well, seems not to check kernel signatures)

- send "fastboot erase data" from locked bootloader (worked fine as well !?! phone booted to fresh data partition):

$ fastboot erase userdata
erasing 'userdata'...
OKAY [ 0.272s]
finished. total time: 0.273s

Recovery - no matter if password protected or not - was not involved at all in the process. In case the phone was not encrypted, stuff in userdata would be lost but I could easily access the emulated internal storage. With some file recovery techniques, I should be probably also able to restore most stuff in userdata, since the "wipe" by "fastboot erase", which took less than 300ms, probably just wrote a new filesystem signature to the data partition without really wiping anything.

Now, if I can get root (i.e. if the previous rom was rooted already or an exploit exists) I can now easily flash a new password-unprotected recovery and revert everything back to stock. And probably so can the burglar which you wanted to lock out with password-enabled TWRP. To put it with your terms, I don't consider this for the list of "other phones which actually make an effort to defend your data. "

Since you counted all Google Nexus devices in your whitelist of "secure phones", can you please confirm that newer devices like Nexus 4, Nexus 5 or OnePlus One are not affected by this vulnerability?
[Android Q&A, Help & Troubleshooting] Lanchon:
devices that were released in android 2.x days with "internal sdcard" emulated in the phone's emmc typically have a fat32 partition that implements it. devices released with android 4.x typically have a fuse process that reflects some content under /data/media (ext4 or some other linux fs) as the sdcard, emulating fat32 properties (no fs level security, case insensitive file names, etc). when devices are upgraded from android 2 to android 4, either by the OEM or by hobbyists, they are typically not repartitioned and the original schema is maintained.

typically all custom recoveries do this because they are based on stock recovery, unless its disabled to work around some bug (brickbug in the exynos 4210 platform, long wipe times in the nexus 5, etc). for CM recoveries see:

https://github.com/search?q=BOARD_SUPPRESS_EMMC_WIPE+user:CyanogenMod&type=Code

locked fastboot means no change to the emmc is possible and no booting of kernels over usb. no exceptions made, no signatures are looked for. locked means fastboot is not an attack vector.
[Android Q&A, Help & Troubleshooting] Defier525:
I don't agree with you in these points:

- considering fastboot, please read my previous posting (probably posted while you were writing this). I definitely consider this a serious attack vector, at least on my Nexus S.

- considering partition layout, I posted the internal layout in stock ROM from my Xperia V in another forum. The Xperia V originally came with Android 4.0 (unlike the Nexus S) and it uses 15 partitions for the internal eMMC. Userdata and SDCard are on separate partitions, no matter how they are mounted later with fuse. Therefore, only wiping Userdata will not affect the internal sdcard at all.
[Android Q&A, Help & Troubleshooting] Lanchon:
the wipe in CM recovery is done here:

https://github.com/CyanogenMod/android_system_extras/blob/cm-11.0/ext4_utils/wipe.c#L42
[Android Q&A, Help & Troubleshooting] Dees_Troy:
The features you're asking for will likely only be used by a tiny subset of users on a small subset of the overall devices that we support. The number of devices that allow you to relock the bootloader and still allow you to boot an unsigned image is basically just Nexus devices and the OPO. The number of users that need / want the feature you're requesting is very small, probably less than 20 people.

The amount of time and effort needed to properly implement what you are requesting is not small. Finding a safe location and method to store the password will hardly be trivial. We need to make sure that adb is completely disabled until after the correct password is entered, otherwise an attacker would be able to use adb to bypass most of the security measures. We cannot safely store the password anywhere in /data because the data partition may be encrypted and thus not accessible.

You still haven't come up with a solution to a fastboot erase command that I believe still works on Nexus and probably the OPO devices even if the bootloader is locked. As I said in my write-up, your best case scenario if someone else gets hold of your phone is that they don't get access to your private data.

You might be able to enter a password on a device with a broken display using a USB keyboard and USB OTG cable. As mentioned earlier, leaving adb running leaves a humongous gaping security hole open that basically makes all of your arguments for better security null and void.

The fact that you don't encrypt your device and the fact that you aren't willing to do the development yourself tells me you aren't that serious about security.

I guarantee you that I have thought about this subject way more than you have. It's extremely unlikely that you're going to win this argument, and even if you "win", it's extremely unlikely that I'm going to develop this feature for you as part of regular TWRP development because of the limited benefit to the overall project. I do take contract work though, on occasion if it is something that you're serious about. It's not cheap though.

Also, for the record, the Nexus S does NOT have unified storage. You can get unified storage on the Nexus S using lvm and some other "hacks", but in stock form it does not have unified storage.