Database Develop

How to skip WiFi configuration during initial setup of Nexus 7

I just got my Nexus 7 this evening and was incensed to find out that I could not skip the WiFi network selection phase of setup. This really irked me because I chose this device specifically because it was open/hackable/etc. Instead, I found that immediately after I picked up the device I was being forced to do something I didn't want to do right then. Naturally, this forcing mechanism was supposedly "for my own good".
I searched around and found others asking the same questions only to receive mockery. Therefore, I wanted to post instructions for those who may really want to skip WiFi setup for whatever reason. It's your device; don't feel like you have to justify what you want to do with it or how.
It will become apparent that this was done out of the principle of the matter. This isn't for people who want to get their device up and running quickly or who aren't familiar with adb, custom recoveries, shell commands, etc. Casual users (or anyone who isn't familiar with what each step does without asking questions) should probably avail themselves of the workarounds posted in some of the other threads on this subject.
Preliminary Tasks:
1. Download the ADB drivers for the Nexus 7 from the ASUS support site & install them.
2. Unlock the bootloader using your favorite method (I booted into the bootloader, then used "fastboot oem unlock") and let it nuke your tablet.
3. Obtain & load ClockworkMod Recovery using your favorite method (I used "fastboot flash recovery ).
4. Reboot into recovery.
5. Mount /system via CWM.
If you're in the intended audience you probably can tell where this is going. You have two choices at this juncture: you can edit the build.prop file to allow you to skip WiFi setup step or you can edit the same file to just disable the setup wizard entirely. Both ways work. So, here's the Choose Your Own Adventure stage...
Disabling The Setup Wizard Entirely:
6. Launch adb shell
7. echo "ro.setupwizard.mode=DISABLED" >> /system/build.prop
8. Exit shell and issue an adb reboot.
9. Watch your tablet launch directly to the home screen.
10. Manually configure your settings without the "help" of the Setup Wizard and go on your merry way.
11. There is no step 11. Stop reading now.
Allowing The WiFi Setup Step To Be Skipped:
6. adb shell sed -i 's/ro.setupwizard.wifi_required=true/ro.setupwizard.wifi_required=false/g' /system/build.prop
(Thanks to steevp for this idea)​7. Issue an adb reboot.
8. Your tablet will launch into the initial setup wizard, but the WiFi page will have a "Skip" button.
9. The developers really didn't anticipate this scenario, so after you skip WiFi selection it will display "Connecting to WiFi" even though there's no connection. This will take a minute or two before it times out and setup continues to the next step.
10. Proceed with the rest of setup however you like.
Naturally, two minutes after I finished getting the tablet booted to the home screen I enabled WiFi and connected to my home network. However, I did this when *I* wanted to do so rather than when Google's devs thought I should; therefore, I am of the opinion that this exercise was worth the effort.
(If your tablet fails to boot after either one of these build.prop file edit approaches, just hold down power + volume down until it reboots. Go into recovery/adb/etc and start debugging what went wrong. This is a particularly fun condition, because you can't adb logcat the issue because you haven't enabled USB debugging because you've haven't setup the device yet. Don't take this the wrong way, but don't bother asking me for help if you can't figure out how to extricate yourself. I mean, how much more dissuasion/warnings/disclaimers do you want?)​
ETA:
Disabling the SetupWizard by simply renaming the apk has deleterious side effects, so I refactored the approach. Among other problems, the home button doesn't work if you just rename the apk--likely because it is disabled to prevent users from escaping the setup wizard/WiFi selection screen. Disabling the setup wizard via build.prop doesn't exhibit this issue. Addditionally, I updated the WiFi skipping instructions to be safer and more efficient.

organophosphate said:
Allowing The WiFi Setup Step To Be Skipped (Dangerous):
...
9. YOUR TABLET WILL FAIL TO BOOT IF YOU SKIP THIS STEP: adb shell chmod 755 /system/build.prop
...
Click to expand...
Click to collapse
Shouldn't this be 644?
Also, in case anyone wants to know, you can bypass activation after connecting to a WiFi network - you do not need to tie the tablet to your Google account.

Reasons for wanting to do this other than just saying "because its mine and I want the choice" ?
the device is useless with out wifi. what purpose does the device serve if you dont connect to a wifi point?
Lets say you follow the above steps you laid out and now you are able to boot into the device with out a wifi AP and google account. what now? ok you can load some movies and sideload some APKs you download off the web.
your device isnt being updated now, and almost seems forgive me for saying this... "bratty" i dont want to have to do this its my choice etc.

cwoggon said:
Shouldn't this be 644?
Click to expand...
Click to collapse
It appears that 644 will work as well. Allowing group/other "write" permissions seems to be the cause of the boot failure. Regardless, suffice it to say that the outcome of a standard "adb push" of the file results in incorrect permissions, at least on my configuration (ie. 666, which is Wrong).
nextelbuddy said:
your device isnt being updated now, and almost seems forgive me for saying this... "bratty" i dont want to have to do this its my choice etc.
Click to expand...
Click to collapse
I can't believe that this kind of sentiment seems common on XDA, of all places. Seriously? Your flawed reasoning can trivially be applied to wanting to load a custom ROM (your device isn't getting system updates from Google after that) or choosing not to activate the device with a Google account (you miss out on all the Google features). Repeat after me: this is my device; I don't have to justify anything I may want to do with it.
Besides, preventing setup from proceeding without a WiFi connection certainly is a flaw, as others have amply demonstrated. I'm just irked that it requires so much effort/specialized tools to bypass. And no, "It doesn't matter if you're in Afghanistan/at work with no WiFi/only have access to paid WiFi networks. Just go to a McDonald's: your device is worth less than a flaming sack of canine excrement without WiFi and who doesn't have eleventy billion open WiFi networks around in 2012, herp derp!" is not an acceptable workaround (or even constructive advice).

organophosphate said:
It appears that 644 will work as well. Allowing group/other "write" permissions seems to be the cause of the boot failure. Regardless, suffice it to say that the outcome of a standard "adb push" of the file results in incorrect permissions, at least on my configuration (ie. 666, which is Wrong).
Click to expand...
Click to collapse
Well, in my opinion, less is more
organophosphate said:
I can't believe that this kind of sentiment seems common on XDA, of all places. Seriously? Your flawed reasoning can trivially be applied to wanting to load a custom ROM (your device isn't getting system updates from Google after that) or choosing not to activate the device with a Google account (you miss out on all the Google features). Repeat after me: this is my device; I don't have to justify anything I may want to do with it.
Besides, preventing setup from proceeding without a WiFi connection certainly is a flaw, as others have amply demonstrated. I'm just irked that it requires so much effort/specialized tools to bypass. And no, "It doesn't matter if you're in Afghanistan/at work with no WiFi/only have access to paid WiFi networks. Just go to a McDonald's: your device is worth less than a flaming sack of canine excrement without WiFi and who doesn't have eleventy billion open WiFi networks around in 2012, herp derp!" is not an acceptable workaround (or even constructive advice).
Click to expand...
Click to collapse
IIRC, this would have been helpful to a gentleman who was looking to bypass WiFi activation awhile back. I applaud little workarounds such as this... you never know when this information might be useful.

cwoggon said:
Well, in my opinion, less is more
Click to expand...
Click to collapse
True.
I was dissatisfied with the original approach because of the risk of causing boot failure, so I refactored the implementation to avoid the problem altogether. The updated procedure should be cleaner & more efficient.

organophosphate said:
It appears that 644 will work as well. Allowing group/other "write" permissions seems to be the cause of the boot failure. Regardless, suffice it to say that the outcome of a standard "adb push" of the file results in incorrect permissions, at least on my configuration (ie. 666, which is Wrong).
I can't believe that this kind of sentiment seems common on XDA, of all places. Seriously? Your flawed reasoning can trivially be applied to wanting to load a custom ROM (your device isn't getting system updates from Google after that) or choosing not to activate the device with a Google account (you miss out on all the Google features). Repeat after me: this is my device; I don't have to justify anything I may want to do with it.
Besides, preventing setup from proceeding without a WiFi connection certainly is a flaw, as others have amply demonstrated. I'm just irked that it requires so much effort/specialized tools to bypass. And no, "It doesn't matter if you're in Afghanistan/at work with no WiFi/only have access to paid WiFi networks. Just go to a McDonald's: your device is worth less than a flaming sack of canine excrement without WiFi and who doesn't have eleventy billion open WiFi networks around in 2012, herp derp!" is not an acceptable workaround (or even constructive advice).
Click to expand...
Click to collapse
ehh i still have to disagree with you there. this isn't the same as wanting to install a custom ROM.
installing custom ROMS and Kernels have true benefits whch are optimization and customization that stock does not offer aka more choice.
bypassing wifi on a brand new device just because it's your device an you want that freedom does not have the same benefit and doesnt give oy more choice. as i asked before, what could you do with your tablet if you were allowed to bypass wifi on a brand new device?
I know that many custom roms and kernels give me the ability to inccrease speed and add more options in the operating system that i am looking for hence i will choose to flash a new rom and kernel.
there is nothing i can or want to do with a tablet that allowed me to bypass the wifi setup.. at least not that I can think of.
Im not trying to be argumenative just to do it, im trying to determin your real actual justificaton for wanting this besieds "
its my device let me do what i want" because at no point did i say nor did anyone else say they wanted to flash new roms and kernels because it was their device and they wanted to do what they want, they did it because those options benefitted them in a way that the stock experience did not.
Just because someone is on XDA does not man they are here ot hack their device to pieces. there are many reasons people come to XDA..
talk and interact with others that have a love for media devices
ask questions about their devices
learn from others on how to modify their devices
completely change their devices
just to name a few.
it does not mean that all of us want the ability to change devices out of the box just because its ours necessarily.

nextelbuddy said:
bypassing wifi on a brand new device just because it's your device an you want that freedom does not have the same benefit and doesnt give oy more choice.
Click to expand...
Click to collapse
Ipso facto, yes it does: it gives you the choice to skip the WiFi configuration during the initial setup. Whether this is a useful option for you is a decision you make for yourself, but now you have a choice about it whereas you had none before.
nextelbuddy said:
as i asked before, what could you do with your tablet if you were allowed to bypass wifi on a brand new device?
Click to expand...
Click to collapse
That's not salient to this thread, but I suppose you can read your previous post for some possible uses that you suggested.
nextelbuddy said:
there is nothing i can or want to do with a tablet that allowed me to bypass the wifi setup.. at least not that I can think of.
Click to expand...
Click to collapse
Then this procedure is obviously not for you. There's no need for the existence of the procedure to be justified, because no one is forcing you to perform this modification.
nextelbuddy said:
Just because someone is on XDA does not man they are here ot hack their device to pieces.
Click to expand...
Click to collapse
Then this procedure is obviously not for them. That's perfectly okay.
nextelbuddy said:
it does not mean that all of us want the ability to change devices out of the box just because its ours necessarily.
Click to expand...
Click to collapse
Sensing a pattern? This procedure is obviously not for you, but others do want this ability. The existence of this procedure in no way infringes upon your ability to use the device just as Google intended.
I still don't get the reaction from this contingent of the XDA community. Honestly, I expected most people to shrug and realize that this workaround might only be useful in certain esoteric cases. Instead, it seems like a vocal group of users must own stock in WiFi router companies, given their insistence that the only valid use of a Nexus tablet is with WiFi connected (haha).

organophosphate said:
Ipso facto, yes it does: it gives you the choice to skip the WiFi configuration during the initial setup. Whether this is a useful option for you is a decision you make for yourself, but now you have a choice about it whereas you had none before.
That's not salient to this thread, but I suppose you can read your previous post for some possible uses that you suggested.
Then this procedure is obviously not for you. There's no need for the existence of the procedure to be justified, because no one is forcing you to perform this modification.
Then this procedure is obviously not for them. That's perfectly okay.
Sensing a pattern? This procedure is obviously not for you, but others do want this ability. The existence of this procedure in no way infringes upon your ability to use the device just as Google intended.
I still don't get the reaction from this contingent of the XDA community. Honestly, I expected most people to shrug and realize that this workaround might only be useful in certain esoteric cases. Instead, it seems like a vocal group of users must own stock in WiFi router companies, given their insistence that the only valid use of a Nexus tablet is with WiFi connected (haha).
Click to expand...
Click to collapse
Im only one person. I can appreciate your work into finding a valid work around and am in no way attempting to take that from you and im sure there will be many that will be happy and thankful with your hard work. Dont take what I said as any sense that this is how the community feels please.
keep on with your work!

Thanks for the effort. I just got my N7 and was also surprised I couldn't skip the wifi setup.

nextelbuddy said:
Reasons for wanting to do this other than just saying "because its mine and I want the choice" ?
the device is useless with out wifi. what purpose does the device serve if you dont connect to a wifi point?
Lets say you follow the above steps you laid out and now you are able to boot into the device with out a wifi AP and google account. what now? ok you can load some movies and sideload some APKs you download off the web.
your device isnt being updated now, and almost seems forgive me for saying this... "bratty" i dont want to have to do this its my choice etc.
Click to expand...
Click to collapse
I am on a military base with in room wifi. The wifi redirects me to the browser which makes me agree to their terms. Since it is initial setup I can't use the browser and since I can't skip I can't use the tablet until later when I get leave and can go to somewhere with free wifi. There's your reason.

lex1020 said:
I am on a military base with in room wifi. The wifi redirects me to the browser which makes me agree to their terms. Since it is initial setup I can't use the browser and since I can't skip I can't use the tablet until later when I get leave and can go to somewhere with free wifi. There's your reason.
Click to expand...
Click to collapse
That's a good reason!
Absolutely agree that you should be able to skip that step. AND no valid reason needed. Unless Google can show a valid reason for not letting you skip that step. I'm sure most of us have watched the Google, (and Facebook) 'net' close in around us. When I started on Android I thought it was so cool how it was all tied to Google and was cross device. Now I'm like: Google would you just get out of my way, I'll be more than happy to click on 'you' when I need something from you.
The latest insult is that annoying "Keep Shopping" prompt in the Play store. Clicking Back, and Keep Shopping does the exact same thing. I shouldn't have to do either. Since I used to be dropped back to the same place anyway.

While the initialization does require a Wi-Fi connection it does not require an Internet connection. I was able to connect to my printer Wi-Fi network and let the waiting bar run for 2-3 minutes then the initialization would continue to completion.
I didn't like this Google forced initial setup either but at least no information was broadcast this way. The Nexus 7 is very useful even when not connected to the Internet.

Chicken and egg
organophosphate said:
I just got my Nexus 7 this evening and was incensed to find out that I could not skip the WiFi network selection phase of setup. This really irked me because I chose this device specifically because it was open/hackable/etc. Instead, I found that immediately after I picked up the device I was being forced to do something I didn't want to do right then. Naturally, this forcing mechanism was supposedly "for my own good".
I searched around and found others asking the same questions only to receive mockery. Therefore, I wanted to post instructions for those who may really want to skip WiFi setup for whatever reason. It's your device; don't feel like you have to justify what you want to do with it or how.
It will become apparent that this was done out of the principle of the matter. This isn't for people who want to get their device up and running quickly or who aren't familiar with adb, custom recoveries, shell commands, etc. Casual users (or anyone who isn't familiar with what each step does without asking questions) should probably avail themselves of the workarounds posted in some of the other threads on this subject.
Preliminary Tasks:
1. Download the ADB drivers for the Nexus 7 from the ASUS support site & install them.
2. Unlock the bootloader using your favorite method (I used "fastboot oem unlock") and let it nuke your tablet.
3. Obtain & load ClockworkMod Recovery using your favorite method (I used "fastboot flash recovery </path/to/clockworkmod.img>).
4. Reboot into recovery.
5. Mount /system via CWM.
If you're in the intended audience you probably can tell where this is going. You have two choices at this juncture: you can edit the build.prop file to allow you to skip WiFi setup step or you can edit the same file to just disable the setup wizard entirely. Both ways work. So, here's the Choose Your Own Adventure stage...
Disabling The Setup Wizard Entirely:
6. Launch adb shell
7. echo "ro.setupwizard.mode=DISABLED" >> /system/build.prop
8. Exit shell and issue an adb reboot.
9. Watch your tablet launch directly to the home screen.
10. Manually configure your settings without the "help" of the Setup Wizard and go on your merry way.
11. There is no step 11. Stop reading now.
Allowing The WiFi Setup Step To Be Skipped:
6. adb shell sed -i 's/ro.setupwizard.wifi_required=true/ro.setupwizard.wifi_required=false/g' /system/build.prop
(Thanks to steevp for this idea)​7. Issue an adb reboot.
8. Your tablet will launch into the initial setup wizard, but the WiFi page will have a "Skip" button.
9. The developers really didn't anticipate this scenario, so after you skip WiFi selection it will display "Connecting to WiFi" even though there's no connection. This will take a minute or two before it times out and setup continues to the next step.
10. Proceed with the rest of setup however you like.
Naturally, two minutes after I finished getting the tablet booted to the home screen I enabled WiFi and connected to my home network. However, I did this when *I* wanted to do so rather than when Google's devs thought I should; therefore, I am of the opinion that this exercise was worth the effort.
(If your tablet fails to boot after either one of these build.prop file edit approaches, just hold down power + volume down until it reboots. Go into recovery/adb/etc and start debugging what went wrong. This is a particularly fun condition, because you can't adb logcat the issue because you haven't enabled USB debugging because you've haven't setup the device yet. Don't take this the wrong way, but don't bother asking me for help if you can't figure out how to extricate yourself. I mean, how much more dissuasion/warnings/disclaimers do you want?)​
ETA:
Disabling the SetupWizard by simply renaming the apk has deleterious side effects, so I refactored the approach. Among other problems, the home button doesn't work if you just rename the apk--likely because it is disabled to prevent users from escaping the setup wizard/WiFi selection screen. Disabling the setup wizard via build.prop doesn't exhibit this issue. Addditionally, I updated the WiFi skipping instructions to be safer and more efficient.
Click to expand...
Click to collapse
There seems a "chicken and egg" problem with the above instructions? To unlock the boot loader, you seem to need "USB debugging mode" enabled (for example, see how-unlock-nexus-7-bootloader at androidcentral), but since you can't reach the Nexus 7 options menu without getting through the wifi setup, you can't do that? What am I missing?

violincello said:
There seems a "chicken and egg" problem with the above instructions? To unlock the boot loader, you seem to need "USB debugging mode" enabled (for example, see how-unlock-nexus-7-bootloader at androidcentral), but since you can't reach the Nexus 7 options menu without getting through the wifi setup, you can't do that? What am I missing?
Click to expand...
Click to collapse
You can boot into the bootloader by holding volume down + power while the tablet is off. Then fastboot oem unlock. Job done.
Sent from my Nexus 7 using Tapatalk 2

We can just create a hotspot with our phone..this method is more easier than the method mentioned.and it doesn't require an active internet connection..just WiFi connectivity .
Sent from my Nexus 7 using XDA Premium HD app

chiggy2212 said:
We can just create a hotspot with our phone..this method is more easier than the method mentioned.and it doesn't require an active internet connection..just WiFi connectivity .
Sent from my Nexus 7 using XDA Premium HD app
Click to expand...
Click to collapse
That's exactly what I did. I was sitting in a parking lot after purchasing my N7 and didn't have a hotspot nearby. I wanted to play with my tab for a few before heading home so I just fired up WiFi Tether on my Rezound.
Sent from my Nexus 7 using xda app-developers app

chiggy2212 said:
We can just create a hotspot with our phone..this method is more easier than the method mentioned.and it doesn't require an active internet connection..just WiFi connectivity .
Click to expand...
Click to collapse
Absolutely. As I mentioned in the OP, this isn't the fastest solution. Hell, you can probably tell I don't even recommend it for common scenarios.
That said, the approach *does* work. Before I started this I searched and was unable find any other way to accomplish the specific goal of skipping/disabling WiFi connection during initial setup. Therefore, when I was finally able to get it working I wanted to document it for the community.

dr.m0x said:
You can boot into the bootloader by holding volume down + power while the tablet is off. Then fastboot oem unlock. Job done.
Sent from my Nexus 7 using Tapatalk 2
Click to expand...
Click to collapse
Thanks. I tweaked the OP to indicate this more clearly.

Simply
Andie00 said:
Thanks for the effort. I just got my N7 and was also surprised I couldn't skip the wifi setup.
Click to expand...
Click to collapse
When it happened to me, i just restarted it. It then booted to the homescreen.

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?

[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.

Fire 7 2020 mustang Brainstorming

Trying to brainstorm ideas for unbrick (firstly) of the new Fire 7 2020 Gen 9 models that feature 6.3.1.5 and were released post Feb 2020. Already have a method to downgrade this and many other devices (HD8 Onyx and HD 10 post patch Feb 2020) possibly a lot more other devices
Downgrade is a bit of a Sledge Hammer, in that it impacts numerous parts of IT (not just Android) as a new general hacking technique, and currently there seems no way of using my technique on these devices without resulting in hard brick, with no recovery possible.
On devices, if they exist, which contain cryptographic key burnt by eFuse, my bug will not be easily fully patchable. Very likely these devices will be constantly able to be attacked by different permutations of the bug.
I'm also not entirely sure if the technique is needed at all on this device (fbtool sounds more promising Started work on my own tool to talk to bootrom and preloader -after playing around with the protocol and staring at the preloader source, it seems impossible to to send DA / jump DA properly on this device), I actually suspect it will work on the HD 10 post Feb 2020 devices better - i.e. forcing downgrade from 7.3.1.2 to 7.3.1.0 but again it might brick instead from RPMB checks, similar to current scenario with using it on the Fire 7. Need to test hack on HD 10 2020, should work fully, holding back whilst fixing the fire 7.
SOFTWARE Related Ideas/Notes:
AFTV2-tools?
THOUGHTS: Can complete handshake, but on read it stalls - no response. Was this blocked on this preloader? YES.
Does anyone have any other crash to bootrom from preloader methods other than the one's in this code base?
amonet-kamakiri?
THOUGHTS: How do you modify this to use UART instead of VCOM? Maybe UART mode for flashing might allow it, anyone know how to get device into UART SP Flash mode?
Don't think this device has UART flashing mode but can't be sure (only able to get logging)
mediatek-datool?
GitHub - mtk09422/chromiumos-third_party-mediatek-datool
Contribute to mtk09422/chromiumos-third_party-mediatek-datool development by creating an account on GitHub.
github.com
THOUGHTS:
This might do it, but sounds complicated, I think it might be able to be used to clear existing chain of trust if used in a certain method - still mulling over the details. Upon some brief testing when used with 6315 preloader and lk.bin i get error about .sign file, but the gibberish from the UART seems different to cold boot scenario, i.e. the device is logging something extra based on passing in command to device. Jump DA / Send DA logging appeared on UART
Need to understand what the code is doing more - looks like it is sending a preloader and lk.bin to boot the device into fastboot mode, and the sign file is rather a patch file generated by the gen-dalk-from-lk.py to make a temporary DA file to start transfer of the preloader/lk.bin to reboot into fastboot - if so, then this may work as a generic method for mtk devices to unlock/root, by compiling lineage lk.bin/preloader without secureboot enabled and with fastboot unlocked then using the script to create the .sign file and using fbtool to boot to fastboot which is then unlocked. Might also need a hacked preloader which bypasses rpmb rollback check and any other security preventing booting. I still think it is possible by using MTK's key not Amazon's key. Need to find a MTK 8163V preloader / lk.bin source code (anyone have any links?)
This will only work with lineage compiles not FireOS as you need to boot it in secure chip mode using fbtool which then would need an auth file from existing amazon key (This is assuming that there is no existing key check to block fbtools from booting up - Need to confirm if fbtool can be used in insecure mode to boot into fastboot on this device Insecure mode doesn't work) - There is still possibly a way to use FireOS, but it would mean fully unsigning FireOS and resigning it with your own key then flashing that on, after having generated the relevant auth file / sign file for fbtool - This approach should enable FireOS with your own key. Whilst once in hacked fastboot should be able to reflash the original full ROM which would cause it to revert to stock.
I think fbtool is one of the only uses for the preloader, and offers a chance to unbrick devices which only have preloader access and no bootrom access (like this patched device). Need to either sign with Amazon or MTK's key - I think either one may work. Whilst Amazon's key is unavailable, isn't MTK's key supplied in the BSP?
Anyone have lineage installed on Fire 7? Need someone to test generating a DA file from fbtool's python script to see if it works. If what I'm thinking about the difference in Secure DA and DAA is right it is likely to work - DAA i think is disabled as it looks like it is to do with verifying preloader / lk.bin at bootrom stage.
[ROM][testing][mustang] Lineage-16.0 [25 Jan 2022]
Disclaimer /* * I am not responsible for bricked devices, dead SD cards, thermonuclear war, * or you getting fired because the alarm app failed. * Please do some research if you have any concerns about features included * in the products you find...
forum.xda-developers.com
Doesn't seem to have lk.bin. lk..bin provided by MTK not android project...
Some further ideas to investigate:
Using a blank preloader file for fbtool, to see if it causes device to drop into bootrom mode
DIdn't notice in fbtool readme that enable DAA was a one time operation.
Does anyone know of a definitive example of a device which has eFuse blown for crypto key?
Looking at previous threads, there is an indication that amazon attempted to test whether the eFuse is functioning, but there was no verified proof that eFuse has been blown. For the Fire 7 Gen 9 that I have, it appears the brom access was disabled by changing the eMMC chip not blowing a eFuse.
There is also no evidence of Amazon using an eFuse to store the crypto keys for this device that I can locate, meaning fbtool is very likely to be where chain of trust begins.
I think the way to check properly is to look at SPFT's terminal mode for reading the efuse's on the device. We might be able to do this on a unlocked/accessible Fire 7 Gen 9 2019 (i.e. one with available eMMC short to brom)
signfile-for-brom.sh indicates the preloader is patched with key? Does the preloader.img.sign file get accessed by the brom when being used by fbtool?
Need to look at bootrom code to verify what it does when fbtool has sent it a sign file as part of reboot to fastboot cycle. Looked at preloader code for answers instead
Is TEE/TZ1/TZ2/Trustzone updated by fbtool/datool? Is this where it is processing the sign files. Its also maybe using RPMB to store keys?
fbtool requires a almost payload like data structure, this is contained in gen-dalk-from-lk.py and will require one per SoC type. The above github does not contain a copy, but I have located one for MT8163 from another source. In order for this method to work on more devices, would need to locate more "payloads" for other SoCs. This method is very likely to be a clean method to access numerous MTK based devices.
The preloader contained inside Amzons rom files seems to be split into main preloader.img and preloader.hdr0/1 files, These look like they need merging or prehaps they are the MTK headerless version of the files (fbtools readme indicates a need for headerless files)
Any ideas where you might find "fbtool-da-pl.bin is a pre-built preloader_${PROJECT}_NO_GFH.bin" for this device? Should be in preloader/lk.bin compile process.
What about boot.img renamed to factory.img and placed on sdcard?
THOUGHTS: strings on the preloader indicate this may be possible, unless this has been blocked and the message hasn't been removed. Need this tested. No sdcard boot on preloader/lk.bin available but... Bootrom boot maybe possible see latest!
Tried SP Flash 5.1532 (insecure boot version) any other flashing tools that might work?
If it is in preloader mode, will there still be security blocking flashing if attempting to do UART flash instead of USB flash (UART might have different permission level than USB), will MTK-Bypass work with some modifications to talk to real COM port instead of VCOM?
THOUGHTS: mtk-bypass says it is bypassing DAA (Download Agent Authorization), My current understanding is it is disabling DAA and SecureBoot unnecessarily and should only disable SLA.
DAA sounds like it occurs at bootrom to verify preloader and lk.bin has been signed itself (fbtool Readme)
Secureboot sounds like it is the flag that is passed through to AVB (Android Documentation)
SLA sounds like it is the Secure DA being verified at preloader stage
Had a look at source / info online about it, and i think I'm right that DAA and secureboot disabling are not needed - SLA bypass is needed for SPFT fulll flash as that is bypassing secure DA check on preloader - whilst DAA and secureboot bypass via MTK-Bypass is needed only for a tethered boot scenario where device has DAA enabled fully, and you want to boot a preloader/lk.bin that hasn't been signed, mtk-bypass could then be used to tether bootup to disable both flags and enable booting - maybe then we can modify it a bit for devices where DAA is fully working with secureboot?
Which devices have problems with modified preloader/lk.bin which feature mtk chip, those would likely benefit? Not relevant for this Fire 7 I dont think. This allows a tethered boot solution for various scenarios, like linux dual boot, full system rw android install, etc.
Would using a hacked preloader which has secure DA verification disabled, whilst the device has bricked preloader and in bootrom mode, enable SPFT to flash device without mtk-bypass?
This would mean mtk-bypass is only worth using if you can't remove secure DA support from the preloader file itself - i think it might be patchable out with decompilation. Either that or the preloader is not fully bricked and still being read by bootrom to perform secure DA verification, would likely also need mtk-bypass in this situation.
This pad is ridiculously infuriatingly annoying to attempt to recover back to stock... Unless I am missing something obvious that i haven't tried.
Also anyone know where I can find the signed images for 6.3.1.1 6.3.1.0 or earlier, need the original update-*.bin files?
THOUGHTS: Already got everything from waybackmachine - any other sources of urls from their servers?
Also is there any available Preloader versions for this device or any *OTHER* Amazon devices that have preloader crash to Bootrom available? I need full collection of Amazon ROMs for all devices if possible, with it I might be able to get unlock/root working on them all - Chasing after a preloader that works to crash to get into bootrom or has available shortcut to enter bootrom (i.e. power/vol buttons) - with it plus what i've worked out, should be answer to all Amazon devices unlock, hopefully. I might also be able to repeat for all other devices - this might even work with the 2021 HD 10 which is just released!
Also any good guides to preloader/IDA Pro decompiling? Is this what I need to buy from IDA in order to repair and recover my Fire 7?
IDA Pro Computer License [Windows]1879 USD
ARM64 Decompiler Fixed License [Windows]2629 USD
ARM32 Decompiler Fixed License [Windows]2629 USD
The home version is a cloud based decompiler isn't it? Above is minimum price for offline decompilation isn't it?

Hardware related Ideas/Notes:
Tried hw method for CMD/DAT0/CLK and the emmc pin at front, no response (CMD jumps to preloader while all other test points result in no response - same as previous testers of newer Fire 7 device)
Anyone know what the other testpoints are, like:
VCOM/VGH/RST/ON/ID/VBAT/AUX_NTC/PWRKEY/USB_ID/DP/DM/VBUS/VGP3_PMU/FCHR_ENB/COL0
GND - Why did they put a pad for this when there is GND everywhere on the board?
CLK/CMD/DAT0 - MicroSD connection! NOT eMMC... Test with ohmmeter against MicroSD pins!
TX/RX - UART
SDI/SDO/SCI/CS
Is SDI/SDO/SCI/CS some kind of SPI or another interface? Likely it is SPI (anyone know how to talk to it? I have raspberry pi's / picos / arduinos / ch341a)
What about the covered over points?
VIO8_PMU - 1.8V to eMMC?
VCC_IO - Cant rememebr if it is this one or above, need to retest.
VEMC3V_PMU - 3.3V to eMMC?
VCCK_PMU - Voltage to SoC?
AVOD/VGL/LEDA/LEDK/SPK_N/SPK_P/VPROC_PMU/VMCH_PMU/VMCA_PMU/VCAMD_IO/VCAMD_PMU/HPL/HPR
Maybe can make a list of all points and how they behave for this board?
Anyone know of how to interface directly with the eMMC by soldering MMC adapter?
Tried to attach to dat0 from front of board but ended up tearing pad - need to use a better method than soldering, maybe use Rubber+Needles+Crocodile Clips
Any chance of doing stock recovery by UART RX/TX flash?
THOUGHTS: Probably not, likely only get boot logs.
Can I use a raspberryPi B to connect to UART, Do I have to use RS232 or TTL?
THOUGHTS: No, possibly dangerous, RaspberryPi B is at 3.3v whilst this is possibly 1.8v - need to measure using voltmeter. RS232 should be safe as it uses -13v-+13v for RX/TX. USB TTL would also need a logic level shift from 3.3v to 1.8v. Therefore USB RS232 adapter is best choice. (I think for TX from board to RX from USB Serial - But dangerous from RX from board to TX from USB Serial because of over voltage from adapter possibly supplying +13v - need confirmation as this is useful for potentially debugging other gear by UART) Problem with RS232 is signal is inverted when read, therefore needing inversion by another chip to display correctly - better RS232 USB adapters seem to be able to be flashed by EEPROM to invert signal (FTDI ones with mProg). Need a USB TTL for further testing. Need to see if PL2303 can be hacked to invert signal - maybe driver hack for linux possible? Anyone have any simpler solutions to see UART logging from this device, or do I need a logic level analyser?
If so how to connect it?
THOUGHTS: Connect TX to Pin 2 from RS232 and GND to Pin 5 (Dont attach RX from board, else possible over voltage from sending data from PC). Using CH340G attach RX to TX on PCB, GND to GND, Make sure cables are shielded or split due to interference from cabling touching each other. Connection currently without battery installed seems to output gibberish, need to test with battery installed (Maybe bootloader logs will output) -Currently despite gibberish output it is most likely 961200 baud Databits 8, no flow control, 1 stop bits for preloader. Bootrom logging sounds like it might be 115200 (according to older kindle device thread )
Since the device can seemingly only output from UART, why is there an RX pad on the board? How or what can you transmit to the device by UART?
Is there anything inside the console for flashing back 6.3.1.5? No Console
Managed to hook this pad up by UART - RS232, but despite trying all the baud speeds / settings only getting gibberish output - is this because the UART is spitting out MTK flashing protocol language since its in preloader mode without battery attached?
THOUGHTS: Think it is inverted signal logic rather than low level protocol.
Should I attach battery instead of USB power to see Bootloader logs? If so, how to attach battery to board whilst UART is soldered to cabling?
THOUGHTS: Unlikely to help, and potentially dangerous
Anyone tried any dongles with the Fire 7 or any other Amazon devices? MT/NCK/etc?
Last thing I can think to try is the NCC Group Hack on mt8163v chips using FPGA and chip whisperer. Anyone know how to simplify that process for this scenario of brick recovery rather than full unlock? - sounds like some well timed shorts in bootup might glitch it enough. Does this even work still or was this fully patched as part of mtk-su patching? Tried GND VCCK_PMU but couldn't get anything other than normal boot
There’s A Hole In Your SoC: Glitching The MediaTek BootROM
This research was conducted by our intern Ilya Zhuravlev, who has returned to school but will be rejoining our team after graduation, and was advised by Jeremy Boone of NCC Group’s Hardware &…
research.nccgroup.com

Modding the Redmi Note 8 Pro — An Adventure
Back in November 2019, Xiaomi sent some of us the Redmi Note 8 Pro through XDA, to play with and mod. The Redmi Note 8 Pro is powered by…
medium.com
"The difference between the two is, in SLA, BootROM performs the checks and in DAA, Download Agent (DA) performs the check. Download Agent is loaded by SP Flash Tool. On devices that implement SLA, you cannot load a DA file without completing the SLA challenge. On devices that implement DAA, the challenge is done by DA and a modified DA file is enough to bypass security (That is, assuming you manage to reverse things or have the BSP)."
I think the above (one of the few places I've seen talking about DAA online) is again not quiet entirely right - Description above indicates DAA is Just normal Secure DA necessity, i.e. less secure than SLA.
SLA is the usage of a Secure DA itself, whilst DAA is preloader and lk.bin signature verification.
Secure DA could contain, in this case Xiaomi Authroisation Request, therefore in this case only SLA needed disabling.
What is interesting is the mention of BSP. fbtool is part of this isn't it?
Given how complicated this is and the number of slight mistakes in terminology use I see everywhere online, I think fbtool really might work on this device and many others for a "fastboot cable" with enough tinkering.
Also notice how the tool is named both datool and fbtool in the same package, google also returns very little about both of these, and DAA now contains only links to mtk-bypass. Suspicious!

https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp3264.pdf
The above links to the cryptocore usage for X30 chip MT6799W, which sounds like a more complex design than the MT8163V.
"Chaining of secondary public keys, signed by the root-of-trust public key, to permit parts of the system image to be signed by other trusted developers"
Don't we just need a copy of the root-of-trust public key for signing the bootloader image?
"The module remains assigned to the User Role permanently, unless the operator moves the module into one of the special Life Cycle States intended for fualt discovery (Secure Debug and RMA)"
"a) Run a special boot loader that can be flashed to the device
Flash a special boot loader to the device and power up
The boot loader enables RMA state
Set all 1’s for all the platform keys that are stored in OTP
b) Use a PC tool to send command to the device
Send a zeroization command from PC tool to the device
Device firmware interpreters the command and enables RMA state
Set all 1’s for all the platform keys that are stored in OTP"
Wonder how to shift the Life Cycle State? Wonder what PC tool is being referred to there?
I doubt the MT8163 is as secure, can anyone confirm?
Also notice they call it One-Time-Programmable but you seem to be able to set all 1s after the One Time Programming operation! (isn't zeroing setting it to 0 not 1...)
Bit off topic, but too appropriate:

stickfiretv2020 said:
After months of slowly calculating this I finally have some solutions for the latter hw revised devices!
Option 1:
Randomly poke at area near the emmc chip, yes seriously... I did it on one that I was trying to scrape the pcb tracks on, after tearing off pads near emmc by accident. It now doesn't boot but I get bootrom output!?! bootrom is halting (as seen on uart) and its error message is varying based on changes to inserted microSD (i.e. change partition names on card and I get different error from bootrom), i.e. I think I got bootrom booting from microSD - I don't think these newer devices have bootrom DL mode at all anymore, replaced by microSD boot instead. The damage to board is likely the cutting of one of the eMMC tracks that has done this, need a microscope to see where i cut exactly on the pcb.
Problem I now have is how do I partition a microSD card to match the eMMC's layout and flash Android onto the card? Anyone got good instructions? It is MTK Bootrom MicroSD boot mode not preloader/lk.bin boot Android from MicroSD mode. I think I need to partition EMMC_BOOT0 EMM_RPMB EMMC_USER etc like Jedec standard, or like armbian.
There is a second option but I wont go into that as it is very hard! requires special circuit made from arduino/microcontroller and a really clever hack for fire 7 2020, for fire 10 2020 it may only need hack still waiting to try it on my pads, holding back testing it because of this dead fire 7 i've been trying to fix instead.
Click to expand...
Click to collapse
So close!

Is there a way to identify these devices? I was given a new Fire 7 Gen 9 and updated it to the stock rom 6.3.2.1 I think. Then used the h/w trick of shorting a tiny pin, which worked. It's now running a non-stock rom with TWRP 3.3.1-0. I don't know how to tell if I have an older device or just lucky with the new device.

stickfiretv2020 said:
There is a second option but I wont go into that as it is very hard! requires special circuit made from arduino/microcontroller and a really clever hack for fire 7 2020, for fire 10 2020 it may only need hack still waiting to try it on my pads, holding back testing it because of this dead fire 7 i've been trying to fix instead.
Click to expand...
Click to collapse
Any progress on this option? I have a Fire 7 2019 that appears to be a post-Feb 2020 hardware that I'd like to have running LineageOS. It currently has stock 7.3.2.2. I'm comfortable with arduino/microcontrollers and soldering, so I'd happily volunteer to help with testing.

It's unfortunate that the Fire 7 9th gen can't be downgraded. I've done everything I can to slim down the bloat with this tablet, such as fire toolbox, but it's just not enough to make this tablet usable in real life. It is excruciatingly slow trying to do anything with it. The grossly insufficient 1gb ram is full after boot with bloated apps and services before you even try to do anything and it only gets worse from there. The best thing you can do with this tablet is to make it into a digital picture frame or something that requires no intervention. Nowadays, I only use mine to run a ping app to continuously ping google.com during an internet outage to see when my connection is restored while I'm using the hotspot on my phone waiting for my home connection to work again. This tablet is effectively dead for the unfortunate people who own one except for the most desperate of people who can afford to wait a full minute or two or three for a website to load or just an app to open, or to just get it to respond to any user intervention. It's too painful to try to use in any way at all. It's like trying to run Vista on an old grossly underpowered XP office pc. We all know how that went. So, I think I speak for everyone when I say that this tablet is effectively dead until a method is discovered to root it. R.I.P. Fire 7 9th gen. "He's dead, Jim."