Related
Before we begin. This solution is for people who have tried everything multiple times, and failed. If you haven't read and have not tried the following solutions yet, please do so first:
How to start over: From original stock to rooted latest OTA (WiMAX working!)
[GUIDE] Bad WiMax MAC? Broken 4G after update? Fix HERE!
The guide below is ONLY for people who did not have success with above methods (i.e. they are really really hosed). And there are limitations for now, until everything is confirmed and tested. The most important part you need access to a second, healthy and rooted EVO. As of yet, this is the only way to guarantee that one binary dump is not used a million times, negating the effect.
Please read the whole guide before starting the process, so that you know the risks, limitations, and potential issues with all this.
I am going to sign off for a few hours, and go enjoy my life for a brief time, before returning to answer any questions that may arise.
Ok, so for now, this is more of a proof of concept solution, since I understand not everyone has more than one EVO to do what I did.
My idea about partitions was correct, so without further ado, here is how to restore a botched wimax.
What you need.
2 Fully rooted EVOs (step 1 and step 2), one with working 4G (any version of all firmware on either, all we care for is working WiMax)
System which can do fastboot commands. That means you will have to have Android SDK installed. I also add path to /tools folder into my system PATH, so I don't have to type out the full path to adb or fastboot every time
Custom recovery. I use clockwork for this, since I am not sure all the files are signed, as required by Amon RA's recovery
Broken EVO backup
Backup your existing wimax partition on your broken EVO. We may need it some day.
Open command line window (cmd)
Make sure you have no PC36IMG.zip files in the root of your SD Card, or it will take a while to power your phone up
Power down your phone
Power it up while holding down the Volume Down key
HBOOT will attempt to scan for PC36IMG files. Let's hope you read carefully and don't have it on your SD Card root
Once HBOOT fails to find the file, use Vol Up/Down buttons to go into Fastboot mode
Connect the USB cable to your phone (and PC). You may have to install the USB drivers that come with Android SDK, but chances are if you are looking for this solution, you already have them installed and working
The FASTBOOT mode will switch to FASTBOOT USB (that's good)
Test your fastboot by typing "fastboot oem h" in command window you opened earlier (note, no adb, or adb shell anywhere, the command is "fastboot oem h". From here on all fastboot commands are issued in that window
If you see less than ~40 lines of output, you don't have a propertly rooted phone, and you need to do step 1 and step 2 (see above)
Dump your wimax data by issuing "fastboot oem saveprt2sd wimax -n wimax.bin" command (varies, anywhere between 7 to 8.5 MB, mine was 7MB)
Dump complete partition (~12MB) by issuing "fastboot oem saveprt2sd wimax -n wimax.bin -a" command
Reboot your phone
Pull the data files you dumped to a safe place ("adb pull /sdcard/WIMAX.BIN" and "adb pull /sdcard/WIMAXRAW.BIN"). Note the capitalization, it's important
We are done with your "bricked" phone.
Getting correct wimax image from a working phone
Now, repeat the same steps for your working phone (steps 1-14)
Pull the files to a different (safer) place, and cherish them like they are the only thing you care about in this world (which you do, right?)
Make a copy of your WIMAX.BIN file from the working phone (do NOT edit the actual file, just in case something breaks with your working phone at any time)
Use hex editor to update the working file in 2 places, and change the MAC address (which should be your working evo MAC - 1) to your broken evo MAC - 1 (remember, A becomes 9, F becomes E, etc). It's a big file, so search for "00:18" to find the 2 places. There will be exactly 2, not 3+ and not 1.
Rename the file you just edited to "wimax_25641R01.img"
Fixing your bricked phone
Push it to your sd card root: "adb push wimax_25641R01.img /sdcard"
Push the attached zip file to sdcard root: "adb push new_wimax.zip /sdcard"
Reboot your bricked phone into recovery
Flash new_wimax.zip. This will force write wimax_25641R01.img you pushed earlier, including the certificates in it
Reboot from recovery, let it finish, and boot up into Android
If not running the latest evo WiMax firmware yet, use the second attached zip to do so
Reboot your phone. Allow everything to complete and boot into Android
If needed, update PRL/Profile (I didn't need to, but I already updated it 50 times by now, so YMMV)
Now, I can not attach any of my dumps yet, before I test and make sure whether both phones can stay online on 4G without interruption, I will do some more testing later, since the Encryption keys are different (between 2 working evos I dumped binaries from). I still have 1 more phone to check when I get home. So if you have another evo (friend, family, etc) - you can do that already.
Otherwise, be patient, more testing is needed to make sure we are not going to steal anything from your friend, family, etc, since encryption keys are unique.
But the above solution works for completely restoring your 4G into working state.
I am currently running latest rooted OTA update, too, so it definitely works fine on latest and greatest.
Red,
Have you actually seen the encryption keys in plain text? How many bits are they?
Also, when you restored the wimax part from the working phone to your non-wimax-working phone, did you keep the MAC the same between the two phones?
Red,
Now that you have 4g fixed, can you take a look at your *.tree.xml files? Look at the ones from when 4g was broke, and then look after. Everything from boot.bin gets written into that file, and I'm hoping the signature does as well. If so, we may be able to pull it out of an old xml file and somehow work it back into the wimax.img.
Thanks
EDIT: On second thought, I do recall there being a way to flash the signature via fastboot..
MAC addresses were kept different, exactly what they are on a label behind the battery. For each phone. Hence, the editing step for the wimax partition dump.
Tree.xml does not contain any signatures, I verified this some time ago before I even started playing with the wimax partition by taking one from a working evo.
The keys are in plain text, simple RSA keys, judging by the size looks like 1024 bit. both public and private key are stored. Who knows, maybe just faking one will do it but I am guessing they are signed by some sort of CA otherwise it would be too insecure of Sprint.
So if we had a Nandroid backup from when Wimax was working, the boot.bin in that backup would have the key in it right?
Let's pretend it does, it would get written over when you powered on the phone after flashing. What if we didn't reboot after the restore and went back to recovery? We would then be able to get the boot.bin via adb and get our respective signatures. If they are indeed 1024bit, I don't see us being able to regenerate them anytime soon.
This may be worth a shot. I am not sure boot.bin has the signatures, but I will check later tonight. If it does, I am guessing we should be able to just do a drop in replacement of signatures in the image file and it should work.
Sent from my PC36100 using XDA App
Also since nandroid is just a simple copy and I'd the keys are indeed preserved, I would think we can pull them from there.
Sent from my PC36100 using XDA App
mpa4712 said:
So if we had a Nandroid backup from when Wimax was working, the boot.bin in that backup would have the key in it right?
Let's pretend it does, it would get written over when you powered on the phone after flashing. What if we didn't reboot after the restore and went back to recovery? We would then be able to get the boot.bin via adb and get our respective signatures. If they are indeed 1024bit, I don't see us being able to regenerate them anytime soon.
Click to expand...
Click to collapse
Does the Boot.bin actually store the keys? You are correct that once you restore a nandroid your working Boot.bin is replaced on boot of Android, in fact from what I saw it seemed it was replaced upon every boot but I could just be mistaken. With that said once you nandroid you can pull it by adb shell mount -a then adb pull /data/wimax/Boot.bin all from right within recovery without booting back into Android.
redsolar said:
Also since nandroid is just a simple copy and I'd the keys are indeed preserved, I would think we can pull them from there.
Sent from my PC36100 using XDA App
Click to expand...
Click to collapse
Cordy said:
Does the Boot.bin actually store the keys? You are correct that once you restore a nandroid your working Boot.bin is replaced on boot of Android, in fact from what I saw it seemed it was replaced upon every boot but I could just be mistaken. With that said once you nandroid you can pull it by adb shell mount -a then adb pull /data/wimax/Boot.bin all from right within recovery without booting back into Android.
Click to expand...
Click to collapse
My thoughts exactly gentleman.
The only problem I forsee is that when you restore a nandroid backup, doesn't the phone reboot automatically afterwards? I think it does.
mpa4712 said:
My thoughts exactly gentleman.
The only problem I forsee is that when you restore a nandroid backup, doesn't the phone reboot automatically afterwards? I think it does.
Click to expand...
Click to collapse
ugh it shouldn't, not sure what recovery you're using but using toasts or Amon_Ra's recovery it just restores the nandroid and then you choose manually to reboot. In fact I've already pulled my Boot.bin from before I messed up my MAC this way already, I actually puled the whole wimax folder.
you can unyaff your data.img in your nandroid and dig thru watever you want.
david279 said:
you can unyaff your data.img in your nandroid and dig thru watever you want.
Click to expand...
Click to collapse
*grumble* going to compile it now....*grumble*
david279 said:
you can unyaff your data.img in your nandroid and dig thru watever you want.
Click to expand...
Click to collapse
lol or do that so much easier huh!
looking at my boot.bin from 6/20, I don't *think* the signature is in it. However, I will let Red confirm that since he knows exactly what to look for.
I've only dealt with rsa encryption using openssl, in a full screen terminal, not a tiny hex editor.
There are some fw files in the wimax directory that are worth a look too though.
mpa4712 said:
looking at my boot.bin from 6/20, I don't *think* the signature is in it. However, I will let Red confirm that since he knows exactly what to look for.
I've only dealt with rsa encryption using openssl, in a full screen terminal, not a tiny hex editor.
There are some fw files in the wimax directory that are worth a look too though.
Click to expand...
Click to collapse
That was the reason I asked, I as well as others have looked through the Boot.bin before. I also looked through all the firmware files. Interestingly there is a default firmware and that a manufacturer firmware I'm guessing one to fall back on the other. You're mac is in the Boot.bin as well as wimax_properties. If these files stored the keys great, but either way they'd have to be changed on the actual firmware.
Interestingly enough, my boot.bin from my broken wimax is about 10kb smaller than my boot.bin from my nandroid backup that had working wimax.
Clearly there is something in that file that the other one does not have. I do think the rsa keys need to be stored somewhere though. I really do not believe the phone does on the fly encryption/decryption with them from the wimax partition.
If they come in an actual file, red will be able to extract the wimax.img he made and look.
mpa4712 said:
Interestingly enough, my boot.bin from my broken wimax is about 10kb smaller than my boot.bin from my nandroid backup that had working wimax.
Clearly there is something in that file that the other one does not have. I do think the rsa keys need to be stored somewhere though. I really do not believe the phone does on the fly encryption/decryption with them from the wimax partition.
If they come in an actual file, red will be able to extract the wimax.img he made and look.
Click to expand...
Click to collapse
you know for something that obvious I never noticed that. I never ran a diff on them. I just scanned through it to see if there was anything that struck out as being different and I stopped when I saw the different MAC's
I just went through the two boot.bin files and I'm pretty sure the keys are not in there. However, there are plenty of files that get overwritten on every boot, so I'm going to go through all of them. A 1024bit key should stick like a sore thumb if it's in plain text..
How can I tell if my keys were effed up? I'm currently out of 4G coverage and will be for the next week or so, but I'd like to get it fixed.
I know it was broken because my MAC was changed, I've fixed everything, my boot.bin is the same as pre-screwup as is wimax_properties, everything appears to be working fine, but I can't tell without coverage.
I just wanna know if I messed my keys up too, but I'm not sure whether I did or not?
Geniusdog254 said:
How can I tell if my keys were effed up? I'm currently out of 4G coverage and will be for the next week or so, but I'd like to get it fixed.
I know it was broken because my MAC was changed, I've fixed everything, my boot.bin is the same as pre-screwup as is wimax_properties, everything appears to be working fine, but I can't tell without coverage.
I just wanna know if I messed my keys up too, but I'm not sure whether I did or not?
Click to expand...
Click to collapse
From what we know, if you ever had a messed up MAC then your keys are also gone.
I have been trolling the forums for awhile and I never post but this is something that I have not been able to come across. Why after I used the bootstrap app and load into the recovery menu that now every time I go to reboot my phone I automatically go into the recovery menu even after a successful boot? Hope I worded that right. Please help and thank you!!
just realized I am in the theme section. Can this be moved to the appropriate board. THANKS!!
That's the way it works, it hijacks the bootloader, trust me its a good thing. Bootloop, battery pull, recovery, restore backup. Several times I've been glad it works that way.
Sent from my DROIDX using XDA App
Wait. I have a normal reboot. Maybe mine is messed up?
Yeah I got that but I thought it was only if I pulled the battery after it bootlooped. It does it every reboot except after I flashed a "rom", but I didn't like the rom so I reverted back to stock. I mean its awesome to have the security blanket but it can also be a bad thing if my 14 yo cousin gets ahold of my phone then formats my system an then reboots. Thanks for the help by the way.
Sent from my DROIDX using XDA App
The recovery works by looking for a file : /data/.recovery_mode
If it's there, then it goes into recovery mode, if not, then it allows for a normal boot.
However, if doing normal boot, it actually places the /data/.recovery_mode file and then erases it once the system is fully booted. I know this is confusing, but this is how it knows to go back into recovery if you did a battery pull (ie, the file was created, but never erased since you didn't complete the boot process).
All of this is supposed to happen automagically, but I've heard of that file sometimes getting 'stuck' and not deleted. Thus, causing you to reboot into recovery every time.
There is nothing inside the file, just an empty marker. You may want to delete that file and reboot. Should help.
-Z
If you want to remove bootstrap, you can do SBF flash, which I did several times and it perfectly works.
Zaphod-Beeblebrox said:
The recovery works by looking for a file : /data/.recovery_mode
If it's there, then it goes into recovery mode, if not, then it allows for a normal boot.
However, if doing normal boot, it actually places the /data/.recovery_mode file and then erases it once the system is fully booted. I know this is confusing, but this is how it knows to go back into recovery if you did a battery pull (ie, the file was created, but never erased since you didn't complete the boot process).
All of this is supposed to happen automagically, but I've heard of that file sometimes getting 'stuck' and not deleted. Thus, causing you to reboot into recovery every time.
There is nothing inside the file, just an empty marker. You may want to delete that file and reboot. Should help.
-Z
Click to expand...
Click to collapse
Ok I understand completely I knew the process but did not quite understand. Now the last question, is the only way to remove it to flash or can I use a file manager to remove it?
Oh and thanks for the help by the way.
UPDATE:
So I think I found it.
Unroot and Remove Recovery Via RootExplorer
jkpair said:
Ok I understand completely I knew the process but did not quite understand. Now the last question, is the only way to remove it to flash or can I use a file manager to remove it?
Click to expand...
Click to collapse
You can just delete it with a file manager (I am not sure about the permissions though .. you may need rootexplorer?)
I generally just do things like that from adb shell.
I KNOW I can delete it that way
Zaphod-Beeblebrox said:
You can just delete it with a file manager (I am not sure about the permissions though .. you may need rootexplorer?)
I generally just do things like that from adb shell.
I KNOW I can delete it that way
Click to expand...
Click to collapse
so for adb shell it would be something like:
Code:
adb shell
cd /system/bin
rm -r hijack
If thats right I won't try unless I know for sure. I don't know why but I have just got into a habit of googling after I ask. Lol I think this is it: Easy way to remove Koush's recovery?
So the logwrapper is the main file that matters not the hijack file and the original logwrapper was renamed to logwrapper.bin so I just replace Koush's recovery logwrapper with the previous one by copying over it.
Once again thanks for the help. Seems the answer is always 42.
jkpair said:
so for adb shell it would be something like:
Code:
adb shell
cd /system/bin
rm -r hijack
If thats right I won't try unless I know for sure. I don't know why but I have just got into a habit of googling after I ask. Lol I think this is it: Easy way to remove Koush's recovery?
So the logwrapper is the main file that matters not the hijack file and the original logwrapper was renamed to logwrapper.bin so I just replace Koush's recovery logwrapper with the previous one by copying over it.
Once again thanks for the help. Seems the answer is always 42.
Click to expand...
Click to collapse
I'm sorry, I misunderstood you goal here. I thought you wanted to keep the recovery, just fix it so it didn't come up on each reboot. If you are looking to completely remove the recovery, then I yes, I would follow the directions in the post you referenced, not the code section.
If you are only looking to 'fix' your reboot issues, I would suggest looking to see if /data/.recovery_mode exists on your phone. If it does, delete it. That's likely what is causing you to reboot into recovery each time.
Zaphod-Beeblebrox said:
I'm sorry, I misunderstood you goal here. I thought you wanted to keep the recovery, just fix it so it didn't come up on each reboot. If you are looking to completely remove the recovery, then I yes, I would follow the directions in the post you referenced, not the code section.
If you are only looking to 'fix' your reboot issues, I would suggest looking to see if /data/.recovery_mode exists on your phone. If it does, delete it. That's likely what is causing you to reboot into recovery each time.
Click to expand...
Click to collapse
Oh wow now I feel dumb. I thought I got it. So this would allow me to reboot and keep the recovery without it going into recovery every time I reboot. I hate asking noob questions lol
jkpair said:
Oh wow now I feel dumb. I thought I got it. So this would allow me to reboot and keep the recovery without it going into recovery every time I reboot. I hate asking noob questions lol
Click to expand...
Click to collapse
Assuming that is the problem. There may be another reason that you are getting dumped into recovery each time, but I suspect this is it. I will say that it's not 'normal' for recovery to come up each time. It should only come up if you somehow stop the boot process mid-way (Battery pull, etc) or use the Bootstrap recovery program to set it to reboot in recovery (which basically just creates the data file in question).
I would suggest you work through fixing this problem rather than just getting rid of the recovery. It's quite a powerful tool.
Zaphod-Beeblebrox said:
Assuming that is the problem. There may be another reason that you are getting dumped into recovery each time, but I suspect this is it. I will say that it's not 'normal' for recovery to come up each time. It should only come up if you somehow stop the boot process mid-way (Battery pull, etc) or use the Bootstrap recovery program to set it to reboot in recovery (which basically just creates the data file in question).
I would suggest you work through fixing this problem rather than just getting rid of the recovery. It's quite a powerful tool.
Click to expand...
Click to collapse
Yeah I really don't want to rid myself of it. I do believe I have an understanding now I am going to give it a shot when I can leave work. I will come back and post results.
Awesome It worked like a charm. Deleted the .recovery_mode file and am now happy.
Thanks for replying so quickly before I decided to just go ahead and remove the recovery menu all together.
jkpair said:
Yeah I really don't want to rid myself of it. I do believe I have an understanding now I am going to give it a shot when I can leave work. I will come back and post results.
Awesome It worked like a charm. Deleted the .recovery_mode file and am now happy.
Thanks for replying so quickly before I decided to just go ahead and remove the recovery menu all together.
Click to expand...
Click to collapse
Where is this file located? Im having the same problem.
Sent from my DROIDX using XDA App
DrewDanger said:
Where is this file located? Im having the same problem.
Sent from my DROIDX using XDA App
Click to expand...
Click to collapse
From my earlier post:
The recovery works by looking for a file : /data/.recovery_mode
If it's there, then it goes into recovery mode, if not, then it allows for a normal boot.
However, if doing normal boot, it actually places the /data/.recovery_mode file and then erases it once the system is fully booted. I know this is confusing, but this is how it knows to go back into recovery if you did a battery pull (ie, the file was created, but never erased since you didn't complete the boot process).
All of this is supposed to happen automagically, but I've heard of that file sometimes getting 'stuck' and not deleted. Thus, causing you to reboot into recovery every time.
There is nothing inside the file, just an empty marker. You may want to delete that file and reboot. Should help.
Click to expand...
Click to collapse
I went through Astro and searched "/data/.recovery_mode" but it didnt bring up that file. I guess Im just confused at what exactly Im supposed to be looking for...
Yeah I ended up using a root file manager to do this was really easy. Just go the root menu and browse to data find recovery_mode and delete then reboot.
Oh and astro will not show what is in the data folder you have to get a root explorer app I think the one I used was android mate.
Sent from my DROIDX using XDA App
Ok cool I'll check that out. When I use Astro and go under "system" and scroll down it has a "recovery from boot" folder. Any idea what that is? When I open it there is a bunch of code script in it
Ok I deleted that file and it fixed it. I think Im just gonna un-root it when I get off work. Im over all this, lol. I'll wait until the Droid has more development as far as root access and what you can do. Can I just do the un-root through the one -click-root I used?
DrewDanger said:
Ok I deleted that file and it fixed it. I think Im just gonna un-root it when I get off work. Im over all this, lol. I'll wait until the Droid has more development as far as root access and what you can do. Can I just do the un-root through the one -click-root I used?
Click to expand...
Click to collapse
Yeah it has an option to unroot, but I can't state whether or not this is the best method to remove the root. I acctually am keeping my root and bootloader. Yeah I will be glad when there is a true rom as well but progress is progress.
Alright so looks like I did something completely stupid and now my phone won't finish the boot process. I was looking at some remappings for the recent key to the menu option and from a post in the development section I found a thread in the International One X development forum that had re-odexed files so that the recent key stayed as the recent key and holding the home button became the menu key. Since they were re-odexed and I had root access I figured I would just manually replace them on my phone with Root Explorer...bad idea. The files were:
System/Framework/android.policy.odex
System/Usr/keylayout/qwerty.kl
After I moved them and reset permissions I rebooted my phone and now it goes through the first couple of boot animations but gets stuck on screen that displays beats audio at the bottom.
I really need to know what to do to fix this. When I plug my phone into my computer it recognizes it as a new \drive, but I don't have access to any of it (still says I need to mount). I also have the android SDk and adb installed if thats of any help. I would really like to not lose any data so hopefully thats possible.
Please help me with this if you have any knowledge of what to do.
Just one little quick update. Even though my computer won't let me access my One X as a drive, when I use command prompt and adb to check for adb devices my One X is listed.
Run the at&t ruu exe file, located in the Dev section.
tanman21 said:
Run the at&t ruu exe file, located in the Dev section.
Click to expand...
Click to collapse
Alright I'm downloading that now.
In the meantime, how do I get root access with adb/give it permission to overwrite read only files? I pulled the two files that caused this messed and pulled my backups, but when I push them back to the phone it tells me I can't because their read only. I'd rather do it this way since I will be changing only the files that caused the problem.
EDIT: Is the RUU really going to delete all the information on my device? If thats the case I would really appreciate figuring out how to get adb to push my backuped files to the /system directory instead
ErikWithNoC said:
Alright I'm downloading that now.
In the meantime, how do I get root access with adb/give it permission to overwrite read only files? I pulled the two files that caused this messed and pulled my backups, but when I push them back to the phone it tells me I can't because their read only. I'd rather do it this way since I will be changing only the files that caused the problem.
EDIT: Is the RUU really going to delete all the information on my device? If thats the case I would really appreciate figuring out how to get adb to push my backuped files to the /system directory instead
Click to expand...
Click to collapse
Yeah, the RUU returns your phone to factory (but doesn't touch your personal files)
EDIT: Also, just pulling this off the top of my head so take it with a grain of salt...
adb devices
adb shell
su
*grant the su request on your device*
adb push <from> <to>
stnguyen09 said:
Yeah, the RUU returns your phone to factory (but doesn't touch your personal files)
EDIT: Also, just pulling this off the top of my head so take it with a grain of salt...
adb devices
adb shell
su
*grant the su request on your device*
adb push <from> <to>
Click to expand...
Click to collapse
Thanks for your comment. I used the RUU and it kept my personal data so its not a big lose. Had to reinstall a few apps, but for most of them (games at least) my saved data was still there.
I tried a lot using adb and just couldn't get it to work. I don't the phone got far enough through the boot process for root access to be allowed. I was able to run the one click root tool while it was in its stuck boot phase, but it still wouldn't give me permission to modify the /system portion of the phone to be read/write.
All in all though this was a great learning experience. Prior to this happening I knew nothing about adb and now I know commands for pulling, pushing, remounting, shell commands, and other things. I also learned how to fix a softbrick (first one) and what RUU is.
My TF300 is on stock and is unrooted with a locked bootloader. However, despite this, it is no longer booting into the stock ROM. It gets stuck on the bootanimation phase with the loading circle constantly circling round, even after a few hours. It hasn't moved on from this stage unfortunately and I was wondering if there was anything that could be done? I know I could try wiping my data, but there are files and app data that I would not like being lost so is there any way they would be salvageable? Thanks for any help
If ADB is accessible, you could pull /sdcard/, and save it on your computer.
While waiting at the animation, plug it in to your computer, open a terminal, cd into whichever directory ADB resides, and run
Code:
adb devices
If it returns your tablet, then run
Code:
adb pull /sdcard/
adb pull /data/
It should copy everything from your internal storage and your app data into the directory containing ADB, but I'm honestly not sure if you could pull /data/ without root access. And even if you did, I'm not sure how you could safely restore the files without breaking something (or especially without root). At the very least, you'll have the contents of your internal storage.
At that point, you should be OK to wipe your data.
If that doesn't work, then assuming you're on the 4.2 bootloader, you could boot into the bootloader by holding Volume Down as you start your tablet, and you will automatically be in fastboot mode. This should allow you to flash a stock blob with fastboot. Instructions to do so have been posted throughout this forum.
If all else fails, it should still be under warranty since it's locked, so you could get a free replacement. I'm thinking the data wipe should be enough, though. Good luck.
Thank you kindly. I'll thank you later as I seem to be out of thanks today. Admittedly though, I'm not too experienced with this stuff and don't really know which directory ADB is in
Am I right in opening the command window inside sdk--> platform tools?
If so, no devices show up when running the "adb devices" command although I can see my TF300 in device manager
UndisputedGuy said:
Am I right in opening the command window inside sdk--> platform tools?
If so, no devices show up when running the "adb devices" command although I can see my TF300 in device manager
Click to expand...
Click to collapse
That's the right place, unfortunately. I'm assuming you have the ADB drivers installed and everything. Otherwise, install them, and try again.
If you can still get into the bootloader, you should be able to fastboot flash a stock blob. I don't believe that wipes data or your SD card, but I could be wrong. I know that flashing them in a custom recovery wipes both, but I don't think the fastboot method wipes either. Unless tobdaryl or someone else more experienced than I can think of another option, your only next move is using your warranty.
EndlessDissent said:
That's the right place, unfortunately. I'm assuming you have the ADB drivers installed and everything. Otherwise, install them, and try again.
If you can still get into the bootloader, you should be able to fastboot flash a stock blob. I don't believe that wipes data or your SD card, but I could be wrong. I know that flashing them in a custom recovery wipes both, but I don't think the fastboot method wipes either. Unless tobdaryl or someone else more experienced than I can think of another option, your only next move is using your warranty.
Click to expand...
Click to collapse
Thanks again for your help. I'll need to look into using fastboot to flash a stock blob.
I was able to find the device using adb and then run the "adb pull /sdcard/" command (thanks a ton for the help in doing that) but it seems like it's only pulling my files from my downloads and Ringtones folder and even then, it doesn't pull all of them within my downloads folder. Any idea on why this is happening?
UndisputedGuy said:
I was able to find the device using adb and then run the "adb pull /sdcard/" command (thanks a ton for the help in doing that) but it seems like it's only pulling my files from my downloads and Ringtones folder and even then, it doesn't pull all of them within my downloads folder. Any idea on why this is happening?
Click to expand...
Click to collapse
No, I have no idea why it's only pulling a couple directories. It should pull everything from the internal storage since the command includes the whole /sdcard/ directory. I hope someone else knows. If you remember the names of your most important folders, you could try pulling them individually to see if it gives you an error message. If it does, we have a starting point to fix it. If it pulls them fine, then I'll probably be stumped.
EndlessDissent said:
No, I have no idea why it's only pulling a couple directories. It should pull everything from the internal storage since the command includes the whole /sdcard/ directory. I hope someone else knows. If you remember the names of your most important folders, you could try pulling them individually to see if it gives you an error message. If it does, we have a starting point to fix it. If it pulls them fine, then I'll probably be stumped.
Click to expand...
Click to collapse
Thanks! I shall probably try that soon, but I currently want my files from the download folder so will have another stab at that. Thanks again for the assistance :good:
I have been able to pull some files using ADB and thank you greatly for your assistance in doing so. I hadn't really used ABD before but now I'm more familiar with it, so thanks. I have a question regarding using the fasboot method to flash a stock blob. Do I need an unlocked bootloader for flashing a stock blob? The guides I've found have suggested as such. My bootloader is locked.
Honestly, I'm not sure. I would imagine it would do a signature check before flashing, and since you'd be using the official ASUS firmware, it would pass. All I know for sure is that fastboot works on locked tablets. I have no idea to which extent it works.
EndlessDissent said:
Honestly, I'm not sure. I would imagine it would do a signature check before flashing, and since you'd be using the official ASUS firmware, it would pass. All I know for sure is that fastboot works on locked tablets. I have no idea to which extent it works.
Click to expand...
Click to collapse
Thanks again. You've been a great help
Sent from my R800i using xda-developers app.
It's nice to be important, but it's more important to be nice.
UndisputedGuy said:
Thanks again. You've been a great help
Sent from my R800i using xda-developers app.
It's nice to be important, but it's more important to be nice.
Click to expand...
Click to collapse
I was just about to post that your first step should be to wipe data and see if it boots before we get caught up in fastboot. That is a last resort here. If wiping data may work, fastboot is more work than necessary.
Just to confirm that my tablet did indeed start working again after wiping the data although the stock Asus Backup App fails to restore my app backups from a while ago. It stops at 15%.
Sent from my ASUS Transformer Pad TF300T using xda app-developers app
Argh! Pulling my hair out over this one. I've been flashing custom ROMs and rooting my phones for years now, since my old HTC G1. Even had KitKat running on my HTC Desire 4G!
... but this Sidekick is proving another matter. I've been through forum after forum, all saying the same things on how to root/flash this thing, but I haven't managed to get anything to work! So, here's step-by-step of what I just did and the result I get every single time, no matter the initial method:
1: Fired up ODIN3.
2: Wiped the user data and cache from the stock recovery (Android System Recovery (3e)).
3: Connect USB cable, reboot phone into download mode (using the battery-pull method).
4: Successfully flash to stock ROM, reboot.
5: Sign in with Google, enable WiFi.
6: Run SuperOneClick, reboot.
7: Grab ES File Explorer from the Market, after it updates.
8: Attempt to replace "recovery" in /system/bin with custom
... and here's where things break. Doesn't matter what version of SuperOneClick I use (and I've tried from 1.9.1 through 2.2.3), nor does it matter what exploit I select. What happens? Well... aside from everything on-screen claiming to be okay, and everything claiming it's working, once the rooting is "successful", I reboot like it says, see that SuperUser is in the applications, it shows me an su binary version...
... but anything that tries to run super-user (ES File Explorer included) that gets added to the super-user list simply does not work. I can't over-write the recovery, can't delete or muddle with anything that requires elevated privileges, and the ROM Manager for sure won't work because I can't get CWR installed.
I love my phones with keyboards. I really do. I'd love to keep this thing, but the stock firmware is driving me up a wall (especially that stupid media scanner). So if anyone has any ideas to throw at me, care to offer some? Haven't a clue at this point what I'm doing wrong.
Hey buddy!
I feel your pain, this is one of the last nicely built hardware keyboard phones, first time rooting it is a bit strange
See post #27 (or so) here
http://forum.xda-developers.com/showthread.php?t=2221030
I ran through the manual steps there and have links for needed files
If you get stuck let me know, I'll be around
demkantor said:
Hey buddy!
I feel your pain, this is one of the last nicely built hardware keyboard phones, first time rooting it is a bit strange
See post #27 (or so) here
http://forum.xda-developers.com/showthread.php?t=2221030
I ran through the manual steps there and have links for needed files
If you get stuck let me know, I'll be around
Click to expand...
Click to collapse
Awesome! I'll give this a go once I'm all done with today's activities and see if it works.
Well, apparently I have root access for the moment, but it is denying my replacing of /system/bin/recovery - in adb shell, it states "Filesystem is read-only", so I re-mounted /system -rw and no dice. Going to attempt to try again in a moment, after a reboot.
Okay, so since there's a problem with all of this, I'm going to try that second ROM (KD2 I think it was) - but as I recall, it was on a very slow server. Plus I have a load of things to do tomorrow, so it probably won't be until tomorrow evening sometime when I'll be able to flash it. Once I've used Odin to re-flash, I'll get back to you.
Well, I had to dissect "t839-Sidekick4G-UVKG2-One-Click.jar" and remove the xml file from within it, but I acquired the necessary package to upgrade to KG2 from KD1 through Odin3. Took a while to figure out just how to deal with it, and I was successful in flashing... and I even replaced the recovery file after rooting it again!
... however, now it just sits there at the "T Mobile Sidekick 4G" start-up screen when I attempt to boot into recovery, so now I'm preparing to re-flash it again to recover the stock recovery. So... still more on this, later.
EDIT: Also, I named the tar file "KG2OdinHeimdall.tar", since I basically ripped it right off the "HeimdallPackage.tar" file from the Heimdall one-click thing. Turns out, it apparently works just fine if you remove the .xml file from the original tar.
Finally!
I ended up having to use my own method to get the KG2 update installed because the one-click program kept crashing on me when selecting "Show all devices", and I opted to use AntTek Explorer (all you have to do is go into the program's options and it'll attempt to acquire admin privileges, if the device is rooted) to copy the recovery file to /system/bin - but your post worked for everything else, once I got past not being able to copy the recovery file.
I opted for the CM6 package and it's quite fast! Thank you loads, demkantor!
Nice! I'm glad all worked out well for you!
If you get a chance try out the one gingerbread ROM, its cool to see it running but there are still driver issues so keyboard is borked, really makes it pointless to have on this phone...
But there are a few nice froyo ROMs ready to be played with, someday development will hopefully pick up again
Until then, happy flashing!