ORIGINAL POST:
Hello,
this is almost a brand new phone, still no resources over the internet about how to root it.
Is anybody working on it?
Does anybody know a viable solution to effectively root BL8800 Pro without any damage?
Thanks
--------------------------------------------
ROOTING PROCEDURE WITH UBUNTU 22.04 - ONLY FOR PHONE FIRMWARE 20220617v02 (big thanks to adamfahdi)
***WARNING*** THIS IS RISKY: 1 USER REPORTED A BRICKED PHONE WITH BOOT LOOP, ALL OTHERS OK - PLEASE DO NOT CHANGE ANYTHING AND CONTROL SYSTEM VERSION THOROUGHLY
***WARNING*** THIS PROCEDURE WILL WIPE ALL YOUR PHONE CONTENTS, IT'S LIKE A FACTORY RESET, BACKUP ANYTHING YOU NEED BEFORE ACTING!
ACTIONS ON BL8800 Pro PHONE
---> activate developer menu and USB debug on BL8800 Pro
---> check "oem unlocking" in developer menu
---> check "enable USB debug" in developer menu
---> install latest magisk apk (CURRENTLY 25.2)
---> check "enable alternate sources" when installing magisk
---> connect USB cable
---> copy boot.img on phone (downloaded from https://mega.nz/file/rDIAWJaR#TOjmxZl5LdjyVur3lwqP2wgNCm19tNoLhxXioRV8n70 this is for 20220617v02 firmware ONLY!)
---> patch boot.img with magisk
---> copy patched pboot.img on PC
ACTIONS FROM UBUNTU 22.04
---> open terminal
$ sudo apt install adb fastboot
$ adb devices -l
List of devices attached
BL8800PEEAxxxxxxx unauthorized usb:3-2 transport_id:1
---> authorize PC from BL8800 Pro screen
$ adb devices -l
List of devices attached
BL8800PEEAxxxxxxx device usb:3-2 product:BL8800Pro_EEA model:BL8800Pro device:BL8800Pro transport_id:1
---> check if adb is working correctly and reboot to bootloader
$ adb shell
BL8800Pro:/ $ ls
acct bin cache d data_mirror default.prop etc init.environ.rc lost+found mnt oem proc sdcard sys system_ext apex bugreports config data debug_ramdisk dev init linkerconfig metadata odm postinstall product storage system vendor
BL8800Pro:/ $ reboot bootloader
$ fastboot devices
BL8800PEEAxxxxxxx fastboot
$ fastboot flashing unlock
---> press VolumeUP on phone to choose "Yes" <----- THIS WILL WIPE ALL YOUR PHONE CONTENTS!!!
(bootloader) Start unlock flow
OKAY [ 7.348s]
Finished. Total time: 7.348s
$ fastboot flash boot pboot.img <----- THIS MAY BRICK YOUR PHONE!!!
Sending 'boot_a' (40960 KB) OKAY [ 1.368s]
Writing 'boot_a' OKAY [ 0.177s]
Finished. Total time: 1.563s
$ fastboot reboot
EXTRA: PROCEDURE TO RUN APPS THAT DENY EXECUTION WITH ROOTED PHONE
Some sleazy apps (banking, ebay, etc.) check if you have rooted your phone and refuse to run/authenticate/etc.
This is how you can solve this, everything done from MAGISK:
activate Magisk Hide, in the "App" settings section - rename magisk app to whatever you like
activate Zygisk, in the "Magisk" setting section, then reboot
in the "Magisk" setting section, select the rogue apps you want to hide rooting from (e.g. ebay)
in Magisk modules section install "Shamiko" module downloaded from https://github.com/LSPosed/LSPosed.github.io/releases then reboot
in Magisk modules section install "Universal SafetyNet Fix" module downloaded from https://github.com/kdrag0n/safetynet-fix/releases then reboot
check in Magisk modules section that both modules are active and running
EXTRA: in order to check that safetynet fix is working, you may download "YASNAC" app from play store
ENJOY YOUR PHONE!!!
do you only want to root?
Keep in mind:
Rooting may void the manufacturer’s warranty on your device.
Rooting will block the firmware OTA updates.
Required Downloads:1)Download ADB & Fastboot files
2)Blackview USB Drivers install on your pc
3)Download Other Drivers: Mediatek VCOM Drivers or MTK USB Drivers
4)Download And Install the SP Flash tool on your computer
5)Download the latest Blackview Stock ROM and move it to the PC
Download and extract the stock ROM to your PC.
You need to extract the boot image using the MTK Droid Tool
Attach your device via USB cable and copy only the boot.img file from the extracted folder to your device storage
Launch Magisk Manager. When a popup appears asking to install Magisk, select INSTALL and choose install again.
Tap on “Patch Boot Image File”.
Navigate to internal storage and select your phone’s boot image that you transferred earlier.
Wait for a couple of seconds. Magisk will start patching the boot image.
Once the boot image has been patched, copy the “patched_boot.img” from the internal storage and replace it in the same extracted ROM folder on your PC.
To flash stock rom whit the patched image follow this
Hi, thanks for your answer.
Do these tools also work on linux?
I saw that BL8800 Pro ROM is not available on the page, is there anyother source where I can download or some tool that can make a snapshot from the phone?
I saw that MTK Droid Tool looks like windows only but I am not worried... while the USB drivers are included in linux kernel? Here running ubuntu 22.04, thanks!
Update: I just obtained two firmare files, one maked EEA (likely for Europe) with date 2022-06-17 and another one marked NEU (likely NotEUrope) with date 2022-06-10, both subversion V02 directly from Blackview customer support. This is listing of EEA version:
-rw-rw-r-- 1 1000 1000 41943040 giu 16 19:59 boot-debug.img
-rw-rw-r-- 1 1000 1000 41943040 giu 16 19:59 boot.img
drwxrwxr-x 2 1000 1000 4096 giu 16 19:59 DATABASE
-rw-rw-r-- 1 1000 1000 136976 giu 16 19:59 dpm.img
-rw-rw-r-- 1 1000 1000 148064 giu 16 19:59 dpm-verified.img
-rw-rw-r-- 1 1000 1000 8388608 giu 16 19:59 dtbo.img
-rw-rw-r-- 1 1000 1000 72960 giu 16 19:59 dtbo-verified.img
-rw-rw-r-- 1 1000 1000 2029376 giu 16 19:59 gz.img
-rw-rw-r-- 1 1000 1000 2033072 giu 16 19:59 gz-verified.img
-rw-rw-r-- 1 1000 1000 1226000 giu 16 19:59 lk.img
-rw-rw-r-- 1 1000 1000 1233392 giu 16 19:59 lk-verified.img
-rw-rw-r-- 1 1000 1000 8420336 giu 16 19:59 logo.bin
-rw-rw-r-- 1 1000 1000 8424032 giu 16 19:59 logo-verified.bin
-rw-rw-r-- 1 1000 1000 440624 giu 16 19:59 mcupm.img
-rw-rw-r-- 1 1000 1000 444320 giu 16 19:59 mcupm-verified.img
-rwxrwxr-x 1 1000 1000 64971072 giu 16 19:59 md1img.img
-rw-rw-r-- 1 1000 1000 64982208 giu 16 19:59 md1img-verified.img
-rw-rw-r-- 1 1000 1000 50656 giu 16 19:59 MT6833_Android_scatter.txt
-rw-rw-r-- 1 1000 1000 83956 giu 16 19:59 MT6833_Android_scatter.xml
-rw-rw-r-- 1 1000 1000 2080 giu 16 19:59 pi_img.img
-rw-rw-r-- 1 1000 1000 5776 giu 16 19:59 pi_img-verified.img
-rw-rw-r-- 1 1000 1000 391996 giu 16 19:59 preloader_tf929_dk_dk029_lepton_6833_r0_eea.bin
-rw-rw-r-- 1 1000 1000 428528 giu 16 19:59 scp.img
-rw-rw-r-- 1 1000 1000 435920 giu 16 19:59 scp-verified.img
-rw-rw-r-- 1 1000 1000 11088 giu 16 19:59 spmfw.img
-rw-rw-r-- 1 1000 1000 14784 giu 16 19:59 spmfw-verified.img
-rw-rw-r-- 1 1000 1000 657344 giu 16 19:59 sspm.img
-rw-rw-r-- 1 1000 1000 661040 giu 16 19:59 sspm-verified.img
-rw-r--r-- 1 1000 1000 5135711316 giu 16 19:59 super.img
-rw-rw-r-- 1 1000 1000 970240 giu 16 19:59 tee.img
-rw-rw-r-- 1 1000 1000 977632 giu 16 19:59 tee-verified.img
-rw-r--r-- 1 1000 1000 2343188 giu 16 19:59 userdata.img
-rw-rw-r-- 1 1000 1000 4096 giu 16 19:59 vbmeta.img
-rw-rw-r-- 1 1000 1000 4096 giu 16 19:59 vbmeta_system.img
-rw-rw-r-- 1 1000 1000 4096 giu 16 19:59 vbmeta_vendor.img
DATABASE/
-rw-rw-r-- 1 1000 1000 202741 giu 16 19:59 APDB_MT6853_S01__W2209
-rw-rw-r-- 1 1000 1000 20943 giu 16 19:59 APDB_MT6853_S01__W2209_ENUM
-rwxrwxr-x 1 1000 1000 11093341 giu 16 19:59 MDDB_InfoCustomAppSrcP_MT6833_S00_TF928_R0_6833_NLWCG_V0_1_9_S220505_1_unlwctg_n.EDB
-rwxrwxr-x 1 1000 1000 746087 giu 16 19:59 MDDB.META_MT6833_S00_TF928_R0_6833_NLWCG_V0_1_9_S220505_1_unlwctg_n.EDB
Is this the correct overall filesystem suitable for modifying before flashing?
Thanks
One update: trying to feed scatter.xml file to SP Flash Tool gets the complaint that "MT68 platform not supported on this version" (it's MT6833) but versions following 5.1924 don't have the field for scatter.xml file....
SO at the moment I am stopped at full adb shell to the device, but nothing much more.
Btw, in order to avoid problems I am running tests from inside a W10 VM in vitualbox inside linux.
derjaeger said:
One update: trying to feed scatter.xml file to SP Flash Tool gets the complaint that "MT68 platform not supported on this version" (it's MT6833) but versions following 5.1924 don't have the field for scatter.xml file....
SO at the moment I am stopped at full adb shell to the device, but nothing much more.
Btw, in order to avoid problems I am running tests from inside a W10 VM in vitualbox inside linux.
Click to expand...
Click to collapse
Hi.
Have you tried the Fastboot method?
I also go astray
I am looking for a way to root and I take risky actions. Perhaps I understand it all wrong, but...
I unlocked the bootloader using MTKClient. Then I wanted to create a scatter myself using MTK Droid Tool to get boot.img from the phone. Unfortunately, MTK Droid Tool did not support (I think) memory.
Would you share the boot.img file, please? I'd like to try the Fastboot method.
Thank you.
Hello
First of all, I didn't worry about unlocking bootloader as, pressing power+vol_up buttons when phone is off, already lets you enter to a factory stock bootloader with a menu an option of which can also apply patches, so it looks kinda "ready" without the need of injecting something via fastboot (which is, btw, also an option of that menu). I don't know if that applies for you too, I have a European "EEA" latest firmware version installed.
Second, as written in my previous mail, the tool didn't operate with MT68xx devices, so it couldn't therefore extract anything.
((
I think that either an updated version of that tool comes out (but 6.x versions don't have the "scatter" file field) or we could start from that full firmware that Blackview let me download. I can transfer it to you if needed, you find the file list in my other previous mail.
At the moment the basic idea would be, I think as you might have in mind, once the boot.img file is somehow extracted, patch it with magisk, transfer it to the phone and apply it though the bootloader.
Do you agree?
Pasha
@derjaeger
Thank you for your response
I think you are completely right.
I read everything again and noticed that there are only two ROM files, not this whole list, and that there is some doubt about the scatter file and how SP Flash Tool supports it.
So the new firmware has no obvious procedure to upload it and the boot.img file must first be extracted to use Magisk.
It will be best if I wait for a proven method
I will be grateful for the ROM files, they will certainly be useful. Do you have restrictions on their distribution?
Thank you and best regards.
Saper
Yes, the MT68xx platform is likely to have introduced substantial modifications to the architecture and, therefore, the extraction methods. Is anybody reading this thread aware of new tools?
About the SW, I got no restrictions at all, pls let me know in private how you would like to receive them.
Have anybody here the Stock ROM for the Blackview BL8800 Pro?
Hi, I have it, but you gotta wait up to 25th August, as I am now on holiday.
Sorry, I forgot I had the ready link from the company: https://mega.nz/file/rDIAWJaR#TOjmxZl5LdjyVur3lwqP2wgNCm19tNoLhxXioRV8n70
Please let me know if this helps you to make some progress!
WELL DONE!! i been following this threat and failed to flash the boot.img many times as it's not supported by MTk flash tool- Droid tool SP-FLASH. Been working on this for over month now!! Finally after 9 hours of work non stop got it solved i was able to flash the patched boot.img
BE AWARE!!!! ALL YOUR FILES WILL BE DELETED ----- WARRANTY VOIDED !!
Finally
DONATIONS ARE WELCOMED FOR THE HARD WORK!! CASHAPP: $adamkey99
1-Download - Install - Extract -----> Platform Tools.Zip (ADB-Fastboot) etc,, in the ZIP file
2-rename the patched boot file TO boot.img to the same folder Platform Tools
3- Boot to Recovery & connect USB
4- Choose ENTER Fastboot
5- Choose Reboot to bootloader
6- open the folder Patform Tools and open CMD
7- Type the commend "fastboot devices" letters only!! you'll see your device pop up
8- Type the commend "fastboot flashing unlock" letters only!!
9-you'll see your phone in very small letters saying choose if you want to unlock WARRANTY VODIED
10- choose yes
11- type commend "fastboot flash boot boot.img" Letters only!
12-Type commend "fastboot reboot" Letters only!!
ALL DONE
how to Gain ROOT???
SUPRIZE ME WITH DONATIONS FOR HARD WORK!! CASHAPP: $adamkey99
1-open settings and Enable Developer options
2- Download-Install Dr Fone Root on your computer HERE'S GOOD LINK TO DOWNLOAD: https://myphoneupdate.com/download-dr-fone-root/
3- connect your device via USB and select file transfer
4- Run Dr Fone Root
5- Accept-install anything might pop up on the phone screen
your phone will reboot multiple times very normal
Congratulations!!! ALL DONE
DONATIONS ARE WELCOMED FOR THE HARD WORK!! CASHAPP: $adamkey99
Hello Adam, thanks for your replies.
I am not understanding well, in the first one you talk about a patched boot.img but there's no link to it.
In the second one you talk about using a 3rd party app, but is it safe? How do you know it does not install some unwanted stuff?
So I don't understand if you rooted your phone in the 1st or 2nd way, but how is it behaving? Any slowdowns/crashes/unwanted behaviours?
Thanks
derjaeger said:
Hello Adam, thanks for your replies.
I am not understanding well, in the first one you talk about a patched boot.img but there's no link to it.
In the second one you talk about using a 3rd party app, but is it safe? How do you know it does not install some unwanted stuff?
So I don't understand if you rooted your phone in the 1st or 2nd way, but how is it behaving? Any slowdowns/crashes/unwanted behaviours?
Click to expand...
Click to collapse
Where to get the boot.img??
1- download and extract the stock room for your device using Winrar or any zipping tools : https://mega.nz/file/rDIAWJaR#TOjmxZl5LdjyVur3lwqP2wgNCm19tNoLhxXioRV8n70
2-look inside the stock room folder you just extracted there's boot.img file
3- Copy the boot.img to your device
4- lunch magisk and patch the boot.img you just moved to your device
5- copy the patched boot.img to your pc
now go follow the steps on my first comment
-------------------------------------------------------
No issues at all
Related
Very bad news.
I appear to have had an accident with /efs. Not 100% sure what I did but suspect it related to a product code change.
My SGS2 now will not show an IMEI or connect to the cell network.
I connected with /adb and saw a number of files were updated earlier today
drwxrwxr-x 5 root root 4096 Jan 1 2000 .files
drwxrwxr-x 2 radio radio 4096 Jan 1 2000 imei
-rw-rw-rw- 1 radio radio 832 Jan 1 2011 nv.log
-rw-rw-rw- 1 radio radio 1 Jan 1 2011 .nv_state
-rwx------ 1 radio radio 32 Jan 1 2011 .nv_data.bak.md5
-rwx------ 1 radio radio 2097152 Jan 1 2011 .nv_data.bak
-rwx------ 1 radio radio 32 Jan 1 2011 .nv_core.bak.md5
-rwx------ 1 radio radio 1048576 Jan 1 2011 .nv_core.bak
-rw-r--r-- 1 root root 1 Jan 1 2011 cryptprop_rebootMode
drwx------ 3 system system 4096 Jan 1 2011 dmp
-rw-r--r-- 1 system system 14 Jan 1 2011 cryptprop_persist.sys.timezone
-rw-r--r-- 1 system system 9 Jan 1 2011 cryptprop_applied_result
-rwxrwxr-- 1 radio radio 880 Jan 1 2011 redata.bin
-rw-rw-rw- 1 system system 6 Aug 12 22:43 calibration_data
-rw-rw-rw- 1 system system 256 Oct 4 15:55 edk_p
-rw-r--r-- 1 system system 3 Nov 2 01:27 cryptprop_persist.sys.language
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lockscreen.patterneverchosen
-rw-r--r-- 1 system system 6 Nov 2 15:21 cryptprop_lockscreen.password_type
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lock_pattern_visible_pattern
-rw-r--r-- 1 system system 6 Nov 2 15:21 cryptprop_lock_pattern_tactile_feedback_ena
bled
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lock_pattern_autolock
-rw-r--r-- 1 root root 3 Nov 2 21:08 cryptprop_securewipedata
-rwx------ 1 radio radio 32 Nov 3 17:44 nv_data.bin.md5
-rwx------ 1 radio radio 2097152 Nov 3 17:44 nv_data.bin
-rw-r--r-- 1 system system 0 Nov 3 18:02 cryptprop_onetimeboot
drwxrwx--x 5 radio system 4096 Nov 3 21:23 .
drwxr-xr-x 21 root root 0 Nov 3 21:58 ..
You can see the changes to nv_data.bin.md5 and nv_data.bin -- I have no idea what crptprop_onetimeboot is but it looks a little suspicious.
Firstly I have a copy of the above as
- a directory on my sdcard
- a dd'd image on my sdcard
- a file copy on my PC (!)
I also see I still have backup files, so with a lot of difficulty (fs kept going read only when trying to copy files, so I ended up renaming the old name to the new name)
ie
.nv_data.bak -> nv_data.bin
.nv_data.bak.md5 -> nv_data.bin.md5
This didn't work (still no service/no imei), so I removed(renamed) the .md5 file -- but it still doesn't work
so it now looks like
# ls -latr
ls -latr
drwxrwxr-x 5 root root 4096 Jan 1 2000 .files
drwxrwxr-x 2 radio radio 4096 Jan 1 2000 imei
-rwx------ 1 radio radio 32 Jan 1 2011 nv_data.bin.md5.orig
-rwx------ 1 radio radio 2097152 Jan 1 2011 nv_data.bin
-rw-rw-rw- 1 radio radio 832 Jan 1 2011 nv.log
-rw-rw-rw- 1 radio radio 1 Jan 1 2011 .nv_state
-rwx------ 1 radio radio 32 Jan 1 2011 .nv_core.bak.md5
-rwx------ 1 radio radio 1048576 Jan 1 2011 .nv_core.bak
-rw-r--r-- 1 root root 1 Jan 1 2011 cryptprop_rebootMode
drwx------ 3 system system 4096 Jan 1 2011 dmp
-rw-r--r-- 1 system system 14 Jan 1 2011 cryptprop_persist.sys.timezone
-rw-r--r-- 1 system system 9 Jan 1 2011 cryptprop_applied_result
-rwxrwxr-- 1 radio radio 880 Jan 1 2011 redata.bin
-rw-rw-rw- 1 system system 6 Aug 12 22:43 calibration_data
-rw-rw-rw- 1 system system 256 Oct 4 15:55 edk_p
-rw-r--r-- 1 system system 3 Nov 2 01:27 cryptprop_persist.sys.language
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lockscreen.patterneverchosen
-rw-r--r-- 1 system system 6 Nov 2 15:21 cryptprop_lockscreen.password_type
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lock_pattern_visible_pattern
-rw-r--r-- 1 system system 6 Nov 2 15:21 cryptprop_lock_pattern_tactile_feedback_ena
bled
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lock_pattern_autolock
-rw-r--r-- 1 root root 3 Nov 2 21:08 cryptprop_securewipedata
-rwx------ 1 radio radio 32 Nov 3 17:44 nv_data.bin.md5.bk
-rwx------ 1 radio radio 2097152 Nov 3 17:44 nv_data.bin.bk
-rw-rw-rw- 1 root root 0 Nov 3 20:55 p
drwxrwx--x 5 radio system 4096 Nov 3 21:48 .
-rw-r--r-- 1 system system 0 Nov 3 21:52 cryptprop_onetimeboot
drwxr-xr-x 21 root root 0 Nov 3 21:58 ..
#
[/FONT]
I DID NOT BACKUP EFS beforehand (only just learnt I need to) and know this may now be screwed, but I'm still hopeful I have the original file and just made a silly error.
I could also
- try recreating the whole fs and copying files back
- checking the prod code within the rom (but why?)
- flashing original firmware
- modifying the dd'd image *offline*, swapping the files, and dd'ing the image back
Any advice. PLEASE....
if you have a backup the easiest way I have found is to use root explorer.
go in to the /efs folder, set to read/write, mark everything and delete (not scrictly necessary simply copying over will work) but if you have been tinkering probably better.
then paste all the back up files and folders in
finally reboot (in my experience when something has gone wrong even this is not necessary)
Root explorer is worth every penny
and keep multiple backup's of your /efs on different drives
If this does not work you are screwed. The file contains your IMEI encrypted and the only way to get that restored is by returning it.
oh I just realised you are saying the back up you have is only of it in the current state?
If that's the case you are probably screwed, have you ever used any apps like nitrality or any unlocking tools? they will create copies of your efs folder on the scard in various locations. have you run a file seach on you sdcard to see if there is any copies at all?
if you have no backups of this folder then I think you will find its a return to manufacturer / sevice centre / provider issue.
I *think* I have restored the files -- and the dates look reasonable, as if they were the originals.
I've now flashed an old ROM (KE5) for good measure, but still no signal
One discrepancy I did notice is that after installing a rom there was some bootup message about csc and XEU when copying files.
My original sales code was VOD (UK vodafone). I had then run XEU firmware and just recently tried to set the sales code to XEU using a *# code. I subsequently flashed back to vodafone firmware today.
So somewhere there's a lingering reference to XEU -- this prod code incompatability could be causing the error?
I definately feel I should have the data to fix this -- after all I have the encrypted file, but am not quite sure of all the factors involved (one being "you're stuffed I know")
type *#06# this should display you IMEI number
if this does not match your IMEI from the box then you have not fixed this
if it shows all zeros or 004999010640000 then you are on a generic IMEI number
strangely when I screwed mine up and got the generic one above I was still able to use mine with a vodafone (UK) sim but not an orange on
if this is the case, and there is no efs backup prior to this you might well be screwed.
if this backup is all you have an you believe the .bak file is intact then I believe you will find solutions for deleting the primary version of the file and keeping only the backups and rebooting
the log file should give you more information on how successful this was, but if this was the result of flashing you probably overwrote both primary and backup
*#1234# is returning a reasonable CSC I9100VODKE2
Checking the nv data files, it appears
- the new ones modded today contain XEU
- the original ones contain VOD
This is consistent with what happened, so I am still confused why the renamed original files do not work, and why there's a reference to multi-csc XEU during bootup.
Some remnant of XEU?
*#06# is currently showing blank -- but those .bak files looked fine.
Annoyed and frustrated...
In that case I would try deleting nv_data.bin and nv_data.m5 and rebooting
(assuming you have copies of everything
with just nv_data.bak nv_data.bak.md5
At least with the SGS1 this would work provided those bak files are the originals but the nv.log file will tell you more after the boot.
HOWEVER the SGSII has a lot more in this folder and I do not claim to fully understand them all but if you have a back up it's worth a shot
planetf1 said:
*#1234# is returning a reasonable CSC I9100VODKE2
Checking the nv data files, it appears
- the new ones modded today contain XEU
- the original ones contain VOD
This is consistent with what happened, so I am still confused why the renamed original files do not work, and why there's a reference to multi-csc XEU during bootup.
Some remnant of XEU?
Click to expand...
Click to collapse
Took some inspiration from http://www.communityhosting.net/sgsunlock/i9000.html and decided to check permissions & recreation of md5.
md5 wasn't recreated, so no matter, I had a backup. that is restored, but I don't know if the .bak files are needed. Yet trying to create them I get:
# mv nv_data.bin.md5.orig nv_data.bin.md5
mv nv_data.bin.md5.orig nv_data.bin.md5
# cp nv_data.bin .nv_data.bak
cp nv_data.bin .nv_data.bak
cp: write error: Read-only file system
#
This isn't a space issue.
There could be another cause -- /efs/imei/mps_info.dat contains the 3 characters "XEU" even though the file is dated Jan 2011
So either
- the date has been manually fudged
OR
- the code always was XEU -- unlikely.
I'm currently working on the basis that fundamentally the IMEI is intact, that the original nv_data.bin is intact & that the phone is validating the CSC in mps_info.dat (XEU) against nv_data.bin (VOD) and failing.
Though this wouldn't explain why before the fix, with XEU in the nv_data.bin, it wasn't working
Unless the issue is the filesystem itself. could it be corrupt? Is this in fact why it switched to R/O mode each time? I've tried multiple kernels including insecure. surely they wouldn't all "protect" this fs.
But if this is the case where is fsck? maybe I need to copy the fs image to another linux box with ext4 & inspect/correct before shipping back and dd'ing
Continuing.
Found /system/bin/e2fsck -- ran this against /efs with
# /system/bin/e2fsck /dev/block/mmcblk0p1
/system/bin/e2fsck /dev/block/mmcblk0p1
e2fsck 1.41.11 (14-Mar-2010)
ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determini
ng whether /dev/block/mmcblk0p1 is mounted.
/dev/block/mmcblk0p1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found. Create<y>? y
yes
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(3202--3203) +4104
Fix<y>? yes
/dev/block/mmcblk0p1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/mmcblk0p1: 60/1280 files (1.7% non-contiguous), 2188/5120 blocks
**** >>> I NOW HAVE AN IMEI <<< ****
AND SIGNAL
LOGGED ONTO VODAFONE
WOOOHAY.
THIS HAS BEEN FUN. LOOK AND LEARN..
and seriously thanks to all the other articles and some moral support here tonight.
Going to put back proper firmware , remove dodgy kernels and GET A BIG BEER OR THREE
planetf1 said:
Continuing.
Going to put back proper firmware , remove dodgy kernels and GET A BIG BEER OR THREE
Click to expand...
Click to collapse
and make several backups of the /efs folder in its current state one would assume
Phone seems working. restoring over a HSPA connection happily, recognized voda sim.
now reinstalling titanium backup and copying down from dropbox...
The final step was restoring from titanium backup.
I had erased my sdcard -- though my backup was on dropbox.
However titanium backup is awful at copying files to/from dropbox -- as is IMO the phone when in "phone/kies" mode.
Finally I simply copied the dropbox directory back in USB debug=mass storage mode which was quick and reliable -- and then restored most items en-masse (I have a pro license).
For the record so far phone is fine - and indeed I've since run a new efs backup
The key takeaways from this are
* Backup efs and save it somewhere offline
* get titanium backup pro. it's good (better if it backed up efs too!)
* usb mass storage mode is the most reliable way for file xfer
* backup efs (again)
* don't get complacent
And of course if you do get a similar problem to mine
a) take a backup of efs with dd if=/dev/mmcXXX of=/mnt/scard/myefs.img (check name - I forget)
b) copy files you can to sdcard
c) copy both of this to a seperate pc
d) Just try running fsck (as above) - If I'd done this sooner I'd have saved hours. I should have gone with the obvious -- I've seen this on enough linux systems in the past to know what was happening but was thrown by no kernel messages.
Thanks for letting us know, might be a nice reference for future problems, especially the filesystem check.
Writing about it also helped keep me sane.giving up and hitting the beer was becoming increasingly attractive.
I do think making the warning about efs clearer would help.backup really should be a must at the earliest opportunity
Sent from my GT-I9100 using Tapatalk
Another thought.do unmount /efs before fsck
Sent from my GT-I9100 using Tapatalk
Unable to restore
I know I had a valid IMEI during the last week or so.
I have flashed several ROM's during the last month.
Last night lost IMEI
Now , no matter what I try, I can't seem to restore my IMEI. I have the fake one that ends in a bunch of zero''s
My SDCARD has a folder called EFS_BACKUP with multiple efs_xxxxxxx.tar.gz files in it. If I extract any of these and try to restore them to the /EFS folder I still have the fake IMEI number.
Please help - I didn't understand all the adb code in this post
Hi there,
/efs is fairly new to me too, to be honest it took hours of careful rooting before I gained some useful knowledge in how that area works.
-- what I would suggest before *anything else* is to copy anything you do have left in /efs. You will need to be root to do this. I found the gui root explorer type tools a bit clunky so I used the android SDK (adb is one of the tools in this package) to help. IF YOU NEED HELP WITH THIS SAY. You need to copy the files to multiple places for safety. Someone OFF your phone, ie on a PC. This is just in case things get worse. Do the same with any of those .gz backups you have. Maybe you'll need them *if* you make things worse...
If you're familiar with linux/unix systems this is all fairly easy, but if you're not it can be quite scary. For example you have to be able to write to /efs as well as list files and move them around. One wrong step and you could make things worse.
If you're unsure perhaps you could find a friend who knows *nix well to help you out. The bottom line is that you need to
a) ensure the right files are in there
b) The filesystem itself was intact
I definately suffered from b -- less sure about a.
What you need to do will depend a fair bit on what files you find in there, and what dates they are.
You said you had some backup files. Are you sure you have some from before the problem started? Can you look inside those backup files (I think winzip or similar will expand them for you). WIthout divoluging the actual contents (since you don't want to share your IMEI with anyone), is there an nv_data.bin file in there? Out of all the files it seems to be the most critical. When's it dated (mine was Jan 2011). If you cant' find that file how about .nv_data.bak - is that a good size, and again an old one.
If you have either of these -- even without anything else I think you can probably recover.
If you can get up and running with adb, a good start would be
adb shell
ls -laR /efs
Thank you very much, fsck method fixed my efs. Phone just broke it while doing nothing :/
I love you
You just saved my Galaxy S2
Yay. Brilliant news
Good evening!
I have been trying to give FreeXperia another chance after over a year, but I can't figure out where in the package is the ROM itself.
I downloaded the file FXP125-cm-9-20120616-UNOFFICIAL-es209ra-KERNEL.7z per the instructions on the development forum. This archive contains the following files:
Code:
-rw-rw-r-- 1 jp jp 152 juin 16 07:49 config.properties
drwx------ 9 jp jp 4096 juin 16 07:47 custom
drwx------ 22 jp jp 4096 juin 16 07:47 devices
drwx------ 2 jp jp 4096 juin 16 07:47 drivers
drwx------ 3 jp jp 4096 juin 16 07:48 firmwares
-rw-rw-r-- 1 jp jp 729 juin 2 14:36 FlashTool
-rw-rw-r-- 1 jp jp 144384 juin 2 14:36 FlashTool64.exe
-rw-rw-r-- 1 jp jp 3190 juin 2 14:36 FlashToolConsole
-rw-rw-r-- 1 jp jp 212992 juin 2 14:36 FlashTool.exe
drwx------ 2 jp jp 4096 juin 16 07:47 loaders
-rw-rw-r-- 1 jp jp 2183 juin 13 15:02 stderr.log
-rw-rw-r-- 1 jp jp 74905 juin 5 08:03 uninstall.exe
-rw-rw-r-- 1 jp jp 806494 juin 3 14:17 x10flasher.jar
drwx------ 8 jp jp 4096 juin 16 07:48 x10flasher_lib
Based on my previous ROM experience, there should be a .zip file in there to install from CWM or xRecovery. Looking for anything zip related in the archive yields the following result:
Code:
zip.exe
gzip.exe
ffjcext.zip
zipfs.jar
libzip.so
libzip.so
ffjcext.zip
zipfs.jar
zip.dll
ffjcext.zip
zipfs.jar
zip.dll
ffjcext.zip
zipfs.jar
I did find the kernel and was able to flash it and back to my Oodie 7.2 v3 kernel. That part is well covered. I also tried copying the whole archive to the phone and flash it from there, but it is not recognized.
Is there a different way to install this ROM?
Thanks!
Download the zip file
http://fiberupload.com/users/jerpelea/8294/FXP125_CM9.0_RC0
The file is located in es209ra. Put that on your sd card
Follow install guide:
http://forum.xda-developers.com/showpost.php?p=17998666&postcount=12446
Sent from my X10i using xda premium
Doh! It makes so much sense. Thanks!
I did it successfully this time. However, the colors are crap, WiFi does not work and the mobile data does not work either. I guess I will have to wait for another couple of weeks before trying again...
here's the fiix for data bug:
http://forum.xda-developers.com/showpost.php?p=22464715&postcount=561
for colour fix:
flash this in cwm : http://icxperia.com/championswimmer/x10-semc-es209ra/aokp/displayfix_FXP121_CM9_es209ra_CWM.zip
Thanks THElogiC! The colors are now OK. However, using the app to correct the APN issue is more difficult. I did find the .apk file on the developer website and copied it to my SD card. However, how can I install it? FXP125 does not come with a pre-installed file manager...
I am facing the same problem if I try to install a new file manager, and since I don't have data connectivity, I cannot install it from Google Play.
Is there any other way to install this .apk?
Thanks again!
---
UPDATE: I found this clever way of doing it...
http://forum.xda-developers.com/showpost.php?p=27511309&postcount=2
But it does not work either.
Code:
20/030/2012 21:30:30 - INFO - Installing ./custom/apps/HiAPN.apk
20/030/2012 21:30:30 - INFO - Installing ./custom/apps/Ghost Commander 1.41.1b5.apk
20/030/2012 21:30:30 - INFO - APK Installation finished
20/030/2012 21:30:41 - INFO - Device disconnected
And the apps still do not show in the drawer...
This is what I will be trying next:
http://forum.xda-developers.com/showpost.php?p=22600260&postcount=247
There's a way you can install apps without using file manger but using browser.
I will post link soon
Right now on mobile
Sent from my X10i
---------- Post added at 09:08 AM ---------- Previous post was at 08:52 AM ----------
here's the link:
http://forum.xda-developers.com/showthread.php?t=1695355
So..... I've been fussing with the kernel these days.
I managed to add cwm recovery just by editing initramfs.
also, I could enable init.d support
I had a repacker script that only involves original zImage and edited initramfs folder and it made my work easier.
Now, I became greedy and I wanted to add cpu governor.
If I want to do so, I 've gotta actually compile the kernel from source.
I first used this command
export ARCH=arm
export CROSS_COMPILE=/home/xxxxxxxx/arm-2009q3/bin/arm-none-eabi
make venturi_kor_defconfig #I have Korean device
make menuconfig # at the menu, i located my initramfs folder
make -j2
I've got numerous errors no matter what toolchain I used.
arm-eabi-4.4.0
arm-eabi-4.4.3
arm-eabi-4.7
arm-2009q3
arm-eabi-linaro 4.6.2
arm-eabi-linaro 4.7
all the zImages created had similar sizes as the original ones but none of them passed samsung logo (they do boot into recovery though)
4.4.3 and 4.7 didn't even make zImage so I guess that's guaranteed failure.
But Samsung's YP-GB70 Opensource zip says that I should use arm-2009q3 and when I do, it still gives me error
I use 12.04 LTS 64bit
any suggestion please? I'm dire
stylemate said:
So..... I've been fussing with the kernel these days.
I managed to add cwm recovery just by editing initramfs.
also, I could enable init.d support
I had a repacker script that only involves original zImage and edited initramfs folder and it made my work easier.
Now, I became greedy and I wanted to add cpu governor.
If I want to do so, I 've gotta actually compile the kernel from source.
I first used this command
export ARCH=arm
export CROSS_COMPILE=/home/xxxxxxxx/arm-2009q3/bin/arm-none-eabi
make venturi_kor_defconfig #I have Korean device
make menuconfig # at the menu, i located my initramfs folder
make -j2
I've got numerous errors no matter what toolchain I used.
arm-eabi-4.4.0
arm-eabi-4.4.3
arm-eabi-4.7
arm-2009q3
arm-eabi-linaro 4.6.2
arm-eabi-linaro 4.7
all the zImages created had similar sizes as the original ones but none of them passed samsung logo (they do boot into recovery though)
4.4.3 and 4.7 didn't even make zImage so I guess that's guaranteed failure.
But Samsung's YP-GB70 Opensource zip says that I should use arm-2009q3 and when I do, it still gives me error
I use 12.04 LTS 64bit
any suggestion please? I'm dire
Click to expand...
Click to collapse
Hmmm. First make sure you downloaded source for the gingerbread kernel (2.6.35) and not froyo (2.6.32) - it should also be a zip.
Second 4.4.3 is what I use, so that's quite strange. I'll need complete output to see what the problem is.
Mevordel said:
Hmmm. First make sure you downloaded source for the gingerbread kernel (2.6.35) and not froyo (2.6.32) - it should also be a zip.
Second 4.4.3 is what I use, so that's quite strange. I'll need complete output to see what the problem is.
Click to expand...
Click to collapse
Hmm sorrry for not clarifying that. I'm certain that I got Gingerbread source and it said to use G++ toolchain for EABI. Which is arm-2009q3-68
I made a mistake saying that It gave me an error. they were warnings. zImages were succesfully made along with other modules but it just doesn't boot.
btw, do you know how to fix bootloop when recovery can't locate cache partition and can't even factory reset?
stylemate said:
Hmm sorrry for not clarifying that. I'm certain that I got Gingerbread source and it said to use G++ toolchain for EABI. Which is arm-2009q3-68
I made a mistake saying that It gave me an error. they were warnings. zImages were succesfully made along with other modules but it just doesn't boot.
btw, do you know how to fix bootloop when recovery can't locate cache partition and can't even factory reset?
Click to expand...
Click to collapse
Do you have the initramfs packed into the rom because Samsung kernels have the initramfs inside them.
Sent from my Nexus 7 using Tapatalk HD
zaclimon said:
Do you have the initramfs packed into the rom because Samsung kernels have the initramfs inside them.
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
....... hmmmmmm I'm having quite hard time comprehending that....... sorry
i first extracted initramfs from zImage, (you know by using magic number like 30 37 30 37)
Then I added cwm recovery from Entropy's source.
I repacked it to modified_ramdisk.cpio
Then I tried to compile kernel by samsung's open source zip (inside there were one tar.gz for platform and another for kernel)
I used those commands at the first post, using the right toolchain that the opensource specified.
I even located my initramfs directory in the GUI section of config.
What did I do wrong?
stylemate said:
....... hmmmmmm I'm having quite hard time comprehending that....... sorry
i first extracted initramfs from zImage, (you know by using magic number like 30 37 30 37)
Then I added cwm recovery from Entropy's source.
I repacked it to modified_ramdisk.cpio
Then I tried to compile kernel by samsung's open source zip (inside there were one tar.gz for platform and another for kernel)
I used those commands at the first post, using the right toolchain that the opensource specified.
I even located my initramfs directory in the GUI section of config.
What did I do wrong?
Click to expand...
Click to collapse
Oh sorry I meant kernel instead of ROM. Hmm why don't you take an initramfs from another source or copy-paste the scripts from your device and add the cwm binaries from entropy's?
Sent from my Nexus 7 using Tapatalk HD
stylemate said:
Hmm sorrry for not clarifying that. I'm certain that I got Gingerbread source and it said to use G++ toolchain for EABI. Which is arm-2009q3-68
I made a mistake saying that It gave me an error. they were warnings. zImages were succesfully made along with other modules but it just doesn't boot.
btw, do you know how to fix bootloop when recovery can't locate cache partition and can't even factory reset?
Click to expand...
Click to collapse
stylemate said:
....... hmmmmmm I'm having quite hard time comprehending that....... sorry
i first extracted initramfs from zImage, (you know by using magic number like 30 37 30 37)
Then I added cwm recovery from Entropy's source.
I repacked it to modified_ramdisk.cpio
Then I tried to compile kernel by samsung's open source zip (inside there were one tar.gz for platform and another for kernel)
I used those commands at the first post, using the right toolchain that the opensource specified.
I even located my initramfs directory in the GUI section of config.
What did I do wrong?
Click to expand...
Click to collapse
As far as I know, you didn't do anything wrong. The issue must be somewhere in the init scripts (init.<whatever>, recovery.rc, ueventd.<whatever>). Did you copy those from Entropy's ramdisk too? Which ones?
zaclimon said:
Oh sorry I meant kernel instead of ROM. Hmm why don't you take an initramfs from another source or copy-paste the scripts from your device and add the cwm binaries from entropy's?
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
I think I'm the only one with korean SGP5 initramfs source.....
anyway, I had a repacking script which doesn't bother with compiling the actual kernel.
I could make a kernel with just CWM recovery and it worked.
But I figured out that I had to compile the actual kernel to add governor or OC stuff... so......
Mevordel said:
As far as I know, you didn't do anything wrong. The issue must be somewhere in the init scripts (init.<whatever>, recovery.rc, ueventd.<whatever>). Did you copy those from Entropy's ramdisk too? Which ones?
Click to expand...
Click to collapse
Ho Thanks for your suggestion. I didn't copy the actual files of those scripts, I looked at his commit and saw those lines changed when he was adding CWM. So I just added or replaced few lines at recovery.rc
Then I copied bunch of files in sbin, which seemed necessary for the recovery.
I copied the clockworkmod image file
Then finally i copied the recovery.fstab
to misc/
I edited recovery.fstab several times to get mount and storage work.
So I think initramfs itself has no problem....... It got me a working kernel with CWM recovery.
But it's the problem when I actually try to compile kernel from the scratch.....
stylemate said:
Ho Thanks for your suggestion. I didn't copy the actual files of those scripts, I looked at his commit and saw those lines changed when he was adding CWM. So I just added or replaced few lines at recovery.rc
Then I copied bunch of files in sbin, which seemed necessary for the recovery.
I copied the clockworkmod image file
Then finally i copied the recovery.fstab
to misc/
I edited recovery.fstab several times to get mount and storage work.
So I think initramfs itself has no problem....... It got me a working kernel with CWM recovery.
But it's the problem when I actually try to compile kernel from the scratch.....
Click to expand...
Click to collapse
When you were just modifying the initramfs, did it boot normally then?
Mevordel said:
When you were just modifying the initramfs, did it boot normally then?
Click to expand...
Click to collapse
yes. very smoothly
I used linaro tool chain 4.6.2 and also arm-eabi-4.7 both worked fine when i just modified the initramfs with a simple script.
stylemate said:
yes. very smoothly
I used linaro tool chain 4.6.2 and also arm-eabi-4.7 both worked fine when i just modified the initramfs with a simple script.
Click to expand...
Click to collapse
Can you boot into CWM and (using adb shell) give me the output of
Code:
cat /proc/cpuinfo
ls -la /
Thanks.
Mevordel said:
Can you boot into CWM and (using adb shell) give me the output of
Code:
cat /proc/cpuinfo
ls -la /
Thanks.
Click to expand...
Click to collapse
Sorry I couldn't do anything because my device was hard bricked and I fixed it today 0.0
Hope you are still around here.
I can't run adb shell with my newly compiled kernel
computer does not detect my device and i tried plugging it in and out several times, killing adb server each time.
interesting thing is that i can't mount USB storage, system, efs or anything else in CWM recovery.
Only cache partition is mounted which is strange. I used same initramfs source for both working kernel and newly compiled kernel,
but i don't know what happened during the compiling process.
I tried compiling with the original intiramfs folder (not modified one) and <3e> recovery also gave me numerous errors like can't mount where, where, where, where.
so there mustn't be a problem in both init.rc-like scripts and ultimately initramfs. It's probably the compiling process and how I set up the compilation.
Do i have to check all lines in venturi_kor_defconfig......?
oh btw, sdcard can be mounted with original ramdisk compiled kernel also, just checked it now.
stylemate said:
Sorry I couldn't do anything because my device was hard bricked and I fixed it today 0.0
Hope you are still around here.
I can't run adb shell with my newly compiled kernel
computer does not detect my device and i tried plugging it in and out several times, killing adb server each time.
interesting thing is that i can't mount USB storage, system, efs or anything else in CWM recovery.
Only cache partition is mounted which is strange. I used same initramfs source for both working kernel and newly compiled kernel,
but i don't know what happened during the compiling process.
I tried compiling with the original intiramfs folder (not modified one) and <3e> recovery also gave me numerous errors like can't mount where, where, where, where.
so there mustn't be a problem in both init.rc-like scripts and ultimately initramfs. It's probably the compiling process and how I set up the compilation.
Do i have to check all lines in venturi_kor_defconfig......?
oh btw, sdcard can be mounted with original ramdisk compiled kernel also, just checked it now.
Click to expand...
Click to collapse
I mean from CWM on your repacked-but-not-compiled kernel -- the one you said worked.
Also, which exactly zip did you download from Samsung's site? You don't need to go through the defconfig as long as you got the right one.
Third, please only compile with 4.4.3 or the one Samsung recommends. Anything newer will probably not work.
Fourth, as to partitions, they are all formatted to RFS, right? And can you run in CWM (where everything mounts and is mounted):
Code:
mount
fdisk -l /dev/block/mmcblk0
Mevordel said:
I mean from CWM on your repacked-but-not-compiled kernel -- the one you said worked.
Also, which exactly zip did you download from Samsung's site?
Third, please only compile with 4.4.3 or the one Samsung recommends. Anything newer will probably not work.
Click to expand...
Click to collapse
1st
Processor : ARMv7 Processor rev 2 (v7l)
BogoMIPS : 99.40
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc08
CPU revision : 2
Hardware : SMDKC110
Revision : 0000
Serial : 08c5603ec1690711
-rw-r--r-- 1 system system 118 Dec 25 12:19 default.prop
drwxr-xr-x 9 root root 2840 Jan 23 01:26 dev
drwxrwxr-x 1 radio system 0 Jan 23 01:26 efs
drwxr-xr-x 2 root root 0 Jan 23 01:26 emmc
lrwxrwxrwx 1 root root 11 Jan 23 01:26 etc -> /system/etc
-rwxr-xr-x 1 system system 1876 Dec 25 12:19 fota.rc
-rwxr-xr-x 1 system system 168364 Dec 25 12:27 init
-rw-r--r-- 1 system system 1677 Dec 25 12:19 init.goldfish.rc
-rwxr-xr-x 1 system system 30941 Dec 28 08:32 init.rc
-rwxr-xr-x 1 system system 30931 Dec 25 17:46 init.rc~
-rwxr-xr-x 1 system system 4489 Dec 25 12:19 init.smdkc110.rc
drwxr-xr-x 3 system system 0 Dec 25 12:19 lib
-rwxr-xr-x 1 system system 1419 Dec 25 12:19 lpm.rc
drwx------ 2 system system 0 Dec 26 16:21 misc
drwxrwxr-x 3 root root 0 Jan 23 01:26 mnt
drwxr-xr-x 2 root root 0 Jan 23 01:26 preload
dr-xr-xr-x 60 root root 0 Jan 1 1970 proc
-rwxr-xr-x 1 system system 410344 Dec 25 12:19 recovery
-rw-r--r-- 1 system system 2182 Dec 25 12:39 recovery.rc
drwxr-xr-x 3 system system 0 Dec 25 12:40 res
drwxr-xr-x 2 system system 0 Dec 26 16:31 sbin
drwxr-xr-x 2 root root 0 Jan 23 01:26 sdcard
drwxr-xr-x 12 root root 0 Jan 23 01:26 sys
drwxr-xr-x 1 root root 0 Jan 23 01:26 system
drwxrwxrwt 2 root root 60 Jan 23 01:26 tmp
-rw-r--r-- 1 system system 0 Dec 25 12:19 ueventd.goldfish.rc
-rw-r--r-- 1 system system 4245 Dec 25 12:19 ueventd.rc
-rwxr-xr-x 1 system system 1749 Dec 25 12:19 ueventd.smdkc110.rc
drwxrwxr-x 3 system system 0 Dec 28 08:33 vendor
init.rc~ file is the autocreated backup file that i forgot to erase
2nd
I downloaded YP-GB70-WW GB Opensource.zip
3rd
Yes I've been using the right toolchain that the readme file specified.
I have tried 4.4.3 too and many other toolchains.
4th
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
it's very normal... I had to fix this part of partition cause my partition was messed up beginning from block 12 but now it's perfect.
picture stolen from Siraki......
stylemate said:
1st
Processor : ARMv7 Processor rev 2 (v7l)
BogoMIPS : 99.40
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc08
CPU revision : 2
Hardware : SMDKC110
Revision : 0000
Serial : 08c5603ec1690711
-rw-r--r-- 1 system system 118 Dec 25 12:19 default.prop
drwxr-xr-x 9 root root 2840 Jan 23 01:26 dev
drwxrwxr-x 1 radio system 0 Jan 23 01:26 efs
drwxr-xr-x 2 root root 0 Jan 23 01:26 emmc
lrwxrwxrwx 1 root root 11 Jan 23 01:26 etc -> /system/etc
-rwxr-xr-x 1 system system 1876 Dec 25 12:19 fota.rc
-rwxr-xr-x 1 system system 168364 Dec 25 12:27 init
-rw-r--r-- 1 system system 1677 Dec 25 12:19 init.goldfish.rc
-rwxr-xr-x 1 system system 30941 Dec 28 08:32 init.rc
-rwxr-xr-x 1 system system 30931 Dec 25 17:46 init.rc~
-rwxr-xr-x 1 system system 4489 Dec 25 12:19 init.smdkc110.rc
drwxr-xr-x 3 system system 0 Dec 25 12:19 lib
-rwxr-xr-x 1 system system 1419 Dec 25 12:19 lpm.rc
drwx------ 2 system system 0 Dec 26 16:21 misc
drwxrwxr-x 3 root root 0 Jan 23 01:26 mnt
drwxr-xr-x 2 root root 0 Jan 23 01:26 preload
dr-xr-xr-x 60 root root 0 Jan 1 1970 proc
-rwxr-xr-x 1 system system 410344 Dec 25 12:19 recovery
-rw-r--r-- 1 system system 2182 Dec 25 12:39 recovery.rc
drwxr-xr-x 3 system system 0 Dec 25 12:40 res
drwxr-xr-x 2 system system 0 Dec 26 16:31 sbin
drwxr-xr-x 2 root root 0 Jan 23 01:26 sdcard
drwxr-xr-x 12 root root 0 Jan 23 01:26 sys
drwxr-xr-x 1 root root 0 Jan 23 01:26 system
drwxrwxrwt 2 root root 60 Jan 23 01:26 tmp
-rw-r--r-- 1 system system 0 Dec 25 12:19 ueventd.goldfish.rc
-rw-r--r-- 1 system system 4245 Dec 25 12:19 ueventd.rc
-rwxr-xr-x 1 system system 1749 Dec 25 12:19 ueventd.smdkc110.rc
drwxrwxr-x 3 system system 0 Dec 28 08:33 vendor
init.rc~ file is the autocreated backup file that i forgot to erase
2nd
I downloaded YP-GB70-WW GB Opensource.zip
3rd
Yes I've been using the right toolchain that the readme file specified.
I have tried 4.4.3 too and many other toolchains.
Click to expand...
Click to collapse
Thanks. I edited my post after you quoted it. But from what you posted, everything looks in order. (A minor OCD is that you should delete init.rc~, but it shouldn't make a difference.)
It's somewhat a hunch, but try downloading the "YP-G1 US" source and compiling it with venturi_kor_defconfig,
And I'm not sure, as I don't have any of the Korean devices, but isn't there a difference between YP-G70 and YP-GB70? If so, then venturi may not even be the right config.
Mevordel said:
Thanks. I edited my post after you quoted it. But from what you posted, everything looks in order. (A minor OCD is that you should delete init.rc~, but it shouldn't make a difference.)
It's somewhat a hunch, but try downloading the "YP-G1 US" source and compiling it with venturi_kor_defconfig,
And I'm not sure, as I don't have any of the Korean devices, but isn't there a difference between YP-G70 and YP-GB70? If so, then venturi may not even be the right config.
Click to expand...
Click to collapse
DMB function and Camera is the major and maybe the only difference. But That doesn't really matter.
As long as i get bootable kernel I will be fine with it. Haha
Thank you, I will try with YP-G70 later.
There are some posts on how to root the Xiaomi Redmi 9 (Galahad/Lancelot) phone, but since they have lots of "don't know" phrases (or files of unknown origin), I've managed to do the whole process from scratch.
Lancelot or Galahad
Basically, the codename for Xiaomi Redmi 9 phone is Lancelot. But when you get shell via ADB, you will see Galahad. This can cause lots of confusion because you may think that Galahad and Lancelot are two different phones. In reality they're the same phone. Moreover, the specs of the Xiaomi Redmi 9 says that the phone has a MT6769T SoC (the info comes from the phone's /proc/cpuinfo). But it looks like the official ROM, TWRP, even CPU-Z treats the phone as if it had the MT6768 SoC. So keep that in mind when you look for some info concerning the phone.
The phone was bought in Europe/Poland last year (the black Friday, 2020) from the official source. Here's some more info:
Code:
galahad:/ # getprop | grep -i model
[ro.product.model]: [M2004J19C]
[ro.product.odm.model]: [M2004J19C]
[ro.product.product.model]: [M2004J19C]
[ro.product.system.model]: [M2004J19C]
[ro.product.vendor.model]: [M2004J19C]
galahad:/ # getprop | grep -i ro.build.version.
[ro.build.version.base_os]: [Redmi/galahad_eea/galahad:10/QP1A.190711.020/V12.0.0.1.QJCEUXM:user/release-keys]
[ro.build.version.incremental]: [V12.0.1.0.QJCEUXM]
[ro.build.version.security_patch]: [2021-01-05]
galahad:/ # getprop | grep -i baseband
[gsm.version.baseband]: [MOLY.LR12A.R3.MP.V98.P75,MOLY.LR12A.R3.MP.V98.P75]
[ro.baseband]: [unknown]
[vendor.gsm.project.baseband]: [HUAQIN_Q0MP1_MT6769_SP(LWCTG_CUSTOM)]
$ fastboot getvar all
...
(bootloader) product: lancelot
...
(bootloader) version-baseband: MOLY.LR12A.R3.MP.V98.P75
(bootloader) version-bootloader: lancelot-2b1e22f-20201123162228-2021011
(bootloader) version-preloader:
(bootloader) version: 0.5
...
The bootloader unlock
Before you even start thinking of flashing the TWRP image to the Xiaomi Redmi 9 (Galahad/Lancelot) phone, you have to unlock it's bootloader first. It's a straightforward operation, but you need some proper tools to achieve that. If you're using windows, use Mi Unlock, if you're on linux, use xiaomitool. I'm a linux user so I can't help with this process those of you who use windows. If you're going to use xiaomitool, there's a bug in the current version (20.7.28 beta), and you have to patch the source yourself to make it work again. It's not hard. There's an article step by step how to do it. It's in Polish, but all the necessary commands are included so you can just ctrl+c and ctrl+v.
When you unlock the bootloader, you can flash the TWRP image, so make sure you have the following in the Developer options:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
The TWRP image
There are some prebuilt TWRP images in the wild, but I wanted source of the files, and I couldn't get any. But I've managed to target this device tree. I attached the twrp-recovery.img (64MiB) file in this post. It looks like the TWRP image built from that source has everything that's needed, so you won't really have to build it yourself. If you want to build the TWRP image yourself from the provided source, you have to go through setting up the android build environment.
Flashing the TWRP image
When you have the TWRP image, you can flash it to the Xiaomi Redmi 9 (Galahad/Lancelot) phone using fastboot. On Debian, you just install the fastboot package. To flash the TWRP image, turn off you phone, turn it on using volumeDown+power, plug the phone via USB to your desktop/laptop and issue the following command:
Code:
$ fastboot flash recovery twrp-recovery.img
Remember one thing. This flashing has only a temporary effect. When you boot the device in a normal mode, the recovery partition will be automatically regenerated and flashed by your phone. So when you issue the command above, boot to recovery via:
Code:
$ fastboot reboot recovery
After you boot into TWRP recovery, it will ask for password. This is the password that you use to unlock your phone's lock screen.
Backup the phone's flash
The temporary TWRP recovery is needed to take the backup of the whole phone's flash. The only partition that has been changed is the recovery partition. Other partitions are intact. In this way, you can backup partitions that hold IMEI, WiFi/BT MACs, and other important stuff. If something goes wrong, you can restore the phone to it's default state (after unlocking) using fastboot and the partition images.
To make the backup of the whole phone's flash, use the following command:
Code:
$ adb pull /dev/block/mmcblk0 mmcblk0.img
This command is issued from your desktop/laptop computer, and not from the phone. Of course you could just use the dd command and backup the flash to the external SD card, but my external SD was only 32G, and the phone's flash is 64G. Besides it's better to store the phone's flash on your computer for future use.
The process of taking a backup is rather slow. It took around 2h (14M/s). After it finishes, you can check whether everything with the image is OK by looking into the image using the gdisk tool:
Code:
$ adb pull /dev/block/mmcblk0 mmcblk0.img
/dev/block/mmcblk0: 1 file pulled. 14.0 MB/s (62537072640 bytes in 4266.682s)
# gdisk -l /media/Zami/mmcblk0.img
GPT fdisk (gdisk) version 1.0.7
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /media/Zami/mmcblk0.img: 122142720 sectors, 58.2 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 00000000-0000-0000-0000-000000000000
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 122142686
Partitions will be aligned on 16-sector boundaries
Total free space is 61 sectors (30.5 KiB)
Number Start (sector) End (sector) Size Code Name
1 64 131135 64.0 MiB 0700 recovery
2 131136 132159 512.0 KiB 0700 misc
3 132160 133183 512.0 KiB 0700 para
4 133184 174143 20.0 MiB 0700 expdb
5 174144 176191 1024.0 KiB 0700 frp
6 176192 192575 8.0 MiB 0700 vbmeta
7 192576 208959 8.0 MiB 0700 vbmeta_system
8 208960 225343 8.0 MiB 0700 vbmeta_vendor
9 225344 271631 22.6 MiB 0700 md_udc
10 271632 337167 32.0 MiB 0700 metadata
11 337168 402703 32.0 MiB 0700 nvcfg
12 402704 533775 64.0 MiB 0700 nvdata
13 533776 632079 48.0 MiB 0700 persist
14 632080 730383 48.0 MiB 0700 persistbak
15 730384 746767 8.0 MiB 0700 protect1
16 746768 770047 11.4 MiB 0700 protect2
17 770048 786431 8.0 MiB 0700 seccfg
18 786432 790527 2.0 MiB 0700 sec1
19 790528 796671 3.0 MiB 0700 proinfo
20 796672 797695 512.0 KiB 0700 efuse
21 797696 850943 26.0 MiB 0700 boot_para
22 850944 982015 64.0 MiB 0700 nvram
23 982016 998399 8.0 MiB 0700 logo
24 998400 1260543 128.0 MiB 0700 md1img
25 1260544 1262591 1024.0 KiB 0700 spmfw
26 1262592 1274879 6.0 MiB 0700 scp1
27 1274880 1287167 6.0 MiB 0700 scp2
28 1287168 1289215 1024.0 KiB 0700 sspm_1
29 1289216 1291263 1024.0 KiB 0700 sspm_2
30 1291264 1324031 16.0 MiB 0700 gz1
31 1324032 1356799 16.0 MiB 0700 gz2
32 1356800 1360895 2.0 MiB 0700 lk
33 1360896 1364991 2.0 MiB 0700 lk2
34 1364992 1496063 64.0 MiB 0700 boot
35 1496064 1528831 16.0 MiB 0700 dtbo
36 1528832 1539071 5.0 MiB 0700 tee1
37 1539072 1549311 5.0 MiB 0700 tee2
38 1549312 1582079 16.0 MiB 0700 gsort
39 1582080 1844223 128.0 MiB 0700 minidump
40 1844224 2630655 384.0 MiB 0700 exaid
41 2630656 4727807 1024.0 MiB 0700 cust
42 4727808 4744191 8.0 MiB 0700 devinfo
43 4744192 4767743 11.5 MiB 0700 ffu
44 4767744 19447807 7.0 GiB 0700 super
45 19447808 20332543 432.0 MiB 0700 cache
46 20332544 122021823 48.5 GiB 0700 userdata
47 122021824 122109887 43.0 MiB 0700 otp
48 122109888 122142655 16.0 MiB 0700 flashinfo
As you can see, there's the whole flash layout with all the partitions in their stock state (except for the recovery partition, of course). If something goes wrong, you can extract the individual partition by mounting the image on a linux system in the following way:
Code:
# losetup /dev/loop5 /media/Zami/mmcblk0.img
# losetup -a
/dev/loop5: [64769]:12 (/media/Zami/mmcblk0.img)
The above command uses the /dev/loop5 device to mount the image. Since the image has many partitions, the corresponding devices will be created for each partition, which looks like this:
Code:
# ls -al /dev/loop5*
brw-rw---- 1 root disk 7, 320 2021-08-29 02:54:11 /dev/loop5
brw-rw---- 1 root disk 7, 321 2021-08-29 02:54:11 /dev/loop5p1
brw-rw---- 1 root disk 7, 330 2021-08-29 02:54:11 /dev/loop5p10
brw-rw---- 1 root disk 7, 331 2021-08-29 02:54:11 /dev/loop5p11
brw-rw---- 1 root disk 7, 332 2021-08-29 02:54:11 /dev/loop5p12
brw-rw---- 1 root disk 7, 333 2021-08-29 02:54:11 /dev/loop5p13
brw-rw---- 1 root disk 7, 334 2021-08-29 02:54:11 /dev/loop5p14
brw-rw---- 1 root disk 7, 335 2021-08-29 02:54:11 /dev/loop5p15
brw-rw---- 1 root disk 7, 336 2021-08-29 02:54:11 /dev/loop5p16
brw-rw---- 1 root disk 7, 337 2021-08-29 02:54:11 /dev/loop5p17
brw-rw---- 1 root disk 7, 338 2021-08-29 02:54:11 /dev/loop5p18
brw-rw---- 1 root disk 7, 339 2021-08-29 02:54:11 /dev/loop5p19
brw-rw---- 1 root disk 7, 322 2021-08-29 02:54:11 /dev/loop5p2
brw-rw---- 1 root disk 7, 340 2021-08-29 02:54:11 /dev/loop5p20
brw-rw---- 1 root disk 7, 341 2021-08-29 02:54:11 /dev/loop5p21
brw-rw---- 1 root disk 7, 342 2021-08-29 02:54:11 /dev/loop5p22
brw-rw---- 1 root disk 7, 343 2021-08-29 02:54:11 /dev/loop5p23
brw-rw---- 1 root disk 7, 344 2021-08-29 02:54:11 /dev/loop5p24
brw-rw---- 1 root disk 7, 345 2021-08-29 02:54:11 /dev/loop5p25
brw-rw---- 1 root disk 7, 346 2021-08-29 02:54:11 /dev/loop5p26
brw-rw---- 1 root disk 7, 347 2021-08-29 02:54:11 /dev/loop5p27
brw-rw---- 1 root disk 7, 348 2021-08-29 02:54:11 /dev/loop5p28
brw-rw---- 1 root disk 7, 349 2021-08-29 02:54:11 /dev/loop5p29
brw-rw---- 1 root disk 7, 323 2021-08-29 02:54:11 /dev/loop5p3
brw-rw---- 1 root disk 7, 350 2021-08-29 02:54:11 /dev/loop5p30
brw-rw---- 1 root disk 7, 351 2021-08-29 02:54:11 /dev/loop5p31
brw-rw---- 1 root disk 7, 352 2021-08-29 02:54:11 /dev/loop5p32
brw-rw---- 1 root disk 7, 353 2021-08-29 02:54:11 /dev/loop5p33
brw-rw---- 1 root disk 7, 354 2021-08-29 02:54:11 /dev/loop5p34
brw-rw---- 1 root disk 7, 355 2021-08-29 02:54:11 /dev/loop5p35
brw-rw---- 1 root disk 7, 356 2021-08-29 02:54:11 /dev/loop5p36
brw-rw---- 1 root disk 7, 357 2021-08-29 02:54:11 /dev/loop5p37
brw-rw---- 1 root disk 7, 358 2021-08-29 02:54:11 /dev/loop5p38
brw-rw---- 1 root disk 7, 359 2021-08-29 02:54:11 /dev/loop5p39
brw-rw---- 1 root disk 7, 324 2021-08-29 02:54:11 /dev/loop5p4
brw-rw---- 1 root disk 7, 360 2021-08-29 02:54:11 /dev/loop5p40
brw-rw---- 1 root disk 7, 361 2021-08-29 02:54:11 /dev/loop5p41
brw-rw---- 1 root disk 7, 362 2021-08-29 02:54:11 /dev/loop5p42
brw-rw---- 1 root disk 7, 363 2021-08-29 02:54:11 /dev/loop5p43
brw-rw---- 1 root disk 7, 364 2021-08-29 02:54:11 /dev/loop5p44
brw-rw---- 1 root disk 7, 365 2021-08-29 02:54:11 /dev/loop5p45
brw-rw---- 1 root disk 7, 366 2021-08-29 02:54:11 /dev/loop5p46
brw-rw---- 1 root disk 7, 367 2021-08-29 02:54:11 /dev/loop5p47
brw-rw---- 1 root disk 7, 368 2021-08-29 02:54:11 /dev/loop5p48
brw-rw---- 1 root disk 7, 325 2021-08-29 02:54:11 /dev/loop5p5
brw-rw---- 1 root disk 7, 326 2021-08-29 02:54:11 /dev/loop5p6
brw-rw---- 1 root disk 7, 327 2021-08-29 02:54:11 /dev/loop5p7
brw-rw---- 1 root disk 7, 328 2021-08-29 02:54:11 /dev/loop5p8
brw-rw---- 1 root disk 7, 329 2021-08-29 02:54:11 /dev/loop5p9
To extract some partition (for instance the stock boot), use the following command:
Code:
# dd if=/dev/loop5p34 of=./34-stock-boot.img
Extracting any of the partitions from the backup creates a file that can be flashed via fastboot or directly via dd from TWRP recovery. So as long as fastboot (or TWRP recovery) works and you are able to switch to that mode, you shouldn't brick the phone for good. All the bricks should be only temporary and they go away when you flash the stock partitions to the changed ones. So pay attention what changes you commit to the phone's flash.
The Magisk app and a bootloop
To sum up, we have a backup of the phone's flash on our computer, we have flashed a temp TWRP image to the recovery partition, and we are booted in the TWRP recovery mode. Now it's time to flash Magisk and get root on our Xiaomi Redmi 9 (Galahad/Lancelot) phone.
But not so fast. If you just flashed the Magisk apk file using TWRP, you will get a bootloop. This is because of the Android Verified Boot mechanism, which still works even after you unlock the phone. You can read about this AVB mechanism more here. Basically it's all about the boot partition hashes (and possibly other partition hashes as well) which are allowed by manufacturer of the phone to be valid. So only those boot images that have valid hashes can be used in the boot process of the device. Flashing Magisk changes the boot partition, and in this way the hash of the boot partition changes. So, when you try to boot the phone after you flashed Magisk from the TWRP recovery, it will bootloop. Also you will loose access to the recovery partition, so you won't be able to revert the change you did when you flashed the Magisk app. The only way to restore the phone in such state is to flash the stock boot partition. That's why you should make the phone's whole flash backup. I include the stock boot partition here for those who didn't have the backup, but pay attention that this boot image is for Android10/MIUI12 (see the specs above), and I don't know what will happen if you use the image with different software/firmware/ROM.
Install the Magisk app
To avoid the unpleasant bootloop situation after flashing the Magisk app, you have to deactivate the AVB mechanism. You do this by flashing the stock vbmeta partition using fastboot, i.e. the following command:
Code:
# dd if=/dev/loop5p6 of=./6-stock-vbmeta.img
$ fastboot --disable-verity --disable-verification flash vbmeta 6-stock-vbmeta.img
You can proceed with flashing the Magisk app only after you disable the AVB mechanism.
If your phone restored the stock recovery, flash once again the TWRP recovery, and boot into the recovery mode. Download the most recent Magisk app, currently Magisk-v23.0.apk. Yes, I know it's an APK file, and yes, you have to flash the APK file via TWRP recovery. You're going to see some messages about repacking the stock boot and flashing it.
This is the step when the phone stops rewriting the custom recovery partition. So, after installing the Magisk app, the TWRP recovery will be persistent, and you won't have to flash it again.
After flashing the APK file, you have to boot to the phone's OS in order to finish installing Magisk (the OS part/app). You'll be prompted to do this step, so follow what it says and ultimatelly you get the Magisk installed:
SafetyNet
The next thing is to open the Magisk App. After this, check the SafetyNet. It should fail. Go to the options and "Hide the Magisk app". You also have to activate MagiskHide. After this, check the SafetyNet again. It should pass now.
So now you have the root access on your Xiaomi Redmi 9 (Galahad/Lancelot) and also it passes the SafetyNet.
This HOWTO should work for the Xiaomi Redmi 9 (Galahad/Lancelot) phones, but I'm not sure whether I forgot to mention about something. Anyways, if you have any questions, or something doesn't work, ask.
Wow,realy great guide,good written and all infos are there,not bad!!!Cheers!!!
I fixed some spelling mistakes, now it should be easier to read.
Thanks a lot for this great guide.
Small problem here though ;-)
Entering
$ fastboot reboot recovery
leads to:
fastboot: usage: unknown reboot target recovery
Looking at fastboot --help there is no such parameter. Either bootloader or emergency (the latter doesn't work)
Thanks in advance - Chris
It works just fine with my phone:
Code:
$ fastboot reboot recovery
Rebooting into recovery OKAY [ 0.001s]
Finished. Total time: 0.252s
Maybe you need a newer version of the tool?
morfikov said:
It works just fine with my phone:
Code:
$ fastboot reboot recovery
Rebooting into recovery OKAY [ 0.001s]
Finished. Total time: 0.252s
Maybe you need a newer version of the tool?
Click to expand...
Click to collapse
Thank you, morfikov - that was it. Mine was nearly 12 years old :-D
Everyone else facing this issue: latest SDK Platform Tools always under https://developer.android.com/studio/releases/platform-tools
Thanks again for your fabulous guide!
Great guide! I even managed to compile latest TWRP from the devicetree you linked. The only thing that I would add is that I had to use losetup -fP <name>.img. The "P" flag forces the loop device to display partitions and "f" just takes the first available device. As for magisk, I had to use the Didgeridoohan's MagiskHide Props Config module in order to pass CTS check. I just had to "Force BASIC key attestation" using the default value "galahad". I suspect that has to do with the fact that i'm running latest EEA rom (Android 11), other than that I use the same phone - European version bought in Poland
morfikov said:
The process of taking a backup is rather slow. It took around 2h (14M/s)
Click to expand...
Click to collapse
You might have been using a USB 2.0 port.
It is advised that you use a USB 3.x Port. Throughput here was: 146.5 MB/s. It took around 10-15 Minutes.
Maybe you want to put that advise in your guide..
Another tipp which makes the the deavtivation of the AVB mechanism and flashing the stock vbmeta partition using fastbootmuch easier, fast - and also suitable to Windows machines. It takes all together only 2-3 minutes then:
When you're in TWRP after the first flash, instead of pulling the complete image of your Redmi 9 (which is not bad at all, but the image is not loadable under Win machines), you use the means of TWRP:
In TWRP you enter the section "Backup"
There you select the storage "Micro SD card"
In the list of partitions to be backed up ONLY select "vbmeta". It's only 8 MB. (This only takes a few seconds and requires not more than 9MB on your SD card ;-) )
Then "Swipe to Backup"
After that you stay in TWRP
Then you copy the tiny backup to your adb/fastboot folder on the PC (as you're in TWRP, you have full access):
Copy from your phone the files from Redmi's "External_SD/TWRP/BACKUPS/Redmi_9/<current date/time/ID>" to your adb/fastboot folder on the PC:
vbmeta.emmc.win
vbmeta.emmc.win.sha2
(recovery.log is not needed, it only contains the console output)
Within TWRP go back to the main menu and select "Reboot" and select "Fastboot"
The Smartphone reboots into TWRP / Fastboot mode
Now from the PC you turn the the AVB mechanism off by flashing:
$ fastboot --disable-verity --disable-verification flash vbmeta vbmeta.emmc.win
Now you continue with the guide above - reflashing TWRP & booting in Recovery:
$ fastboot flash recovery twrp-recovery.img
$ fastboot reboot recovery
In TWRP back again, now flash Magisk-vXY.Z.apk and reboot to System after that (to clean Cache & Dalvik is not a bad idea).
The flash of TWRP is now permanent (can be entered anytime from device off --> Press and hold Power and Volume up buttons)
It's weird that windows still can't mount such images.
Any tip for me?
I have J19AG (lancelot at first). The problem is that I can't fix broken Google Play Protect on other roms than EEA. This phone came with EEA rom which had GPP. Then I unlocked bootloader and flashed non EEA rom. I have tried TR, ID, IN, RU fastboot roms but none worked with GPP.
Im now on ID rom and trying to fix it using Magisk modules to change props. But neither galahad or lancelot worked for Force Basic Key attestation. After changing galahad to lancelot my base_os prop is empty. Magisk CTS check is still failed.
Code:
[ro.build.version.all_codenames]: [REL]
[ro.build.version.base_os]: []
[ro.build.version.codename]: [REL]
[ro.build.version.incremental]: [V12.0.3.0.QJCIDXM]
I would suggest you to restore the phone stock state with fastboot ROM. You can find some here:
Download: MIUI 12 stable update rolling out to several Xiaomi, Redmi and POCO devices
MIUI 12 stable builds have begun rolling out to several Xiaomi, Redmi, and POCO devices. Head on over for Recovery ROM and Fastboot ROM download links!
www.xda-developers.com
No I do not want this.
I asked some certain question.
I know exactly what I'm doing and have skills for that.
My goal was to have galahad with rom other than EEA with Google Play protect on.
Currently only EEA <-> Galahad is possible. ID, TW, TR rom have no Google Play protect when unlocked or locked bootloader on galahad (Redmi 9 with NFC).
The trick is to fix Google Play protect with Magisk and TWRP. But above methods didnt work for me.
I have no knowledge on this subject, so I can't help you with this.
Hello.
I'm having a problem using the losetup command. After using
sudo losetup /dev/loop3 mmcblk0.img
and checking out the partitions created with
[I]ls -al /dev/loop3*[/I]
I only get ...
brw-rw---- 1 root disk 7, 3 d’oct. 16 10:40 /dev/loop
When checking mmcblk0.img with command
[I]gdisk -l mmcblk0.img[/I]
I get the same as you.
I understand that losetup doesn't create the partitions other than one so I can't extract anyone in particular. Am I doing something wrong. I'm using an updated Ubuntu 20.04.
Thanks for your help.
Use:
Code:
# modprobe -r loop
# modprobe loop max_part=64
morfikov said:
Use:
Code:
# modprobe -r loop
# modprobe loop max_part=64
Click to expand...
Click to collapse
After using the first command I get
modprobe: FATAL: Module loop is builtin.
The second one doesn't display anything.
Then again when using ls -al /dev/loop3* I get
brw-rw---- 1 root disk 7, 3 d’oct. 16 10:40 /dev/loop3
Then edit the kernel cmd line in grub bootloader (or whatever ubuntu is using) and add to it loop.max_part=64 and restart the system.
morfikov said:
Then edit the kernel cmd line in grub bootloader (or whatever ubuntu is using) and add to it loop.max_part=64 and restart the system.
Click to expand...
Click to collapse
Thanks again. I'm still trying. In Ubuntu it's different and after doing it it didn't work (and somehow I broke the OS and had to reinstall it).
I think I will try to do it in a virtualised Debian system.
lotiopep said:
Thanks again. I'm still trying. In Ubuntu it's different and after doing it it didn't work (and somehow I broke the OS and had to reinstall it).
I think I will try to do it in a virtualised Debian system.
Click to expand...
Click to collapse
Finally it worked! Thanks!
I bricked my phone (XT2041-1 "sofiar") by flashing an unnoficial build of TWRP 3.5.0 downloaded from a Telegram channel by doing:
$ fastboot flash recovery_a twrp-3.5.0-0-rav-sofia.img
$ fastboot flash recovery_b twrp-3.5.0-0-rav-sofia.img
$ fastboot reboot recovery
Since then, my phone is hard bricked - won't boot, recognized on Linux in EDL Mode only (i.e. ID 05c6:9008).
I got the latest official stock firmware, named SOFIAR_RETAIL_11_RPES31.Q4U-47-35-12_subsidy-DEFAULT_regulatory-DEFAULT_CFC.xml.zip, from lolinet, and in its contents there's boot.img and recovery.img (among others).
I have qdl on my Arch Linux, and am wondering whether I can use it to flash the stock recovery image back to both slots and get my phone booting again.
How should I approach it?
P.s. I also got a blankflash from https://forum.xda-developers.com/t/...equest-solicitud-blankflash-g8-power.4431193/ that is supposed to get the phone working again, but am unsure whether using it will cause loss of data.
I absolutely cannot lose any data from internal storage.
Any help appreciated. Thanks in advance.
Ok, now we're rolling...
First things first. Motorola sucks because they only give you restricted Firehose loaders.
That means of the 70-odd partitions that you have you can only read/write about 1/3 of them using EDL.
If you post your Firehose loader I can tell you which ones you can read/write.
Second, are you sure that the only damage you did was by writing recovery_a and recovery_b?
And you're on Linux, *sad face*.
I was disassembling the Motorola Firehose for my Moto G (2021) and I discovered that they have more reboot options than stock.
There's reset-to-edl and reset-to-fastboot.
I've added those options to my edl.exe (in the sig) this morning. You need to download the very latest.
What may have happened is that you wrote a bad recovery which may have set the boot option in the BCB or misc.
Since the recovery is good enough to be recognized as an image but not good enough to reset this boot option you're stuck.
Your first recourse is flashing a proper recovery.
I'm not sure whether "blank flash" tries to wipe everything. In any case I wouldn't risk it.
Your first try should be to fix the broken things, not everything.
Yes, any edl client that supports ad-hoc xml should be able to get you to fastboot but I'll only answer for my code.
I've tested it.
Code:
C:\>edl /lwhatever.bin
C:\>edl /zf
C:\>fastboot flash recovery_a good_recovery.img
C:\>fastboot flash recovery_b good_recovery.img
C:\>fastboot reboot
I admit to not properly understand what a firehose loader is. :x
Second, are you sure that the only damage you did was by writing recovery_a and recovery_b?
Click to expand...
Click to collapse
Yes, 100%.
So, for now, I should try booting Windows, installing the 9008 driver and following your instructions... Will let you know how it goes.
Thanks a lot.
marc.2377 said:
I admit to not properly understand what a firehose loader is. :x
Click to expand...
Click to collapse
A Firehose loader is a replacement xbl/sbl secondary loader that has special sauce added to it to make it interactive.
It is not to be confused with a Windows driver (which, in this case is Zadig, as per the instructions on my web page).
In this case, your Firehose loader is packed in singleimage.bin in the RPE here: https://mirrors.lolinet.com/firmware/motorola/sofiar/blankflash/
I extracted it for you. I renamed it sofiar.bin
The extension name does not matter.
Code:
C:\>edl /lsofiar.bin
That's slash-ell-sofiar.bin
Edit: And yes, your Firehose loader has the reset-to-fastboot.
Right, thanks for the explanation. I figured that was programmer.elf from my files.
Ok, I got as far as:
> edl /l
Found EDL 9008
Serial: 69cccc95
HWID: 0010a0e102e80000, QC: 0010a0e1, OEM: 02e8, Model: 0000
Hash: 974359c4290cac7f-9f0dc9a802815b5e-2b376b7a7c1be92c-1e816b5287f18610
> edl /lsofiar.bin
Found EDL 9008
Resetting Sahara
Serial: 69cccc95
HWID: 0010a0e102e80000, QC: 0010a0e1, OEM: 02e8, Model: 0000
Hash: 974359c4290cac7f-9f0dc9a802815b5e-2b376b7a7c1be92c-1e816b5287f18610
Sending sofiar.bin 100% Ok
Waiting for Firehose... Ok
> edl.exe /zf
Found EDL 9008
Requesting reset to fastboot... Ok
But it doesn't boot to fastboot.
It seems to me that your tool, edl could be used to write the recovery partition directly, no?
I tried this:
> edl /w /precovery_a recovery.img
Found EDL 9008
Configuring... Ok
Requesting GPT 0 header... Ok, receiving... Ok, requesting entries... Ok, receiving... Ok
Requesting write recovery.img...
<log value="ERROR: range restricted: lun=0, start_sector=1591552, num_sectors=131072" />
Nope
P.s. curiously, the file I downloaded from https://raw.githubusercontent.com/b...a/0010a0e102e80000_974359c4290cac7f_fhprg.bin wasn't accepted as a valid firehose loader file.
Edit: nevermind. Had to restart the phone.
I believe that's an older loader, anyway.
How shall I proceed?
marc.2377 said:
But it doesn't boot to fastboot.
Click to expand...
Click to collapse
Hmm, the screen stays black?
Is it still in EDL mode or some other mode?
Does Windows "bong" when you pull the USB cable?
It's possible that this goes to a fastboot without a screen?
Try holding various buttons, both by long power button reset and /zf
marc.2377 said:
It seems to me that your tool, edl could be used to write the recovery partition directly, no?
Click to expand...
Click to collapse
Yes, it could if Motorola wasn't such a pain with the "range restricted".
They've really clamped down (that other file you mentioned is the same):
Code:
qcomview /r sofiar.bin
Addr LUN Start Count
------ --- -------- --------
007f10 0 0 256
007f28 0 256 78336
007f40 0 1609948 512
007f58 0 1610496 512
007f70 1 1 1
You can do this to see which partitions this means:
Code:
C:\>edl /lsofiar.bin
C:\>edl /g
I have a feeling that the Motorola "Blankflash" stuff writes something to those 3 areas that allow it to write everything.
But it probably wipes the userdata.
I'm not an expert on their tools.
Tell me what the GPT says (you only need to quote stuff in the area of that table).
Edit: It looks like in the multi GB zip there are two "instruction" files, flashfile.xml and servicefile.xml
They are mostly the same except that flashfile will wipe userdata!
Curious. The partition table is as follows:
Code:
Found EDL 9008
Configuring... Ok
Requesting GPT 0 header... Ok, receiving... Ok, requesting entries... Ok, receiving... Ok
# Name Start Count Type
-- ---------------- ---------- ---------- --------------------
1 xbl_a 256 9216 Inactive
2 xbl_b 9472 9216 Bootloader
3 tz_a 18688 8192 Inactive
4 tz_b 26880 8192 TrustZone
5 rpm_a 35072 1024 Inactive
6 rpm_b 36096 1024 Resource/power mgmt
7 hyp_a 37120 1024 Inactive
8 hyp_b 38144 1024 Hypervisor
9 devcfg_a 39168 256 Inactive
10 devcfg_b 39424 256 Device config
11 xbl_config_a 39680 256 Inactive
12 xbl_config_b 39936 256 Boot config
13 abl_a 40192 2048 Inactive
14 abl_b 42240 2048 Android bootloader
15 uefisecapp_a 44288 4096 Inactive
16 uefisecapp_b 48384 4096 be8a7e08
17 qupfw_a 52480 160 Inactive
18 qupfw_b 52736 160 QUP firmware
19 cmnlib_a 52992 1024 Inactive
20 cmnlib64_a 54016 1024 Inactive
21 cmnlib_b 55040 1024 Common lib
22 cmnlib64_b 56064 1024 Common lib64
23 keymaster_a 57088 1024 Inactive
24 keymaster_b 58112 1024 Key master
25 storsec_a 59136 256 Inactive
26 storsec_b 59392 256 Store secure
27 spunvm 59648 16384 Spun VM
28 uefivarstore 76032 1024 165bd6bc
29 multiimgoem_a 77056 64 Inactive
30 multiimgoem_b 77120 64 e126a436
31 multiimgqti_a 77184 64 Inactive
32 multiimgqti_b 77248 64 846c6f05
33 prov_a 77312 512 Inactive
34 prov_b 77824 512 d05e0fc0
35 modem_a 78336 368640 Inactive
36 modem_b 446976 368640 FAT32
37 fsc 815616 256 FSC
38 ssd 815872 16 Secure SW download
39 dsp_a 816128 65536 Inactive
40 dsp_b 881664 65536 DSP
41 ddr 947200 2048 DDR
42 utags 949248 1024 1dd40d18
43 utagsBackup 950272 1024 c490f39c
44 modemst1 951296 8192 Modem ST1
45 modemst2 959488 8192 Modem ST2
46 fsg_a 967680 49152 Inactive
47 fsg_b 1016832 49152 Modem storage
48 persist 1065984 65536 Persist
49 prodpersist 1131520 16384 Persist
50 frp 1147904 1024 FRP
51 cid 1148928 256 459abd04
52 carrier 1149184 32768 c63d32d8
53 metadata 1181952 32768 988a98c9
54 kpan 1214720 16384 56465e10
55 boot_a 1231104 131072 Inactive
56 boot_b 1362176 131072 Boot
57 dtbo_a 1493248 49152 Inactive
58 dtbo_b 1542400 49152 DTBO
59 recovery_a 1591552 131072 Inactive
60 recovery_b 1722624 131072 Recovery
61 misc 1853696 2048 Misc
62 logfs 1855744 16384 Log FS
63 apdp 1872128 512 APDP
64 msadp 1872640 512 MSADP
65 dpo 1873152 2 DPO
66 devinfo 1873160 8 Device info
67 bluetooth_a 1873168 9216 Inactive
68 bluetooth_b 1882384 9216 Bluetooth
69 logo_a 1891600 66848 Inactive
70 logo_b 1958448 66848 Splash
71 vbmeta_a 2025296 128 Inactive
72 vbmeta_b 2025424 128 Verified Boot meta
73 padA 2025552 6064 Empty
74 hw 2031616 16384 b2d77ec0
75 padB 2048000 16384 Empty
76 sp 2064384 16384 40aef62a
77 padC 2080768 16384 Empty
78 padD 2097152 32768 Empty
79 super 2129920 16973824 System
80 userdata 19103744 103038943 User data
Doesn't seem to match the output of qcomview.
Also, the file 0010a0e102e80000_974359c4290cac7f_fhprg.bin lists the following codenames:
Code:
QCA6390
QCS605
SA8150
SDA670
SDA845
SDA855
SDA855A
SDA865
SDC830
SDM450
SDM670
SDM830
SDM845
SDM855
SDM855A
SDM1000
SDX24
SDX24M
SDX55
SM6150
SM6150P
SM7150
SM7150P
SM_NICOBAR
While programmer.elf (same as sofiar.bin that you uploaded) lists, additionally, QCM_NICOBAR and QCS_NICOBAR.
I wonder whether this is actually the correct file for me...
Btw, before attempting any further writing strategies, I confess to being interested in pulling userdata. As I understand the real decryption key is stored in the TEE functionality of the chipset and such an image would be unreadable for me, except if I were to restore it later.
With your tool I got the "range restricted" for edl /r /puserdata parts\userdata.img /t too.
Code:
Addr LUN Start Count
------ --- -------- --------
007f10 0 0 256 - GPT
007f28 0 256 78336 - xbl_a to prov_b
007f40 0 1609948 512 - ??? random spot in recovery_a
007f58 0 1610496 512 - ??? random spot in recovery_a
007f70 1 1 1
So, basically, you have free read/write access to partions 1 to 34
Reading is always safe.
Also, you're on the B slot.
So why does reboot to fastboot fail?
It could be that it was never implemented correctly in this Firehose
It could be that this Firehose is not for your device
It could be that xbl and/or abl was damaged somehow
I'd do some checking, xbl_b and abl_b to start with.
Read 'em then compare them to the xbl and abl you have in your big packages.
Code:
C:\>edl /lsofiar.bin
C:\>edl /r /t /pxbl_b xblb.img
C:\>edl /r /t /pabl_b ablb.img
The /t will copy these ELF files only as big as they need to be (not all the blank space).
OTOH, they will enlarge to an exact number of 512 byte sector.
So they could be 511 bytes bigger than what comes out of that package.
If things are wacky, try without /t, but they'll be padded with all the zeroes in the partition.
If those files aren't in the big package, here's ones I extracted from the blankflash.
Check 'em all.
Also, it's possible that somehow the slots got switched.
While you're at it, look at xbl_a and abl_a also.
Hey, thanks for the continued efforts to help me. Sorry for absence for the past days, real life caugh in ^^
I'm glad to report that, amidst some binary checking and all that, I managed to resuscitate my phone using the blankflash strategy, after carefully revising it.
Strangely, it seems that TWRP got installed in the boot partition, such as that "normal boot" kept entering TWRP, despite I having flashed the stock recovery images to both recovery slots. I'll detail this all later.
At this point my phone is on and I backed up what I needed, and have been using it. A few strange glitches are present, i.e. battery charging is acting weird. I plan on doing a clean flashing of the stock ROM soon. Maybe I should take the opportunity to study how to make a fully working port of the latest LineageOS for this device, too.
Will get back within a few days with a detailed report of the endeavour
marc.2377 said:
Will get back within a few days with a detailed report of the endeavour
Click to expand...
Click to collapse
I'm looking forward to hearing how you got EDL mode working.
I bricked XT2041-3 Sofiar (downgrade to A10) and am stuck trying the phone to succeed at qboot blank-flash, but it hangs (on linux):
Code:
< waiting for device >
Motorola qboot utility version 3.86
[ 0.000] Opening device: /dev/ttyUSB0
[ 0.000] Detecting device
[ 0.002] ...cpu.id = 266 (0x10a)
[ 0.002] ...cpu.sn = 3773339940 (0xe0e89924)
[ 0.002] Opening singleimage
[ 0.002] Loading package
[ 0.004] ...filename = pkg.xml
[ 0.005] Loading programmer
[ 0.005] ...filename = programmer.elf
[ 0.005] Sending programmer
[ 0.178] Handling things over to programmer
[ 0.178] Identifying CPU version
[ 0.178] Waiting for firehose to get ready
With --debug=2 there can be seen some parsing errors in xmls being passed for about 13 more seconds. On Windows VM phone is recognized as a single QDLoader 9008 device, but qboot fails after half a minute with IO Errors. Is this even EDL mode?
A tried without luck Renate's edl tool. edl.exe /lsingleimage.bin:
Code:
Found EDL 9008
Could not open device
I was growing increasingly desperate, so I opened the phone and played with EDL points according to
MatiasLopezxD. No combination of vol-, power, shorting points, plugging usb seem to make a difference. I must be missing something simple.
Any help would be appreciated.
@ybea: Quick answer for now - I got into EDL mode by holding down VolDown+Power for about 8-10 seconds. Let me know if it works for you. What's your output for lsusb?
Same as yours - ID 05c6:9008 (Qualcomm, Inc. Gobi Wireless Modem (QDL mode)). It reconnects after pressing power for 9 seconds (with or without vol-), nothing new.
Try restarting it into EDL mode while it's plugged. I found that to be necessary sometimes.
Edit: Btw, I don't remember why exactly, but I only had success running the blankflash from Windows. Linux didn't do the magic, nor a Windows VM with USB redirection...
marc.2377 said:
Edit: Btw, I don't remember why exactly, but I only had success running the blankflash from Windows. Linux didn't do the magic, nor a Windows VM with USB redirection...
Click to expand...
Click to collapse
That was it! I didn't event try it on the metal, because Motorola driver installer and uninstaller crash for me for some reason. Should be straightforward from now.
Thank you so much. You saved the day.
ybea said:
A tried without luck Renate's edl tool. edl.exe /lsingleimage.bin
Click to expand...
Click to collapse
Sorry. edl.exe uses the generic Zadig (i.e. WinUsb) driver).
If you have the Qualcomm driver loaded it's stealing the poor WinUsb interface and forcing it into some bogus virtual com port.
Also, singleimage is Motorola's completely morally bankrupt idea of packing stuff in a file.
It is not a Firehose loader, although it contains one.
Add to all your miseries, Motorola is crap and releases only restricted Firehose loaders.
If you're still stuck, ship me the "single-and-totally-bogus.bin" and I'll extract the Firehose loader for you.
Better poke me or I won't see it.
No longer stuck. The problem for me was neither VM USB passthrough nor blankflash tools for linux did work, although both showed proper EDL mode. It seems it only works on native Windows. Thanks for your interest.