I've been running SHOstock3 for a few days to get comfortable with it. Tonight, I decided to encrypt the device. It rebooted, encrypted itself, then rebooted again and asked me for the password. For over half an hour now, it's been playing the SHOstock3 boot animation over and over again. The SAMSUNG screen doesn't show up between loops.
Is that normal behavior? Should I just give it more time?
The power button was able to turn it off. After restarting, it would ask for the password and do the same thing. I should point out that entering the wrong password would make it ask again, so it was working "properly". I decided it was toast and tried wiping it. However, it still asked for the password. Repeatedly entering the wrong password to force a wipe didn't work properly either. It still remembered that it had a password, but forgot what it was.
To fix it, I had to go back to stock Jelly Bean (flash stock Gingerbread then use Kies to upgrade; Gingerbread doesn't know about encryption). When the newly flashed Jelly Bean asked for a password, but as soon as I entered something, it rebooted. I presume that it wiped whatever encryption information was left because it rebooted properly.
I'm still trying to decide where to go from here. I keep work stuff on my phone, so encryption is fairly important to me.
I found this information regarding encryption on Android:
http://source.android.com/tech/encryption/android_crypto_implementation.html
It's for Honeycomb, but I'm going to assume that it hasn't changed significantly. It looks like all the encryption information is stored at the end of the /data partition. However, it's not part of the filesystem itself. If init can't mount /data, it assumes that it's encrypted and takes appropriate action.
As such, I would assume that completely erasing the entire /data partition would take care of it. Note that the /data partition needs to be erased, not just the filesystem. Based on what I've read, I think that the /data partition needs to be wiped/erased/formatted in such a way that the last 16KB of the partition is erased. After that, a new filesystem would need to be created to keep it from asking for a non-existent password.
So, does anyone know what the wipes actually do in recovery?
A couple of observations.
I don't think it is advisable to work at this level of the file system while making assumptions. In my view, you make two very questionable assumptions in your remarks.
I don't have any information on the workings of wipe and format in recovery. You can, however, work with eMMC blocks using Linux commands. For instance, if you use the dd command to make a copy of the data partition, you will get the whole partition, not just the file system. You could then use reverse engineering to see what is contained in the last 16 kb of the partition. This would require a skill set that is certainly way beyond me, and I suspect beyond you. You could also use dd to write to just the last 16 kb as well.
Well, at this point, I'm not really trying to find a "solution", I'm just trying to understand why it's so hard to wipe the phone after it's been encrypted. The only reliable method I've found is to put on the stock firmware, then repeatedly enter the wrong password until it wipes itself.
I was poking around in the jeboo github (SHOstock3 uses the jeboo kernel) to see if I could figure out what's going on. I found the following line in fstab.smdk4210:
Code:
/dev/block/mmcblk0p10 /data ext4 noatime,nosuid,nodev,discard,noauto_da_alloc,journal_async_commit,errors=panic wait,check,encryptable=/efs/metadata
I'm currently running stock 4.1.2 and I found the same file with that line. After doing some research, I found that the encryptable flag tells the system to allow encryption for that particular filesystem. Its argument says were to keep the encryption metadata. In this case, it's kept in /efs/metadata. That file exists on my encrypted stock JB system and the file happens to be exactly 16KB. The first part of the file is plain-text and it appears to be encryption related. After further research, I found that "footer" is an acceptable value for encryptable. In that case, it stores the metadata in the last 16KB of the partition (but the filesystem can't extend into it for obvious reasons).
Given the behavior I've seen, my guess is that if init sees /efs/metadata, it asks for the password. This would explain how wiping /data would cause the system to still remember the password. Even if you were to erase everything in /data, /efs/metadata would still exist. I also suspect that certain methods of "wiping" /data don't actually do so because they attempt a check before doing the wipe. I'm far from an Android expert, most standard methods of checking a filesystem in linux would fail if said filesystem were encrypted.
So, I think I've figured out why wiping an encrypted phone is so hard, but I still haven't figured out why SHOstock3 doesn't boot after it encrypts the phone.
Jebo knows a lot about the kernel. You could probably get into a meaningful discussion with him on encryption. I don't know if he has a chat channel of his own, but he is probably in Shoman94's chat channel quite a lot. You can find that in the OP of the SHOstock3 thread.
Related
I've seen a number of requests for this functionality and recently it became necessary for one user who had a disabled Home Key to clear cache and data without the use of ClockworkMod. I have reserached two methods to address this issue. These instructions require some familiarity of android, computer and tablet terminology and usage. Feel free to ask for clarifications in comments. Here we go...
Method I - Stock Recovery Command File
Technical: Stock Recovery command file can be used to perform a few additional functions as well as to alter the path to update files. These commands will execute with all privileges available to recovery mode.
Advantages: Very easy to use. Very little technical knowledge required. No third party software is required for use.
Prerequisites: You will need a MicroSD card formatted FAT32 and a method for transferring files from your computer to the MicroSD.
Usage:
1) Prepare a text file named "command" (no file extension) with one of the following commands on a single line. The wipe data command will wipe both data and cache. Wipe cache will wipe cache only.
--wipe_data
--wipe_cache
2) Place the file in a folder named "recovery" in the root directory of your MicroSD card.
3) From a powered down state, insert the MicroSD card into your tablet and boot into recovery by powering it on while holding down the Volume Up key.
4) Allow the command to execute completely then the tablet should reboot (this may not occur automatically depending on firmware installed).
Method II - Updater Script
Technical: The attached "Updater Scripts" perform delete commands (recursively if necessary) on the named directory or file(s). The directories are mounted automatically by the system before the script executes but it could be easily revised to include that step if necessary. The partitioning, formatting and directory structure are left untouched. Only files are deleted.
Advantages: No third party software is necessary for execution. Relatively easy to modify for more surgical precision (i.e. leaving installed apps but clearing possibly corrupted system data). Included example: "Clear Battery Stats"
Prerequisites: You will need a MicroSD card formatted FAT32 and a method for transferring files from your computer to the MicroSD.
Usage:
1) Download the attached archive (ClearData.zip) to your computer.
2) Extract the files to your computer. You should then have a folder named "recovery" (which contains a file named "command") and an additional archive named "update.zip"
3) Place the recovery folder and the update.zip in the root directory of the MicroSD card.
4) From a powered down state, insert the MicroSD card into your tablet and boot into recovery by powering it on while holding down the Volume Up key.
5) Allow the script to execute completely then reboot the tablet (this may occur automatically depending on firmware installed).
This will become handy someday.
Thanks for sharing your knowledge.
You're welcome. One quick note... the new stock recovery adds a menu simiilar to ClockworkMod. These methods will still work since the recovery folder/command file are checked first but it really isn't as necessary any more.
Need Help
Tried both methods above but either way I get to the viewsonic splash with the message "Booting recovery kernel image" in the upper left and it just stays there, stuck there, I left it for a long time to see and it never leaves that screen.
Any ideas?
Me too
I can't get into clockworkmod either. My machine is running faster. I almost hate to mess it more.
lrgche said:
Tried both methods above but either way I get to the viewsonic splash with the message "Booting recovery kernel image" in the upper left and it just stays there, stuck there, I left it for a long time to see and it never leaves that screen.
Any ideas?
Click to expand...
Click to collapse
That's an indication that you may have more serious problems. nvflash will be required. http://forum.xda-developers.com/showthread.php?t=861950
Once done you will likely need to install ClockworkMod and repartition your internal storage.
Loukoebel said:
I can't get into clockworkmod either. My machine is running faster. I almost hate to mess it more.
Click to expand...
Click to collapse
If your tablet boots properly but you can't get into CWM then it probably isn't installed properly (or at all). http://forum.xda-developers.com/showthread.php?t=865245
Keep in mind that CWM is NOT compatible with all ROMs. Make sure the developer for your chosen ROM recommends it before installing it.
Does your method in opening post have to be run from external micro sdcard?
Both methods are performed with an external MicroSD card. They will work from internal also but it is a little more difficult to get the files in place if your tablet is not booting properly.
K J Rad said:
Both methods are performed with an external MicroSD card. They will work from internal also but it is a little more difficult to get the files in place if your tablet is not booting properly.
Click to expand...
Click to collapse
so your method is a simple way to replace one of the main uses of Clockword MOD?--Plus you stay stock more or less.
That is correct. Method II can also be modified to be less intrusive (leave user apps installed) or embedded into update scripts to perform a wipe during new ROM installs.
K J Rad said:
That is correct. Method II can also be modified to be less intrusive (leave user apps installed) or embedded into update scripts to perform a wipe during new ROM installs.
Click to expand...
Click to collapse
Wipe data does what--remove the apps installed?
And the partitions?
Your post is very interesting. It implies that you have a knowledge of the g-tabs partition structure. I have played with Linux off and on for the last 10+ years. When I began, I used Slackware and when you set it up you had to manually create partition tables using fdisk. You were only required to create two - the data partition and a swap partition but it was often recommended that you create several others - one to contain the home directory to prevent users from using all the disk space (in the days of small disks) for example. It appears that there are a lot of partition on the g-tab. Up to now, I have used various wiping tools like clockwork or calkulins wipe all on faith. I would really like to know what all the partitions are and what is in them. I have used terminal to get to the root folder and tried to do an fdisk to display the partitions but try as I might everything remains hidden. It would seem that a script like yours could be adapted to do many things but I would certainly want to understand the structure a little better before I did anything. I have searched and been unable to find that information. Can you point a way for the curious to learn more about the partition structure on the g-tab?
Wish I had a direction I could point you in. What I've found so far has mostly been stumbled upon while looking for something else. What I can tell you is this...
1) When using fdisk in Android you must specify the device to look at. Try something like: fdisk /dev/block/mccblk3 That should list the current partitions as defined by CWM or whatever was used originally.
2) Within one of those partitions in the list generated above are sub-partitions holding the bootloader, system, data, etc partitions. You can see how they're described in the .cfg files in the nvflash restores that are lying about.
lsu205 said:
Wipe data does what--remove the apps installed?
Click to expand...
Click to collapse
Removes user apps and their associated data as well as system related data and settings.
K J Rad - any idea if the partition size can be set with these methods (2048 & 0) in case I can't get clockwork installed?
CodeNamePapa said:
K J Rad - any idea if the partition size can be set with these methods (2048 & 0) in case I can't get clockwork installed?
Click to expand...
Click to collapse
I'm looking for a solution to that problem. Unfortunately these methods still require the ability to get into recovery mode which likely won't work if you're having trouble getting CWM installed.
If, however, you can get into recovery... then it is theoretically possible to create a script that would accomplish that. As soon as I have one I'll be adding it to the mix ;-)
Edit: I've found something I think will work. Will do some testing tonight. It will still require access to recovery.
I wasn't sure if you saw my other post but I am seeing no partition 0 when I NVFlash with a verifypartition.
http://forum.xda-developers.com/showpost.php?p=13059520&postcount=57
I haven't yet but I will. Let's try to keep this thread on topic. Thanks.
More thoughts:
because I went w/ cyan7 is it possible i have a "bad" kernel and that the stock bekit-1105 or the roebeet-3588 files are crashing w/ the kernel in place already?
I know custom ROMs can have a custom kernel applied separately, but I have no idea whether cyan7 loads it's own kernel...
I have yet to try the nvflash_gtablet_46 version, as I see the img files w/in are different from the original 1105 .zip
Also:
read on another thread that part 2 and part 3 aren't loading for other users when doing nvflash - I did notice that it pauses, runs some stuff, then starts loading part 4 through to the last part, then success. - do part 2 and 3 run for you?
edit: I see a 4349 downgrade.zip in another thread for those who got the OTA update but want to go back to stock 3588 prior to jumping off somewhere else - I can't expect that would help me as I can't do squat w/ recovery yet, but could that possibly "reset" any bad kernel problems? - again, I'm just thinking out loud.
This is well outside the scope of this thread but I find some of what you mention interesting so I'll address it and then end any further off topic discussions.
I did not build nor have I ever used Cyan7 so I have no basis for an opinion on the matter other than this... Each ROM comes with a kernel installed so if properly done an nvflash should overwrite any "bad" kernel.
Part2 and Part3 do indeed load, they are just displayed differently than the other Parts. Just minutes ago I flashed down from Mountain Laurel (4349 based with the new bootloader and recovery) with absolutely no trouble. I can, and have, read back those partitions after an nvflash to prove that point.
The 4349 downgrade will only work for you if recovery is working. Having never used it I don't know that it would "reset" the kernel but any subsequent flashing of a new ROM image would.
I am working on a stock recovery solution for partitioning but it isn't likely to help anyone who is stuck in an APX loop. I do have some ideas on what might help for that condition but I haven't been able to get my hands on one for testing and trying to help people here is like being a consulting mechanic for a car repair that's in someone else's shop having work done on it that you're not being told about.
I'll be happy to address any further comments or questions regarding your specific issue in an appropriate thread or via PM. Thanks.
This issue was resolved by Meghd00t's new REPART.IMG file. See this post on that thread: http://forum.xda-developers.com/showpost.php?p=26060323&postcount=151cool:
I have the 8gb model Nook Tablet and (mistakenly) tried to flash CWM & CM7a to the EMMC of my tablet. At that time, there were no warnings about how the internal flash version would brick the NT8.
Now, my tablet will not boot to ANYTHING on the internal memory. I do NOT get the stock "reset" warnings - or even a flash of light. No matter how I try to boot it (with or without cable, with or without the Nook button) or how long I hold the buttons down, it still remains with a BLACK SCREEN.
However, the SDCard will boot properly.
I followed the instructions on this thread ( http://forum.xda-developers.com/showthread.php?t=1515788) precisely to reset the BootData. I did NOT receive any errors. However, it still will not boot internally.
I then tried sigmabeta's process to flash CM9 (http://forum.xda-developers.com/showthread.php?p=25661314) to the internal emmc (which is supposed to work on NT8). The flash process (via SD/CWM) went properly and I did not receive any errors. However, I still cannot get anything to boot (except my SDCards).
If I put my CM7a (bootable) SDCard (http://forum.xda-developers.com/showthread.php?t=1481826) into the NT8, it boots and runs great! Likewise meghd00t's recovery/CWM sdcard boots and runs properly.
I can do ADB & FASTBOOT and I have even done the dd to download my partitions (for backup) and then dd copies from online onto the device's partitions. Still no joy.
However, even after dd'ing a downloaded copy of p5 to the device, ADB still reports my TRUE serial number? It seems that the dd to part5 did not take?
The only other thing that I have found, that seems significant, is the fact that when I am in CWM, I cannot mount the EMMC. I can ADB/shell into the device but that did not allow me to mount the emmc either.
Any ideas how I can get this thing to boot internally? How can I force the device to mount the emmc?
Click to expand...
Click to collapse
If you have tried all the unbrick methods out there with no luck, then throw it to the wall and see it is fixes .
~ Veronica
Final "fix"
lavero.burgos said:
If you have tried all the unbrick methods out there with no luck, then throw it to the wall and see it is fixes .
~ Veronica
Click to expand...
Click to collapse
Not sure that I have tried ALL of them, that is why I am still searching. Also, people come up with new ideas that have not previously been published.
Thanks for all YOUR help. Especially the dd to fix bootdata.
Sure wish someone would come up with a solution for this problem. There seems to be quite a few of us who are looking for answers.
Sent from my Nook Tablet using XDA
I have been reading for a while and I didn’t want to the answer because the answers are already in the Dev. area. I rather have people do some research and learn to solve their own problem rather than listen to someone else that might misled to do something even worse.
NT already has a recovery in place; factory restores (eight failed boot method). Most people do not know this and try something in an environment that they are not familiar with, Ubuntu. If you are using Windows, then you can resolve it in Windows. You do not need to repartition, format, or delete partitions. I have learned that many people like to format things apparently.
The most common problem seems to be; my NT does not turn on or my nook only boot with sdcard. It is not technically true; your NT actually turns on. The backlight just doesn’t turn on because you format/replace the x-loader/bootloader. X-loader loads the bootloader. You know the bootloader work if you see the “n” logo screen. If your NT restart after the "n" logo screen, it mean bad recovery.img/boot.img.
How did this happen? You flash the wrong MLO file to your x-loader, you used an old CWM (experimental one) and formatted your sdcard or you like to format things.
How do I resolve this? First thing is to make a proper CWM sdcard, one with proper partition table. You can compile your own CWM recovery when you compile CM7. Second, flash stock 1.4.2 rom, which contain the latest x-loader, bootloader, boot, and recovery files that works on both 8GB/16GB NT. This will restore your NT to stock android gingerbread.
If you happen to format the rom partition, you need to restore it with a backup and perform the eight failed boot method. This will restore your proper rom partition data along with the stock android. It is all in my thread in the Dev. area.
If you happen to screw up your partition table, obviously this will not help you until you fix your partition table.
Existing solutions
succulent said:
I have been reading for a while and I didn’t want to the answer because the answers are already in the Dev. area. I rather have people do some research and learn to solve their own problem rather than listen to someone else that might misled to do something even worse.
NT already has a recovery in place; factory restores (eight failed boot method). Most people do not know this and try something in an environment that they are not familiar with, Ubuntu. If you are using Windows, then you can resolve it in Windows. You do not need to repartition, format, or delete partitions. I have learned that many people like to format things apparently.
The most common problem seems to be; my NT does not turn on or my nook only boot with sdcard. It is not technically true; your NT actually turns on. The backlight just doesn’t turn on because you format/replace the x-loader/bootloader. X-loader loads the bootloader. You know the bootloader work if you see the “n” logo screen. If your NT restart after the "n" logo screen, it mean bad recovery.img/boot.img.
How did this happen? You flash the wrong MLO file to your x-loader, you used an old CWM (experimental one) and formatted your sdcard or you like to format things.
How do I resolve this? First thing is to make a proper CWM sdcard, one with proper partition table. You can compile your own CWM recovery when you compile CM7. Second, flash stock 1.4.2 rom, which contain the latest x-loader, bootloader, boot, and recovery files that works on both 8GB/16GB NT. This will restore your NT to stock android gingerbread.
If you happen to format the rom partition, you need to restore it with a backup and perform the eight failed boot method. This will restore your proper rom partition data along with the stock android. It is all in my thread in the Dev. area.
If you happen to screw up your partition table, obviously this will not help you until you fix your partition table.
Click to expand...
Click to collapse
Thanks for the info. I do appreciate it and I will be trying some of your suggestions later today when I get home.
One problem (that seems to be easing up a bit) is the fact that few posters distinguish WHICH version of the NT that they are working with. The NT16 "solutions" became the NT8 "problems." It would be great if everyone posted WHICH version they have.
The other issue is (as you stated) when you follow a guide to fix an issue, it CAN mess up your device even worse that it was. Then, you have TWO issues to deal with - rather than just one as before. I am afraid that is where I am now.
One question: You mention "compiling" CWM. Are you referring to the technical term of compiling code into an executible? Or, are you simply referring to the process of putting a working image onto an SDCard? I can do the latter without issue but I have never compiled code.
I do use Ubuntu Linux so many of the Windows driver issues are moot for me. However, I do have a dual boot with XP in on the other side - just in case I need to do some Windows-only stuff.
I really appreciate the help. I am no novice but I am not a developer either. I can usually search, read, try, and work out the problems that I (and other less technical users) experience. That is what my website is all about - translating the really "tech" jargon into everyday language for non-techies to follow. But this one has stumped me (and at least a few others) for the past couple of months.
succulent said:
I have learned that many people like to format things apparently.
Click to expand...
Click to collapse
Sent from my NookTablet using Tapatalk
I've noticed this as well. People really need to do more reading before randomly selecting/flashing things.
Hi,
I used to know a way to dump a raw range of data (i.e. specifying start/end in hex address) from a block device which I used to do from data recovery days, but I can't remember what it is. I have been googling for about an hour and it's driving me nuts! Can anybody help?
FYI, I am trying to grab data from an unknown range of data on the nand layout for the Xperia Play but this is a general linux/busybox question. For details on what I'm doing check here.
Thanks so much in advance.
EDIT: Nevermind, I've discovered that the range I'm trying to read is a protected area. Mods please close if possible.
cat is more like a parser, dd is capable of dealing with raw data.
http://www.linuxquestions.org/questions/linux-newbie-8/learn-the-dd-command-362506/
http://linux.die.net/man/1/dd
Yeah I figured it would be done with dd, though I can't find any device that represents the "entire" mtd/nand - only mtd# for existing partitions exposed by the kernel. If i could find a "root mtd" device I could use skip and count parameters of dd to read what I want.
Regardless, I don't really need help with this specifically anymore - my problem seems to be specific to the Xperia Play. I am basically trying to resize the partitions (which I did previously on the X10) and I have exposed an unknown ~100MB+ that goes between userdata and cache, but I can't read or write to it at all no matter what I do.
I think what I'm trying to get is a protected area for DRM or something which I want to shift (so I can give space from cache to userdata). I/we need to make kernel or bootloader changes for the device.
Thanks for the help anyway.
I have a Samsung and Samsung is the probably the only one brand that adopt a different partition system for mtd; but remember that dd just copies everything, free space included, if with dd you are copying a filesystem with a total of 100MB and only 40MB are in use, you end up having a 100MB image file with dd.
Yeah I know it's a raw by-sector mirror/dump tool. Well what I did was edit the kernel to only create one entire partition taking the complete nand storage and then tried to dd from that, it works for a long time then once it hits this special "protected" area around ~800MB offset it spams a lot of "I/O Error" messages but doesn't fill these with zero's or anything (using conv=noerror), then once it passes the protected area it successfully dumps the rest (which is where the cache partition for the zeus would go).
OK, I have another question now. I found that this unknown 133MB has about 53MB of data in there, somewhere in the middle, which grabs fine. But the resulting file is not 133MB so I don't know the offset. Can I use dd or another tool to grab this partition while filling I/O errors with zero's? I have googled a lot and couldn't find anything.
Nevermind *facepalm* I use conv=noerror,sync. http://www.mkssoftware.com/docs/man1/dd.1.asp
Before I start, I'm aware there are great data recovery guides on this forum and elsewhere. Unfortunately, I was unable to find one pertaining to Nougat and my specific circumstances. Thank you for bearing with me.
How the Data Was Wiped
I ran "fastboot format userdata" to fix a "Decryption Unsuccessful" error message after going from LineageOS 14.1 to 15 on a Xiaomi Mi 5 Pro. Because I was in a hurry to get my phone back online, I foolishly assumed the wipe would leave /data/media intact, just like TWRP, without making sure of it. I know the assumption was wishful thinking at best and I can see the irony in then spending the rest of the day trying to undo the damage.
How the Data Was Dumped
Immediately after finishing the fastboot format, I booted back into TWRP 3.1.1-0 where I discovered the extent of the data loss. Since I hadn't flashed a ROM and didn't want to write anything else to my /data partition, I did a "adb pull /dev/block/sda14 sda14.img" on my computer over USB with my phone still in recovery. With a 128GB phone, the process took a whopping 8102.059s to finish.
How I attempted to Recover Data
I let both R-Studio 8.3 and UFS File Explorer Professional Recovery 5.23.4 scan through my dump to no avail. All they found were meaningless, small files, mostly in a .txt or .so format. I also attempted to mount the image using DiskInternals Linux Reader 2.6, but PhotoRec didn't recognise the volume.
Where do I go From Here?
Christian Weiske wrote about his attempt at recovering photos from a Galaxy S5 mini, running Marshmallow. He noted that data he pulled in Windows was broken using various commands until he tried "adb exec-out". Does the problem lie in my pulled data also being broken/incomplete, or is "fastboot format" actually capable of completely destroying more than 100GB worth of data in mere seconds on TRIM-enabled devices? If I am to do a second /data dump using a different method, I would have to do it directly to my computer as my phone doesn't have a microSD slot. I should add that, to the best of my memory, I never encrypted the storage, as I went directly from CyanogenMod to LineageOS using the experimental migration build.
To anyone who chimes in, if only to tell me that I should suck it up and stick to whatever data I have backed up and move on, I'll be most appreciative! Even more so if anyone can shed some light on modern-day Android data recovery/wiping and limitations.
I'm going thru a recovery process myself. Using a few guides. First I completed a raw dump of the whole phone w/out installing any os over the phone. I'm about to check that and see if testdisk can find something via https://roubert.name/joakim/androidfilerecovery/
In the background, I have another dump going on from https://forum.xda-developers.com/ga...de-internal-memory-data-recovery-yes-t1994705 guide. Hopefully, something comes up.
Ok, I get that boot-debug has been around for years... since android 10 for me, before that, it was variant=user, or variant=eng(ineer).
Strange how after I show boot-debug.img, magisk chooses this very path, but only after. Keeping in mind many people come here asking questions, and all those that know sit back and say nothing. Until they dont like what they see.
If you know better, and cant help, please keep your comments to yourself. This thread is intended to HELP, and is targetted toward those who CHOOSE to HELP because they CAN.
How I got su to work. Is this root? Now this is a good question. I dont want ANY overlaid system in my fone. I want to write to system like many others want to.
Not some google way of forcing us to use their mirrored online version of a locked filesystem already on my f'n.
Priority 1: I want to root my f'n without internet. Period. I do NOT want magisk using my credit. This proves we pay for magisk. I sometimes live so far from the world wide web, that offline is the only way to work. So I need to be able to root without google or THEIR employees offerings.
Priority 2: RW-able system.
So, I discover boot-debug.img for my f'n. Had it for a year, before I discovered it. Yeah, I discovered it after a year here asking, and getting NO replies that worked. Only after I'm vindicated to the naysayers 'thats been around forever...' yeah, try helping instead of useless comments.
In the end, I learned so much in such a short time. Constructive critiscism is NOT insulting. Magisk kills root in MY f'n. PERIOD. Camera does not work, location does not work, and I cant make/receive calls. But hey, it's an overlaid file system, of course it wont ALL work, I mean, I'd expect to lose a lil functionality, but disabling the GSI ability in dev options? I dont think so.. Worse, lack of adb or fastboot is produced in my f'n when using magisk, so tata magisk.
My logs actually explain all, so no more crappy adb logs. Yeah, I like simple adb, it works, or I'll MAKE it work.
Like this:
Attempt every possible method of flashing magisk according to tut's, nada. 3 different paths lead me to...?
1: The note9 recovery I found, that lopstom was kind enough to twrp for me (well appreciated) is the KEY to gaining root on my ulefone armor x5 mt6765. It turns out that the note9 recovery is actually an android 9 os, with a 'super' .img - and being android 9, the bootloader I used is an OLD bootloader, in particular, the variant=eng type. Note this, this is key.
2: With the note9 flashed to recovery I can RW system in android 10 properly, but only in twrp.
3: Discover boot-debug.img - yup, it's not quite a variant=eng build, but it does work for the following:
Flash boot-debug.img. By doing so, you get the adb root command, and the disable-verity options, way better than wiping vbmeta, which contains the 'is it rw, or ro' of every file in every partition to be mounted in their own partitions, but what most dont know, is each file mounted in it's own mountpoint also has the information contained by vbmeta, but for each seperate file. So unless you add the /null (one for system, the other for vendor) after the disable-verity...
Nah, wipe most of your directory structure, then wonder why in a RW-able system, it still dont work. Because each file in it's own mountpoint knows if the system directory SHOULD be ro or rw. That's EACH and EVERY stock file in it's OWN mountpoint, has the RW or RO inf for the system & vendor directory, ie, is system RW?
Example: Camera wont work, get it?
In the end, this is how I went about installing su.
Flashed boot-debug.img did NOT flash recovery. Flashed meefik busybox-arm64 to f'n, but did NOT install it, instead, I opened it to install it, top left, saved the busybox-arm64 and then flashed twrp, and while there, flashed the system_rw, to defeat the system_RW saying not enough space, I chose 1024, did the copy over of super_fixed, then rebooted, enabled system, THEN flashed the busybox-arm64 from twrp, and rebooted.
Results: I copied the busybox-arm64 su, from xbin to system. In order to defeat the system_RW saying not enough space, I chose 1024. Round numbers matter with system_RW, same senario as memory, so use sizes equal to how memory works. ie, 32, 64, 128, and multiples of.
Look at the adb posts in my closed thread.
With Su installed, I have to type exit TWICE to exit. without su in system, exit only needs typed once.
Now here is why I continue. I found root, but dont have the experience, but it's like this:
See all those lovely new file that end in .cel? Mine says platinum. That means I AM ROOT. By swapping out .cel files, I have all the access magisk denies me. .cel files... get on it devs... swap them out, try try try... find what I found.
I dont actually need su, but i need it for some apps. What I have proven, is that SU does NOT kill android 10_Q.
variant=user or variant=eng, is NOW dependant on .cel files, like, say, boot-debug.cel.
Have a nice discovery... I hacked googles latest offering my-cel-f
Edit: Cel files are found in the bootloader, a zero byte file, the file NAME decides what the loader can or cant do, PERIOD.
New root tools only require swapping these out, as well as a few system edits when done.
Ok, slight mistake in spelling so I'll add the following for you to 'see'..
userdebug_plat_sepolicy.cil
So it's not cel as I wrote in the first post, my point being just as valid.
Platinum clearly states there are more who's names I have yet to obtain...
Theoretically in my mind, if I swap the .cil file in the bootloader for say hypothetically:
engdebug_plat_sepolicy.cil... with the few edits seen in the android 10 notes I posted from china, the one where people say 'too much hassle' - I say, for them. Those notes show the rest of the cil files, so yeah, I got root OPTIONS to play with
Stay tuned for more scottish inventor style NOTES.
Edit: for the record: https://source.android.com/compatibility/vts/vts-on-gsi