Related
Hi all...
I've been getting a lot of suspicious errors recently (force closes and app shortcut names disappearing) and I'd like to go from apps2sd back to just a normal setup with my apps on the internal phone storage.
Can somebody please verify that the instructions here are up to date? I'm a little nervous about wiping my data (or bricking my phone).
http://wiki.cyanogenmod.com/index.php/Apps2SD
Also, can somebody tell me whether doing this will wipe out the (single) app I paid for from the Marketplace? If so, can I redownload it, or will I need to pay for it a second time?
I originally got apps2sd set up by using the recovery ROM prior to flashing Modaco's custom ROM v1.1.
The easiest thing to do would be to load the new RA 1.5.1 recovery image.
Then boot into it.
Go to Partiton SD
Select FAT EXT3 SWAP
and then set the partition sizes of EXT3 and SWAP to 0
Is there a reason you want to do this???
This runs a very very minimal chances of bricking your phone. The other method on that Wiki page has more potential to get you in trouble.
Did see the market place question.
There is a method laying around somewhere to copy all of your apps back to the phone instead of loosing them. Restoring a Nandroid backup would likly put them all back into the /apps/ directory sd card or not. apps2sd just changes the location of that directory really.
But the market does keep track of your google account and what apps you purchase, you wont have to re purchase (maybe on a totaly new handset).
hope my jiberish has made sense
jashdlfjasdhfjablgjkasgjlkasfhlajshf
At first I was interested in the whole apps2sd process, but have yet to implement it on my rooted, Fresh 1.0 Hero since so far, I haven't really seen a need for it.
But if you were to 'turn on' apps2sd and then decide later that you don't want it, there's a possibility of bricking?? Although I assume you can always reflash the RUU if something like that were to happen? Hopefully?
Think I'll stay away from the whole offloading applications thing for awhile.
mkhopper said:
At first I was interested in the whole apps2sd process, but have yet to implement it on my rooted, Fresh 1.0 Hero since so far, I haven't really seen a need for it.
But if you were to 'turn on' apps2sd and then decide later that you don't want it, there's a possibility of bricking?? Although I assume you can always reflash the RUU if something like that were to happen? Hopefully?
Think I'll stay away from the whole offloading applications thing for awhile.
Click to expand...
Click to collapse
The possibilities of bricking the phone are very slim, but they still exist. If a phone is truly a brick, not even RUU can help. RUU has to be able to detect the phone is there in Windows, so if its beyond that RUU is useless.
Nothing to worry about as long as follow the *usually* very well written step by steps across the interweb.
If it makes you feel any better I have only heard of one or two people to brick the Hero. Most things are recoverable.
Yeah, sorry, I didn't expect it would brick the phone so much as badly mess it up - like if it expects to run apps from the SD card and they aren't there I could see the phone being tough to use as a phone, but it wouldn't really be "bricked" in the sense of not responding to user input at all.
As far as why I want to do this, I haven't really seen a huge need for apps2sd yet, and when I was recently helping an app developer to debug their app it was just one more weird variable that seemed like a possible source of problems. I'm also hoping to start developing apps myself soon, so having a more vanilla phone seems like a good idea. (I also was influenced by the Fresh ROM apps2sd rant, to be honest.)
Anyhow, thanks for your replies. I'll probably repartition the card from RUU and then restore from Nandroid at that point. Will a repartition wipe the card filesystems out, or is the partitioner smart enough to preserve the existing data?
What I did is RUUed back to 1.2, OTA updated to 1.6
Flashed to the 1.5.1 image
(At this point I went to mess with the partitions and there was no ext)
Flashed to Fresh 1.0
I'm no expert when it comes to the topics of rooting and getting access to the emmc and all of that good stuff. I more specialize in ROMs and themes and stuff, the less complexed stuff lol
Someone has posted an idea in the general forums in relation to permanent root, I'm not sure if he posted it here or not. So here's what he wrote....and is it possible? Or does it have to be done manually first before this idea can happen?
Originally Posted by deliberate187
In order to unlock the phone, we have to figure out what the protected sectors are first and all related flags. If an Android app could be made to have direct read access to the eMMC filesystems (including write protect flags) and save a log to the SD card detailing these items, this would be ideal.
Then all that would remain is a program to undo the write protection (and re-do it if necessary to unvoid warranty)
If anyone is willing to create these programs, I would be more than happy to test them out on my own G2.
However, I think the keys to the mystery may lie in the recovery image, and/or in the bootloader itself. Has anyone disassembled these yet?
Click to expand...
Click to collapse
Sorry to have to tell you but this is all old information stuff we already know just are unable to do anything about it. Its harder then just coming up with an idea of something. Now if we knew a person that programed the g2 in htc factory then all would be good but as of now we just dont have the information we need to do anything
thanks
Thanks for the idea. Some people will be mad you didn't post in the root thread though.
File under "I'm no expert but..."
Here is one observation I have noted in my exploration. The root filesystem and system partition are mounted with the flags "-o ro,relatime" but in addition the /system partition has ",errors=continue" leading me to believe that this change is in fact written to the release configuration rather than to the eMMC itself. Can anyone try to get a permanent write to the fstab and see if this can net us permanent root? Possibly take a temp root session and remount the system and / filesystems read/write to see if writes stick... just an idea.
The errors=continue flag allows the ext3 filesystem to continue working even if there was a read/write error.
I've been able to get the system to change to r/w a couple times while wandering through root explorer. I have made subtle changes to certain folders such as moving txt files but nothing has ever been permanent. I can't really tell you how I did it either seeing as I can't replicate it on demand...I'm assuming it still gets written to cache despite being in the /system
Sent from my T-Mobile G2 using XDA App
heyy, I'm not punchie, I've got what the doctor calls a relaxed brain
I am thinking there should be a set of adb commands to unlock the nand. I am definitely thinking a nand dump and full disassembly of the bootloader and recovery image could be absolutely crucial in discovering what needs to be done. Just a thought, has anyone done a nandroid backup of the G2 yet? I'm pretty sure TMob doesn't have HTC encrypt its bootloaders...
deliberate187 said:
I am thinking there should be a set of adb commands to unlock the nand. I am definitely thinking a nand dump and full disassembly of the bootloader and recovery image could be absolutely crucial in discovering what needs to be done. Just a thought, has anyone done a nandroid backup of the G2 yet? I'm pretty sure TMob doesn't have HTC encrypt its bootloaders...
Click to expand...
Click to collapse
if you can figure it out, go for it and i wish you luck
deliberate187 said:
Here is one observation I have noted in my exploration. The root filesystem and system partition are mounted with the flags "-o ro,relatime" but in addition the /system partition has ",errors=continue" leading me to believe that this change is in fact written to the release configuration rather than to the eMMC itself. Can anyone try to get a permanent write to the fstab and see if this can net us permanent root? Possibly take a temp root session and remount the system and / filesystems read/write to see if writes stick... just an idea.
The errors=continue flag allows the ext3 filesystem to continue working even if there was a read/write error.
Click to expand...
Click to collapse
If it were only this easy.
Re-mounting /system as r/w is part of the rooting process. This does not result in changes written to eMMC. In fact, the controller "lies" to Linux that the change has been synced. From then on, Linux holds the changes in its cache which, when dropped or rebooted, reverts changed files to their original state (because they were never written in the first place.)
The ext3 continue on errors thing is merely a way to skip fsck in the event that the read-only system has issues in the journal (very unlikely to happen, since nothing can write to it.) Presumably, this only covers an oversight in OTA updates (where the journal of the image provided by the OEM is dirty for some odd reason.) Again, since nothing can write to /system, it's all but an impossible scenario (nothing can write to the journal either...)
As for marking "sectors" as write-protected or not, that's also easier said than done. Entire partitions are locked, and half of the space is mysteriously "missing." It's difficult to see what's really going on from userland, as the device is deceptive as to what is and is not being written, or what is even stored on the eMMC in the first place.
The real solution is to exploit either the boot-loader or eMMC (re)/initialization somehow to allow a) unsigned firmware to be loaded and/or b) allow booting without write protection, allowing us to c) flash rooted rom to the phone and/or d) disable said protection. The unlock procedure will likely be similar to Unrevoked, as that is essentially the same situation (aside from the controller issue.)
All of this is covered in the wiki and various threads - check those out, if you find a way around it everyone would be glad to hear it.
HamNCheese said:
If it were only this easy.
Re-mounting /system as r/w is part of the rooting process. This does not result in changes written to eMMC. In fact, the controller "lies" to Linux that the change has been synced. From then on, Linux holds the changes in its cache which, when dropped or rebooted, reverts changed files to their original state (because they were never written in the first place.)
The ext3 continue on errors thing is merely a way to skip fsck in the event that the read-only system has issues in the journal (very unlikely to happen, since nothing can write to it.) Presumably, this only covers an oversight in OTA updates (where the journal of the image provided by the OEM is dirty for some odd reason.) Again, since nothing can write to /system, it's all but an impossible scenario (nothing can write to the journal either...)
As for marking "sectors" as write-protected or not, that's also easier said than done. Entire partitions are locked, and half of the space is mysteriously "missing." It's difficult to see what's really going on from userland, as the device is deceptive as to what is and is not being written, or what is even stored on the eMMC in the first place.
The real solution is to exploit either the boot-loader or eMMC (re)/initialization somehow to allow a) unsigned firmware to be loaded and/or b) allow booting without write protection, allowing us to c) flash rooted rom to the phone and/or d) disable said protection. The unlock procedure will likely be similar to Unrevoked, as that is essentially the same situation (aside from the controller issue.)
All of this is covered in the wiki and various threads - check those out, if you find a way around it everyone would be glad to hear it.
Click to expand...
Click to collapse
Listen to this dude. Absolutely correct.
" PWNED " :-D
As you know, Archos bootloaders check digital signatures of init and recovery kernels, so you need to install SDE to use custom kernels, and it somehow "watermarks" the device.
Good news everyone! I've disassembled both bootloaders, found the code which checks signature, and replaced it (first instructions of verify_hash function) with "return 0" which is "mov r0, #0; bx lr" in ARM assembly. It's much the same hack as on Archos 5, thanks EiNSTeiN from archos.g3nius.org for reverse engineering previous generation.
Archos gen8 boots using OMAP boot ROM from internal eMMC card. Primary bootloader ("boot0") is in 0x20000 bytes after the first sector of internal flash (i.e. at 0x200) and secondary bootloader is written into rawfs, /mnt/rawfs/avboot. boot0 contains image size and loading address in first 8 bytes.
So, here is the patch:
1) boot0: replace 8 bytes at 0x7520 from the beginning of mmcblk0 from 7F402DE9003091E5 to 0000A0E31EFF2FE1.
2) avboot: replace 8 bytes at 0x14424 in avboot from 7F402DE9003091E5 to 0000A0E31EFF2FE1 (same patch). 0x14424 from avboot beginning is usually 0x14824 from the beginning of mmcblk0p1 (avboot comes first in rawfs, just after 2 blocks of header).
Of course you need root to do it. I've done it on my Archos 101, then changed 1 byte in recovery image - it boots into recovery without problem (before the hack it didn't boot into this 1-byte changed recovery).
And of course do it with caution and at your own risk DO NOT replace the bytes if you find other original data at these offsets! Bad boot0 or avboot means bricked Archos. There must be some sort of test point (something connected to OMAP SYS_BOOT5 pin) to boot from USB, or a boot UART interface, so debricking the device must be possible, but it would require some effort to find it, find a proper bootloader and use it.
If someone wants to see IDA database, I'll send my.
P.S: I do not have enough messages to post inside Development subforum, so I'm posting here.
Great work! With this base, can yout get something like CW to run?
I'm so waiting for him to come back and say April fools.
I'm gonna screw him up if this was an april fool
First, if this is an April fools, I will find you and hurt you.
Second, what does all that mean anyway? Does that mean Cyanogen on Gen8 is near? Does it have anything to do with roms?
vitalif said:
P.S: I do not have enough messages to post inside Development subforum, so I'm posting here.
Click to expand...
Click to collapse
Maybe you should increase that number of post by explaining how you did this.
)))) No it isn't an April fool, my device now really has a modified recovery. Ridiculously modified (1 byte changed), but that's the proof!
Check the patch by yourself )) all you need to write to mmcblk0 is a standard linux dd tool... which is included into standard Archos busybox...
wdl1908 said:
Maybe you should increase that number of post by explaining how you did this.
Click to expand...
Click to collapse
In fact, it was not hard, and if I knew ARM assembly language before, it would be even easier... All I had to do is to find bootloader on the flash (boot0 is obviously in its beginning, and avboot is on /mnt/rawfs), copy it to computer, download IDA, feed bootloader to it and find functions similar to ones described on archos.g3nius.org (BigInteger_ModulusEnter, RSADecipher, etc). It also could be simpler, as BigInteger_ModulusEnter is mentioned inside an ASCII string inside data section... But I've found them by text search also there is a magic "ZMfX" in first 4 bytes of avboot and some other magic inside init and recovery... One also could use them to find interesting points in bootloader.
At first I've started disassembling with the wrong base address, but bootloader has code which copies itself to the correct one in the very beginning, so I've changed it and started over. In fact, it has size and address in first 8 bytes, so this also could be simpler...
So the hack is done, what needs to be done by now - utilize it and create some custom ROM or simply flash urukdroid without SDE...
chulri said:
Great work! With this base, can you get something like CW to run?
Click to expand...
Click to collapse
CW == ClockWorkMod recovery? I don't have any experience with CWM porting yet, but in theory yes, the hack gives us the ability to run custom recovery images.
Don't know alot about the bootloader, but what advantage does this have?
SWFlyerUK said:
Don't know alot about the bootloader, but what advantage does this have?
Click to expand...
Click to collapse
Hm. I'll explain... Bootloader is the program which starts up the device, similar to bootloader on your PC signature check in bootloader prevents us installing modified Linux kernel, initial ramdisk and recovery images. So, for example, we can't have netfilter in kernel without installing SDE, we can't have ClockWorkMod recovery on Archos at all, and we can't, for example, change MMC card splitting into 512M mmcblk0 for system + remaining for "internal SD" with data.
With signature check removed, all this is possible.
The underlying idea of all this signature checking is probably protecting f**king DRM... I HATE IT !!!!!! And hate companies promoting it =) When you install SDE on previous generation archos (5it), it removes drm keys from device memory (this is the "watermarking" mentioned on Archos site). It makes device unable to play the content buyed for it anymore... Not a big deal, but unpleasant. I don't know if this is the same on gen8.
In detail: Archos 101 has OMAP3630 processor. The "0-stage" (very-very first stage) bootloader, i.e. program which gains control after processor power-up, is hard-coded into one-time programmable area on the processor itself and is named "OMAP boot ROM" (similar to PC BIOS). The boot ROM can continue device booting process from different devices including SD/MMC card, NAND flash, UART (serial port) or USB interfaces. The boot sequence is determined from physical pin connection configuration. Our Archos boots from internal eMMC card.
So, OMAP boot ROM loads primary Archos bootloader, without checking any signatures or checksums, and simply transmits control to it. Primary bootloader sets up some processor configuration and then reads secondary bootloader (avboot) from flash. Then, it checks its MD5-RSA digital signature using Archos public key. If signature is incorrect, it hangs the device (goes to infinite loop). So if we modify avboot without removing signature check from boot0, device would be bricked. If signature is correct, control is transmitted to avboot. Avboot determines what system we want to start by pressing different keys, loads it, checks signature if system is init (normal system) or recovery, sets up configuration for Linux kernel and transmit control to Linux.
Interesting facts:
* According to the code, boot0 can use rawfs or FAT filesystems for boot partition.
* During boot process, various messages are printed to serial console. avboot even has some code for receiving commands over serial connections.
* OMAP processor boot sequence can be configured via special memory area which remains unchanged after soft reset, and this configuration will override one determined by physical pin configuration. This does not give us much profit, but is also interesting...
Thanks for the explanation, so is it worth doing for a noticable difference in performance etc?
SWFlyerUK said:
Thanks for the explanation, so is it worth doing for a noticable difference in performance etc?
Click to expand...
Click to collapse
Whats being done will have no affect on performance of the device. It will however, allow a lot of work that can contribute to better performance on the device. That is assuming that we can put on a modified clockworkmod recovery on these devices without bricking them.
He says the only way to do this is with root but in order to have root with r/w access at this point is SDE....right? Don't get me wrong custom recovery with the ability to make backups would be awesome but it seems SDE will still be necessary unless a new rooting option comes along.
*on a side note about root has anyone tried using psneuter to gain temp root through ADB? I really am not super knowledgeable about this stuff but this was used on the thunderbolt to aid in getting full root and s-off.
Sent from my ADR6400L using XDA App
JBO1018 said:
He says the only way to do this is with root but in order to have root with r/w access at this point is SDE....right? Don't get me wrong custom recovery with the ability to make backups would be awesome but it seems SDE will still be necessary unless a new rooting option comes along.
*on a side note about root has anyone tried using psneuter to gain temp root through ADB? I really am not super knowledgeable about this stuff but this was used on the thunderbolt to aid in getting full root and s-off.
Sent from my ADR6400L using XDA App
Click to expand...
Click to collapse
Archangel will give you temp root without using SDE.
He said root with r/w access. Archangel won't do that, the file system is still protected.
pbarrett said:
He said root with r/w access. Archangel won't do that, the file system is still protected.
Click to expand...
Click to collapse
Nope r/w access is not needed the only changes to be made are on /dev/mmcblk0p1 which is mounted on /mnt/rawfs the read-only is on the root file system so they are seperate. Archangel will do just fine for this.
wdl1908 said:
Nope r/w access is not needed the only changes to be made are on /dev/mmcblk0p1 which is mounted on /mnt/rawfs the read-only is on the root file system so they are seperate. Archangel will do just fine for this.
Click to expand...
Click to collapse
To be correct, there is no write protection on internal MMC at all, there is readonly rootfs which is mounted from a squashfs archive (squashfs is compressed readonly filesystem commonly used on Linux Live CDs), so you can't modify _files_ on it while it is mounted. But, nothing stops you from updating it as a whole.
Urukdroid
Someone should give a shout out ro $auron, creator of the Urukdroid project about this, he might find it useful.
So, if your hack is confirmed, that would give us the possibility to port CW recovery and Cyanogen to Gen8 devices... am I right ?
shrewdlove said:
Someone should give a shout out ro $auron, creator of the Urukdroid project about this, he might find it useful.
Click to expand...
Click to collapse
I think he has already seen this thread but you can ask him
lechuckthepirate said:
So, if your hack is confirmed, that would give us the possibility to port CW recovery and Cyanogen to Gen8 devices... am I right ?
Click to expand...
Click to collapse
Yes you are^^ but the thing is you have to port cyanogen to our gen8^^ and this must be done by a or more devs
i heard the biggest problem is that our touchscreen is connected by an usb controller inside the archos thats why the honeycomb port by luisivan is not recognize our touchscreen ( but when the source code is released, finally, we will get a hc port )
Lennb said:
i heard the biggest problem is that our touchscreen is connected by an usb controller inside the archos thats why the honeycomb port by luisivan is not recognize our touchscreen ( but when the source code is released, finally, we will get a hc port )
Click to expand...
Click to collapse
this isn't a problem for cyanogen (v7 = Android 2.3.3) because we have the source.
SOLVED the best way.. See post #5
Hello
I have asked this in other threads, but have not gotten an answer that I can manage to make work yet. I'm also hoping that this thread may help the many others out there with this same problem.
I have an Iconia A500 that has the bad sector problem. I cannot get it to format partitions through any of the EUU's out there,or even the Babsector .bat's . Same thing every time-read/write failure. I have seen mention in a thread or two about guys who have used the "rawdeviceread" and "rawdevicewrite" commands in NvFlash to "map out" any bad sectors on the EMMC chip, and create "dummy" partitions over them so that the tablet will function again, at least until more sectors die anyhow.
Can someone please explain this process, including describing the files needed, exact commands, and the rest of the process to make this happen? I have seen member "Yaworski" describe the basis of it, but again his commands are no-go for me. It would also be great if a partition could be created, but not formatted, completely bypassing any possibility of NvFlash failure.
Thanks in advance By helping me I'm sure you wil also help many others. It seems many a500's are starting to suffer form this same exact issue.
Anyone? I have read thru this post: http://forum.xda-developers.com/showthread.php?t=1691729&page=3 , and seen a couple recommendations to it in other threads, but no dice on making it work .. or even being able to map out the bad sector/s. I know this'lll fix me up at least temporarily...
I need help with this as well. There doesn't seem to be a step by step guide anywhere :\
Sent from my SGH-T769 using xda premium
dynospectrum said:
I need help with this as well. There doesn't seem to be a step by step guide anywhere :\
Sent from my SGH-T769 using xda premium
Click to expand...
Click to collapse
I've been asking around about a possible process of mapping out bad sectors, and not just members in here, but engineers and technicians I know as well. First, the NAND has this sort of embedded firmware that directs it to remap or bypass bad sectors “spontaneously,” if you can call it that. When you're stuck with “write errors” or where the NVflash even fails to create and format a partition, it suggests that this part of that firmware is not working. Why the loose fit, or lack thereof, I don't know.
Second, The FCK guys mention that you can write a dummy file and make the device read back so you can see where the data is missing and circumvent it altogether. But they also state that if Sector 0 – which NVFlash is slated to access – is kaputt, then it would hang, as probably in your case and certainly in mine.
Given that the Boot Configuration Table is 4Kb tiny while the NAND is 16Gb large, I can't imagine the latter being damaged so badly as not to have a continuous space of 4Kb to accommodate such partition. As a matter of fact, I did have someone with special equipment probe my NAND “physically” and the initial report indicated that the first half (50%) of it had less than 3% of its sectors that was bad. NVFlash, however, could neither create nor format, let alone write on it.
So, either one must have the appropriate hardware to do a very low level format to restore the NAND in full or in part, or NVFlash has to be hacked to command writing at a Sector different than 0. Until that happens, I doubt it that a step-by-step guide grounded in current programs would be viable.
I know that neither the custom ROMs nor the custom Bootloaders and Recoveries are remotely the cause, because this occurred way before any of it came onto the scene. But in light of the frequency at which this happens to some of us, it seems ironic to term this device bullet-proof. I'd like to think it's not incurable, but what the FCK do I know? (Sigh) Anyone with the essential hardware know-how to tackle this?
SOLVED..well the "easy" way....
I sourced out a broken A500(strangely the screen is fine though lol), re-soldered the power button on it(PITA), and put it into my A500.
I plan on taking it easy with the flashing on this one. A500s seem to have a growing history of EEMC chip failure from over-flashing. My old board had been flashed MANY times by the previous owner, and a few by me before it died. The "new" tab was only flashed enough to get it to Stock ICS. Now it has the V8 bootloader and Civato's Re-Flexx ROM(Best out there IMHO).
So there you have it.. this seems to be the best way to fix this problem on the A500---Replace the Darn motherboard. I'd imagine mapping/skipping sectors is only a temporary fix that will probably lead to the tablet dying when its needed most.
I am relatively new here, but was reading some threads and a couple people have said that the community hasn't found the 13.3.2.7 update to manually force a rollback. A couple days ago I called Amazon because I had updated to 4.5 and needed to go back to root.
Since then I have been looking around for where the patch was saved to and found the scripts that setup for the OS update and the scripts to run it. The scripts show where it is and what commands are called to do the update, but the actual 13.3.2.7 OS seems to be hidden. I know where it says it should be, but its hidden somehow. If this is something anyone wants copies of my files on let me know, if this isn't something the community needs I apologize, just trying to help get this tablet further along.
Either post here or message me if you want/need what I have.
Why don't you just post your findings so far on this thread?
I was under the impression that OTA files are downloaded to the /cache folder, therefore inaccessible without root.
Either way, updates are still verified (see: /system/app/otaverifier.apk) by the system, so I'm not sure how you'd get around that.
EncryptedCurse said:
Why don't you just post your findings so far on this thread?
I was under the impression that OTA files are downloaded to the /cache folder, therefore inaccessible without root.
Either way, updates are still verified (see: /system/app/otaverifier.apk) by the system, so I'm not sure how you'd get around that.
Click to expand...
Click to collapse
I see, that part is already known then. Other posts I read people were still looking for it, but I was sure if i found it many others have too. I'm still looking around though, I found the verification coding also, thanks for that. I am thinking about updating my tablet again, and having them roll it back again, but this time running a packet sniffer. Might possibly get some really good info about the verification process or at least the steps it takes to make the rollback. I did a search but haven't seen anyone try this, it's probably heavily encoded though.
Another thing I noticed while looking around... They put a kill switch fuse in it? That's pretty rough, and what causes it to activate? Software modification or Hardware like Jtags?
Eclipsys said:
I see, that part is already known then. Other posts I read people were still looking for it, but I was sure if i found it many others have too. I'm still looking around though, I found the verification coding also, thanks for that. I am thinking about updating my tablet again, and having them roll it back again, but this time running a packet sniffer. Might possibly get some really good info about the verification process or at least the steps it takes to make the rollback. I did a search but haven't seen anyone try this, it's probably heavily encoded though.
Another thing I noticed while looking around... They put a kill switch fuse in it? That's pretty rough, and what causes it to activate? Software modification or Hardware like Jtags?
Click to expand...
Click to collapse
once rooted again .it may be possible to modify your build.prop like we were on past firmware to achieve rollback just to initiate download ,it will ultimately fail once it downloaded it and trys to install it will check a few more things it will fail and erase it ...the trick would be not too let the device idle..or to have the battery below I believe 30 percent it may be as high as 40 I'm not sure but I believe under 30 it will refuse to install update delay till charged ,anyway it may buy you time to find it
jimyv said:
once rooted again .it may be possible to modify your build.prop like we were on past firmware to achieve rollback just to initiate download ,it will ultimately fail once it downloaded it and trys to install it will check a few more things it will fail and erase it ...the trick would be not too let the device idle..or to have the battery below I believe 30 percent it may be as high as 40 I'm not sure but I believe under 30 it will refuse to install update delay till charged ,anyway it may buy you time to find it
Click to expand...
Click to collapse
That is actually a very good idea, something I am testing right now is getting the FireOS to run in VMware. I have a standard Android KitKat OS running, but getting the Kindle's OS to run is giving me a few issues. I am very skittish to try this stuff on my actual device as it's brand new and I don't have a backup... But if I can I will give you idea a shot. Might be able to save it before it deletes. Also if I can get it going in VMware it might be possible to use a debugger to examine the ASM code in great detail.
Eclipsys said:
That is actually a very good idea, something I am testing right now is getting the FireOS to run in VMware. I have a standard Android KitKat OS running, but getting the Kindle's OS to run is giving me a few issues. I am very skittish to try this stuff on my actual device as it's brand new and I don't have a backup... But if I can I will give you idea a shot. Might be able to save it before it deletes. Also if I can get it going in VMware it might be possible to use a debugger to examine the ASM code in great detail.
Click to expand...
Click to collapse
I didn't have any problem doing the modifications myself and I'm no Pro that's for sure. Never written a line of code in my life. I just tend to thoroughly research and understand before I attempt things and I've been practicing here for a while if you go to the, rollback .0.1 and safestraped thread there is quite detailed instructions serval times throughout the thread I would skim it.you will just be substituting version numbers and kind of a inverse idea compared to what we were doing there but it should accomplish it. I used rOM Toolbox lite I believe as an editor and saved each timeI didn't have any problems with the permissions getting screwed up while tampering with it rOM Toolbox took care of that issue. I have seen tons of people brick trying to make these modifications. But I don't think they understood completely what they were attempting to do it's actually very simple and as long as you do it thoroughly and get all of them changed I have not seen any problems other than maybe having to repeat the process.there are a couple of lines that only use the last section of your version numbers I even changed those back then.
Eclipsys said:
I am relatively new here, but was reading some threads and a couple people have said that the community hasn't found the 13.3.2.7 update to manually force a rollback. A couple days ago I called Amazon because I had updated to 4.5 and needed to go back to root.
Since then I have been looking around for where the patch was saved to and found the scripts that setup for the OS update and the scripts to run it. The scripts show where it is and what commands are called to do the update, but the actual 13.3.2.7 OS seems to be hidden. I know where it says it should be, but its hidden somehow. If this is something anyone wants copies of my files on let me know, if this isn't something the community needs I apologize, just trying to help get this tablet further along.
Either post here or message me if you want/need what I have.
Click to expand...
Click to collapse
Please upload the file somewhere (preferably to mega). If it doesn't pass the version check we can use my hack to bypass it.
p1gl3t said:
Please upload the file somewhere (preferably to mega). If it doesn't pass the version check we can use my hack to bypass it.
Click to expand...
Click to collapse
https://mega.co.nz/#!wlQl2bZD!Kk-rcWtcMPWxoEH5VcHrtZb7nOsJet9si1pm5FYhT44
5.2 build prop file