yashsingh1/xdaforums huggingface dataset:
[Fire Android Development] DragonFire1024:
I agree 100% I never owned a Moto phone I didn't like. I owned an LG Vista 1st Gen for a short time. I didn't like it because it was too big. I ended up cracking the screen and the liquid crystal ended up bleeding through one of the corners one night. I think my next one will stick to a 5in or less screen. I don't do well with anything bigger in terms of phones. But I digress as this is a bit off topic.
[Fire Android Development] MeowDude:
I miss android so much, I haven't used it since 5.1 on my Kindle Fire HD 7 (then when I bricked it, and 8.9), and my Huawei Fusion 2 (surprising amount of support considering how unpopular it is)
[Fire Android Development] DragonFire1024:
Personally, I'm a KitKat 4.4 fan myself. That version was when you could do a lot more with Android. Too bad it's just too old now.
[Fire Android Development] MeowDude:
My fav version will always be ICS, 4.1.x was nice to, but nothing in the world beats classic 4.0
[Fire Android Development] DB126:
More a case of familiarity and tool sets. Android 5 moved some functionality 'under the covers' for security and performance reasons. All knobs and dials remained accessible to those with root and the right box of tools (eg: Xposed). Same with subsequent builds.

The expansion of Google Play Services (which most app developers leverage) is arguably more debilitating to tinkerers.

Was pretty fond of my Timex Sinclair, Commodore 64 and later everything Z80, especially the elegantly simple command set that made machine language a breeze. Also rebuilt 4-bbl carbs for giggles-n-grins and liberated a few pink slips from foolish youngsters. Alas - the past is what it is; looking forward is far more productive.
[Fire Android Development] glockman4519:
I agree but the direction Google is headed with android is far from developer friendly. They are moving more towards an IOS type of system with more things unable to tweak and change. I look forward to seeing what is coming around the bend like everyone else but the days of awesome custom development I fear is also going to be a thing of the past.
[Fire Android Development] DB126:
On that point we are in 100% agreement, especially if unwilling to use the limited suit of knobs and dials that Google provides. Kinda like watching "kids" (arguably anyone under 30) code. Everything is a library call. Ask one to write a simple bubble sort and differentiate between algorithms - clueless.
[Fire Android Development] N0tHum4n:
Is it possible to modify this app for avoid the locked bootloader? https://xdaforums.com/fire-phone/development/recovery-safestrap-v4-0-1-t3149888
[Fire Android Development] DB126:
SafeStrap v4.0.1 is a custom build for Fire HDX (3rd gen) and Phone running specific builds of FireOS v4. It will not work on this device; the developer has shown no interest in doing so. Nor is it needed or beneficial.

SafeStrap predated FlashFire and offered a means of flashing custom ROMs on bootloader locked devices. The underlying ROM must be rooted to install Safestrap which at present is the largest obsticle for Fire users at present. It does not sidestep the bootloader nor offer the robust recovery capabilities of a bootable custom recovery. The interface looks like TWRP - but it isn't.
[Fire Android Development] t3chwizard:
They had something like that for the Motorola Atrix 2. It allowed you to flash ROMs without unlocking the bootloader
[Fire Android Development] steve8x8:
I've been reading through this thread multiple times now (having been pointed at the serial connection via USB). About one and half a year ago, [MENTION=4381075]hwmod[/MENTION] claimed he had found a way to "write everything to any location in EMMC".

What I couldn't spot is how to actually do this, for recent versions of fireOS (may have ended up in another thread?).

Also, I'm still focusing my curiosity on the RPMB which cannot be reached using normal means as the kernel forbids access to it, but using a low-level approach like [MENTION=4381075]hwmod[/MENTION]'s it should be possible to (a) extract the RPMB from any device, and identify the PL, TEE and LK version numbers stored in it - and perhaps (b) write something to the RPMB that makes it look corrupted (as the preloader might try to fix that - a flipped bit should not lock out a rightful user).

This isn't "unlocking the bootloader" in almost any sense, I agree. It still might enable version r*llb*cks, which would be a gain.

Should I look again, or get a new set of glasses?
[Fire Android Development] Kramar111:
Only for 5.0.1-5.1.1. On 5.1.2 and up it didn't work.

And only on user area, not on RPMB

https://xdaforums.com/amazon-fire/development/unbrick-fire-7-5th-gen-downgrade-t3388747/post67085514

As for "identify the PL, TEE and LK version" you can see line like this "[ANTI-ROLLBACK] PL: 2 TEE: 3002 LK: 3" on USB-serial log, don't need to disturb RPMB :)
[Fire Android Development] steve8x8:
Thanks for clarifying the first point. End of the road, once again.

For bootloader identification, if you got the serial log line it may already be too late. And it's not accessible to anyone.

What I was aiming at was a list (as comprehensive as possible, i.e. using the available stock rom images) of numbers the (unknown to us) RPMB ones get compared to. Rationale: If those change from one release to the next, there's no downgrade path. No need to try and brick.

I presume there's a code pattern in the preloader that has been stable since 5.1.1 - the question is how to identify it. (Let me guess: next gen preloaders will come encrypted.)
[Fire Android Development] t3chwizard:
Interesting, but maybe we could go about this a different way?

Would it be possible to tie in a function similar to SafeStrap into the Lineage ROM by [MENTION=5749760]ggow[/MENTION]? (Being that he is the guy who made that thread for the HDX and also is the one building Lineage for our device). If we did that maybe we could start to get somewhere else? Just thinking out loud. If not for everyone this could at least be beneficial for those who still have devices that can install custom ROMs, whether it be via fastboot with TWRP or via FlashFire. At this point I'm thinking this may be our only option left to progress beyond Lollipop ROMs unless Amazon suddenly has a change of heart and decides to provide us with a bootloader unlock tool.
[Fire Android Development] DB126:
SafeStrap offers no benefit over FlashFire. It will not enable progression beyond Lollipop (Android 5.11) based ROMs as kernel dependencies remain. Enjoy this device for what it is.
[Fire Android Development] ggow:
Safestrap wouldn't help us here. This is because we would still be stuck with amazon's kernel at lollipop patch level. As previously pointed out we have FlashFire now which serves us nicely for custom rom flashing.
[Fire Android Development] t3chwizard:
Darn. That sucks. They did something on the Atrix 2 using something called Boot Menu Manager to boot custom ROMs without unlocking the bootloader. I'm not sure how it works but maybe that's different?

Here's a link to a guide with instructions discussing it http://ravi.rajiniravi.com/blog/2014/02/cyanogenmod-11-on-atrix-2/

Note: Edited because second question was answered for me by someone in another thread.
[Fire Android Development] sd_shadow:
FlashFire works with many devices, but it depends on the device, twrp and bootloader lock or unlocked are only part of the equation
[Fire Android Development] t3chwizard:
I'm talking about on our Amazon Ford.
[Fire Android Development] sd_shadow:
Only root is required for FlashFire to work on Ford
[Fire Android Development] t3chwizard:
Thanks I'll give it a try then.
[Fire Android Development] Abdullah_hammoed:
How can i do all of those
[Fire Android Development] sd_shadow:
all what?
[Fire Android Development] Abdullah_hammoed:
Add all of the codes into my phone lg l22c

:laugh:
[Fire Android Development] sd_shadow:
Add all of the codes into my phone lg l22c

This is an Amazon Fire Tablet thread,

Please stay on topic,

and Post Titles are not shown in forum apps (XDA Labs, Tapatalk...)
[Fire Android Development] t3chwizard:
Maybe we could see if geohot could help us? Just throwing ideas out there
[Fire Android Development] steve8x8:
Are you talking of the same geohot I have in mind? There has been almost only King*root for more than a year now, where has geohot been all the time? I think focus has changed to something more promising. (As always, feel free to prove me wrong.)
[Fire Android Development] t3chwizard:
I am talking about the dude who made towelroot
[Fire Android Development] Robius:
He's busy hacking cars
[Fire Android Development] t3chwizard:
Lol
[Fire Android Development] steve8x8:
Hacking cars is more prestigious then than playing with Fire...
[Fire Android Development] t3chwizard:
Depends on what kind of car, like if he is hacking a station wagon from 1980 then playing with flames might actually be more interesting.
[Fire Android Development] DB126:
...or juggling chainsaws :)
[Fire Android Development] Robius:
Not much to digitally hack on a car that old.

I have actually seen chainsaws being juggled. Yes, they were full on and not just idling.
[Fire Android Development] blakegriplingph:
So, uh, any hope on getting the bootloader/preloader to ba hacked? I know I own a different device, but I am having a similar issue with my LeapFrog Epic - bootloader's restricted, and I can't use SP Flash Tool normally unless I use Write Memory or somehow get my hands on a signed ROM scatter package.
[Fire Android Development] DB126:
Exceptionally unlikely given the history of bootloader exploits on Amazon devices.
[Fire Android Development] hwmod:
Could it be a different Firmware Updater Tool exists ?

Hooking up the serial interface to my bricked Fire 7 5th Gen, I am getting the following prompt:

BUF2!F1

The prompt stays for just 1 second or less and then is followed by a series of READYREADYREADY ... then starts the normal boot process.

I never noticed this fact previously so I went with a quick Google search and ended up here:

https://hackaday.io/project/21273-try-porting-linkit-one-on-linux/details

This is the only place I could find having small info on this, nothing else !

Does anybody have more info on this ? Is this the same protocol used by SPFlashTool or is it something different ?

Maybe a Lower level flashing procedure ? Can we use Linkit One Firmware Updater tools on this ?

Many questions and few information, I know. But anyway better than nothing...

Have fun,

.:HWMOD:.
[Fire Android Development] blakegriplingph:
Care to elaborate on the serial interface you used? If it helps, the PC I am using has a serial port built in.
[Fire Android Development] DragonFire1024:
If bricked, can you boot to fastboot? See if the tool responds to fastboot? I mean it can't hurt to just plug it in and not do anything.
[Fire Android Development] hwmod:
I have now taken out the board from the tablet case and connected the board TX / RX and GND point to my PC through a USB to Serial converter I bought from Sparkfun.

Here is the the link to the Sparkfun page of the converter I am using: SparkFun FTDI Basic Breakout - 3.3V

By using "minicom" on Linux or Mac, when I connect the USB cable to the board I get printed the string "BUF2!F1" from the serial port.

.:HWMOD:.

---------- Post added at 10:35 AM ---------- Previous post was at 10:20 AM ----------

No ... the board cannot be recognized by "fastboot", with other tools I can write to all the partitions except the "mmcblk0boot0", "mmcblk0boot1" and "mmcblk0rpm" blocks.

.:HWMOD:.
[Fire Android Development] blakegriplingph:
Sounds interesting. Not sure if I could get my hands on one of those though, but if anyone is willing to donate or part with one, I'd be glad to have it so I could revive and unlock this LeapFrog Epic I bricked last January. Is that all what we need to interface with the board, or is there anything else I need to take note of?

As for the the "mmcblk0boot0", "mmcblk0boot1" and "mmcblk0rpm" blocks, could that be the reason why my Epic stayed dead even after writing pretty much every partition using Write Memory? The problem is yes the tablet is still seen by the computer, but not as an MTK preloader device unlike with a functional tablet, i.e. "USB Serial Device (COM4)" or something along the lines of it. Even if you flash everything needed to get the device to work using the aforementioned tool in SPFT, the device is still stuck in that mode - I believe that's meta mode, right? Is there a way to knock it out of meta or something?
[Fire Android Development] truetech000:
Would this work!?!?!?!?!

I was just snooping around the net and found this, https://xdaforums.com/android/software-hacking/question-mounting-recover-partition-adb-t3591261, would we be able to use anything like this to flash a custom recovery permanently. not unlocked bootloader but might be on to something. cant boot to my recovery partition so it must have done something to modify it, it might work better for someone who knows what they are doing :)
[Fire Android Development] BeeWall:
Technically, it flashed it for you. However, the bootloader checks the signature, so it won't let you boot into it.
[Fire Android Development] t3chwizard:
Ooooooo this is progress
[Fire Android Development] BeeWall:
Not really, it's just like using Flashify or similar. If it still doesn't boot, it doesn't do much. And makes it impossible to restore if there is a bootloop because you get rid of stock recovery.
[Fire Android Development] blakegriplingph:
Same goes if you use Write Memory on critical partitions using SP Flash Tool. You can flash /system and it would still boot, but do the same with boot or logo.bin and it either gets stuck on the logo, or doesn't boot at all.
[Fire Android Development] Robius:
Anyone have a line on the Sceptre vuln on ARM? Could be a good unlock vector.
[Fire Android Development] t3chwizard:
Damn I was just gonna ask about this lol you beat me to it.
[Fire Android Development] hwmod:
Here is the disclosed POC:

https://packetstormsecurity.com/files/145645/Spectre-Information-Disclosure-Proof-Of-Concept.html

Have fun,

.:HWMOD:.
[Fire Android Development] Supersonic27543:
I'm not objecting anything, but, isn't Spectre used only to READ data? So, if Spectre vulnerability is going to be used, it will have to be used for reading bootloader unlock keys, and I doubt that they will not be encrypted.

Never mind if I'm wrong :)
[Fire Android Development] BeeWall:
Yep, you're right. Read only. So I guess maybe it could be read bootloader codes? But as you said, I doubt it'd be that easy.
[Fire Android Development] Supersonic27543:
From what I know, the effort required to implement Spectre is, well, overwhelming. Everything I saw about it said that the resources required to implement Spectre properly makes it pretty much useless against individuals and that it will only be useful if hacking into a very valuable database.

This article explains it quite neatly.

EDIT: Saw the speed? 10KB/S!!
[Fire Android Development] blakegriplingph:
Has anyone actually done the effort of running the preloader through IDA Pro?
[Fire Android Development] BeeWall:
If I remember, we can't actually read the preloader, it shows as just a bunch of random bytes, not the real thing. Could be wrong, but I think that was preloader.
[Fire Android Development] blakegriplingph:
So could it be encrypted then?
[Fire Android Development] Supersonic27543:
Yep, the data set we see is completely random, and you have to figure out what is the set of bytes we want. So you'll have to find a way to figure out that, and keep going and going and going until you read that set of bytes, and last but not least, decode them to get a meaning of them. :sigh:

---------- Post added at 02:43 PM ---------- Previous post was at 02:41 PM ----------

How in earth do someone figure out the actual byte set of the preloader, apart from decoding them?
[Fire Android Development] BeeWall:
Maybe? It might also be hidden (I think somewhere, maybe this thread, people talked about some sort of patented, hidden-from-user device, which might hold boot0 and boot1), but either way it'll be tough (and way beyond my level unfortunately).
[Fire Android Development] Supersonic27543:
If THAT way is implemented properly, then it definitely is a great unlock vector. :laugh: Do you know, if it is possible to copy that partition? I don't think so, however.

---------- Post added at 02:48 PM ---------- Previous post was at 02:47 PM ----------

And, please tell me the post number? Thanks,
[Fire Android Development] BeeWall:
I can't find it, sorry. Must've been another thread. I'll keep looking.
[Fire Android Development] Supersonic27543:
Thanks, and NVM. I'm happy knowing that it is not a complete lost cause now. :)
[Fire Android Development] steve8x8:
IIRC, it's RPMB, not BOOTx that isn't readable (locked kernel blocks access).

Since the other parts of the boot loader access it to check for rollback, running them in an emulation environment won't give the full picture immediately.

There was a guy who managed to unsolder the flash chip... Never heard back from him whether the contents could be read.
[Fire Android Development] Robius:
Dump privileged ARM system registers from usermode using variant 3a of Meltdown

https://github.com/lgeek/spec_poc_arm
[Fire Android Development] Kramar111:
Preloader is not encrypted

All *update*.bin contain preloader_prod.img

RPMB is "encrypted", we can't write it w/o RPMB authentication key :)
[Fire Android Development] BeeWall:
Yeah, that's right, sorry. So someone took the flash chip off and tried to read it with an outside device?

Yep, RPMB is what I was talking about, just got confused, it's been a while since I looked at these threads. RPMB is the encrypted/random data. Do we know if its encrypted, or just fake data somehow?

---------- Post added at 11:37 PM ---------- Previous post was at 11:34 PM ----------

That's for 64 bit, not sure if it would work.
[Fire Android Development] Supersonic27543:
Anyway, my device is not vulnerable. Fire HD 8 (2017) has a Cortex-A53 which is the only ARM CPU that is not vulnerable as I can remember. :crying:
[Fire Android Development] DragonFire1024:
I have an HD 8 (2016) on 5.4.0.0. let me know if anyone wants me to test on it.
[Fire Android Development] Supersonic27543:
Sorry, DragonFire. It shouldn't work. HD 8 (2016) share the same chipset and same processor with HD 8 (2017). [Cortex-A53] And therefore incompatible with Spectre.
[Fire Android Development] Supersonic27543:
Look at the HD 10 (2017). It got rooted because it has an ARM64-V8A compiled syatem. And now, its processor, Cortex-A72 is also vulnerable to Spectre, confirmed. Good Luck, HD 10 owners! Your devices may have a future ahead. :laugh:
[Fire Android Development] DragonFire1024:
Maybe vulnerable but I haven't seen logs which show what was rooted specifically. It's speculation
[Fire Android Development] Supersonic27543:
Not sure about what is really vulnerable to Spectre but did you see the charts on the GitHub page referred by post #295? It says that Cortex-A72 is confirmed to be vulnerable.

Hpwever I'm keeping my fingers :fingers-crossed: for an exploit on HD 8.
[Fire Android Development] Kramar111:
It's not encrypted, just fake data (if we try dd mmcblk0rpmb - https://xdaforums.com/showpost.php?p=67430850&postcount=68).
[Fire Android Development] BeeWall:
OK, thanks for clearing that up.
[Fire Android Development] Supersonic27543:
Darn, is it a lost cause at this point? :crying:
[Fire Android Development] t3chwizard:
Don't give up just yet. Hopefully a new exploit will pop up. All we have is hope. We must not lose that
[Fire Android Development] DB126:
While hope is a good thing so is reality. A bootloader exploit VERY unlikely.
[Fire Android Development] t3chwizard:
:mad:
[Fire Android Development] Supersonic27543:
I'm curious, OP said that he created "unlock.bin s with this unlock code." How to create an unlock.bin with an unlock code? :confused:

---------- Post added at 03:22 PM ---------- Previous post was at 03:10 PM ----------

Yes, it is true indeed. If you look at the history, you will see the very small number of Bootloader exploits that was ever discovered.

But don't give up hope anyway. Though it is VERY unlikely, it is not completely impossible that a bootloader exploit will pop up.

And if someone has some free time, you may want to try this out, if you didn't try this already.

Bootstomp
[Fire Android Development] Robius:
Has anyone seen useful hacks using BlueBorne BT stack exploits?
[Fire Android Development] t3chwizard:
Interesting approach
[Fire Android Development] Jaytn:
I'm by no means a hacker of that caliber, but I'd hazard a guess that it's highly unlikely that an exploit in the BT stack is of any use for attacking the bootloader - I'd doubt that that would even touch any radio :/
[Fire Android Development] Supersonic27543:
Not just highly unlikely, but impossible. The maximum it will do is rooting the device. In fact, only specifically bootloader exploits will even touch the bootloader
[Fire Android Development] t3chwizard:
People said similar things about the Spectre and Meltdown but yet here we are...
[Fire Android Development] DB126:
Right. But those flaws were not uncovered by the 'average Joe' (hey, I resemble that characterization!). Or in the words of Arthur C Clark: "Any sufficiently advanced technology is indistinguishable from magic." :)
[Fire Android Development] Master Melab:
Is preloader signature-checked by the boot ROM at power on?
[Fire Android Development] Supersonic27543:
Yes it is, at least it should be, if it's not we should have unlocked the BL long ago.

It's like a chain, untouchable boot ROM verifies the preloader, preloader verifies the little kernel, little kernel verifies recovery, boot, and some of the other partitions. Looks like invincible. :crying:
[Fire Android Development] munwwer:
hi,

my kindle 7 2nd g. after using KFU for downgrading stuck in orange kindlefire bootlogo and after every 5 seconds auto reboot. if any solution please help me. thanks
[Fire Android Development] DragonFire1024:
Reflash the stock firmware you are on. Make sure it's the same version you're on now.
[Fire Android Development] sd_shadow:
Kfu doesn't work with 2nd gen fires, likely you have bricked it beyond repair

---------- Post added at 09:23 AM ---------- Previous post was at 09:22 AM ----------

Please ask in 2nd gen forum

Fire Index: Which Amazon (Kindle) Fire Do I have?
[Fire Android Development] munwwer:
ADB/MTP Already installed but pc not recognize or detecting my device.

I have Kindle Fire HD 7" (2nd Generation)

model no X43Z60

FCC ID YJM-0725

(Operating System: Windows 7 & ubuntu 12.04 & ubuntu 17.04)
[Fire Android Development] DB126:
Wrong forum for this device. Please move conversation here. Thanks.
[Fire Android Development] Master Melab:
Where did you come by this information?

Not necessarily. The pre-Honeycombos Android tablets from Archos used no hardware-based digital signature checks and only one model received a patch to the first-stage bootloader that made it skip verification of the second-stage bootloader. It would only be easy if the first-stage bootloader could be written while in some kind of DFU mode running from the boot ROM in devices, but people keep on saying, for many devices, that corrupting the first-stage bootloader will brick the device in question.

"Unlocking the bootloader" is terminology that is inconsistent, sloppy, and useless. If I were to use it the way most people use it, "unlocking the bootloader" means putting one of the bootloaders in Android's boot chain, usuakly aboot, into a state that will not refuse to load an unsigned image.

As far as it being some overlooked route to achieve full control over our devices, XDA posters and posters on other sites are rarely clear on whether or not so-and-so device's first-stage bootloader is verified by its boot ROM.

I am well aware of the chain-of-trust concept. Not all chains of trust, especially the ones in personal computers, have a root-of-trust that is based in silicon/hardware.
[Fire Android Development] Supersonic27543:
Well, someone modified some bytes in the preloader and it refused to boot after that. So what's your idea?