So, I've gotten my SGS2 today and went ahead to root it. Flashed CF-Root matching my current version (KE7 PDA/KE4 baseband). I used the S2Root app posted here on the forum to get root and flashed a stock kernel back.
In either of these stages, I couldn't get ADB to run as root, needed for a modification i'm trying to do (can't write to /system/framework otherwise).
Is there a known way to get ADB to run as root?
(The issue at hand - /default.prop contains ro.secure=1 and ro.debuggable=0 - And i can't edit this file in order for it to persist after reboot)
even in CWM i can't get ADB to run as root and thus cannot copy files to /system/framework even though /system is mounted as r/w.
Thanks for the help.
ransagy said:
So, I've gotten my SGS2 today and went ahead to root it. Flashed CF-Root matching my current version (KE7 PDA/KE4 baseband). I used the S2Root app posted here on the forum to get root and flashed a stock kernel back.
In either of these stages, I couldn't get ADB to run as root, needed for a modification i'm trying to do (can't write to /system/framework otherwise).
Is there a known way to get ADB to run as root?
(The issue at hand - /default.prop contains ro.secure=1 and ro.debuggable=0 - And i can't edit this file in order for it to persist after reboot)
even in CWM i can't get ADB to run as root and thus cannot copy files to /system/framework even though /system is mounted as r/w.
Thanks for the help.
Click to expand...
Click to collapse
Try this:
adb shell mkdir /sdcard/temp/
adb push fileToPush /sdcard/temp/
adb shell
$ su
# cp /sdcard/temp/ /system/path/to/push/to/
ADB doesn't run as root, as it's not safe to, as you can bypass superuser security in a rogue app otherwise
I'll try it ASAP, Thanks.
Isn't there a way to edit /default.prop though?
I'd prefer to have adb run in root at the very least while running this mod, and then restore it.
the mod currently patches framework.jar/libwebcore.so for RTL issues, and relays on scripted access to adb and r/w access to /system.
I ended up discovering that i need a different ROM either way since stock is odexed.
I'll try making my own ROM based on stock with deodexed files and make the fix before hand.
Related
Question: Is your Superuser app asking for permissions from apps? Mine isn't. On my old rooted Eris, if I ran an app such as Titanium Backup or Root Explorer, I would get a dialog which would ask if I wanted to grant that app root access. This dialog was via the Superuser app. I don't get that now. It seems like any/every app on my phone has su access.
I'm wondering if it's just me or if this is the way the current root exploit works.
DeezNotes said:
Question: Is your Superuser app asking for permissions from apps? Mine isn't. On my old rooted Eris, if I ran an app such as Titanium Backup or Root Explorer, I would get a dialog which would ask if I wanted to grant that app root access. This dialog was via the Superuser app. I don't get that now. It seems like any/every app on my phone has su access.
I'm wondering if it's just me or if this is the way the current root exploit works.
Click to expand...
Click to collapse
It's just you. Try running root explorer or a screen cap program, and verify that you have root access. You may want to use an updated Superuser.apk too, I know the one I'm using (2.3.6.1) asks, (unless I told it not too).
I'm using Superuser 2.3.6.1. When I run Titanium or Root Explorer, everything works without prompting. Now, I'm concerned.
UPDATE: I opened Superuser, went to settings, scrolled to the bottom and updated the su binary. Now, I get prompted when an app needs access. Problem is, when I reboot the su binary is reset. I think this is due to me using the joeykrim root procedure, which uses a version of su that is scripted to be put in place during the boot process. I'm going to take a look at his scripts and change them so I can keep the su binary installed by the Superuser.apk.
Thanks for the info.
Confirmed my issue was due to using the joeykrim method. I backed out his procedure and used Dirrk's method (posted here: http://forum.xda-developers.com/showthread.php?t=779238) and I get a proper Superuser prompt when an application needs access.
I also noticed another flaw in the joeykrim method. Since his procedure was developed for the Epic, he has some incorrect file names in some places.
If you notice in his instructions where he says use playlogos1 instead of playlogos, this is not updated in all of his steps.
To get your boot screen back, you have to change the last line of playlogos1 or playlogosnow (based on whether you did the lag fix or not)
The file that will not show your boot animation will look like this:
Code:
#!/system/bin/sh
#joeykrim-SDX sdx-developers.com scripted
/system/bin/joeykrim-root.sh
/system/bin/playlogo-orig
To fix it, change the last line to read:
Code:
#!/system/bin/sh
#joeykrim-SDX sdx-developers.com scripted
/system/bin/joeykrim-root.sh
/system/bin/playlogos1-orig
In summary, the playlogos1 file is used to execute other startup scripts. The original playlogos1 file has the boot animation in it. It must be referenced in one of the startup scripts. Since these instructions were used for the Epic, there's a slight typo which keeps the original playlogos1 file from being executed.
Thanks--I came to the forums looking for a solution to the fact that my boot animation was now missing. I tried making your changes but I still can't seem to recover it. Here are what my playlogo scripts look like, keeping in mind I have also installed the lag fix:
playlogos1
Code:
#!/system/bin/sh
sh /system/bin/userinit.sh
playlogosnow
playlogosnow
Code:
#!/system/bin/sh
#joeykrim-SDX sdx-developers.com scripted
/system/bin/joeykrim-root.sh
/system/bin/playlogos1-orig
I'll also have a 3rd file called just playlogo (which was very long). Do you know what the issue is? Thanks so much for your help.
theicemonkey said:
Thanks--I came to the forums looking for a solution to the fact that my boot animation was now missing. I tried making your changes but I still can't seem to recover it. Here are what my playlogo scripts look like, keeping in mind I have also installed the lag fix:
playlogos1
Code:
#!/system/bin/sh
sh /system/bin/userinit.sh
playlogosnow
playlogosnow
Code:
#!/system/bin/sh
#joeykrim-SDX sdx-developers.com scripted
/system/bin/joeykrim-root.sh
/system/bin/playlogos1-orig
I'll also have a 3rd file called just playlogo (which was very long). Do you know what the issue is? Thanks so much for your help.
Click to expand...
Click to collapse
Judging by what your files look like, things should work. The original file is playlogos1. We never touch the playlogo file from what I can remember, so let's not do anything there.
What I would do is make sure the permissions are straight on all the files listed above (primarily playlogos1). They should be 755 (shown below):
Code:
# cd /system/bin
# ls -l playl*
-rwxr-xr-x root shell 10060 2010-08-12 04:30 playlogo
-rwxr-xr-x root root 106 2010-09-11 18:53 playlogos1
-rwxr-xr-x root root 177 2010-09-11 18:55 playlogos1-lagfix
-rwxr-xr-x root shell 14420 2010-08-12 12:30 playlogos1-orig
-rwxr-xr-x root shell 14204 2010-08-12 04:30 playlpm
#
If all else fails, you can always grab the original file from the system dump off of this link: http://forum.androidcentral.com/fascinate-roms-hacks/32839-fascinate-system-dump.html
DEAR GOD
Well, I'm an idiot.
I tried to take the playlogos1 file from the dump you showed me and copy it to my /system/bin file and, sure enough, I got the boot animation back. Problem is, I didn't think it through (that the edited playlogos1 file pointed to the rest of the modified boot sequence) and then the phone wouldn't boot. It would just loop the animations.
I booted into recovery, did a factory reset, and now I can get to the lockscreen and the very beginning of setup but TWLauncher force closes over and over and over and I'm unable to do anything except pull down the notification bar occasionally. I think this is because I moved some things (like bing, daily briefing, etc.) that TWLauncher wants at the outset, and it doesn't have them. I tried to bluetooth over LauncherPro and run it, but it fails at the last moment.
Does anyone know of a way to get to ADB Shell so that I can fix my mistake? Or if someone had an update.zip I could flash to get back to factory (with all of the system files in place), that would be super! Otherwise, it looks like I'm effed and will need to come up with a good story to tell Verizon...
theicemonkey said:
Well, I'm an idiot.
I tried to take the playlogos1 file from the dump you showed me and copy it to my /system/bin file and, sure enough, I got the boot animation back. Problem is, I didn't think it through (that the edited playlogos1 file pointed to the rest of the modified boot sequence) and then the phone wouldn't boot. It would just loop the animations.
I booted into recovery, did a factory reset, and now I can get to the lockscreen and the very beginning of setup but TWLauncher force closes over and over and over and I'm unable to do anything except pull down the notification bar occasionally. I think this is because I moved some things (like bing, daily briefing, etc.) that TWLauncher wants at the outset, and it doesn't have them. I tried to bluetooth over LauncherPro and run it, but it fails at the last moment.
Does anyone know of a way to get to ADB Shell so that I can fix my mistake? Or if someone had an update.zip I could flash to get back to factory (with all of the system files in place), that would be super! Otherwise, it looks like I'm effed and will need to come up with a good story to tell Verizon...
Click to expand...
Click to collapse
Sorry you're having issues. Bad news is, you can't flash any zip updates because we don't have a custom recovery re our phones yet. However, what you should be able to do is use adb to push the apps from /system/app from the system dump. That is.. if you can get adb to work? If it can work from recovery, that should save you.
Good luck.
Can someone knowledgeable please submit a detailed post, which instructs how to remove any files added during the Root Process, as well as any other file permission changes or modifications of any other type?
I see many half assed posts in these forums made by unqualified members, which are nothing but a waste of time and clutter this great resource. I would appreciate it if this post could be addressed by those who truly understand this process.
The file that was used to Root the SCH-i905 from Verizon was the one attached to this post.
Thanks in advance! This could be a great learning tool if answered properly.
Can some one please respond? Or is it that everyone is too scared to post helpful information?
Well, since no one was of any assistance, I was forced to piece together information and come to an understanding of how this works, and how to fully reverse what was done by this Root Update.
To begin, I would like to mention, that removing Superuser.apk from the /system/app folder, along with 'su' from the /system/bin folder, will negate your Root Access, and put you back to your default levels of access. This will prevent Mobile Device Management Solutions, such as AirWatch, Zenprise, or MobileIron from detecting your device as being compromised.
I was not successful in removing these two files via the ADB shell, however I was successful when using a Terminal Emulator App on the Device itself.
1.) I began by installing a free Terminal Emulator from the Android Market.
2.) Launched the Terminal Emulator and typed 'su' , then pressed Enter to gain Root Shell Privileges.
3.) From the Root Shell, I typed the following commands to remount the '/System' Directory to gain Read/Write Access.
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
4.) I typed the following commands to remove 'Superuser.apk' and 'su'.
cd /system/app
rm Superuser.apk
cd /system/bin
rm su
5.) Type the following command to remount the '/System' Directory back to Read Only.
mount -o ro,remount -t yaffs2 /dev/block/mtdblock3 /system
6.) Sync your device with Google under Settings / Accounts & Sync.
7.) Reboot your device, and you are good to go.
It might be a good practice to perform a Factory Reset on your device after doing this, however this is not completely necessary. I tested the Air-Watch Agent installation after performing the procedure mentioned above, and the Air-Watch console no longer detected my device as being compromised.
I will add that on my sch-i905 I found the bin directory under system not under system/app. For me, replacing cd /system/app/bin with cd /system/bin did the trick but the rest worked a treat - thanks for the post!
Thanks for pointing out my typo. I corrected the path in my Post.
Thanks for this.
Does this restore the stock recovery that was replaced with Clockwork when the kernel.zip and recovery.zip files were flashed to obtain root? I do not totally understand the relationship between Superuser and CWR. I found a reference to a flashable stock recovery in post 14 here http://forum.xda-developers.com/showthread.php?t=1205639&page=2 , but I'm unclear on the instructions.
I'm trying to understand how, if possible, to return my VZW LTE Tab to out-of-the-box stock, if desired.
Rooted: Droid Incredible / Droid X / Thunderbolt / 3G-4G Xoom / Galaxy Tab 10.1 LTE
I have the Superuser icon showing up in my apps folder, but I don't appear to have root access. I can't su in the terminal emulator nor can I load apps that require root access. I also tried removing the Superuser.apk via a file manager with no luck.
Any idea how to remove this thing if I don't actually have root access?
---------- Post added at 09:25 PM ---------- Previous post was at 09:10 PM ----------
OK, I rooted again and fixed whatever was broken. Then I was able to apply these commands to unroot the device.
Thank you!
tbcpn said:
Thanks for this.
Does this restore the stock recovery that was replaced with Clockwork when the kernel.zip and recovery.zip files were flashed to obtain root? I do not totally understand the relationship between Superuser and CWR. I found a reference to a flashable stock recovery in post 14 here http://forum.xda-developers.com/showthread.php?t=1205639&page=2 , but I'm unclear on the instructions.
I'm trying to understand how, if possible, to return my VZW LTE Tab to out-of-the-box stock, if desired.
Rooted: Droid Incredible / Droid X / Thunderbolt / 3G-4G Xoom / Galaxy Tab 10.1 LTE
Click to expand...
Click to collapse
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
Stock Recovery isn't required to Root the device. However, if you wish to install CWM via ROM Manager from the Android Market, Root Permissions are required.
If you use an ODIN Flash of CWM, there is no need for Root Permissions because you are flashing via ODIN.
The stock recovery zip file that you referenced in the other post should be fine.
Just use ODIN to Flash back to Stock Recovery and use the process that I mentioned to remove Root Permissions and Super User, and you should be all set to return your device after a Factory Wipe.
Cheers!
~Scott~ said:
I have the Superuser icon showing up in my apps folder, but I don't appear to have root access. I can't su in the terminal emulator nor can I load apps that require root access. I also tried removing the Superuser.apk via a file manager with no luck.
Any idea how to remove this thing if I don't actually have root access?
---------- Post added at 09:25 PM ---------- Previous post was at 09:10 PM ----------
OK, I rooted again and fixed whatever was broken. Then I was able to apply these commands to unroot the device.
Thank you!
Click to expand...
Click to collapse
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
Scott,
I'm sorry for just seeing your post. I'm sure that you figured it out by now. You need to gain Root Access to your device again to remove Super User. You are in a Catch22.
If you are using an SCH-I905, Root your device, then download Script Manager from the Android Market.
Run this very simple Bash Script that I wrote to remove Root and Super User.
Paste this into notepad and save it as Unroot.sh then run with Script Manager.
Code:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
cd /system/app
rm Superuser.apk
cd /system/bin
rm su
mount -o ro,remount -t yaffs2 /dev/block/mtdblock3 /system
Be sure to run the Script as Root from within Script Manager. The app will kind of freeze up as soon as it runs, which is normal. This will certainly take care of your problem.
Thanks for your post of stockrec in a different post. You saved me a month ago with that one.
Cheers!
Will Samsung know if I rooted my GT 10.1 LTE after using these commands, and sending in for warranty?
Does anyone know how often airwatch checks for the root? anyway to bypass the checks?
Is this the same for the US Cellular 4G Tablet? I have been reading and all that I have found was WiFi only files. Which if I were to root with those I lose the 4G radio.
Perfect.. Just what I need. Thanks
Hi everyone.
I apologize for my first post because it's not one helping, but one asking for help instead.
I have recently struggled with the problem of not being able to move apps to the SD card which you may already be aware of.
So I read somewhere about changing some things on /system/etc/permissions/platform.xml and I had the stupid idea to try to change it without really understanding it.
So I did some ****. Now I can't mount sd (internal or external) and I don't have permissions to restore platform.xml (I have a platform.xml.bak in the same directory which is identical to the original one).
So I was wondering if there could be any trick to restore it. Neither ES File Manager nor Terminal Emulator were capable of replacing the files or edit platform.xml's content (even with root access, su - with terminal emulator).
What could I do? I honestly don't think a factory reset would solve that.
My ROM is stock UBDLI2 (4.1.1) which I found kinda hard to find.
Since you haven't posted a log of your Android Terminal Emulator session, here's my guess at trying to resolve this:
Code:
su
mount -o remount,rw /system
mv /system/etc/permissions/platform.xml.bak /system/etc/permissions/platform.xml
If you need it, chown root.root platform.xml && chmod 644 platform.xml.
similar problem with platform.xml
qwerty12 said:
Since you haven't posted a log of your Android Terminal Emulator session, here's my guess at trying to resolve this:
Code:
su
mount -o remount,rw /system
mv /system/etc/permissions/platform.xml.bak /system/etc/permissions/platform.xml
If you need it, chown root.root platform.xml && chmod 644 platform.xml.
Click to expand...
Click to collapse
I was trying to replace my platform.xml file with a modified platform.xml file and in doing so I moved the 0riginal platform.xml file to another folder (just in case I needed the 0riginal again), I changed the permissions of the permissions folder and rebooted for them to take affect without having the platform.xml file in there and boom I'm in never-never-bootloop land. Can anyone help me or does this phone need to be used for skeet shooting? Thanks in advance!
Reflash the same rom, no wipe.
boomboomer said:
Reflash the same rom, no wipe.
Click to expand...
Click to collapse
Thanks for the reply. I was rooted but still on stock since I had yet to successfully get a custom recovery on my phone (apparently SGH-I337 on the BN1 baseband is tough to get a custom recovery on)...so I only have the stock recovery which really doesn't offer many options. And everytime I have tried to flash anything via the custom recovery it fails due to it not being signed (or at least I think that is what it says). I'm open to try anything if you got more ideas.
Odin
Odin
boomboomer said:
Odin
Click to expand...
Click to collapse
I don't want to be "that guy" as described in your signature...so I want to first say I have searched on this, but I have only found various sections on Odin instructions for various versions of Odin typically pertaining to one specific topic rather than an actual manual/guide for how to use Odin to reinstall a file that was idiodically removed (that'd be me....the idiotical remover of pertinent files). So I hate ask you for more help, but I only can't seem to get anything I try flashing with odin to work, I'm not sure if I'm putting things in the wrong slot (BOOTLOADER, PDA, PHONE, CSC) or what, but I really need some guidance.
Go read the sticky thread in general forum, how to flash with Odin, you can only flash the whole firmware not one file.
Hello everybody,
i have gained root access to my phone via backup/restore method through adb where local.prop is stored in /data/. So when i log onto my phone with adb i have root access. I copied busybox, su and the superuser.apk to the right place and removed the local.prop file again. After a reboot I was hoping to remove some crapware off my phone but to my surprise the binaries i copied vanished from the filesystem. So the phone reverted the changes by itself. I did this process several times copying busybox and su to various places referred to by $PATH, but it´s everytime the same after i reboot. The files are gone.
After the first attempts failed i tried to make changes to my phone while logged in as root. I wanted to uninstall unnecessary packages with "pm uninstall" but that failed also. The command just responds "failed". Even when /system is mounted rw (it remounts itself to ro after a while though). I´ve also made changes to /init.rc but they are also gone after a reboot as other changes i´ve made. Basically i wasn´t able to accomplish anything with root access no matter what i did.
So what i want to know is how this black magic works andy why i cant do anything with root. I know how to achieve real root through htc dev and various other methods.
Thanks for reading!
nasenstueber said:
Hello everybody,
i have gained root access to my phone via backup/restore method through adb where local.prop is stored in /data/. So when i log onto my phone with adb i have root access. I copied busybox, su and the superuser.apk to the right place and removed the local.prop file again. After a reboot I was hoping to remove some crapware off my phone but to my surprise the binaries i copied vanished from the filesystem. So the phone reverted the changes by itself. I did this process several times copying busybox and su to various places referred to by $PATH, but it´s everytime the same after i reboot. The files are gone.
After the first attempts failed i tried to make changes to my phone while logged in as root. I wanted to uninstall unnecessary packages with "pm uninstall" but that failed also. The command just responds "failed". Even when /system is mounted rw (it remounts itself to ro after a while though). I´ve also made changes to /init.rc but they are also gone after a reboot as other changes i´ve made. Basically i wasn´t able to accomplish anything with root access no matter what i did.
So what i want to know is how this black magic works andy why i cant do anything with root. I know how to achieve real root through htc dev and various other methods.
Thanks for reading!
Click to expand...
Click to collapse
is your RECOVERY.img
and beside i dont really think your /system is fully mounted rw
mauricio.valladolid said:
is your RECOVERY.img
and beside i dont really think your /system is fully mounted rw
Click to expand...
Click to collapse
Thanks for the reply. i use mount -o remount,rw /system as mount command to get read/write permission on /system. If there is something more to do please let me know. And if the behavior i ve seen is caused by the recovery.img is there something i can do about it?
nasenstueber said:
Thanks for the reply. i use mount -o remount,rw /system as mount command to get read/write permission on /system. If there is something more to do please let me know. And if the behavior i ve seen is caused by the recovery.img is there something i can do about it?
Click to expand...
Click to collapse
why dont you just install ext4 recovery and flash supersu.zip?
I really dont get it why are you trying to do it the hard way
Hey all,
when changing my build.prop I didn't set the permissions and now I see the grey kindle logo at bootup. I'm on 13.3.2.4 and did a Towelroot before this happened.
Trying to fix the permissions I noticed I cannot change the build.prop because ADB says it is a read-only file system. The mount / remount doesnt work either.
I think what I need is a re-root via ADB (e.g. ghettoroot), as described here http://forum.xda-developers.com/kindle-fire-hdx/help/help-build-prop-edit-rooted-hdx-brick-t2973070
Sadly this also doesnt work, at the chmod 0644 /system/build.prop it still tells me read-only file system. I can only imagine it is due to the modstring being for 14.3.2.6.
Is there a way to do an ADB-only root on 13.3.2.4 (does someone have the corrent modstring) or any other way to set the right permissions on my build.prop?
Thanks in advance for your help!
------
UPDATE: UNBRICKED MY KINDLE. The ghettoroot call was correct
./ghettoroot -n -m "1337 0 0 0 4 0" /system/bin/sh
But afterwards I was still not able to change the build.prop (despite having the "#" which would indicate I have sufficient rights)
Then I used
Code:
su
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
chmod 644 /system/build.prop
(not sure if the "su" is needed, but I will not rebrick my Kindle to find out)
which I found in HERE
What exactly do you want to mess up your build.prop for? If you want to downgrade to 3.1.0 in order to use TWRP and to unlock your bootloader you should install Safestrap v3.75 (if you haven't already) and use the rollback image provided by @ggow. Take a look at this thread (page 1 is about 3.2.5/3.2.6 users who can NOT use the rollback images).
Cl4ncy said:
What exactly do you want to mess up your build.prop for? If you want to downgrade to 3.1.0 in order to use TWRP and to unlock your bootloader you should install Safestrap v3.75 (if you haven't already) and use the rollback image provided by @ggow. Take a look at this thread (page 1 is about 3.2.5/3.2.6 users who can NOT use the rollback images).
Click to expand...
Click to collapse
Yes my plan was to downgrade to 3.1.0 in order to use TWRP and to unlock the bootloader. I wasnt aware of ggows solution and followed this thread http://forum.xda-developers.com/showthread.php?t=2782159 but used the "change build.prop with ES File Explorer instead of build prop editor". And I dont know why my root is gone (I had towelrooted it before and was able to change the build.prop file). And now I need a root to fix the build.prop.
OriginalJones said:
Yes my plan was to downgrade to 3.1.0 in order to use TWRP and to unlock the bootloader. I wasnt aware of ggows solution and followed this thread http://forum.xda-developers.com/showthread.php?t=2782159 but used the "change build.prop with ES File Explorer instead of build prop editor". And I dont know why my root is gone (I had towelrooted it before and was able to change the build.prop file). And now I need a root to fix the build.prop.
Click to expand...
Click to collapse
Did you try to re/root it with Hdx toolkit? IMHO if this can't re/root your kindle, probably nothing can...
jeryll said:
Did you try to re/root it with Hdx toolkit? IMHO if this can't re/root your kindle, probably nothing can...
Click to expand...
Click to collapse
HDX toolkit needs the tablet to be running, but I can only ADB it. That's why I'm locking for a root that is working via ADB only (like the ghettoroot described in the linked thread).
Well, I'm not exactly sure about this, but most likely @Davey126 is right:
Davey126 said:
Messing with build.prop is a bad idea on this device as you unfortunately discovered. I'm almost certain it can not be replaced via adb as the file is processed before adb access becomes available (assuming you previously enabled USB debug in FireOS).
Click to expand...
Click to collapse
OriginalJones said:
HDX toolkit needs the tablet to be running, but I can only ADB it. That's why I'm locking for a root that is working via ADB only (like the ghettoroot described in the linked thread).
Click to expand...
Click to collapse
I am sorry, I did miss that booting process is stuck at the grey logo. I always thought that you can't communicate with the hdx tablet at that point via ADB. So far what I learn from posts here is that messing with build.prop in wrong way (i.e. permissions set in wrong way) is fatal to the HDX tablet and there is no known way how to repair this...