Related
I live in Japan and after more than 6 months I have successfully and permanently rooted both my Sharp 003 SH Galapagos and the 005SH Galapagos (Softbank not Docomo). My next concern is how to SIM unlock. I have been reading the posts about hacking the nv_bin file. I have searched through all of the the files (Root FTP thank you!) but there was no such file. I am happy to send along any screenshots or data files if that helps.
Thanks in advance.
Search Sharp 003SH Root Success and Sharp 005SH Root success on Youtube for more info
Can't really help you. Don't know anything about it. But I would like to know how you ended up rooting this phone of ours.
Its not a file on the filesystem. The sim locking in these phones is in the radio image; which can be accessed when you use the custom build kernel thats in the latest rootkit (I assume thats what you are using).
See the 2ch root/ROM thread for more details, but basically it is done through ADB, manually backing up the "_modem" partition; stripping the spare/ECC bytes and then extracting the radio OS using QualcommDumpAnalyser
I have managed to extract this image, but no idea where to go from there. None of the other device info seems to apply to this (HTC, Samsung, LG, any other Android that has had its sim-lock discovered in the radio)
Advice i got from the guys on 2ch: "Qualcomm's NAND code is neither difficult, nor unique, so if you know what you are looking for its not hard"
003SH 005SH Sim unlock
Thanks very much for giving me a new direction. I'll get started on it right away and let you know how it progresses.
It just sucks that the guys who know how to unlock it are staying quiet, saying its "taboo"
FYI, stripping the Spare/ECC bytes can be done manually (i wrote a C program to do it), but there is an option in the RevSkills app to do it all for you - i recommend doing that.
Of course we face another issue once we find the actual unlock - recalculating the ECC bytes after making the change; the only way to access the radio is with raw data access.
P.S. hope you have warranty on your phones - this is very likely to brick at least one phone until we get it right
---------- Post added at 12:30 PM ---------- Previous post was at 12:24 PM ----------
In the spirit of open cooperation, here are the instructions i was given, translated and simplified
In ADB Shell, type su to get the # prompt, then:
cat /proc/mtd <Enter>
Confirm that you have the "_modem" partition available. If not, you need to reflash with the custom build kernel
Dump the image to file with the following command:
dump_image -r -D -F _modem /sdcard/backupimages/modem.img
Access this with anything as "raw dump" and all blocks will get read as ECC error, so definitely dont do this
ECC positioning is different to Linux, so take care
The following maps out how 512bytes of data and 10 bytes of ECC info are stored in a 528 byte block:
0000 - 01CF (0-463): Data
01D0 - 01D1 (464-465): Unused (0xff)
01D2 - 0201 (466-513): Data
0202 - 020B (514-523): ECC
020C - 020F (524-527): Unused (0xff)
Use RevSkills application to extract the data portions:
Menu⇒Calculators/Generators⇒Android MTD Nand remove Spare and ECC
Extract all of the Data only portions out of the raw dump, and then use QualcommDumpAnalyser to read it and split up the various parts. I did notice that i wasnt able to get the AMSS block out with QualcommDumpAnalyser - i copied that out manually by calculating the byte positions shown in QDA.
003SH bootloader key sequence?
Eternalardor,
I'd be happy to swap information. Perhaps you could shed some light on the question of the bootloader for the Sharp 003SH and 005SH? There seems to be no discernible key sequence (Power+home+Volume up etc.) to access the bootloader. I feel like I've tried them all. Can you tell me this critical piece of information?
Is a form of the USB Jig necessary to access it?
Looking forward to your response.
003SH SIM unlock
Dominik,
Here are the results of the original /proc/mtd (before rooting)
boot
cache
misc
recovery
ipl
system
persist
log
battlog
calllog
ldb
userdata
I don't see the _modem partition. Should I?
I have also included a screenshot of the results showing size. I have most of them backed up as .img files too.
FYI: .img backed up sizes. Perhaps this will help you to ponder where the _modem partition may have gone. Maybe it's been renamed?
boot 11,264KB
cache 3,072KB
misc 1,024KB
recovery 11,264KB
ipl 15,360KB
system 419,840KB
persist 30,720KB
ldb 45,056KB
userdata 405,120KB
There is no bootloader menu AFAIK. If you install the custom kernel, you will have the option of a quasi-recovery mode, by pressing the home button between 7-12 seconds after the Galapagos logo is seen (or was that the Softbank logo)
Anyway, looking at the screenshots, it seems you do not have the custom kernel.
How did you achieve root on your phone?
To do this, you need to use the "003sh_005sh_dm009sh-rootkit" from at least 5/27 (recommend _0614); which is available on the 2ch forums. This includes 2 possible ways of achieving root:
1. A modified standard kernel (boot image), which, when flashed gives you regular root access
2. A custom compiled kernel, which has full root, a bunch of power profiles, and heaps more features (inc that quasi recovery), as well as access to the "_modem" image.
Judging from your youtube videos, you speak some Japanese, so the Japanese menus in the rootkit shouldnt be much trouble.
http://www1.axfc.net/uploader/Si/so/142435
This is what i used.
Go here for help/instructions http://anago.2ch.net/test/read.cgi/android/1337845757/
And dont even think about typing in English on there, or you will be ignored and/or told to go away
This all looks familiar. I have been using the root kit (5/27) to get where I am now - step by blessed step. It was pretty straight forward BUT I have never seen the option to write to the system partition. It is in all the instructions but the only option I have with respect to the system partition is to back it up. I'm confused as to why it doesn't seem to show up for me. I am using a Japanese machine so all the characters are displayed and I can read the instructions but I can't find help anywhere as to why I don't have that particular (and critical) option. I can see a lot of new and cool options in the 6/14 release. I'm excited and would like to get it installed.
I'll let you know how it goes. Thanks for your help .... keep it coming!
And another thing
Could you explain a little more about "having" the custom kernel? Using the root kit, I wrote to the Recovery partition then the Boot partition then rebooted from the Recovery partition and all seemed well. As I said above, I have never been able to write to the System partition despite it appearing in all the instructions. I suspect that is what is holding me back from the latest and greatest custom kernel. Still, I am enjoying all the same functionality that everyone else seems to be enjoying in root. What am I missing?
Eep, you wrote to the boot partition before trying the recovery? Brave!
The steps should be:
Write image to recovery partition;
Then reboot to recovery partition (from the menu) and confirm it all works without errors.
Then write image to boot partition
And then turn off the phone, and reboot (the last part is only my instructions - you could just select "reboot to boot partition" from the menu)
You are doing this on your 005SH right? It should be the same for the 003SH, but i only have the 005SH. In the rootkit there is 2 options when you say "burn custom image":
1 カスタムビルドrootedカーネル（リカバリーキット機能付き）
2 S4080 標準rootedカーネル（簡易リカバリー機能付き）
Q 中止してメインメニューへ戻る
You must do the first one, the CUSTOM rooted kernel, to get any of the really cool features. The second option is only if you just want root access for a particular app or something. AFAIK the second option doesnt even disable MIYABI LSM, which prevents you from mounting the system dir as R/W
But either way, writing to the System dir is not important for what we are doing. You need the Custom kernel, which gives you access to the "_modem"
Edit, i just noticed in your screenshots above, you didnt even get root in ADB shell?
Type
ADB Shell<Enter>
Then type
su<enter>
The cursor should change to a #, this means root. You may get a prompt on the phone from Superuser asking you to give root access to "shell". Once you have this try the cat /proc/mtd again
jcroot003sh,
can you tell me how to root 003sh?
Use the link i provided in my previous post
http://forum.xda-developers.com/showpost.php?p=27989085&postcount=8
You can use a translator if you dont understand Japanese, but the general instructions are in the post above yours
I translated it for a friend, but that is at work, so wont be able to put it up until monday.
DominikB said:
Use the link i provided in my previous post
http://forum.xda-developers.com/showpost.php?p=27989085&postcount=8
You can use a translator if you dont understand Japanese, but the general instructions are in the post above yours
I translated it for a friend, but that is at work, so wont be able to put it up until monday.
Click to expand...
Click to collapse
Thank you for your replying. I will wait for your translated version. You are really a good person.
Progress
I have successfully found and dumped the "_modem" image. Exactly as you stated - forgot the "su" command in ADB. Thanks. The next problem is editing out the code. I am way above my head here so I will do some research before bugging you for a step-by-step for that.
Also, the bootloader worked. I didn't realize how to do it until I read the notes in the 6/14 release. I successfully put a previously dead phone back on it's feet EXACTLY to the point of my current phone simply by backing up and then restoring partitions through the bootloader. Very slick and easy.
Will get to work. I'll be in contact soon with my progress on the SIM unlock.
I have spent a bit of time looking at it, it certainly isnt easy (Certainly isnt a "lock=yes" section). I assume the actual locking portion is encrypted/compressed/or just compiled, because it would be too easy otherwise (be happy to be proven wrong). For starters, i cannot even find my IMEI number in the dump file... I think that this dump only includes the radio code, not the NV RAM which contains the IMEI and SIM Lock status. If that is the case then the solution should be to change the portion of the radio code that queries the NV RAM, so that it doesnt care if the SIM lock is supposed to be applied.
Extracting the spare/ECC bits out should be done with the RevSkills app; extracting the relevant portions, that is a bit of a cludge; QualcommDumpAnalyser can show the start/end positions, but doesnt extract the AMSS part (AFAIK thats where the code will be). You need to use a hex editor to cut that part out manually... And i am still not 100% sure what the block size is on this NAND.
Good luck!
And if there *are* any experienced hackers out there willing to help out, i can offer some monetary help (as will a few of my fellow Japanese smartphone owning friends) as this will be valuable for not just these 2 phones (there is an army of 007SH owners waiting on this unlock)
Shall we give the 007/009 a shot?
I can see mountains of the 007SH on the auction (mostly pink). Perhaps I should pick one up and take it for a spin. I am happy to try to do something to help out for all the help I am receiving.
Or perhaps the 009SH?
How hard would it be to crack the 007? The 009SH looks like it is supported in the latest release kit.
Thoughts?
Currently, the 003/005SH are going to be the easiest, because they have the custom kernel which allows access to the "_modem" image. To do it on the 007SH we need to build a custom kernel (compiled from the sources available on the ktai-dev site), and add the modem access code (this is in the src directory of the rootkit). Not impossible, but i dont have a Linux machine to compile the sources.
However i think that the code will be fairly universal. Once we find it on the 005SH we will know what we are looking for on the 007SH as well. That will make many people happy
Anyway, my 005SH is under warranty/anshin plan so i dont mind if it gets bricked (especially now that we can take nand backups).
First things first though - examining the 005SH modem image. Does anyone know whether the NAND is a 16kb or 128kb block size? Or is it something completely different?
P.S. The DM009SH is just the Disney Mobile version of the 003SH
Linux machine no problem
I have a Linux server running 24/7 so compiling the kernel is easy. Don't let that be the holdup. I'll keep working on the 003SH _modem image.
DominikB,
I can't open this site [anago.2ch.net/test/read.cgi/smartphone/1319287551/] on channel2 for free. This site had been moved to the past-log storehouse. So.... I even can't look at Japanese version for rooting 003sh. It is very helpful if you can show me the steps for rooting 003sh.
I've created a single primary Ext2 partition in my phone's external SD card but Android refuses to mount it automatically. Whenever I attempted to mount it manually it kept throwing the error "mount operation not supported on transport endpoint".
How can I mount it?
Using (SlimKat) Android 4.4.2.
EDIT: I'm now able to mount it only manually but have to specify ext4 as its filesystem -- why and will it make a difference since ext2 is non-journalled? Also, I tried adding a mount entry in /fstab.smdk4x12 but it was deleted upon reboot; does this mean no manual entries are allowed in that file and I will instead have to hack my own /init-xx.rc file to manually mount the partition at boot time?
miguelg_ said:
I've created a single primary Ext2 partition in my phone's external SD card but Android refuses to mount it automatically. Whenever I attempted to mount it manually it kept throwing the error "mount operation not supported on transport endpoint".
How can I mount it?
Using (SlimKat) Android 4.4.2.
EDIT: I'm now able to mount it only manually but have to specify ext4 as its filesystem -- why and will it make a difference since ext2 is non-journalled? Also, I tried adding a mount entry in /fstab.smdk4x12 but it was deleted upon reboot; does this mean no manual entries are allowed in that file and I will instead have to hack my own /init-xx.rc file to manually mount the partition at boot time?
Click to expand...
Click to collapse
Why not just reformat to ext4?
es0tericcha0s said:
Why not just reformat to ext4?
Click to expand...
Click to collapse
Ultimately that's what I'll need to do but was hoping to use the non-journalled ext2. Is it not supported by Android or it the case that only some versions support it (in which case, what idiocy!)?
Have to say I'm beginning to truly hate Android. They might as well build their own kernel such that Linux (and by implication UNIX) is removed from the mix for they have completely butchered this OS. I suppose this is what happens when egos larger than the world are responsible for designing software; NIH syndrome.
Answering myself: if anyone is wondering how to automount a partition at boot time, you'll have to create your own init script and place in /system/etc/init.d/.
Well, realistically, the amount of people that have any use for mounting ext2/3/4 etc partitions is a very small % of users. Most people with android phones don't even know what Linux is, much less know about different kinds of partitions and what they are used for - or have a need for it. 99% of things you would NEED to do on a phone would be covered by the fat32 and exFat types. Of course, here on XDA, you'll find plenty of posts, guides, complaints about it, etc but there's obviously a certain type of user that seeks out or finds XDA and are more inclined to know of or have use for more technical things like this.
As far as auto-mounting the script on boot, you have to be rooted with init.d enabled and not all phones have full /system RW capabilities to even add stuff like that even when rooted. This is rare, but there's some HTCs and others like that. Often times there are ways around, but just saying, it's not a universal thing.
es0tericcha0s said:
Well, realistically, the amount of people that have any use for mounting ext2/3/4 etc partitions is a very small % of users. Most people with android phones don't even know what Linux is, much less know about different kinds of partitions and what they are used for - or have a need for it. 99% of things you would NEED to do on a phone would be covered by the fat32 and exFat types. Of course, here on XDA, you'll find plenty of posts, guides, complaints about it, etc but there's obviously a certain type of user that seeks out or finds XDA and are more inclined to know of or have use for more technical things like this.
Click to expand...
Click to collapse
That doesn't excuse the fact that they've deliberately crippled the OS. As an example, the FAT filesystems don't support symbolic links, which means that if you want to move any data outside of internal storage for whatever reason, you pretty much need an extX partition. Besides, those people (the vast majority) who don't know and don't care about the internals of their devices aren't the ones creating software for said devices in the first place. We are. And so these technical aspects matter and are relevant to us, not the masses.
es0tericcha0s said:
As far as auto-mounting the script on boot, you have to be rooted with init.d enabled and not all phones have full /system RW capabilities to even add stuff like that even when rooted. This is rare, but there's some HTCs and others like that. Often times there are ways around, but just saying, it's not a universal thing.
Click to expand...
Click to collapse
Didn't know about that limitation. Can you not remount the rootfs with RW privileges? And do you mean to say that some devices don't even support init.d; if so, what mechanism do they have in place?
miguelg_ said:
That doesn't excuse the fact that they've deliberately crippled the OS. As an example, the FAT filesystems don't support symbolic links, which means that if you want to move any data outside of internal storage for whatever reason, you pretty much need an extX partition. Besides, those people (the vast majority) who don't know and don't care about the internals of their devices aren't the ones creating software for said devices in the first place. We are. And so these technical aspects matter and are relevant to us, not the masses.
Didn't know about that limitation. Can you not remount the rootfs with RW privileges? And do you mean to say that some devices don't even support init.d; if so, what mechanism do they have in place?
Click to expand...
Click to collapse
Well, cripple might be a bit of hyperbole considering it's not something most people would need. I get your point though, it is weird that it's not native since it works with Linux generally. You can link symbolically to FAT systems while rooted with something like this:
https://play.google.com/store/apps/details?id=com.devasque.fmount
And yes, the tech people are creating software for these devices, but they are made for the general public, because that's who buy 90% of these things.
Could you please clarify what you said earlier on the read-only init.d and even some devices not supporting it? Again, thanks for your input, es0tericcha0s.
miguelg_ said:
Could you please clarify what you said earlier on the read-only init.d and even some devices not supporting it? Again, thanks for your input, es0tericcha0s.
Click to expand...
Click to collapse
Sure. Most android devices, actually I can't think of any of the top of my head, don't come with native init.d support or even have init.d that is not accessible. It's just not there. It's enabled in almost all custom roms, or you can add it yourself to many stock roms via a couple different ways like this:
https://play.google.com/store/apps/details?id=com.androguide.universal.init.d
As far as the system RW issue, some phones, like many newer HTCs, have the system protected so that you can make changes to the /system while booted, no problem, but once you reboot, all the changes will get undone. Very annoying. Example:
https://www.youtube.com/watch?v=KV3YaMBnEYI
Hello everyone,
After spending what feels like the last few days searching and reading and generally driving myself into a state of absolute frustration, I thought I was ask here, because I think if it can't be answered by the XDA crowd, it probably can't be answered. I posted this question in the T-Mobile G3 Q&A forum and while it got 30+ views, no one has replied -- so I'm thinking that perhaps I needed to ask in a more general forum. My apologies if I'm breaking some sort of cross-posting rule (if so I'll remove it no problem).
The phone I'm working with is an LG D851, bootloader unlocked, rooted and currently running the latest LiquidSmooth ROM. The attempts I've made to access these partitions was done under (rooted) stock, PAC ROM, and LS. It doesn't seem to matter, though, as whatever I'm doing wrong is wrong across all of them!
Basically...I can't for the life of me figure out how to mount either /modemst1 or /modemst2 (/dev/block/mmcblk0p21 and /dev/block/mmcblk0p22, respectively).
I'm rooted (of course) and have attempted to do so via both terminal emulator and ADB Shell (both as su/root) -- neither has worked.
I have a sneaking suspicion that the problem is me, and that I can't seem to figure out the correct combination of mount options and locations to get it to work.
Either that, of I have failed to understand something about /modemst1 and /modemst2 which makes mounting them while Android is running impossible (or at least unlikely). If that's the case, is it possible to extract the contents of these directories from one of the /efs image backups that are oh-so-necessary? Or perhaps from a TWRP backup of /efs? Yes, I'm grasping at straws here, but my instincts tell me that you should be able to at least view the contents of these partitions -- and frankly I see no reason why the contents can't be extracted and explored. Or is there something I've failed to grasp there?
Can someone that actually knows what they're doing please enlighten me? I'm feeling really...well, dumb right now, because I know once I see the solution I'm going to be really humbled that my search-fu and my google-fu -- which is normally quire strong -- has failed me...and you have NO IDEA how badly it's failed me, I've literally spent hours researching this. But this time, the dragon has won.
So, XDA Brothers and Sisters...I await your enlightenment!
Thank you in advance...
Alright so I've got a h933 I used the Frankenstein method to convert to us998 and then followed the next steps to flash it with LGUP back to h933 while retaining twrp and root, and then flashed the modified (still stock) updated h933 zip to retain my twrp and root and I believe this is the point at which I lost ability to mount vendor partition (this zip also causes you to lose mobile data for whatever reason which I'm trying to fix hence my need to make a backup).
So since twrp cannot mount vendor partition I can't do a backup of everything so I'm afraid to go about trying to fix anything.
The weird part is I have done this whole thing before and I never had any issues with the vendor partition or mounting any other partitions for that matter. The reason I'm back to this stage is because I ****ed up while flashing something else and didn't retain twrp so I had to start from square one with everything stock h933.
Basically I'm just frustrated and lost here and wondering what the most logical next step would be. Is it possible to somehow gain access to this vendor partition or repair it somehow? I'm not sure why it would be unable to mount or if I need to just wipe everything clean again and start over using LGUP.
just wondering from where the vendor partition is coming from: did you apply the vendorizing script? or is this phone maybe bought used? vendor partition isn't applied by any rom zip available here, it's a single special zip with interaction from user needed. which recovery version (exact title)?
seadersn said:
just wondering from where the vendor partition is coming from: did you apply the vendorizing script? or is this phone maybe bought used? vendor partition isn't applied by any rom zip available here, it's a single special zip with interaction from user needed. which recovery version (exact title)?
Click to expand...
Click to collapse
I think he created vendor partition for some reason. But he's not flashing Treble-ized ROMs, that I'm aware of...
It's not part of the WTF instructions.
ChazzMatt said:
I think he created vendor partition for some reason. But he's not flashing Treble-ized ROMs, that I'm aware of...
It's not part of the WTF instructions.
Click to expand...
Click to collapse
Yeah I have no ****ing clue what happened man. I followed that whole thing and flashed pixel experience but it ended up not fully working so I tried a couple different kernels which also didn't work. Then I reflashed to stock kdz using LGUP and repeated the whole process but left it with just the modified stock 933 firmware that retains twrp and root but then it broke mobile data.
Upon trying the exact same process I followed before using LGUP to flash the bone stock kdz (which is why I wanted the twrp backup incase this ****ed up) it just kept timing out while flashing the system partition and ultimately hard bricked my phone. I'm going to try to have it repaired through Qualcomm mode tonight or tomorrow night.... What a ****ing disaster lol.
seadersn said:
just wondering from where the vendor partition is coming from: did you apply the vendorizing script? or is this phone maybe bought used? vendor partition isn't applied by any rom zip available here, it's a single special zip with interaction from user needed. which recovery version (exact title)?
Click to expand...
Click to collapse
@seadersn
The person who started this thread -- @Cordtus --created a vendor partition on purpose, unlike the the person in the other thread. It's two separate cases. THIS user @Cordtus created a vendor partition following a checklist on how to return to H933 from US998. The person who created that H933 checklist does not specify why they think a vendor partition is necessary, but they were just telling what they did in case it was relevant. @Cordtus followed those instructions, even though he is not flashing Treble-ized ROMs (the only reason to need a vendor partition, I am aware of).
However, I do not know HOW @Cordtus created the vendor partition. What method, a script, what?
2nd, I do not know what TWRP they are/were using.
Can the "basic" TWRP from WTF thread create vendor partitions? If it can, can the "basic" TWRP from WTF also mount vendor partitions?
Both people had trouble MOUNTING vendor partitions -- but while @Cordtus admits creating one, the other person in the other thread says they do NOT have a vendor partition, did NOT create a vendor partition -- yet TWRP thinks they do. Let's say the other person -- @Sixtte -- does have a vendor partition and just doesn't understand what he did to get it (a stretch but go with it). Do they need more advanced TWRP to MOUNT vendor partitions? Is that why they are getting the failure to mount errors?
ChazzMatt said:
@seadersn
The person who started this thread -- @Cordtus --created a vendor partition on purpose, unlike the the person in the other thread. It's two separate cases. THIS user @Cordtus created a vendor partition following a checklist on how to return to H933 from US998. The person who created that H933 checklist does not specify why they think a vendor partition is necessary, but they were just telling what they did in case it was relevant. @Cordtus followed those instructions, even though he is not flashing Treble-ized ROMs (the only reason to need a vendor partition, I am aware of).
However, I do not know HOW @Cordtus created the vendor partition. What method, a script, what?
2nd, I do not know what TWRP they are/were using.
Can the "basic" TWRP from WTF thread create vendor partitions? If it can, can the "basic" TWRP from WTF also mount vendor partitions?
Both people had trouble MOUNTING vendor partitions -- but while @Cordtus admits creating one, the other person in the other thread says they do NOT have a vendor partition, did NOT create a vendor partition -- yet TWRP thinks they do. Let's say the other person -- @Sixtte -- does have a vendor partition and just doesn't understand what he did to get it (a stretch but go with it). Do they need more advanced TWRP to MOUNT vendor partitions? Is that why they are getting the failure to mount errors?
Click to expand...
Click to collapse
Actually I forgot to mention the part where I skipped the vendor partition step of that walkthrough because another user specifically mentioned that it isn't necessary. This is why I'm so confused as to why this happened.
ChazzMatt said:
@seadersn
The person who started this thread -- @Cordtus --created a vendor partition on purpose, unlike the the person in the other thread. It's two separate cases. THIS user @Cordtus created a vendor partition following a checklist on how to return to H933 from US998. The person who created that H933 checklist does not specify why they think a vendor partition is necessary, but they were just telling what they did in case it was relevant. @Cordtus followed those instructions, even though he is not flashing Treble-ized ROMs (the only reason to need a vendor partition, I am aware of).
However, I do not know HOW @Cordtus created the vendor partition. What method, a script, what?
2nd, I do not know what TWRP they are/were using.
Can the "basic" TWRP from WTF thread create vendor partitions? If it can, can the "basic" TWRP from WTF also mount vendor partitions?
Both people had trouble MOUNTING vendor partitions -- but while @Cordtus admits creating one, the other person in the other thread says they do NOT have a vendor partition, did NOT create a vendor partition -- yet TWRP thinks they do. Let's say the other person -- @Sixtte -- does have a vendor partition and just doesn't understand what he did to get it (a stretch but go with it). Do they need more advanced TWRP to MOUNT vendor partitions? Is that why they are getting the failure to mount errors?
Click to expand...
Click to collapse
Just to update you on this, I fixed it! I installed the following version of TWRP and this resolved the issue for me: https://forum.xda-developers.com/lg-v30/development/recovery-twrp-3-2-3-0-time-date-incl-t3852402
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