Related
Does someone unlock Windows Phone 8 OS ?
Will someone do it ?
Thanks for info.
Yeah, when they have bootlevel 0 access, maybe it could be done
As I have heard, and understood, the chips are hard-encoded, for every device, so the JB cannot be achieved Will it ever be? Who knows, this is quite a challenge, but I am no optimist.
Hard coded?? Wow those SOBs. They really need to rethink as to why they are not selling as many phones as they would love to.
LOL. 99% of earth's population does not know or care about the "hard coded" chip (it is not hard coded, it is analogical thus it cant be reprogrammed)
Scumbag Microsoft
Just a question on this. So, boot level stuff is not posable because of encryption. So as of now, Custom roms are out, not possable, YET.
With this being known, what most of us would be happy with is a suto Interop unlock. This would allow max unsigned apps and maybe some minor system level apps (think Advanced Config type apps) maybe bosted with a root tools type of app (almost a custom rom but, not). This stuff will all run on the OS, not the boot level. Shouldn't this be possable once someone finds a hole someplace ?
So, full unlock with custom roms will not be possable but, at least we can have a step there to have some fun with out phones till someone actually figures it out (slim chance if it's encrypted)
mcosmin222 said:
LOL. 99% of earth's population does not know or care about the "hard coded" chip (it is not hard coded, it is analogical thus it cant be reprogrammed)
Click to expand...
Click to collapse
And I agree, becides hobbiests and hackers (and XDA readers ), no one really cares about a unlock, that is about 98% of of the Windows Phone users. That does not mean we (the 2-3%) dont want it...
MSFT clearly does not care about hackers like us. Otherwise they would give us more APIs to program with.
They care about the bad type of hackers.
In WP7 we only had Full Unlock on devices that had a Custom ROM flashed onto it. This does not mean that it is not possible to exploit other loopholes but the NT Kernel is kind of a harder nut to crack than the old CE Kernel powering WP7. Basically you would need a vulnerability in a system App to get your code running. Then that code would have to escape from it's jail and acquire a higher permission level. Then I guess the first step would be to write something to the registry that would allow:
a) to sideload apps (basically what the developer unlock does)
b) to elevate permissions on those sideloaded apps (similar to what the Root Tools were able to do)
We only had two ways ever to get any Unlocks without flashing a CustomROM on WP7. The first was the original ChevronWP7 and the second was Window Break which only worked on certain Samsung devices and was quickly patched. Aside from that everything concentrated on the CustomROM route or on how an Unlock achieved previously could be conserved through system updates (Nodo to Mango).
So it might be quite some time before we even see something like the Interop Unlocks. Even most Android devices were routed by flashing a modified kernel.
It's been a while, has there been ANY progress on a Unlock even if interop or something for Windows Phone 8 ? I have a dev unlock and it limits me to 3 apps but, what I miss the most is apps like Advanced config giving me unlimited options for colors...
I do not believe so.
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.
Apparently the ONLY version of Android that is vulnerable to Heartbleed is 4.1.1. I ran a check on my phone, and sure enough I'm running that version, and heartbeats are definitely enabled. I used the Lookout security app to verify this. Is there a way I can patch my system myself and somehow disable the heartbeats feature without having to wait another 3 years for Motorola to come out with a fix? My phone is rooted, but something tells me that OpenSSL probably needs to be essentially recompiled with a flag set to disable heartbeats?
I was hoping there would be a quick config file for OpenSSL that can be modified, but I'm not usually lucky. Based on everything I've seen thus far, a recompile with a flag set is the only way to fix this. Figured i'd give it a shot and ask on here.
I've been thinking about the same thing.
If memory was encrypted that could solve all or part of the problem.
If the Chrome https browser cache were turned off, which I think requires an APK edit there would not be any clear text data in the browser cache.
What do you think?
dosmac said:
Apparently the ONLY version of Android that is vulnerable to Heartbleed is 4.1.1. I ran a check on my phone, and sure enough I'm running that version, and heartbeats are definitely enabled. I used the Lookout security app to verify this. Is there a way I can patch my system myself and somehow disable the heartbeats feature without having to wait another 3 years for Motorola to come out with a fix? My phone is rooted, but something tells me that OpenSSL probably needs to be essentially recompiled with a flag set to disable heartbeats?
I was hoping there would be a quick config file for OpenSSL that can be modified, but I'm not usually lucky. Based on everything I've seen thus far, a recompile with a flag set is the only way to fix this. Figured i'd give it a shot and ask on here.
Click to expand...
Click to collapse
Yep, 4.1.1 is vulnerable to this. 4.1.2 has the no heartbeat fix added in and 4.1.1 took the update that was bugged. That said, we DO have TWO 4.1.2 Stock roms, Mexican Retail and Bell are both 4.1.2 and should have that fix -- needs confirmation. Our Stock ICS roms are all from before this bug was added in and are safe. In reality, only stock, locked AT&T Atrix HD's are vulnerable to this since all the other roms* have this fix.
Normally I'd say something around the lines of give me a few days and I'll look into this more, but I've been busy lately, and when I'm not busy I'm either tired or sore; did some heavy lifting a few weeks ago and my back is still sore from that day.
*Our 4.1.2 roms are untested, but 4.1.2 AOSP has the fix so our 4.1.2 stocks should too
I was just thinking that ther eis no such thing as security. Security is achieved by being harder to exploit than the other computers. Even 3-DES can be cracked with enough computing power.
So encrypting memory and stopping https caching would close two big holes. I'm now wondering what holes would remain to be exploited by the heartbeat exploit on a 4.1.1 device if this were done?
stevep2007 said:
I was just thinking that ther eis no such thing as security. Security is achieved by being harder to exploit than the other computers. Even 3-DES can be cracked with enough computing power.
So encrypting memory and stopping https caching would close two big holes. I'm now wondering what holes would remain to be exploited by the heartbeat exploit on a 4.1.1 device if this were done?
Click to expand...
Click to collapse
If I was on a stock phone running 4.1.1 and I was that worried about heartbleed, I'd unlock the bootloader and install Bell or Mex Retail because both are 4.1.2. I might even be possible to just swap the exploited binaries with the ones in our 4.1.2 roms, that's something someone else worried about this can do. Hell, it might even be possible to run the 4.1.2 roms with safestrap and the AT&T kernel...again, that's a someone else thing...I have no intention of dicking with SSR.
Think about Wifi being hacked....when it first came out a crappy password like 12345678 was good enough because computing power wasn't that good for consumers yet; nowadays, a basic gaming laptop can check 500,000 wpa2 passwords a second, a decent desktop with multiple GPU's can do over a million a second. All wpa2 hacking is sniffing out the verification md5*, then the tools generate passwords and their md5 and compare it against the sniffed out one, eventually you'll find one that matches, especially so if the password sucks. If you know how certain telecoms set up their wifi passwords, you can shorten the amount of time taken by limiting to the characters they use -- for example, AT&T U-Verse** uses 10 digit numeric passwords, so all you'd have to do is limit the tools to use numbers and start with 10 digits....hint: there are only 1 million codes if you use 10 numbers only....10 to the power of 10 and all....
That isn't a wifi hacking tutorial, just an example of how overtime good security unchanged becomes very bad security and how eventually an exploit will be found and security compromised, like how wpa2 for a split second sends out a the verification md5 unencrypted.
*not sure if WPA2 uses md5, but most of us know what md5's are
**last time I read about that service that's what I saw...and I read that a few months ago
I've been doing research and experimenting for the past few days, with only 6 hours of sleep in the last 48 hours. Long story short, I had a Droid TURBO on Verizon, loved it, the best phone I've ever had hands down. A month or so into having my Turbo, my family switched to Sprint, rendering my Turbo completely useless as a phone Skip a few more months ahead to 11/15 when I broke my Samsung S6. I was looking for an excuse to figure out how to do this, I'd done a few hours of research, but never really had a reason to attempt what I have been. My goal is to allow my droid turbo to call/text with my sprint number and plan. My first idea was to simply open up some bands, maybe change some APN settings, BOY was I in for a trip. I'm currently running the 5.1 OTA of Lollipop on my Turbo, which means I have a locked bootloader, however I've gotten as far as getting temporary root access on 5.1 OTA (SU3TL-39). I wasn't sure how temporary root worked at first so of course, I was trying to get "XPOSED" working with this temporary root, then I could modify the phones information and trick Sprint into thinking that my Droid Turbo, is actually my old phone. I attempted to change the IMEI swap the two different IMEI's however it was soon after that, that I found out that my temporary root doesn't actually save after a boot, or even in-between roots. Kingroot seems to have to keep re-rooting itself in order to keep it's temporary root alive. Anyways, I've been up all night, and I've got to get to Uni. I'd like to see what other ideas you all might have. At this point I've gotten invested in attempting to find my own method to rooting, or flashing a modified firmware of some type. I'd really like some guidance in these fields even if my Turbo will never work with Sprint. I appreciate those of you who read the post entirely.
EDIT: I've gotten many different theories, but the only way I see myself doing this is by somehow downgrading and starting from complete scratch, maybe even rebuilding the OS just to miss the security update? (All of these things are probably impossible, but I'd really like to think that we can figure something out together instead of letting the TURBO die.)
EDIT 2: ****, I really need to leave, but I had one last idea as I walked out the door, I'm sure it's out of the question, but maybe there's some way to physically modify the TURBO, or even modify the IMEI that the SIM card is looking for in the first place, but all just theories, will come back later with more ideas!
Tabrune said:
I've been doing research and experimenting for the past few days, with only 6 hours of sleep in the last 48 hours. Long story short, I had a Droid TURBO on Verizon, loved it, the best phone I've ever had hands down. A month or so into having my Turbo, my family switched to Sprint, rendering my Turbo completely useless as a phone Skip a few more months ahead to 11/15 when I broke my Samsung S6. I was looking for an excuse to figure out how to do this, I'd done a few hours of research, but never really had a reason to attempt what I have been. My goal is to allow my droid turbo to call/text with my sprint number and plan. My first idea was to simply open up some bands, maybe change some APN settings, BOY was I in for a trip. I'm currently running the 5.1 OTA of Lollipop on my Turbo, which means I have a locked bootloader, however I've gotten as far as getting temporary root access on 5.1 OTA (SU3TL-39). I wasn't sure how temporary root worked at first so of course, I was trying to get "XPOSED" working with this temporary root, then I could modify the phones information and trick Sprint into thinking that my Droid Turbo, is actually my old phone. I attempted to change the IMEI swap the two different IMEI's however it was soon after that, that I found out that my temporary root doesn't actually save after a boot, or even in-between roots. Kingroot seems to have to keep re-rooting itself in order to keep it's temporary root alive. Anyways, I've been up all night, and I've got to get to Uni. I'd like to see what other ideas you all might have. At this point I've gotten invested in attempting to find my own method to rooting, or flashing a modified firmware of some type. I'd really like some guidance in these fields even if my Turbo will never work with Sprint. I appreciate those of you who read the post entirely.
EDIT: I've gotten many different theories, but the only way I see myself doing this is by somehow downgrading and starting from complete scratch, maybe even rebuilding the OS just to miss the security update? (All of these things are probably impossible, but I'd really like to think that we can figure something out together instead of letting the TURBO die.)
EDIT 2: ****, I really need to leave, but I had one last idea as I walked out the door, I'm sure it's out of the question, but maybe there's some way to physically modify the TURBO, or even modify the IMEI that the SIM card is looking for in the first place, but all just theories, will come back later with more ideas!
Click to expand...
Click to collapse
There are two problems that you're up against:
1. The /system partition is write protected. Even with temp root (or permanent root, for that matter), /system cannot be modified. To use anything via the xposed framework, the framework must be installed, which requires writing to /system, which is impossible. The only way around this is the moforoot exploit, which allows flashing of pre-modified /system images, eliminating the need to modify /system while the phone is running. However, this does not work on the 5.1 bootloader, which you have.
2. As you correctly state, the bootloader is locked. That means no downgrading and no flashing of modified firmwares using official flashing methods (fastboot, mfastboot) or non-mofo unofficial methods (TWRP, FlashFire).
This thread discusses hardware modifications. It's way above my head, so I'm not sure how useful it is: http://forum.xda-developers.com/droid-turbo/development/rd-turbo-jtag-emmc-direct-hardware-t3162558.
Hope this is at least moderately helpful.
I suppose there's no way to disguise an exploit within some of the core system files? Since all of these files are signature checked, but how exactly does signature checking work with the Lollipop, I doubt that it would be easy to trick, but maybe some reverse engineering of it? Trick it into thinking that everything is okay even though an exploit is riding alongside a system file.
Tabrune said:
I suppose there's no way to disguise an exploit within some of the core system files? Since all of these files are signature checked, but how exactly does signature checking work with the Lollipop, I doubt that it would be easy to trick, but maybe some reverse engineering of it? Trick it into thinking that everything is okay even though an exploit is riding alongside a system file.
Click to expand...
Click to collapse
Even if that were possible, it would not help you, since that would require being able to write a file to where the core system files are stored (/system). As for how signature checking works, I think it is enforced by whatever is stored on the /boot partition, but I'm not sure about that. A locked bootloader will not allow flashing modified images to /boot, and there are no known ways to bypass this.
When I get home, I'm going to do some experimenting on attempting to strip down and down grade to KK. I know that it most likely won't work, but I will gain some knowledge about it at least.
TheSt33v said:
Even if that were possible, it would not help you, since that would require being able to write a file to where the core system files are stored (/system). As for how signature checking works, I think it is enforced by whatever is stored on the /boot partition, but I'm not sure about that. A locked bootloader will not allow flashing modified images to /boot, and there are no known ways to bypass this.
Click to expand...
Click to collapse
Yep, the boot partition is what would have to be bypassed or unlocked in order to be able to write to system. That is where all the sig checks are locked in, right in the boot partition.
Well, we had a BL Unlock coming to us in a few days, maybe a week or two. With that, you can flash what you need to attempt to use with sprint possibly, depending on the bands the Turbo has
I've gotten the phone to work to an extent, I'm hoping if the BL unlock happens that it will open up lots of opportunity.
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.