Disclaimer: I try my best to produce valid answers, but if you have no idea what you're doing, don't do it.
Terms and Definitions
NVflash / APX mode
This is the lowest level of software that can talk to an Nvidia Tegra device. Basically this is the Holy Grail of memory modification, which can even fix a damaged bootloader.
To use it, one boots the tablet with [Vol +] + [Power]. This will lead to the PC detecting an "APX" device. The screen stays blank.
This is no working solution for anything yet, as not only there is no leaked NVflash binary yet, but also the communication is encrypted via an unique 128bit AES key. This key is at no stage accessible, but can be used to encrypt data during boot. This is where the wheelie tool for previous transformers was of help. The Communication itself happens via a protocol called nv3p, which actually is open source, but as long as the key is unreachable, that's not a lot of use. NOTE: I will create an extra post with a lot more details about this.
Fastboot
The Android Bootloader.
This is the essential part of software which loads Android/a Recovery image/rooting ramfs/etc.
This is the most delicate part in the Android boot process, as fastboot is the lowest level of communication we have so far. In other words: The only way to fix a damaged bootloader would be NVflash, which is not yet available for this device.
Generally the Bootloader is locked as a method to prevent unauthorized access to data stored on the device. A locked Bootloader means no Fastboot.
Bootloader unlocking
To gain access to fastboot devices, the Bootloader needs to be unlocked. This can be as simple as installing an APK provided by the manufacturer or running "fastboot unlock".
Unlocking the Bootloader always leads to three resulting actions: Fastboot now works, all data on the device is wiped, the device's warranty is now void.
Unlocking the bootloader via unlock app can require you to have internet access and a valid google account. This can be problematic in the case of one-time-passwords, as the normal password will possibly not work (and you'll wonder why the heck it doesn't run).
Bootloader locking
This is (at least currently) not possible. Warranty void remains permanent.
RamFS
Simple file system in a file, which gets loaded into RAM. We use this for rooting.
Boot image
A file generally called "boot.img". This contains the kernel.
Recovery image
A partition image that contains a bootable linux kernel and file system, which server the purpose of creating and restoring nandroid backups and perform related tasks.
Brick - general
A device with messed up software, not being able to boot let alone perform any higher task other than being a brick.
Soft brick
A device not booting, which still responds to fastboot queries.
Hard brick / Brick
Fastboot doesn't work anymore. Maybe a visible boot loop, maybe nothing. The only point in which this differs from scrap is the ability to get into APX mode.
Chances are, there will be a way to use NVflash to fix this sometime.
Unbrick
Fixing a bricked device. Currently only soft bricked devices can be unbricked.
Root
General term for having super user abilities on a linux powered device. This can be used for reading/writing/executing restricted files, modifying things, loading custom ROMs etc.
Also having Root can mean "running with scissors", as there's not much left to prevent you from deleting important files and bricking your device.
Remember: Having Root is a very useful device, but with power comes responsibility. Also there is Android malware, which specifically targets rooted devices.
Rooting
The process of gaining Root. In early methods this generally starts with unlocking the device's Bootloader, then booting a Kernel with a purposely prepared ramfs to install and modify certain files.
As always, unlocking the Bootloader means all data will be wiped. By chance at some point someone will figure out a way to do this without unlocking.
ROM
A stock or custom Android ROM image. This contains everything needed for a running system. Custom ROMs contain tweaks, themes, improvements, styles, preloaded apps etc. Also more often than not, a load of bloat ware will be removed.
Bloat ware
Apps nobody needs/many fail to understand what they actually do/bring new ways to crash your device/sniff your precious data/revive long fixed and forgotten security leaks/the manufacturer adds to promote sales ("hey look, we've got an app for that pre installed").
Most importantly, cannot be removed from your device without Root.
Stock
A mint Android ROM, just like what the device gets shipped with.
Guides
Rooting
Requirements: Currently none
Compatible versions: anything > 10.14.1.47
Method: Booting custom Kernel and ramfs
Status: Proven
Link: http://forum.xda-developers.com/showthread.php?t=2516215
Recovery
Creator: Drgravy
Version: 6.0.3.7
Status: Abandoned but functional
Requirements: Bootloader <= 10.14.1.47 (this will not work with 10.26.1.7. Trying to do so will not work, but still boot Android as usual.)
Link: http://forum.xda-developers.com/showthread.php?t=2524401
Recovery
Creator: lpdunwell
Version: 6.0.4.5
Status: Experimental, WIP
Requirements: Bootloader >= 10.26.1.7
Link: http://forum.xda-developers.com/showthread.php?t=2556944
Various information
Hardware assembly date
On the box, rear side label.
Partition information / Unbricking
Link: http://forum.xda-developers.com/showthread.php?t=2546941
Keyboard key remapping
The physical keyboard has custom keys, with functions of debatable value. Here's how to remap them to suit your needs.
Note: This also works for other ASUS Transformers.
Warning: Backup any file you attempt to edit!
Method: The keyboard mapping is described in /system/usr/keylayout/asuspec.kl. The structure is pretty straight forward.
After saving the file, reboot the device.
Code:
Key: Function: Key number: Text:
lock Delete 142 "key 142 FORWARD_DEL WAKE UNLOCK"
search ALT 217 "key 217 ALT_LEFT WAKE UNLOCK"
HDMI configuration
The HDMI resolution can be adjusted. This can be handy under certain circumstances, although results may vary.
Method: Via terminal; disable frame buffer 1, change resolution, enable frame buffer 1
Info: To get a list of valid settings, run "cat /sys/class/graphics/fb0/modes".
This will reset at reboot.
This example enforces 1920x1200 @ 59Hz, in my case to force a HP Compaq monitor to keep running (without this it'll go to sleep for whatever reason).
Code:
echo 0 > /sys/class/graphics/fb1/device/enable
echo "D:1920x1200p-59" > /sys/class/graphics/fb1/mode
echo 1 > /sys/class/graphics/fb1/device/enable
Teardown
Teardown with two images and a brief description of the process: http://forum.xda-developers.com/showthread.php?t=2564143
Q&A
Q: "I have never rooted anything before. Can you send me some fairy dust to fix my bricked tablet if anything goes wrong?"
A: No. And if you are not absolutely sure of what you're doing, there's a fair chance you'll mess it up. Been there, done that.
Q: "What are known causes of bricked TF701?"
A:
Failed upgrade
Flashing incompatible boot.img and blob
Flashing something other than blob to staging
Removal of important files after rooting
Q: "I had a quick look at your instructions for xxx and I don't understand..."
A: Tough luck.
Q: "I re-read your instructions for xxx, searched the forum and I still cannot understand..."
A: Check if there's a matching thread. If there isn't create one with a diagnostically conclusive title. Use as much detail as possible.
Final notes
I hope this helps. As always, updates will follow.
Want to see your tutorial/guide/etc. here? Send me a detailed PM with the subject "TF701 Q&A extension".
You can help making this even better!
Found a mistake or believe I'm wrong about something? Let's discuss it.
Has this helped you? Consider clicking thanks.
THANK YOU for the hack to get a forward delete on the keyboard! That has been bugging me for a year!
Works just the same on the TF700 keyboard, btw.
Ask the mod to make it sticky, then it will always be at the top of the main thread.
Sent from my superfast Asus Infinity TF701with Dock
Snah001 said:
Ask the mod to make it sticky, then it will always be at the top of the main thread.
Sent from my superfast Asus Infinity TF701with Dock
Click to expand...
Click to collapse
he is retired .... Doesnt reply to any request ...
berndblb said:
THANK YOU for the hack to get a forward delete on the keyboard! That has been bugging me for a year!
Works just the same on the TF700 keyboard, btw.
Click to expand...
Click to collapse
yeah, the keymapping crap...
I found tons of "unpack this apk, edit soandso..." but I wanted to have it changed on a lower level. the remapping should work on most if not all transformers, and be easily portable to anything that has a hardware keyboard...
Rikodu said:
he is retired .... Doesnt reply to any request ...
Click to expand...
Click to collapse
Huh? Wut?????
Considering this is the first "Q & A" post, I will sticky it.
Provided the OP updates and maintains it.
MD
I'm pretty sure the resolution hack can be improved, but it's all I needed for now...
anybody write an app for that?
Moscow Desire said:
Huh? Wut?????
Considering this is the first "Q & A" post, I will sticky it.
Provided the OP updates and maintains it.
MD
Click to expand...
Click to collapse
go for it, it's sinking...
cheers
lpdunwell said:
go for it, it's sinking...
cheers
Click to expand...
Click to collapse
Seeing if you were paying attention..... :good:
lol
Maybe you could explain where to see the build date.
As far as I know its in the serial number after the characters. But in my case (and maybe others) I can´t see a date in 160074 .
done
hard bricked tf701t
Dear lpdunwell,
I have a bricked tf701, only asus logo available and loopboot, fastboot menu is broken as well. Only APX mode working, but I could not find appropriate nvflash for my pad (s I see there is no nvflash currently available for my tab)
In your explanation about bricked device, you wrote that there is possibility to recover tf701?
Please describe what nvflash version should I use to succeed?
Thanks in advance,
stream1313
stream1313 said:
Dear lpdunwell,
I have a bricked tf701, only asus logo available and loopboot, fastboot menu is broken as well. Only APX mode working, but I could not find appropriate nvflash for my pad (s I see there is no nvflash currently available for my tab)
In your explanation about bricked device, you wrote that there is possibility to recover tf701?
Please describe what nvflash version should I use to succeed?
Thanks in advance,
stream1313
Click to expand...
Click to collapse
Sorry mate we don't have nvflash and it is too late for you now anyway If you only have access to APX you are hard bricked. Best to sell it for parts and move on.... Or if you want to revive it send it to Asus to fix at a cost or source a replacement mainboard and do it yourself.
sbdags said:
Sorry mate we don't have nvflash and it is too late for you now anyway If you only have access to APX you are hard bricked. Best to sell it for parts and move on.... Or if you want to revive it send it to Asus to fix at a cost or source a replacement mainboard and do it yourself.
Click to expand...
Click to collapse
Hi man.. Why do you think I have to forget about my toy.. It was my Christmas (New Year in Tbilisi, Georgia, opposite planet side) present to myself But it is all the lyric only
Pls explain - do you really think that for ex., several weeks / months later, smb will create the nvflash or any similar SW which will be able to fix my problem? Actually I believe that until all electronic components are ok, device is not "dead" forever... Why you so pessimistic exactly for 701 transformer tab? Pls if you have time reply me
Kind regards,
Stan
stream1313 said:
Hi man.. Why do you think I have to forget about my toy.. It was my Christmas (New Year in Tbilisi, Georgia, opposite planet side) present to myself But it is all the lyric only
Pls explain - do you really think that for ex., several weeks / months later, smb will create the nvflash or any similar SW which will be able to fix my problem? Actually I believe that until all electronic components are ok, device is not "dead" forever... Why you so pessimistic exactly for 701 transformer tab? Pls if you have time reply me
Kind regards,
Stan
Click to expand...
Click to collapse
the way nv flash works is you need to flash the special bootloader to extract your device blobs and device specific keys. As you haven't been able to do it and you CANNOT do it once you have bricked you will have no chance. How are you going to flash a bootloader that you need fastboot for?
Sorry to bring bad news but if you only have APX with no saved nv flash files (which is not yet avail for our device) then you currently have 0% chance of recovering.
sbdags said:
the way nv flash works is you need to flash the special bootloader to extract your device blobs and device specific keys. As you haven't been able to do it and you CANNOT do it once you have bricked you will have no chance. How are you going to flash a bootloader that you need fastboot for?
Sorry to bring bad news but if you only have APX with no saved nv flash files (which is not yet avail for or device) then you currently have 0% chance of recovering.
Click to expand...
Click to collapse
Thanks a lot for reply (as well as for my another, initial thread reply) I have only CWM backup of my tab, on the MD card. But I do not know, does this backup contain all needed stuff? At list, I did not found there saved nv flash or blob files. Just "blobgenerator" (462Kb) and "blobtester" (370Kb), also some system files with "nv" in the name. But I do not have Idea, does CWM saving the low level loader files, at list I was not able to recognize them there...
my apologize for too many questions as well as for my poor English - it is not my native lang
Kind regards,
Stan
stream1313 said:
Thanks a lot for reply (as well as for my another, initial thread reply) I have only CWM backup of my tab, on the MD card. But I do not know, does this backup contain all needed stuff? At list, I did not found there saved nv flash or blob files. Just "blobgenerator" (462Kb) and "blobtester" (370Kb), also some system files with "nv" in the name. But I do not have Idea, does CWM saving the low level loader files, at list I was not able to recognize them there...
my apologize for too many questions as well as for my poor English - it is not my native lang
Kind regards,
Stan
Click to expand...
Click to collapse
No having CWM backups saved won't help you as you have no way of getting to the bootloader which would then be used to open the recovery so you could restore. WIthout a working bootloader you can't proceed. NV Flash uses APX mode to restore the blobs via the wheelie binary. You haven't captured the blobs to restore and as they are encrypted to your device you can't use anyone elses.
It's a new main board or nothing I'm afraid.
sbdags said:
No having CWM backups saved won't help you as you have no way of getting to the bootloader which would then be used to open the recovery so you could restore. WIthout a working bootloader you can't proceed. NV Flash uses APX mode to restore the blobs via the wheelie binary. You haven't captured the blobs to restore and as they are encrypted to your device you can't use anyone elses.
It's a new main board or nothing I'm afraid.
Click to expand...
Click to collapse
I see, everything is clear. Thanks for your time man. But I beleive that Asus has some kind of "backdoor" for such cases, for internal usage, of course. Asus manifest about "mainboard replacement" probably just for business, normally must be some way to crack this protection. I hope somebody from Asus will share some useful info or even software for public usage... Maybe it's my dreams only, I'm realistic (I'm working as IT/IS/GSM/WCDMA, but I'm so far from programming..)
Again, thank you. Pls notify me in case of any news about K00C hack
Problems flashing CWM recovery
stream1313 said:
I see, everything is clear. Thanks for your time man. But I beleive that Asus has some kind of "backdoor" for such cases, for internal usage, of course. Asus manifest about "mainboard replacement" probably just for business, normally must be some way to crack this protection. I hope somebody from Asus will share some useful info or even software for public usage... Maybe it's my dreams only, I'm realistic (I'm working as IT/IS/GSM/WCDMA, but I'm so far from programming..)
Again, thank you. Pls notify me in case of any news about K00C hack
Click to expand...
Click to collapse
----------------------------------------------------------------------------------------
Sorry I am not yet familiar with how to ask questions.
I recently bought a TF701T having used a TF700T now for two years and before that the TF101, TF201 and TF300T.
All these tabs I installed a recovery: CWM or TWRP and flashed the best ROM I could find. Usually Cyanomod or CROMi-X.
Everything worked fine so I was very excited when I got hold of the TF701T with its incredible Q-ratings and smoothness.
Unlocking worked just fine but installing CWM just does not work: flashing with Fastboot works OK but when I boot into recovery the little green man falls down and stays there
FYI: I am on the latest BL: 10.26.1.28, so newer than the mentioned 10.26.1.18 !
Please could anyone respond ?
Regards, JOTX10 from the Netherlands.
Hey fellow xda members,i want to share an idea about how to disable the latest security check or even drm check ( in case of unlocked bootloader) .
We all know sony have a TA partition which contains certificates which are used to start the functioning of xreality/ bionz engine and noise cancellation engine. Which when we unlock the bootloader will wipe away by wiping the Ta partition or parts of it..
So after wiping it,when the phone boots the os will be doing some security checks which involves the checking of certificates and if the certificate is not available ,the os will disable certain functional parts and binaries which are responsible for starting xreality/bionz and noise cancellation. So if we are able to stop that security check or interface the returning value ( just like what xposed does) then we can possibly stop these problems .
Another point to be noted that,is we cant use any any apps or such things to stop these things. Becoz this check is one of the first things that happens when os boots. For those who have examined the logcat will always see a TA certificate check that happens at several instances especialy ,it happens when the os boots.
Now we have a similar situation before,sony's RIC policy. That too was running at boot time ,even before os boots . But we are able to disable it ( huge thanks to the cleaver developer) . So my point is... if we can analyse and kill the drm check or pass a verification true value to corresponding check via some scripts similar to " RIC killer script" , cant we possibly disable this condition?
Any discussions are welcome. And ideas and trial and error scripts are also welcome.. you dont need a particular device to check this.. as far as i know all z series ( just because i had only owned z,z1, z2, z3 so far ) have this. But the bad thing is , i dont own a sony now. Switched to edge plus for now. But once if this can be done.. i will swich back to z series again.. becoz i just love sony.
Request to Moderator:- I have created this thread here because to catch more attention for this development. But if you feel this thread belongs to some where else ( as this can be a cross platform hack) you can move to corresponding section.
Thanks all
is it worth the effort?
You can hack anything if you have the resources.
Most important are (in decreasing order):
- knowledge
- time
- determination
- documentation (preferably official - unlikely for breaking DRM)
- tools (debugger sw, maybe even special hardware for debugging ROMs)
e.g. noise cancellation
If it is "in" the software and just disabled when a certain check fails:
Then you could monitor the software in the debugger and patch the check to deliver your desired outcome each time the check runs.
This is a very simple scenario.
There are anti reverse engineering measures available that - see resources esp. point 1 - can be overcome. SONY use some of them and stacks them one over the other.
With each update of any involved component the cycle must be repeated as the crafted patch probably won't work anymore ...
DHGE said:
You can hack anything if you have the resources.
Most important are (in decreasing order):
- knowledge
- time
- determination
- documentation (preferably official - unlikely for breaking DRM)
- tools (debugger sw, maybe even special hardware for debugging ROMs)
e.g. noise cancellation
If it is "in" the software and just disabled when a certain check fails:
Then you could monitor the software in the debugger and patch the check to deliver your desired outcome each time the check runs.
This is a very simple scenario.
There are anti reverse engineering measures available that - see resources esp. point 1 - can be overcome. SONY use some of them and stacks them one over the other.
With each update of any involved component the cycle must be repeated as the crafted patch probably won't work anymore ...
Click to expand...
Click to collapse
ya , that is the case to be considered. but you know, the thing is, if we find the suitable patch once, we can make it work on future versions also. and it is 100% true that these loopholes will be patched once they got notified. that may be the exact thing happend with sony's lastest security procedures.
Sony reads our development, testing & achievements on XDA with greedy eyes.
They can learn & join us.
This to listen to their customers & improve their products.
One hand washes the other
Sent from my E6653 @ XDA Portal
Noise reduction and noise cancellation are two different things. Noise cancellation (as in audio) is not affected by unlocking the bootloader.
blakwhite said:
Noise reduction and noise cancellation are two different things. Noise cancellation (as in audio) is not affected by unlocking the bootloader.
Click to expand...
Click to collapse
DRM function hack is a pretty complex procedure. But it can be done. @jimRnor actually did it from Z - Z3, but seems it doesnt work for Z5. (Not sure about the Z3+/Z4, which doesnt even seem to exist in the world)
Please don't get excited about my example .
To clarify what I mean with stacked measures:
In the boot process the device checks the signatures of the system software. Once you patch any bit there the device does not not boot anymore. You cannot just calculate another signature since this is signed by SONY's private key. You'd have to steal it, they revoke it ...
So you have to (thanks SONY we can!) unlock the bootloader to flash a new kernel that disabled the checking (search here or on the web for DM_VERITY).
SONY have another proprietary measure: RIC (on top of DM_VERITY which is an Android/Linux feature since KitKat; universely in use since Lollipop).
Then you have SELinux...
DHGE said:
Please don't get excited about my example .
To clarify what I mean with stacked measures:
In the boot process the device checks the signatures of the system software. Once you patch any bit there the device does not not boot anymore. You cannot just calculate another signature since this is signed by SONY's private key. You'd have to steal it, they revoke it ...
So you have to (thanks SONY we can!) unlock the bootloader to flash a new kernel that disabled the checking (search here or on the web for DM_VERITY).
SONY have another proprietary measure: RIC (on top of DM_VERITY which is an Android/Linux feature since KitKat; universely in use since Lollipop).
Then you have SELinux...
Click to expand...
Click to collapse
Ya i know that, i know exactly what happens just because i have been with sony devices since 4 years.
What i said is not about altering the original signature or changing any thing from TA partition. This is about disabling the drm check. ( sure it can be disabled) and nothing happens with boot ( if something happens with boot, there is no way we can work with a device having unlocked bootloader) .
If you have checked the logcats and compared... then you can see that the drm check actualy does not stops in an unlocked bootloader. It is still fuctioning. Only difference is the values it passes to the os.
In a simple way the values will be:-
1 for locked boot loader
0 for unlocked boot loader.
So i was thinking of stopping that check... or just edit that drm check binary to pass a value 1 for any condition.
Sure these values are accepted by the os and not by kernel or partition or something else. Its just like a condition check by os..
Something like:-
If value == this
Do this ; else
Do something else...
( lol this is the badest programing condition discription ever happend on earth!!!)
So there is a 3rd possibilty too.. alter / patch system files or services.
Also the point to be noted that is, this is just all software based.. sure we cant crack an encripted signature checksum. But we can surely crack some codes..
Let's clarify some points:
- You unlock BL you lose TA partition contents.
- Although you patch the DRM check binary, the DRM keys are needed to make the stuff work so it won't matter if you return a 1.
I own a Z3 and a Z5 and I know a locked bl root method is the only way, unlocked BL voids the warranty and it will make the phone less valuable in terms of selling it, you can try to lock BL but you will never restore the TA.
But that's my opinion.
Enviado desde mi E6653 mediante Tapatalk
McQueen said:
Let's clarify some points:
- You unlock BL you lose TA partition contents.
- Although you patch the DRM check binary, the DRM keys are needed to make the stuff work so it won't matter if you return a 1.
I own a Z3 and a Z5 and I know a locked bl root method is the only way, unlocked BL voids the warranty and it will make the phone less valuable in terms of selling it, you can try to lock BL but you will never restore the TA.
But that's my opinion.
Enviado desde mi E6653 mediante Tapatalk
Click to expand...
Click to collapse
I think thats not fully correct. Because even though there is a wipe happens to TA partition , the partition itself may not be erased. And TA partition is not empty even if you unlock.. there may be still something avilable in it, like imei, mac id, or some other hardware ids ( the reason behind this guess is, beacuse of the reason that IF YOU RESTORE THE WRONG TA FROM ANOTHER SIMILAR PHONE TO YOUR TA, IT WILL HARD BRICK YOUR PHONE, THAT MAY BE BECAUSE OF SOME UNMATCHING HARDWARE ID'S.) so i guess even after the wipe happens, the kernel or the os copies something back into TA partiton on next boot. And then there is only one thing missing in TA. That is the certificates.
In case of keys... yes digital signature keys are used to decript certificate condents . ( google about digital certificate signing) . And since there will be no cretificate avilable to decript, there is no use of keys, even if it is present or not in case of unlocked bootloader. But i am thinking about the possibilites of hacking into the procedures after the certificate check happens.
Ie, it is possible that, the drm check binaries will get and return a value to os to notify it about the presence / absence of certificate. So if we can hack into that returning value .. we can possibly make the os think that, everything is still intact.
Thats the whole idea behind this. I hope u understand.
Guys check this... As i told you always... There are still people out there who can make things happen... This is all you need for now.. Start unlocking your bootloaders...
http://forum.xda-developers.com/xpe...-credentials-restore-unlocking-t3296383/page1
I ended up flashing stock rom on my phone (Realme 8i RMX3151) while using sp flash tool, apparently wiping or overwriting NVRAM in the process.
I lost the imei and googlekey attestation but managed to restore them using SN writer. However my touchscreen also became erratic and completely unusable, with the four quadrants of the screen also swapped around, and the X and Y axis swapped within them. I've requested help from the manufacturers with no result. I wonder if anyone knows what I have done and how I can fix it. My research so far leads me to think that lost the configuration/calibration data for the touchscreen, something which is no included in the downloadable stock rom. I wonder if I can somehow obtain this data file from an identical phone, either individually if I can identify it, or simply clone everything, in order to restore the required data.
I've read somewhere that I can fix this by flashing touch configuration file, not that that helps me much as I have no idea where to find it.
I'm not sure to what degree this problem, and any solution, might be device specific. I've found many threads of people in the same position, with a wide variety of phones, but no answers on how to solve it.
Does anyone have any knowledge about this issues or and pointers towards solutions?
grimlet said:
I ended up flashing stock rom on my phone (Realme 8i RMX3151) while using sp flash tool, apparently wiping or overwriting NVRAM in the process.
I lost the imei and googlekey attestation but managed to restore them using SN writer. However my touchscreen also became erratic and completely unusable, with the four quadrants of the screen also swapped around, and the X and Y axis swapped within them. I've requested help from the manufacturers with no result. I wonder if anyone knows what I have done and how I can fix it. My research so far leads me to think that lost the configuration/calibration data for the touchscreen, something which is no included in the downloadable stock rom. I wonder if I can somehow obtain this data file from an identical phone, either individually if I can identify it, or simply clone everything, in order to restore the required data.
I've read somewhere that I can fix this by flashing touch configuration file, not that that helps me much as I have no idea where to find it.
I'm not sure to what degree this problem, and any solution, might be device specific. I've found many threads of people in the same position, with a wide variety of phones, but no answers on how to solve it.
Does anyone have any knowledge about this issues or and pointers towards solutions?
Click to expand...
Click to collapse
well, you has screw your device, you will need a full back up froom ther device and install it to rewirte the partitions involved in hardware, or try to flash it using an official tool from realme