Database Develop

Brainstorm of remote exploit targets

Code:
Sooner or later it will be hard to get a rootable Chromecast. The community is limited by the number of people able to root their own devices. A remote exploit is desirable to expand the community. Please brainstorm and post progress in exploring the targets.
Targets:
Web interface
Chromecast executes commands to start netflix etc with user specified arguments. Arguments are sent through dial interface. From app.conf:
Code:
{ "app_name": "Netflix",
"external": true,
"command_line": "/bin/logwrapper /netflix/bin/netflix_init --data-dir /data/netflix/data -I /data/netflix/AACS -D QWS_DISPLAY=directfb -D LD_LIBRARY_PATH=/system/lib:/netflix/qt/lib -D NF_PLAYREADY_DIR=/data/netflix/playready -D KEYSTORE=/data/netflix/AACS -D KEYBOARD_PORT=7000 -D ENABLE_SECURITY_PATH=1 -D DISABLE_SECURITY_PATH_VIDEO=0 -D DISABLE_SECURITY_PATH_AUDIO=1 --dpi-friendlyname ${FRIENDLY_NAME} -Q source_type=12&dial=${URL_ENCODED_POST_DATA}",
"allow_empty_post_data": true,
"dial_info": "<port>9080</port><capabilities>websocket</capabilities>"
},
FFMPEG vulnerabilities
Intercepting updates (I know, the signatures would likely prevent this.)
Cable based attacks similar to current root methods
Soldering based attacks
Post your ideas and progress.
My chromecast is not rooted, so I can't get logs from netflix being run with different URL_ENCODED_POST_DATA, but we might be able to fork the command.

TVRemoteExploit said:
Code:
Sooner or later it will be hard to get a rootable Chromecast. The community is limited by the number of people able to root their own devices. A remote exploit is desirable to expand the community. Please brainstorm and post progress in exploring the targets.
Targets:
Web interface
Chromecast executes commands to start netflix etc with user specified arguments. Arguments are sent through dial interface. From app.conf:
Code:
{ "app_name": "Netflix",
"external": true,
"command_line": "/bin/logwrapper /netflix/bin/netflix_init --data-dir /data/netflix/data -I /data/netflix/AACS -D QWS_DISPLAY=directfb -D LD_LIBRARY_PATH=/system/lib:/netflix/qt/lib -D NF_PLAYREADY_DIR=/data/netflix/playready -D KEYSTORE=/data/netflix/AACS -D KEYBOARD_PORT=7000 -D ENABLE_SECURITY_PATH=1 -D DISABLE_SECURITY_PATH_VIDEO=0 -D DISABLE_SECURITY_PATH_AUDIO=1 --dpi-friendlyname ${FRIENDLY_NAME} -Q source_type=12&dial=${URL_ENCODED_POST_DATA}",
"allow_empty_post_data": true,
"dial_info": "<port>9080</port><capabilities>websocket</capabilities>"
},
FFMPEG vulnerabilities
Intercepting updates (I know, the signatures would likely prevent this.)
Cable based attacks similar to current root methods
Soldering based attacks
Post your ideas and progress.
My chromecast is not rooted, so I can't get logs from netflix being run with different URL_ENCODED_POST_DATA, but we might be able to fork the command.
Click to expand...
Click to collapse
what if somehow we were able to attack it like jailbreakme used to. Looking at the developer options in chrome you could write a program for your phone that has the cast button when you click it, it'll tell chrome cast to go to the apps domain where it automatically roots for you. I'm no developer, so i don't even know if that kind of hack would even be possible. I did download the cast app for windows and it has a button for factory reset. Would it be possible to hack that chromecast program and change the factory reset to use a hacked pulled firmware?

scarygood536 said:
what if somehow we were able to attack it like jailbreakme used to. Looking at the developer options in chrome you could write a program for your phone that has the cast button when you click it, it'll tell chrome cast to go to the apps domain where it automatically roots for you.
Click to expand...
Click to collapse
This would be extremely difficult to pull off, as you would need to both escape Chrome's sandbox and find a privilege escalation vulnerability in the Linux kernel or a setuid binary. Both Chrome and Linux are extremely mature and secure pieces of software, so vulnerabilities are few and far between and get patched quickly when they are found.

I tried tacking commands onto the tail of the netflix commands like this:
Code:
curl ****192.168.1.126:8008/apps/Netflix -X POST -d "intent=play&titleid=***%3A%2F%2Fapi.netflix.com%2Fcatalog%2Ftitles%2Fmovies%2F70138593;reboot"
, however I can't see the log file without root.

tchebb said:
This would be extremely difficult to pull off, as you would need to both escape Chrome's sandbox and find a privilege escalation vulnerability in the Linux kernel or a setuid binary. Both Chrome and Linux are extremely mature and secure pieces of software, so vulnerabilities are few and far between and get patched quickly when they are found.
Click to expand...
Click to collapse
so is our best bet to find a vulnerability within the hardware level we could utilize and wouldn't have the chance of being patched?

In all honesty, the best method of attack would be to figure out the JTAG port. with that, you could then simply just flash back on the rootable bootloader on any device, and go from there. I doubt any software methods will be found, and even if one is found, it will be patched by google within a month. The JTAG port however is at a hardware level, and unless it actually does signature checks (like the USB method does on updated devices), it would allow a person full control of the flash chip.
EDIT: To clarify, if the UART port is hardware based (like normal JTAG ports on wireless routers and such), then there should be no security checks. If, for whatever reason, it is software based though (so like fastboot, or Samsungs ODIN mode), then there is a chance it checks image files.

ddggttff3 said:
In all honesty, the best method of attack would be to figure out the JTAG port. with that, you could then simply just flash back on the rootable bootloader on any device, and go from there. I doubt any software methods will be found, and even if one is found, it will be patched by google within a month. The JTAG port however is at a hardware level, and unless it actually does signature checks (like the USB method does on updated devices), it would allow a person full control of the flash chip.
EDIT: To clarify, if the UART port is hardware based (like normal JTAG ports on wireless routers and such), then there should be no security checks. If, for whatever reason, it is software based though (so like fastboot, or Samsungs ODIN mode), then there is a chance it checks image files.
Click to expand...
Click to collapse
Unfortunately (although I don't believe anyone has confirmed this on the Chromecast), all known GTV devices with this SoC ship with their JTAG port disabled. It may be possible to re-enable it in software, but (of course) that requires running your own kernel. The only hardware hack I know of that is sure to work is manually soldering a NAND flasher up to the memory chip and rewriting the partitions that way, which is expensive, error-prone, and extremely tricky to do right.

tchebb said:
Unfortunately (although I don't believe anyone has confirmed this on the Chromecast), all known GTV devices with this SoC ship with their JTAG port disabled. It may be possible to re-enable it in software, but (of course) that requires running your own kernel. The only hardware hack I know of that is sure to work is manually soldering a NAND flasher up to the memory chip and rewriting the partitions that way, which is expensive, error-prone, and extremely tricky to do right.
Click to expand...
Click to collapse
The more you know.
Well, while looking through the chromecast's "fts" partition in a hex editor, I found the following variable show up in multiple places.
Code:
device_configured=true
makes me wonder what happens if this is flipped to false. I will look through the bootloader source more to see if it is used at a software level.
EDIT: Doesn't look like it does anything for us, seems to just enable the crash counter.

tchebb said:
Unfortunately (although I don't believe anyone has confirmed this on the Chromecast), all known GTV devices with this SoC ship with their JTAG port disabled. It may be possible to re-enable it in software, but (of course) that requires running your own kernel. The only hardware hack I know of that is sure to work is manually soldering a NAND flasher up to the memory chip and rewriting the partitions that way, which is expensive, error-prone, and extremely tricky to do right.
Click to expand...
Click to collapse
ddggttff3 said:
The more you know.
Well, while looking through the chromecast's "fts" partition in a hex editor, I found the following variable show up in multiple places.
Code:
device_configured=true
makes me wonder what happens if this is flipped to false. I will look through the bootloader source more to see if it is used at a software level.
EDIT: Doesn't look like it does anything for us, seems to just enable the crash counter.
Click to expand...
Click to collapse
ddggttff3 said:
In all honesty, the best method of attack would be to figure out the JTAG port. with that, you could then simply just flash back on the rootable bootloader on any device, and go from there. I doubt any software methods will be found, and even if one is found, it will be patched by google within a month. The JTAG port however is at a hardware level, and unless it actually does signature checks (like the USB method does on updated devices), it would allow a person full control of the flash chip.
EDIT: To clarify, if the UART port is hardware based (like normal JTAG ports on wireless routers and such), then there should be no security checks. If, for whatever reason, it is software based though (so like fastboot, or Samsungs ODIN mode), then there is a chance it checks image files.
Click to expand...
Click to collapse
Maybe I'm missing something, possibly am, but couldn't we dual boot firmwares? Have the normal factory firmware on the eMMC chip, then, install a rooted image to a USB stick. Next solder a different wire to each side of pin 26, finally solder a switch in between. This should force the device to load off the USB rather than eMMC. On paper it works. On the physical device? That could be a bit different. If you do try this, I'll do my best to help you and point you in the right direction.
The switch is to choose between the two firmwares, if however, you only want to boot from the USB, you could, possibly, just have a permanent jump of pin 26. That should force booting from the EMMC to fail every time forcing it to boot from USB.
NOTICE: none of these suggested ideas have been used and or tested. They work on paper only! The real device may, and possibly is, different! Attempt at your own risk.
OP, XDA, nor I am responsible for anything that happens to your device. If anything does happen it's completely on you! This is a dangerous hardware mod, I don't recommend if you don't know how to solder. Also, the points for pin 26 are very very small, smaller than some solder iron's tips. All of mine are way too big, and I have bought small tips to use on other mobile devices. If you mess this up there is none to very little chance of going back.
SECOND NOTICE: constantly jumping the 26th pin of the CPU could cause permanent hardware problems. If such problem does happen, it is not known at this time. Once again, this is a dangerous hardware mod that should not be attempted by those who aren't good with soldering.
The good news: if you do attempt this and it works, we could have a hardware way to be rooted. More good news is that if you mess up and can't fix it, then it's only $35 to get a new one.
Aaron Swartz, Rest in Pixels.

jamcar said:
The switch is to choose between the two firmwares, if however, you only want to boot from the USB, you could, possibly, just have a permanent jump of pin 26. That should force booting from the EMMC to fail every time forcing it to boot from USB.
Click to expand...
Click to collapse
Just to let you know, a permanent jump to pin 26 will cause the device to not boot, at all. It causes a read interrupt to the EMMC, so if jumped permanently the device will not see the flash, so it wouldn't even load the bootloader. Jumping the pin should ONLY be used if the standard button hold boot process does not work.

jamcar said:
Maybe I'm missing something, possibly am, but couldn't we dual boot firmwares? Have the normal factory firmware on the eMMC chip, then, install a rooted image to a USB stick. Next solder a different wire to each side of pin 26, finally solder a switch in between. This should force the device to load off the USB rather than eMMC. On paper it works. On the physical device? That could be a bit different. If you do try this, I'll do my best to help you and point you in the right direction.
The switch is to choose between the two firmwares, if however, you only want to boot from the USB, you could, possibly, just have a permanent jump of pin 26. That should force booting from the EMMC to fail every time forcing it to boot from USB.
NOTICE: none of these suggested ideas have been used and or tested. They work on paper only! The real device may, and possibly is, different! Attempt at your own risk.
OP, XDA, nor I am responsible for anything that happens to your device. If anything does happen it's completely on you! This is a dangerous hardware mod, I don't recommend if you don't know how to solder. Also, the points for pin 26 are very very small, smaller than some solder iron's tips. All of mine are way too big, and I have bought small tips to use on other mobile devices. If you mess this up there is none to very little chance of going back.
SECOND NOTICE: constantly jumping the 26th pin of the CPU could cause permanent hardware problems. If such problem does happen, it is not known at this time. Once again, this is a dangerous hardware mod that should not be attempted by those who aren't good with soldering.
The good news: if you do attempt this and it works, we could have a hardware way to be rooted. More good news is that if you mess up and can't fix it, then it's only $35 to get a new one.
Aaron Swartz, Rest in Pixels.
Click to expand...
Click to collapse
This wouldn't work with any post-12072 bootloader, since the USB image's signature is still checked. The signature verification would simply fail and the device would fail to boot, same as if.you tried to boot from USB with a button press.

Force Eureka firmware ?

Where is the firmware stored (ie chip)
Inside the Chromecast? My thinking maybe off but is it possible to have the unit boot and load the firmware we want if the firmware is manually written to memory? I have not found much information on the JTAG port, but I see it also has 16gig TSOP as well with a 4 or 8 gig DDR memory. I assume the DDR is used for a buffer for the CPU and the memory in the CPU is for storing the bootloader . so hoping the TSOP is where the firmware is stored. If we were able to write the firmware there would we be able to achieve our needed root, or would the current firmware on the chip be useful for finding an exploit to root?
Would think unless we are changing the bootloader when we root the unit now at low serial numbers I would think it would be the same as is writing a ROM to a phone and using a factory bootloader.
Correct me if I am all messed up here please.
1080xt root 12.15.15

rekids said:
Where is the firmware stored (ie chip)
Inside the Chromecast? My thinking maybe off but is it possible to have the unit boot and load the firmware we want if the firmware is manually written to memory? I have not found much information on the JTAG port, but I see it also has 16gig TSOP as well with a 4 or 8 gig DDR memory. I assume the DDR is used for a buffer for the CPU and the memory in the CPU is for storing the bootloader . so hoping the TSOP is where the firmware is stored. If we were able to write the firmware there would we be able to achieve our needed root, or would the current firmware on the chip be useful for finding an exploit to root?
Would think unless we are changing the bootloader when we root the unit now at low serial numbers I would think it would be the same as is writing a ROM to a phone and using a factory bootloader.
Correct me if I am all messed up here please.
1080xt root 12.15.15
Click to expand...
Click to collapse
That pretty much what FlashCast did until Google plugged the hole that would let you hijack the boot process....
I don't know how diligently some have been looking but since Google plugged that hole there seems to be no way into the CCast anyone can find.

rekids said:
Where is the firmware stored (ie chip)
Inside the Chromecast? My thinking maybe off but is it possible to have the unit boot and load the firmware we want if the firmware is manually written to memory? I have not found much information on the JTAG port, but I see it also has 16gig TSOP as well with a 4 or 8 gig DDR memory.
Click to expand...
Click to collapse
It was written elsewhere that the gtvhacker team found the JTAG pins are disabled at the hardware level.
There was also mention that there may be a device-specific encryption, but no confirmation on that. Someone with an eeprom programmer and soldering station who can swap chips would have to confirm.

That I have (chip programmer and soldering station) just have not decided if it was stored on the 48 pin TSOP as that is the easiest to gain access to. This one of couple of things I would need to know or at least have a good idea about before tearing my noon rooted unit apart for.
IF ... The firmware is stored there and I had an image of the Eureka firmware that needs to be on the TSOP then tearing it apart is worth the test. I don't see the software being encrypted to the device since JTAG has been disabled seams like a lot of work and keys needed for a simple device and low cost but I could be wrong. The other thing I would need to do is go through the data sheet on the TSOP to see if it has a write once area or a locked portion that would require a key from CPU to allow writing, but kinda doubt that.
So if some one has info on the actual image preferably a .bin image of eureka in the correct data location would be great.
My thought is if it is that simple then ISP maybe possible for the average tinker with a simple chip programmer or even make it possible for some one to program on a larger scale for a small fee of like $5 or $10 instead of $100 on EBay or finding the last few with old software out there.
1080xt root 12.15.15

I like this thread hopefully it will be cracked open...just like the ps3 was miraculously despite many theories that it was impossible to hack even after sony plugged the holes again and again
Sent from my Nexus 5 using Tapatalk

Just a small update. Removed the TSOP and went to read it using factory default settings and found the first 141 bocks are invalid and the rest of the chip was blank "FF". Changed the settings to not skip over the 141 blocks and got a 2 gig data file. Not sure if this a good thing yet need to sort through to see if any of the data is intact valid. My Chromecast is using current firmware. The TSOP does hold 16gigs of data. Only data seen so far is up to data block 3F3C000 then blank from that point on.
Could really use another TSOP from another Chromecast even a dead one for comparison.
1080xt root 12.15.15

Not sure, but maybe @Team-Eureka has a dead CCast they can donate/lend to your effort...

Need some help from some one who knows a few things about the Chromecast.
What I able to do right now is read and write what ever is stored on the 16 gig TSOP that is in the Chromecast. As far as I can see this is where the firmware should be stored.
The idea is to write the firmware that is desired to the TSOP and have the Chromecast boot that software instead.
Problem ... The data that is recovered from my Chromecast that is up to date has about 200-500 MB of data towards the beginning of the blocks and a few more MB just before the end of the blocks. The total .bin file is about 2.2 gigs. When viewing the contents of the .bin there is no readable text (example "Google , version, build" and so forth) and there is usually at least something in text format when viewed in WinHex of other devices that I have read and written to in the past.
What I don't know is where exactly is the TSOP the firmware begins or ends, location of checksum (s) and an image of Eureka firmware as it is written on the TSOP.
Possible solution is a TSOP that has had the firmware already loaded or an image of that TSOP or possibly even the rootable firmware image.
Any help is great. I have been on the IRC channel of Eureka and Gtvhacker and asked there but had no response.
The programmer I have is an older Dataman 48pro (newer version is more efficient and does multiple chips at once) it is very reliable and takes about 20 minutes for a complete read of the 16 gig TSOP. The chip does need to be removed and placed in the adapter to read since ICP is not spotted by the TSOP and from my research the JTAG or UART has been disabled I suspect with in the processor.
Any one with info or even idea would be great.
Thanks
Rekids

Team Eureka hangs out in #team-eureka though they've been busy lately... Wish I knew more but hardware is my weakness.

bhiga said:
Team Eureka hangs out in #team-eureka though they've been busy lately... Wish I knew more but hardware is my weakness.
Click to expand...
Click to collapse
we are here, we are just quiet NAND dump was sent his way.

Thank you and yes understand being busy, I work 40+ them got stuff I do at home with 4 kids and the wife not to mention I do a few things out of town each week.
I did get a full NAND image just got to compare with the read I got and see if there online with each other as to location and type of code in case it is different after it passes through the CPU.
Will keep you posted, as to findings.
1080xt root 12.15.15

Just in case of anyone is following this,
I did get the bootloader downgraded to a TOtable version written on the NAND. Down side is was not able to get the NAND remounted well enough for a boot without some liquid flux I had lost around the house some where so ordered some more. It is definably possible to change all the data in the NAND with a programmer but the NAND has to be removed from the PCB and then remounted. But have to wait for supplies to show up and then a day I can play around with this project again.
The Chromecast I am working with is one with the serial number of 3B and it has updated to the the most recent firmware.
Any how will post when I have it boots again
1080xt root 12.15.15

rekids said:
Just in case of anyone is following this,
I did get the bootloader downgraded to a TOtable version written on the NAND. Down side is was not able to get the NAND remounted well enough for a boot without some liquid flux I had lost around the house some where so ordered some more. It is definably possible to change all the data in the NAND with a programmer but the NAND has to be removed from the PCB and then remounted. But have to wait for supplies to show up and then a day I can play around with this project again.
The Chromecast I am working with is one with the serial number of 3B and it has updated to the the most recent firmware.
Any how will post when I have it boots again
1080xt root 12.15.15
Click to expand...
Click to collapse
Wow, great work [emoji3][emoji106]
Although, this is a method what only few users might use, I'm glad to see someone doing this kind of stuff.
Eagerly waiting to hear if you manage to pull it together and eventually root your device [emoji2]
Sent from my Nexus 4

Can't wait to hear your upcoming updates either. Good work
Sent from my Nexus 5 using Tapatalk

rekids said:
Just in case of anyone is following this,
I did get the bootloader downgraded to a TOtable version written on the NAND. Down side is was not able to get the NAND remounted well enough for a boot without some liquid flux I had lost around the house some where so ordered some more. It is definably possible to change all the data in the NAND with a programmer but the NAND has to be removed from the PCB and then remounted. But have to wait for supplies to show up and then a day I can play around with this project again.
The Chromecast I am working with is one with the serial number of 3B and it has updated to the the most recent firmware.
Any how will post when I have it boots again
1080xt root 12.15.15
Click to expand...
Click to collapse
lots of us are following.
this is great news.
but yes only for advanced users. but once it is perfected a clip could probally be made like the ps3/360 nand clips

Just to be sure every one is aware all thanks goes to those who really deserve it Gtvhackers for the original and only exploit that we have, and every one at Team Eureka, and above all else a very helpful and encouraging person who has helped with the vital info that was needed and willing to spend time helping me out and not knowing a thing about me (just a noob)
Thanks ddggttff3, for the help so much.
1080xt

Could this be used to flash the tsop without desoldering?
http://www.ic2005.com/shop/product.php?productid=137&cat=0&featured=Y
I've been out of the modding scene for years and haven't kept up.
Sent from my Nexus 4 using Tapatalk

Looks like more a way to connect while mounted then a way to program. The NAND requires a particular set instructions to do anything really. The way I understand what needs to happen to program and write are a couple of things,
1 connection to the right pins (obtain with the item you mentioned our to place in a adapter with individual connections for each pin)
2 uninterrupted communication (may have issue with resistors, caps, CPU and any other items on board connected to NAND)
3 instruction set for communication to the NAND to have it do what you want.
I have not come across anything as of yet suggesting in In circuit programming is possible out side of the use of the UART or JTAG. And since as far as I can find the correct set of UART pins are not connected and the JTAG is either disabled or not connected makes in circuit programming not possible as of right now.
A data sheet on the 88DE3005 has not been found by me as of now. Marvell seams to keep that info unavailable to us.
A map out of the armada mini would be great and a pin out of the board connections would help to see if that would be possible in the future.
1080xt 4.4

So got my stuff to remount the NAND with the changed bootloader to the exploitable one and .. no boot. Not sure what exactly went wrong got a sneaky feeling it may have died during the attempt to remount before I got my stuff with a big fat solding iron. Gonna go get another and try again.
It is definitely easier to remount when you use liquid flux and not just trying to hit each leg with solding iron.

Any news? Have we found a hardware method of rooting?

What exactly does encryption do?

I ask because after installing stock MRA58R the contents of my N6 were still visible in Windows Explorer. So I reformatted userdata & cache, and then used the new NRT 2.0.7 to flash MRA58R again - wipe, no root, no recovery, no no-encrypt, just bog-standard install. The "Encrypting device" appeared for literally a few seconds, and now as it's sitting re-installing my apps from Google I can still see the contents of internal memory in Explorer. No USB debug, just a "Use USB for file transfer".
I have a multi-digit PIN on the phone, set up as part of the initialisation process.
I went through all this because my wife's phone was stolen last weekend and it was a wake-up call for me about my data security.
I'm sure I'm being particularly stupid. Can someone please educate me?
Thanks...

And maybe I'm answering my own question...
The contents are visible to me because I entered the device PIN?
Anyone without the PIN gets to see nothing?
And that includes any access via ADB/fastboot?
But is this any different from a non-encrypted device?

dahawthorne said:
Anyone without the PIN gets to see nothing?
Click to expand...
Click to collapse
It is a method to store data that is only readable with the key used for encryption.
Your pin is something different and is used for access permission of a device.

Thanks, but my understanding is that the device PIN is the encryption key. You can't set encryption without having a device PIN. What else could it possibly be using?
So I guess I still don't understand if having my device encrypted is any better than having a simple PIN-secured unencrypted device. If someone can see my data via bootloader mode or some other back door how secure is it?
If I look at an encrypted file I expect to see hieroglyphics. That's not what I'm seeing here. I see either nothing at all because the device isn't recognised by my PC, or I have full access to the data.
So what effect should I expect to see that is different/more secure than a simple PIN-protected device? What's the actual benefit of encryption?

dahawthorne said:
Thanks, but my understanding is that the device PIN is the encryption key. You can't set encryption without having a device PIN. What else could it possibly be using?
So I guess I still don't understand if having my device encrypted is any better than having a simple PIN-secured unencrypted device. If someone can see my data via bootloader mode or some other back door how secure is it?
If I look at an encrypted file I expect to see hieroglyphics. That's not what I'm seeing here. I see either nothing at all because the device isn't recognised by my PC, or I have full access to the data.
So what effect should I expect to see that is different/more secure than a simple PIN-protected device? What's the actual benefit of encryption?
Click to expand...
Click to collapse
Ill be honest. Your device is only as secure as the person that steals it. No amount of security has been 100% proven to prevent the data being attainable if they have access to the device its self. While I am not saying the average thieve will be bale to do it but, then all they care about is the device and end up wiping the device and reselling it without a care about the info inside it.

dahawthorne said:
Thanks, but my understanding is that the device PIN is the encryption key.
Click to expand...
Click to collapse
That wouldn't be a good encryption, you usually need at least 256 bits to encrypt a volume. The pin is only to unlock the encryption key that's stored on a separate partition. Also to unlock the phone.
If you stick a USB cable into a phone that's on, it switches to USB charging mode by default, so you need to unlock it to change it to MTP or Camera. If you want to connect as USB debugging, you first must allow the new computer's fingerprint to connect, so you need the pin to unlock the phone again.
If encryption is used correctly, then you must enter your pin to resume boot. But you can just set MTP as default connection in a custom ROM, build it as userdebug that doesn't require ADB fingerprint, and set pin for unlocking lock screen only

Thanks, people. It looks like encryption is pretty well pointless then if any Tom, **** or Harry can just install a new ROM or recovery and get access to the data... Burning my battery for nothing but a lot of security hot air...?
Speaking of which, I've just rebooted my phone and despite having checked the "Require passcode to start Android", which actually did work at least once (meaning I had to enter a PIN 3 times, for Android, SIM and device), this time there was no Android challenge, only SIM & device.
This security really isn't up to the job at all.

That is incorrect. With out knowing the key, as long as you select require pon at boot, the only thing they could do is reformat your phone and continue using it. No matter what, the key to your data is needed to access it.

dahawthorne said:
Thanks, people. It looks like encryption is pretty well pointless then if any Tom, **** or Harry can just install a new ROM or recovery and get access to the data... Burning my battery for nothing but a lot of security hot air...?
Click to expand...
Click to collapse
I really don't get where this comes from?!? It's a very serious security measure, and it's really not its fault if people dynamite holes into the phone's security like using userdebug builds, and having custom recoveries.
The point is, you have to decide if you want a phone open for modding and to use to store sensitive data on it. There isn't a system that really can accommodate both.
But if you don't have any sensitive data on your phone then encrypting is really pointless.

Thanks again, guys.
@scryan - "select require pin at boot" - does this mean the "require PIN before starting Android"? This is what I mentioned I had but now I don't. An extra layer of security disappeared for no reason I can think of, and I see no option to switch it back on, since the only time it was offered to me was during the initial setup. I still have SIM lock and device lock, but more is better, no?
@istperson - I get the trade-off between security and flexibility. I would consider my photos, for example, to be secure data - even if I'm happy showing them to people I know, I don't want strangers poking around in them.
So bottom line - I still see no argument that says that encryption provides something that the PIN doesn't. How exactly is a PIN-protected encrypted phone more secure than a PIN-protected unencrypted phone?
Edit: I found the "require PIN on boot" option in one of the security tabs, and it appears to work. Back to 3 levels of security, but still in the dark about encryption benefits.

dahawthorne said:
So bottom line - I still see no argument that says that encryption provides something that the PIN doesn't. How exactly is a PIN-protected encrypted phone more secure than a PIN-protected unencrypted phone?
Click to expand...
Click to collapse
If they hit you on the head, take your phone, tear it apart, and remove the sdcard, it won't be readable because of the encryption. If it's unencrypted they can access every data.
But don't store naked selfies on you phone. or in the cloud, then you're safe.
Also the pin to boot doesn't go away by itself without tinkering. Go back to Settings/Security and switch on the Require pin to boot, or whatever it's called.

Basically encryption is how the data is stored on the device. Instead of the normal readable format, its scattered all around in a pattern that requires a key to calculate how to put it all back together.
When you computer goes to read a file, it pulls out a chunk of data, looks at what the right pattern is, then ignores the pieces it doesn't need.
When you phone is running you dont see any of this, because your phone is always in the middle decoding.
If I tried to access your data by circumventing the OS and its checks, all I would see was scrambled randomness.
Decent little wiki entry from arch linux
https://wiki.archlinux.org/index.php/Disk_encryption#How_the_encryption_works
Its more aimed at computers, but its the same thing...

"it won't be readable because of the encryption."
That I understand - thanks. I suppose I was just a bit uneasy because it seems a bit too simple to get in, but obviously tinkering with my own device is far simpler than tinkering with someone else's.
I'll put this one to bed now. I'm very grateful for everyone's patience in answering my questions.

[kernel][RnD][rom] Running Arch Linux Arm with mainline linux on Jemlte

Hi, everyone.
Some time ago I've been working on getting mainline linux to work on our device.
I was mostly interested in running desktop GNU/Linux, not Android, not in chroot.
I used it in Uni for occasional coding, in order not to carry laptop with me.
I'm not sure if I'll continue to actively develop and maintain it, so I decided to share my work with whoever might be interested in it.
However if there would be community interest, I might continue to improve support.
Or maybe someone would like to help me with this undertaking.
The code is not based on amazon kernel, and don't use legacy board files, but is Device Tree based.
Most of the basic hardware works, however, some don't, and would be nice if someone smarter or more stubborn than me helps to troubleshoot it.
What works:
It boots)
Serial console - needs device disassembly, convenient for debugging
eMMC
Display panel with backlight - 18bit mode, without dithering.
HDMI display (hotplug, modeswitching)
USB device - works as usb cdc, handy for SSH access and configuration.
Charging - uses driver from stock kernel
Battery monitoring - doesn't strictly match android measurements, but works.
WiFi - uses brcmfmac driver, needs firmware, haven't tested it outside of regular client mode, not shure if either hotspot or p2p works.
Bluetooth - needs firmware uploaded from userspace, however may be rewriten with serdev interface.
Touchscreen - uses driver from stock kernel.
Vvolume gpio keys
Power button - connected to power management chip
Vivante gc320 - gives a nice speedup for X11 and Xv scaling.
Hall sensor (protective cover (lid) sensor)
Case thermal sensor
Audio codec - headphones, speakers, microphones not tested
LTE modem - can be used for data and SMS but not calling (unless you figure out how to ). Not sure about positioning (if it is available on this modem)
What doesn't work:
Sound - codec works, but I failed to make it properly communicate with omap, am I missing something obvious? works now: mclk pinmux was misconfigured
Camera - not really interested in it anyway.
RPROC - see notes below
[*] DSP - seems to be not used on stock andoid at all;
[*] IPU - required for camera and video encoding/decoding acceleration
[*] IVA-HD - part of VPU.​
GNSS - provided by the same chip as Bluetooth, but communicates via some obscure protocol from userspace.
PoverVR gpu.
What could be brought up with small effort (supposedly):
Various sensors:
IMU: accelerometer, gyroscope, compass.
Hall sensor - protective cover lid
ambient light sensor
various thermal sensors.
LTE (might actually have GPS in it, or call functionality, who knows...)
Bugs:
Bluetooth needs to be enabled in android prior to (hot) reboot to linux, I'm obviously missing some port configuraion.
USB host technically works, but is disabled since it needs some work. (And it makes high pitched noise while 5v booster is on though)
Suspend/resume mighth not work Should work :silly: (proper power management needs newer u-boot).
Charging sometimes get's limited to 500mA -- smb347 driver needs some debugging.
CPU Idle is disabled, not really shure what's wrong with it.
Frequency scaling is not perfect (since omap4470 is not really supported in mainline kernel).
HDMI DDC - EDID reading corrupted, looks like some issues with ddc pullup/esd protection chip, sometimes it might even work. If someone with osciloscope is interested in debugging, you are welcome. And one more thing: after you reboot back to android hdmi wouldn't work here for some time, untill it gets back to normal. Resolved.
Remoteproc functionality (DSP, IPU) for omap chips is not really present in mainline. It IS in TI kernel, I was able to build firmware for ducati, and run it.
But was unable to make it properly communicate with userspace.
Someone experienced with it might help.
What is unlikely to EVER work:
SGX544sc has no userspace drivers, so unless you have some contacts at TI who would bother to compile it, this gpu won't work.
Camera requires some code running on IPU, which, AFAIK, was never opensourced.
Boot process:
The kernel is booted directly via second bootloader.
For now without initramfs, so it needs a separate partition on eMMC for rootfs.
With initramfs, on the other hand, one may put rootfs on the regular `data` partition, either as file or in directory.
Works nicely along with regular Android: with a small tweak to bootloader you can boot either via volume key combination.
The bootloader is configured to boot from `dkernel` partition if both volume buttons are pressed.
Dkernel partition initially contains kernel for factory device check and is not used in regular device operation. Still, you may wish to back it up if you feel like you may need it at some point.
You may choose whichever linux distribution you like, I'm using archlinuxarm for now.
I'll provide a more detailed manual, and flashable binaries, alongside with rootfs later,
But for now, if you know what you are doing, here are some sources:
kernel (current working branch is `integration-4.18`, use omap4jem_defconfig)
u-boot (will upload source code later, for binary build see attachment)
Basic outline of required steps are:
replace secondary bootloader in your main boot partition
rebuild dkernel, with zImage build from sources and flash it.
shrink your 'data' partition
add new partition on your eMMC for your rootfs and format it to ext4 or f2fs
unpack your rootfs onto it
mount and chroot into it to make basic configuration
boot.
A video demo:
https://www.youtube.com/watch?v=mpjwL4VRS-E
Have a nice day!

ipipipipip said:
...
Click to expand...
Click to collapse
Sorry for jumping on the bandwagon a little late here. Seems like a promising project. If you managed to get mainline 4.18 to at least boot (which sounds hard in and of itself), how would it work out if it booted nicely on Android? that wouldn't be too bad of a prospect. Complicated, yes, but maybe remotely possible. I'd be willing to test drive it on my non-lte jem - after I give this project a spin, of course.

A quick update:
Bluetooth now neither require to be powered on prior reboot (there was a clock that I forgot to enable that prevented bcm module from starting), nor a user-space firmware upload.
It now uses serdev bus and kernel-space driver to upload firmware, that removes the hassle of adding system daemon that will properly initiate bluetooth with the correct tty.
There is no proper way for now to check what version of jem/jemlte device you are using so you have to rebuild the kernel with the correct firmware in "firmware/brcm/BCM2076B1_26MHZ.hcd". The default firmware is for lte version, so if you use non-LTE version please replace the file "firmware/brcm/BCM2076B1_26MHZ.hcd" with the 20MHZ one from the same directory (just remove the 26MHZ one, and change 20MHZ to 26MHZ in file name).
WiFi no longer causes issues on resume, and device suspends and resumes properly (more or less), I haven't measured battery drain)
Bad news:
I've bricked my device and not sure if I still can revive it, looks like eMMC is almost dead. Or another case of crappy samsung moviNand firmware.
It is detected over USB as OMAP4470 device and it looks like cpu does not detect emmc.
After about 5 minutes (some kind of watchdog??) it manages to boot u-boot aka fastboot. Any other action that tries to modify content on emmc causes the flash controller lockup and communication with it is no longer possible.
Soldering wires directly to pcb pads doesn't help much, the card is not detected by card-reader.
The main idea for now is to use vendor command 62, as mentioned in one of #Hashcode's posts to wipe all the content of the chip. The problem is that I have wiped linux partition and can't boot into any kind of working linux system on the device. (Recovery tries to mount some partitions rw and thus makes flash chip inaccessible). Guess it's time to make an NFS rootfs and boot the device over USB network.... Or maybe someone knows how to prevent TWRP from accessing partitions on device?
In the worst case scenario I'll have to replace emmc chip (if it's not glued too hard in place), curious if some 128GB will work
Or maybe someone has a spare PCB, or a broken device that they no longer need and may donate?

monster1612 said:
Sorry for jumping on the bandwagon a little late here. Seems like a promising project. If you managed to get mainline 4.18 to at least boot (which sounds hard in and of itself), how would it work out if it booted nicely on Android? that wouldn't be too bad of a prospect. Complicated, yes, but maybe remotely possible. I'd be willing to test drive it on my non-lte jem - after I give this project a spin, of course.
Click to expand...
Click to collapse
There will be no GPU or video decoding acceleration, which might be a problem with modern apps, if you wish, go on and try, might be interesting to have a look, I don't have much experience in building android ROM's.

Sup, have some news on the progress of the project
An eMMC on my tablet died completely, thus I had to replace it with another one. My initial intent was to place some 64gig SanDisk emmc 5.1 from ebay, but I was not sure if it'll work with omap4 and that I won't fry it in the process of replacement. So I've bought some similar scrapped 16gig variant from a local reseller for a couple of pennies. After recovering partition layout and bootloaders the tablet came back to life, thus it's pretty safe to put whatever eMMC chip you have on your hands in your tablet) (it's time to order a larger capacity flash now, 16 gig is rather scarce for both android, arch and some content). The trusty old stock kernel, on the other hand, needed a tiny patch to let kernel understand a flash from the future. The driver checks for known emmc protocol version and unloads flash driver if the revision is too high.
Now feeling more confident in unbrickability of my tablet, I've gone an extra mile of porting mainline U-Boot bootloader to the tablet.
The port is pretty minimal, just support for serial port, usb/fastboot, and framebuffer console. Since pinmuxing and HW initialization is done via stock bl, nothing much to do. But it adds ability to freely manipulate boot sources, kernels, ramdisks, supports dtbs and overlays, environment save/restore, and external boot scrips on a FAT boot partition ). For some reason bootloader font is corrupted and hard to read, bit it should be easy to fix.
The good parts:
kernel version is bumped up to the latest 5.0.0
enabled mpu6050 IMU sensor
enabled tmp103 temperature sensor, supposedly case temperature...
enabled hall sensor that is triggered by a case lid magnet, It's mapped as a SW_LID key
some cleanups for display panel code
resolved HDMI edid issue: two part problem of wrong DDC pin mux sequence and wrong HDMI vdda supply regulator match string
Regressions:
Somewhere in the process it lost the ability to resume from suspend, have to find what caused that.
New bootloader does not handle IDME tags, therefore for the stock os I had to hardcode serial and MAC addresses in stock kernel idme driver. But since there is plenty of place to put different bootloaders on our tablets you may use one for stock rom, and another for development.
A second part of the update is coming soon...

Hi there,
This is very exciting work - how is the tablet doing a year on? I'm wondering how much of your work is applicable to the 7 inch equivalent, seeing as the board is common, just with a few minor hardware differences.
Thanks,
Jack

Jack_Kekzoz said:
Hi there,
This is very exciting work - how is the tablet doing a year on? I'm wondering how much of your work is applicable to the 7 inch equivalent, seeing as the board is common, just with a few minor hardware differences.
Thanks,
Jack
Click to expand...
Click to collapse
Hi Jack, since last update I got some additional pieces working. Specifically: sound (and that was a brain-teaser for a long time) and LTE modem are working now. UEFI boot with u-boot implementation is functional.
Indeed 7-inch tablet may be brought-up with quite a low effort: lcd panel is slightly different, but there is a driver for it already in kernel, touch screen is also different. Apart from that rest of the stuff should work quite the same, that is usb, uart, wifi, bt, audio, backlight, keys, emmc, hdmi, with minor DeviceTree adjustments.
Same for u-boot: for basic functionality only a few pin-assignment changes are needed.

Hi,
For a relative arch Linux beginner, what resources would you point one to to be able to implement this on an OG kindle fire HD 8.9?
I'm decently comfortable on the command line, but once it starts getting deep in the kernel, I am a little more cautious..
Many thanks,
Jeff

Joonatnoon said:
Hi,
For a relative arch Linux beginner, what resources would you point one to to be able to implement this on an OG kindle fire HD 8.9?
I'm decently comfortable on the command line, but once it starts getting deep in the kernel, I am a little more cautious..
Many thanks,
Jeff
Click to expand...
Click to collapse
It depends on what you want to achieve. This kernel will happily work on any kindle fire 8.9 2012. LTE version just has an additional board with a modem on it, (and needs another Bluetooth firmware).
At some point, I created a bit more user-friendly image of Manjaro with LXQt suitable for dual-boot, but without hardware acceleration, it was too sluggish for any real use.
If you want to have some fun and do something useful at the same time, I'd suggest adding support for this device in postmarket os project.
The starting point is here https://wiki.postmarketos.org/wiki/Porting_to_a_new_device
If you encounter any difficulties, feel free to ask

ipipipipip said:
Hi Jack, since last update I got some additional pieces working. Specifically: sound (and that was a brain-teaser for a long time) and LTE modem are working now. UEFI boot with u-boot implementation is functional.
Indeed 7-inch tablet may be brought-up with quite a low effort: lcd panel is slightly different, but there is a driver for it already in kernel, touch screen is also different. Apart from that rest of the stuff should work quite the same, that is usb, uart, wifi, bt, audio, backlight, keys, emmc, hdmi, with minor DeviceTree adjustments.
Same for u-boot: for basic functionality only a few pin-assignment changes are needed.
Click to expand...
Click to collapse
Thanks for all this. I hope to port the 7 inch version (soho) to postmarketOS (am surprised you didn't want to get jem running it so you can have a nice touch interface).
Have you seen the attempts to get mainline drivers that interface with PowerVR SGX 5xx graphics firmware? Seems like one day there might be 3D working...
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx
One more question - have all the changes you described been pulled upstream, so I can just fork from mainline, or are some important ones still not yet in, so I should fork your repo?
Thanks again for all your efforts - I am very excited as to how this will benefit soho development.

Jack_Kekzoz said:
Thanks for all this. I hope to port the 7 inch version (soho) to postmarketOS (am surprised you didn't want to get jem running it so you can have a nice touch interface).
Click to expand...
Click to collapse
I did get it run postmarket, but it was somewhat clumsy and not properly integrated into a build tree. Also, it seemed a bit clumsy to update-rebuild-flash-reboot firmware image after a change contrary to rebuilding some users-pace parts just on the device.
Have you seen the attempts to get mainline drivers that interface with PowerVR SGX 5xx graphics firmware? Seems like one day there might be 3D working...
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx
Click to expand...
Click to collapse
If only there was a non-android userspace driver for sgx544sc that is in 4470, inb4: ti still uses sgx544 in their new chips, but it is different.
Would be nice to have 3d, but I'm afraid that without major testing and bug fixing (on source code driver level, which is closed) It will be buggy as hell.
One more question - have all the changes you described been pulled upstream, so I can just fork from mainline, or are some important ones still not yet in, so I should fork your repo?
Click to expand...
Click to collapse
Nope :angel: . Clone my repo.

Hello again,
I've been trying to get a downstream kernel postmarketOS running on soho, and had noted the bootloader refused to load my kernel (just went to fastboot) unless I hexedited some zeroes (and some other data) at the beginning of my boot image (a technique required for the one custom rom available for it), after which it bootlooped. I see jem too requires some boot image manipulation to get cm11 on it (https://github.com/LineageOS/android_device_amazon_jem/blob/cm-11.0/boot.mk) - how did you get your kernel booting? I don't know much about the boot process, but I imagine there is some sort of signature verification Amazon cooked in that the hex data added at the beginning confuses.
Can I pm you?
Thanks,
Jack

Hi, yes boot image is signed and verified, but at least on Jem there is a vulnerability in stock u-boot that allows to bypass the signature check and execute arbitrary code.
Not sure how it is done on soho, but, at a first glance, the exploit looks kinda the same (even addresses are the same).
https://github.com/TeamWin/android_device_amazon_soho/blob/cm-12.0/exploit.mk
On jem there is an image size check missing when loading boot image into ram. The boot.img header contains image size to be loaded, and thus if you load a large enough chunk you will overwrite current stack frame (and what's important - return address), thus after data is loaded bootloader will jump to user-specified address. The trick is to load your executable code (second bootloader in my case) into ram (put it somewhere at a known place in boot partition) and use that address to overwrite the stack.
One problem was that main boot partition is too small (8MiB) to contain a patch to overwrite the stack, thus initially it was placed somewhere at the beginning of system partition (with hopes and prayers that it will not corrupt ext4). But then I resized those partitions to 16MiB which is enough to fit everything.
If you don't want to bother with modifying bootloader, just retrofit those boot image creation makefiles.

Thanks - so how did you modify your boot image when you were tinkering with pmOS? Did you just replace the stock u-boot so no exploit was necessary? I thought x-loader would refuse to load any u-boot not signed with Amazon's keys? Sorry, you stated you put your second bootloader at an address in the boot partition. I'm just curious as to how exactly one does that when building pmOS.
Thanks,
Jack

Who knows, there is actually no sane way to create simply flashable boot.img without resizing boot partition first, that I highly suggest you to do. Make a backup of all partitions and gpt table, practice a bit on a spare sdcard, boot twrp, remove boot partition, and what's after it, then recreate those with sizes as need (and don't forget to restore partition names, that's important). Also would be handy to increase system partition size on the way, by sacrificing userdata size.

But, if you have working third party ROM, and don't expect to fiddle with bootloader, chances are you may get away with just dd-ing a few values and 2nd loader over boot.img postmarket builds (there is a package stage in linux-xxx target in postmarket's APKBUILD where you can put this code), and hope that magic value (stack smashing value) will not be overwritten while installing firmware

Thanks for this info. I've managed, through your help and others, to get a boot pmOS (on a downstream kernel). I'm in the process of merging my work, and the question is being asked of the boot hack, which I am hoping to get merged into postmarketos-mkinitfs package (not in an APKBUILD for soho) - are there any other devices that use a similar hack? If the answer is yes, I think it makes sense to include them in the same portion of code for future pmOS jem attempts - I know you didn't want to merge all your code, and that's ok, but could I make a request for one part of it? Please may I ask what exact shell commands you needed to run to amend jem's boot.img so that tricking the signature check takes place? For what it is worth, for soho I adapted the boot hack in the rom makefile to the below:
SOHO_HEADER_DATA='\x50\x03\x00\x00\x00\x25\xe4\x00'
SOHO_HEADER_SIZE=848
SOHO_HEADER_OFFSET=52
tempfile=$(mktemp)
dd if=/dev/zero of="${tempfile}" bs=$SOHO_HEADER_SIZE count=1
printf "%b" $SOHO_HEADER_DATA | dd of="${tempfile}" bs=$SOHO_HEADER_OFFSET seek=1 conv=notrunc
cat "${outfile/initramfs-/boot.img-}" >> "${tempfile}"
mv "${tempfile}" "${outfile/initramfs-/boot.img-}"
(I didn't need to resize my boot partition as I believe the hidden bootloader is stored in the recovery partition.) Anyway, thanks for all the help. I'm going to work a bit more on polishing my downstream port before turning my attention upstream, and copying most of your dts and relevant commits

Nice , as for other devices: fire hd 2012 7" (IIRC it is called tate) is likely using the same hack, and that's it, it was an amazons bug so no other devices affected. You may assume that the commands for jem are exactly the same.
BTW, may I have a look at a merge request for postmarketos-mkinitfs, when you create it? I dug a bit, trying to find a nice clean method of wrapping boot.img after mkinitfs creates it, but didn't found any. The closest thing that exists are a few device-specific "sign" steps, which are almost exactly what we need, except that, I don't want to add more ugly device-specific checks in build scripts. Some generic field that names the tool for signing and a separate package that does that device-specific signature would've been the best IMO.
I guess It's time to rebase jem to a latest kernel, with a cleanup, coz a few things are broken now and need additional rework.

The Kindle Fire 2 (otter2) also appears to require a similar exploit. Merge request is here: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/1995
Rebasing jem sounds exciting!

I don't know if you've read the MR comments, but lead dev Ollie has just said what you said re device specific code. Time to rewrite then...

How to install ChromeOS on Sabrina Chromecast with GoogleTV

In this supreme hackerous master page not a single snowden has figure this one out yet?
So.. my question to yous is.. is there any way to turn Sabrina Chromecats into ChromeOS?
Clean install no Virtual ChimiChanga Virtualization Apk that run crippled..

first an exploit has to be discovered. Nobody's loading anything on it until that happens Based on my poor ability to pwn things I haven't figured out squat. I've looked for hardware exploits and tried all the older known stuff. It's pretty locked down.

that being said, you can run chrome... just sideload the apk. I'm not a fan of chrome os but I use my chromecast as a 'computer' to check random websites every once in awhile this way.

While rooting may be possible, it's unlikely that we'll be able to unlock the bootloader and install a different OS. The FireTV 4K took almost a year before a bootrom exploit was discovered, and even that required cracking open the case, removing shielding from the board, and shorting out tiny pins.