Database Develop

Multitouch limited to two fingers?

Hi,
as you may have realized the Streak has only 2 fingers multitouch. Sometimes it is an software limitation and can be adjusted. Does anyone know if this is the case for the Streak? Any hint?

According atmel, it supports 10 touch
http://www.atmel.com/dyn/products/product_card.asp?part_id=4620
http://www.scribd.com/doc/50575488/datasheet-for-mXT224
http://forum.xda-developers.com/showthread.php?t=878936

Okay, now we need to figure out where the limitation is and fix it. Anyone on it?

Every multi-touch tester I've tried only shows 2 fingers max. My Evo 3D shows 4 fingers with the same app.

If you want more touch points (assuming that it is in fact that controller), you'll need to modify/rewrite the touchscreen drivers to make it work with more.
The last link giveen gave is link to a patch to tell it to accept more touch points. It doesnt ADD touch points, it merely tells it to use more points that were already available, but simply not turned on.
If it's simply points not being enabled it should be a trivial rebuild, if it's not in the s7's kernel source code you'll need to merge in a driver that does support the extra points.
There should be a reason that dell didnt turn them on, as a 7" display can reasonably take advantage of at least 4 points.
To compare to the fm audio support on the s5 (which was also turned off) it was due to it being rather buggy, if the code to take use more points is in fact in the kernel, it might not be particularly useful.

Did anyone figured out how to enable more touch points?

If anyone wants to give it a try, this is our TS driver
https://github.com/DJSteve/streak7-...s/input/touchscreen/atmel_mXT224_touch_luna.c
https://github.com/DJSteve/streak7-kernel/blob/master/arch/arm/mach-tegra/board-ventana.c

Well, I'm going to have a go at this, bearing in mind I'm going to be teaching myself as I go along, if I can figure out where to modify the files, I may need someone's help getting it into a kernel. Really I'll be happy if I can figure out how to get even one more touch point active.

TesseractSpace said:
Well, I'm going to have a go at this, bearing in mind I'm going to be teaching myself as I go along, if I can figure out where to modify the files, I may need someone's help getting it into a kernel. Really I'll be happy if I can figure out how to get even one more touch point active.
Click to expand...
Click to collapse
I've actually done a bit of work into this.
First you need to build a linux box, personally I use a virtual machine, using Ubuntu 11.10 x64.
Then you need to get our source, listed above in the ICS branch or the HC branch.
Now our board-ventana.c already states 10 finger touch. That was built-in.
Now the driver is for a Atmel mXT224 touchscreen controller, which is a TS common in lots of devices. Now I am currently working with a couple people in Dell tracking down some information in regard to the DS7. I was informed the reason why the TS controller driver is not a standard format like all other mxT224 drivers is because the screen itself is different. I am still waiting to hear back in regard to this.
I've been denied loads of information due to legality issues.
Anyways........
the driver is a custom one and needs to be re-written to accept more touch.

how would one Install this? im running Giveen and Dj_Steve's HC on a US 4g model

ThattOneKiddMichael said:
how would one Install this? im running Giveen and Dj_Steve's HC on a US 4g model
Click to expand...
Click to collapse
HC build is purely Steve, I didn't do anything with that build.
Second, you can't install this. Its a driver source code that needs to be modified and then built.

Brainstorm of remote exploit targets

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

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

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

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

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

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

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

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

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

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

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

Force Eureka firmware ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

WANTED: Feedback on hobby project 'ANDROID MOBILE TRIAGE KIT'

::THE HOOK
Hello! My name is Atomicmuffin, and may I present the concept of an (aptly dubbed)'Android Mobile Triage Kit'! This is a minor little "side-project" i've been killing time with as of late and it had been suggested by an associate that I share with the community.
::THE GOAL
In a nutshell? I just want community feedback. Before I set to work typing out a series of long articles (I tend to be overly defining in my writing :C), and before I spent the time to lay everything out, taking pictures, tutorializing steps, etc. And that's just the Forum part. The UI/UX is non-existant, nor do I have any sense of established direction with my custom software tools and the like that i've written. SO, before the required time is spent "noobifying" my mini-project and developing documention as such...here I am.
::A BRIEF BACKSTORY
I decided to come here and gather input from th community following my experiences yesterday, which consisted of the successful ressurrection of an associates' pretty-much-dead Galaxy S3-Mini via on-the-spot boot-sdcard generation....subsequently followed by another associate whom wanted the latest firmware (Marshmallow) for their S5 (flashed to PB1..they were still on 4.4.2 KitKatt! NK1 I believe)...and capped off with the first-timers' starter-pack (S4-edition) for a friend: TWRP Flash + Root >> then custom ROM and Kernel.
This general scenario is of course nothing new to the modding community, however there is one (or maybe two or three) critical aspects of this partiticular endeavor that may appeal to some, the primary of which is PORTABILITY.
All of this happened in a 20-minute window, at a Starbucks, and it all fits in my jean pocket. Hell, half the time was spent waiting for downloads to complete on crappy Starbucks wifi. Afterwards, It was suggested that I venture outside of my bubble and share with others this little setup i've assembled. And after brief consideration about persuing it, and longer consideration for the name of it, here I am.
Triage [tree-AZH]:
-Noun -- Triage is the process of examining problems quickly, often with limited resources, in order to decide which ones are the most serious and consequently must be acted upon first.
Alrighty then!...but why?
See...now that's just one o' them great life mysteries. But actually, I'd have to conclude that it is because I lack other, more creative ways to spend my free time. Take this circumstance combined with owning excessive amounts of Samsung mobile devices (in sequential order, too!) and **** like this was just bound to happen sometime....
:EAKING UNDER THE HOOD
So...just what is the 'Android Mobile Triage Kit' exactly?
It is an assortment of tools & utilities, both hardware and software, and self-made as well as some google-search-aquired software components and some Amazon-search-aquired hardware components. And so, with those powers combined, out pops a Triage Kit in which one can quickly assess and attend to any Samsung mobile device capable of being flashed via ODIN.
Even at this stage (lets call it Pre-PreAlpha) or "state" of the project, there is nothing I cannot do in ODIN, nor any other tool that this setup cannot do as well. Mobile Odin and FlashFire (and similar apps), while certainly very useful and convienent for what they are (Thanks Chainfire! And also for the inspiration!), they depend on one, often-critical and unchangeable fact of life: The device has to at least boot. Even further, make it into a ROM after booting, and further still, require root privs. Whereas the only immovable obstacle facing my uniquie approach would be something along the lines of definitive hardware failure (like you dropped it in the pool).
Even if you're hard-bricked and cannot reach ODIN-mode, depending on which device you have the tools exist or are in-development, and those select devices can often be recovered by constructing a boot-sdcard (or more advanced, a boot eMMC-like partition on an external flashdrive). Currently, the pair of tools i'm developing to handle those tasks is on the backburner, but not forgotton.
::TEAR 'ER APART AND PIECE 'ER TOGETHER
All that's left is the how. This article is already too damn long as well so I'll try to be brief..
Absolute Essentials:
1x - Samsung-manufactured device to be operated on. (e.g the phone you wanna ODIN-flash)
1x - Mobile Device running Android 4.4+ (KK+) and ROOT CAPABLE, ideally Samsung-manufactured as well but not critical.
1x - USB-Std A--Female to USB-MicroB--Male Adapter. Colloquially referred to as an USB-OTG adapter.
1x - Length of standard USB-Std A--Male to USB-MicroB--Male cabling. (AKA Charge cord)
MUCH - Patience.
This would be bare minimum. My "kit" contains many more tools and doohickeys to save as many helpless victims on the go as possible. I'll add a pic later, but given the functionality of it all, it STILL FITS INSIDE MY 'TRIAGE BAG' (aka A Crown Royal Baggy), AND FITS ENTIRELY INSIDE MY JEAN-POCKET, ALBEIT SNUGGLY..
::THE NITTY GRITTY
Since Android runs atop the Linux Kernel, The main concept here is what happens inside the MasterDevice (or HostDevice, if you will). We actually piece together a Linux Distribution and build a rootfs imagefile. We "boot" this image inside the phone, passing variables, params and other required resources from Android such as hardware drivers, etc. We then pull a Chinese Fire Drill with various processes, handing the reigns over to this booted image. Once all is said and done, we have (for all our relavent intents and purposes) a running Linux Distro in which we operate. From there it's just a matter of developing the comm tools.
This "chroot", as it's called in Linux terms, isn't only limited to our application of it flashing devices. In fact, I built my "Plebian" (my own personal Debian-based setup) chroot on my VZW-branded Galaxy S4 for the sole purpose of assisting in the ONLY OTHER "side-project" i'm working on currently: Reading, Reverse-Engineering and Hacking the CANBUS its associated modules inside a BMW E90 via the ODB-II port. You can do anything! It's basically a mini-desktop. In fact, i'm (although sparingly) working on further integration with my phones, involving root-switching, kernel-switching, kexec'ing (hot-booting Kernels), and perhaps even bootloader bypasses? Who knows. But anyway....
If interest is lackluster, no big deal, whatevs, it's just a side-project. However should interest explode, patience would be a virture, as it would be a good chunk of time before I'd finish creating all relevant documentations and such, and stabilize the disaster that is the current UX before finally going public. Unforuntely in it's current "working" state, only those with quite the intimate knowledge of Linux (and kernel), usb, serial device communication, etc..etc...would be able to actually use it effectively. Thus why i'm here to receieve feedback!
::THE FINAL QUESTION: Should I continue to develop and release such a project? And would the community benefit to such an extent as to justify the additional time investment? Thank you guys so much for the input!
P.S: Didn't know which forum to post in, since i'm currently only requesting feedback in the conceptual sense, so posting it in off-topic.

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