So far a couple of guys here on the forum has asked me how did I flash GDPR to EXPORT also with different Project ID.
The thing is that the guy from Pakistan via TeamViewer flashed mine phone from GDPR to EXPORT even with different ProjectID.
That means different PCB[2-7].
The truth is that he was using Production or Developer mode with manual servers, guess from China.
He was able to flash from GDPR Project ID-20713 .44 to EXPORT Project ID 20711.
Have provided him the PCB from start 0020713, didn't check it at flashed EXPORT, in 2 days it flashed me back.
From the downloaded files in C:\temp\MsmDownloadTool\DownloadData\ I have checked and found out differencies from the original downloaded roms.
All USF flashed files are the same, except gpt*.bin files, some XML and super*.img and of course userdata.img.
The only difference as I can spotted while doing the forensics is that multi_image.mbn NON-HLOS.bin, even oppo20711.bin and oppo20713.bin are different from the original download rom on the net.
Some of you said that from the aftersale mode you cannot flash GPRD<--->EXPORT witch have the same PROJID.
Looking forward for a support if any1 know a guy with Production or Developer credential or any1 who can give us support regarding this question.
I cannot contact that guy via WA - non existent ?
Weird thing is that now I know I can use keylogger and it works also threougth Team-Viewer, so if any1 wants to test and if they use Production or Developer credential could be usefull for further tests.
That has been stated just for testing purpuses. Use it at your own risk.
Need feedback some Oppo/Realme developers could easily provide that informations for sure.
I can feel/know that the knowledge is hard to share if it's paid, but we are lowering the costs after all ...
To acess PCB on phone dial *#888#
to get current ROM info use the mine info script for RMX3081 more details here.
I'm really looking forward to get this out ...
I'm still looking forward to get my UFS box and ISP circuit boad to do more forensics on the files on UFS.
Till then ...
@StratOS_HTC
I'm studying how the program that decompresses ofp, so that it does the process of recompressing an uncompressed file, it on github only has the recompression process just for oneplus, and from what I studied the code it basically only does the inverse process, so I'm trying to do this for the ofp files as well.
Won't work.
GitHub - bkerler/oppo_decrypt: Oppo .ofp Firmware decrypter and oneplus .ops de-/encrypter
Oppo .ofp Firmware decrypter and oneplus .ops de-/encrypter - GitHub - bkerler/oppo_decrypt: Oppo .ofp Firmware decrypter and oneplus .ops de-/encrypter
github.com
The current flashing Oppo/Realme program is only for OFP (Original firmware package).
You must have a production/manufacture credentials and access to server to done this ok.
You can pack in with the same public key as unpacker, but the flashing procedure won't work.
Need to change also *.xml
It won't work also in fastboot (GDPR) because if you have locked bootloader the only way to flash is throught EDL.
Firehose need auth,verification and certified checked files.
If you have unlocked bootloader (Export), you can only flash non-critical partitions. (Have checked allready).
And also recovery *.ozip is still not documented and is implemented on both versions.
Acess on temp files on /data/ is denied and also rewriting dev blocks via $ and not #.
From what I have learned the thing is highly complexed and will take time to do something.
Realme EU service is just a "bot" for answering.
First the EDL mode in our phone has it's own signing and verification and it's undocumented and via current method (emmcdl, QFIL ...) not implemented that it shoud work.
I guess it should with some USB sniffers via current driver and with official MSM application.
GitHub - bkerler/edl: Inofficial Qualcomm Firehose / Sahara / Streaming / Diag Tools :)
Inofficial Qualcomm Firehose / Sahara / Streaming / Diag Tools :) - GitHub - bkerler/edl: Inofficial Qualcomm Firehose / Sahara / Streaming / Diag Tools :)
github.com
RMX3081 - No kernel driver supported: Operation not supported or unimplemented on this platform · Issue #197 · bkerler/edl
For Realme 8 Pro : MSM8998 - debugmode. The device is first in EDL Sahara mode, then go out to the normal ... Guess this is not the same as in QPST server. It lock the device in EDL Sahara mode (do...
github.com
The GDPR bootloader cannot be unlock ! (Guess 4 now )
So no custom flashing possible. AVB and verity is still present ... No flashing, no root ...
Fully stucked for GDPR rom.
Kernel can be checked/modified/moded :
https://github.com/realme-kernel-opensource/realme_6pro_7pro_8pro_X2-AndroidR-kernel-source
... Also the EXE file for flashing he used were different then the original from the zip for .44 release of OFP zip.
They use jenkins software for OFP, also ota ...
From the original OFP *.zip (md5sum.md5.txt) for both Export and Gdpr
88b86647b46496a0d8c8054ed25b2a84/work/jenkins/workspace/[email protected]/759948/system_vendor/20713/RMX3081GDPR_11_A.44_2021110921090000/build.prop88B86647B46496A0D8C8054ED25B2A848babba8c5a1b36ec0ac94d51825106bd/work/jenkins/workspace/[email protected]/759948/system_vendor/20713/RMX3081GDPR_11_A.44_2021110921090000/super_map.csv8BABBA8C5A1B36EC0AC94D51825106BD0f1ad197293466548b532db1d900b8fe/work/jenkins/workspace/[email protected]/759948/system_vendor/20713/RMX3081GDPR_11_A.44_2021110921090000/MsmDownloadTool.exeEA6EBBBA5F193129CD9E09ED09F51569MsmDownloadTool_V2.0.67-Rcsm.exea00bc5314ae01bf663f24b9720575cdc/work/jenkins/workspace/[email protected]/759948/system_vendor/20713/RMX3081GDPR_11_A.44_2021110921090000/RMX3081GDPR_11_A.44_2021110921090000.ofpnot checked75db4d94375063a76adec420d84e21c4/work/jenkins/workspace/ofp_fat_release/759953/system_vendor/20711/RMX3081export_11_A.44_2021110921030235/super_map.csv75DB4D94375063A76ADEC420D84E21C40f1ad197293466548b532db1d900b8fe/work/jenkins/workspace/ofp_fat_release/759953/system_vendor/20711/RMX3081export_11_A.44_2021110921030235/MsmDownloadTool.exeEA6EBBBA5F193129CD9E09ED09F51569MsmDownloadTool_V2.0.67-Rcsm.exe64738ed2610959172300a1802bfb2be9/work/jenkins/workspace/ofp_fat_release/759953/system_vendor/20711/RMX3081export_11_A.44_2021110921030235/build.prop64738ED2610959172300A1802BFB2BE9392a5f8b25368ff1aa63017ec072de73/work/jenkins/workspace/ofp_fat_release/759953/system_vendor/20711/RMX3081export_11_A.44_2021110921030235/RMX3081export_11_A.44_2021110921030235.ofpnot checked
The 1st column is md5 from the enclosed files for both releases of the OFP zip.
The 2nd column is path to file on server and the file name.
The 3th is the MD5 check I made with md5 for each file.
The 4th is the name of the exe in zip
That means that the included EXE file in zip for both releases (EXPORT and GDPR) (MsmDownloadTool_V2.0.67-Rcsm.exe) are different from the original MsmDownloadTool.exe regarding MD5 check in the original md5sum.md5 text file. !
For both releases they use the same flashing exe in official *.zip.
@StratOS_HTC The change in the ofp package that I intend to do is just take the NV of the GDPR package and put it inside the EXPORT package, and flash it with authentication from the original server, the person who has access, which is the same as you mentioned earlier, will tell me help with that.
Hi.
This won't work.
First the reseler (aftersale) credential is used to flash the same PROJECT ID, Same PCB [0-7].
It is used to flash with exe from the OFP zip.
Second of all, a lot of flashed files written on USF are same for both releases (GDPR-EXPORT).
The difference between is only in multi_image.mbn, NON-HLOS.bin, oppo*PROJID*.bin (all have same size !, but are different), of course userdata.img and of course GPT files gpt_main*.bin and gpt_backup.bin.
Also all Chainded tables and Digest to sign.
Fur sure some xml files also.
Ok, let's start the NV.
The NV is just a way to identify the needed programs,settings,language, enabled/disabled hardware regarding location,provider ...
That is our superimage.
The check is primarly checked via firehose EDL Sahara via XML communication.
That is why we get errors via QFIL,EMMCDL ...
It's the same oppo project, the Realme use just the new branch difference in NV (superimage).
The contents of sparsed superimage determine the situation, that is PROJ ID and specified NV ID.
You were right about that, but since the oppo uses signed NV digest for NV this is mission impossible.
{
"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"
}
But since no debugging for current flashing via OFP is available only USB debugging or sniffing would be optional or EDL exploit ...
Guess super image create the needed init at start and change the flashed files at init.
Will check it after i get the UFS Box and guess in time we will be able to access UFS to check that.
Enclosing the difference in OPF .44 for the both releases and NV infos.
The file is in *.zip, rename it to *.xlsx !
file Diff.zip-->Diff.xlsx
NOTE :
The verification and Authentication of files is via Sahara firehose original program use. The production/development credential are used only to download the needed files for flashing and NV files.
For now no optional flashing is available. Just FRP reset, Format - Factory reset and Partition Infos (Manager and scatter info).
Regarding the Production/Development credential I'm stucked.
The guy from PA (account on WA) is not available anymore ...
@StratOS_HTC
I recently helped to improve a bit the code of a github project that unzips an OFP, then I unzipped an ofp EXPORT and GDPR in the same update, and I made a program to check the differences, it reads the bytes of each unzipped file and converts to a sha256 and then check if it is the same as another. and this was the result:
summary: basically NV and userdata are different.
====================================
ChainedTableOfDigests_nv00011010.bin (have in Export, NOT have in GDPR)
ChainedTableOfDigests_nv00110011.bin (have in Export, NOT have in GDPR)
ChainedTableOfDigests_nv00110111.bin (have in Export, NOT have in GDPR)
ChainedTableOfDigests_nv00111000.bin (have in Export, NOT have in GDPR)
ChainedTableOfDigests_nv00111001.bin (have in Export, NOT have in GDPR)
ChainedTableOfDigests_nv01010101.bin (have in Export, NOT have in GDPR)
ChainedTableOfDigests_nv01010110.bin (have in Export, NOT have in GDPR)
ChainedTableOfDigests_nv01011010.bin (have in Export, NOT have in GDPR)
ChainedTableOfDigests_nv01100000.bin (have in Export, NOT have in GDPR)
ChainedTableOfDigests_nv01100011.bin (have in Export, NOT have in GDPR)
ChainedTableOfDigests_nv01100100.bin (have in Export, NOT have in GDPR)
ChainedTableOfDigests_nv01110100.bin (have in Export, NOT have in GDPR)
ChainedTableOfDigests_nv01110101.bin (have in Export, NOT have in GDPR)
ChainedTableOfDigests_nv10010110.bin (have in Export, NOT have in GDPR)
ChainedTableOfDigests_nv10011010.bin (have in Export, NOT have in GDPR)
DigestsToSign_nv00011010.bin.mbn (have in Export, NOT have in GDPR)
DigestsToSign_nv00110011.bin.mbn (have in Export, NOT have in GDPR)
DigestsToSign_nv00110111.bin.mbn (have in Export, NOT have in GDPR)
DigestsToSign_nv00111000.bin.mbn (have in Export, NOT have in GDPR)
DigestsToSign_nv00111001.bin.mbn (have in Export, NOT have in GDPR)
DigestsToSign_nv01010101.bin.mbn (have in Export, NOT have in GDPR)
DigestsToSign_nv01010110.bin.mbn (have in Export, NOT have in GDPR)
DigestsToSign_nv01011010.bin.mbn (have in Export, NOT have in GDPR)
DigestsToSign_nv01100000.bin.mbn (have in Export, NOT have in GDPR)
DigestsToSign_nv01100011.bin.mbn (have in Export, NOT have in GDPR)
DigestsToSign_nv01100100.bin.mbn (have in Export, NOT have in GDPR)
DigestsToSign_nv01110100.bin.mbn (have in Export, NOT have in GDPR)
DigestsToSign_nv01110101.bin.mbn (have in Export, NOT have in GDPR)
DigestsToSign_nv10010110.bin.mbn (have in Export, NOT have in GDPR)
DigestsToSign_nv10011010.bin.mbn (have in Export, NOT have in GDPR)
super.1.a0f90c6f.img (have in Export, NOT have in GDPR)
super.2.16b9d689.img (have in Export, NOT have in GDPR)
super.2.1913e5ba.img (have in Export, NOT have in GDPR)
super.2.36bdcb22.img (have in Export, NOT have in GDPR)
super.2.3966f314.img (have in Export, NOT have in GDPR)
super.2.4027e833.img (have in Export, NOT have in GDPR)
super.2.4c32ac99.img (have in Export, NOT have in GDPR)
super.2.528bed36.img (have in Export, NOT have in GDPR)
super.2.6fd81839.img (have in Export, NOT have in GDPR)
super.2.88a45b82.img (have in Export, NOT have in GDPR)
super.2.8c6cad19.img (have in Export, NOT have in GDPR)
super.2.8f0b3c8e.img (have in Export, NOT have in GDPR)
super.2.909e14d8.img (have in Export, NOT have in GDPR)
super.2.92ad9583.img (have in Export, NOT have in GDPR)
super.2.aad94f7a.img (have in Export, NOT have in GDPR)
super.2.c44c6680.img (have in Export, NOT have in GDPR)
super.2.fd79bc4d.img (have in Export, NOT have in GDPR)
ChainedTableOfDigests_nv01000100.bin (have in GDPR, NOT have in Export)
ChainedTableOfDigests_nv01010001.bin (have in GDPR, NOT have in Export)
ChainedTableOfDigests_nv10000101.bin (have in GDPR, NOT have in Export)
ChainedTableOfDigests_nv10000111.bin (have in GDPR, NOT have in Export)
ChainedTableOfDigests_nv10001100.bin (have in GDPR, NOT have in Export)
ChainedTableOfDigests_nv10001101.bin (have in GDPR, NOT have in Export)
ChainedTableOfDigests_nv10001111.bin (have in GDPR, NOT have in Export)
ChainedTableOfDigests_nv10100010.bin (have in GDPR, NOT have in Export)
DigestsToSign_nv01000100.bin.mbn (have in GDPR, NOT have in Export)
DigestsToSign_nv01010001.bin.mbn (have in GDPR, NOT have in Export)
DigestsToSign_nv10000101.bin.mbn (have in GDPR, NOT have in Export)
DigestsToSign_nv10000111.bin.mbn (have in GDPR, NOT have in Export)
DigestsToSign_nv10001100.bin.mbn (have in GDPR, NOT have in Export)
DigestsToSign_nv10001101.bin.mbn (have in GDPR, NOT have in Export)
DigestsToSign_nv10001111.bin.mbn (have in GDPR, NOT have in Export)
DigestsToSign_nv10100010.bin.mbn (have in GDPR, NOT have in Export)
super.1.254549e8.img (have in GDPR, NOT have in Export)
super.2.25c7bd95.img (have in GDPR, NOT have in Export)
super.2.4c7ff445.img (have in GDPR, NOT have in Export)
super.2.689c505c.img (have in GDPR, NOT have in Export)
super.2.7694024d.img (have in GDPR, NOT have in Export)
super.2.97984148.img (have in GDPR, NOT have in Export)
super.2.d7d4e2be.img (have in GDPR, NOT have in Export)
super.2.e2378c51.img (have in GDPR, NOT have in Export)
super.2.ea46afff.img (have in GDPR, NOT have in Export)
====================================
abl.elf Equal
aop.mbn Equal
apdp.mbn Equal
boot.img Equal
BTFM.bin Equal
cache.img Equal
ChainedTableOfDigests_2169B_ddr4_persist_no_userdata_no.bin Equal
ChainedTableOfDigests_2169B_ddr4_persist_yes_userdata_no.bin Equal
ChainedTableOfDigests_2169B_ddr5_persist_no_userdata_no.bin Equal
ChainedTableOfDigests_2169B_ddr5_persist_yes_userdata_no.bin Equal
ChainedTableOfDigests_pre_provision.bin Equal
ChainedTableOfDigests_provision_hynix.bin Equal
ChainedTableOfDigests_provision_micron.bin Equal
ChainedTableOfDigests_provision_samsung.bin Equal
ChainedTableOfDigests_provision_toshiba.bin Equal
cmnlib.mbn Equal
cmnlib64.mbn Equal
devcfg.mbn Equal
DRIVER.ISO Equal
dspso.bin Equal
dtbo.img Equal
dynamic_nvbk.2169B.bin Equal
emmc_fw.bin Equal
engineering_cdt.img Equal
featenabler.mbn Equal
fwupdateConfig.xml Equal
gpt_backup0.bin Equal
gpt_backup1.bin Equal
gpt_backup2.bin Equal
gpt_backup3.bin Equal
gpt_backup4.bin Equal
gpt_backup5.bin Equal
gpt_main0.bin Equal
gpt_main1.bin Equal
gpt_main2.bin Equal
gpt_main3.bin Equal
gpt_main4.bin Equal
gpt_main5.bin Equal
hyp.mbn Equal
imagefv_ddr4.elf Equal
imagefv_ddr5.elf Equal
km4.mbn Equal
logfs_ufs_8mb.bin Equal
metadata.img Equal
modemdump.img Equal
multi_image.mbn Equal
NON-HLOS.bin Equal
oppo2169B.bin Equal
opporeserve2.img Equal
oppo_sec.mbn Equal
patch0.xml Equal
patch1.xml Equal
patch2.xml Equal
patch3.xml Equal
patch4.xml Equal
patch5.xml Equal
persist.img Equal
prog_firehose_ddr4.elf Equal
prog_firehose_ddr4_fwupdate.elf Equal
prog_firehose_ddr5.elf Equal
prog_firehose_ddr5_fwupdate.elf Equal
prog_firehose_lite.elf Equal
Projectconfig.xml Equal
provision_hynix.xml Equal
provision_micron.xml Equal
provision_samsung.xml Equal
provision_toshiba.xml Equal
qupv3fw.elf Equal
rawprogram0.xml Equal
rawprogram1.xml Equal
rawprogram2.xml Equal
rawprogram3.xml Equal
rawprogram4.xml Equal
rawprogram5.xml Equal
recovery.img Equal
sec_smt.dat Equal
Setting.xml Equal
splash.img Equal
spunvm.bin Equal
SS_KLUDG4UHDB-B2D1_1900.fw Equal
SS_KLUEG8UHDB-C2D1_1900.fw Equal
static_nvbk.2169B.bin Equal
tz.mbn Equal
uefi_sec.mbn Equal
vbmeta.img Equal
vbmeta_system.img Equal
vbmeta_vendor.img Equal
xbl_config_ddr4.elf Equal
xbl_config_ddr5.elf Equal
xbl_ddr4.elf Equal
xbl_ddr5.elf Equal
zeros_5sectors.bin Equal
====================================
ChainedTableOfDigests_2169B_ddr4_all.bin Different
ChainedTableOfDigests_2169B_ddr4_persist_no_userdata_yes.bin Different
ChainedTableOfDigests_2169B_ddr4_persist_yes_userdata_yes.bin Different
ChainedTableOfDigests_2169B_ddr5_all.bin Different
ChainedTableOfDigests_2169B_ddr5_persist_no_userdata_yes.bin Different
ChainedTableOfDigests_2169B_ddr5_persist_yes_userdata_yes.bin Different
ChainedTableOfDigests_nv00000000.bin Different
DigestsToSign_2169B_ddr4_all.bin.mbn Different
DigestsToSign_2169B_ddr4_persist_no_userdata_no.bin.mbn Different
DigestsToSign_2169B_ddr4_persist_no_userdata_yes.bin.mbn Different
DigestsToSign_2169B_ddr4_persist_yes_userdata_no.bin.mbn Different
DigestsToSign_2169B_ddr4_persist_yes_userdata_yes.bin.mbn Different
DigestsToSign_2169B_ddr5_all.bin.mbn Different
DigestsToSign_2169B_ddr5_persist_no_userdata_no.bin.mbn Different
DigestsToSign_2169B_ddr5_persist_no_userdata_yes.bin.mbn Different
DigestsToSign_2169B_ddr5_persist_yes_userdata_no.bin.mbn Different
DigestsToSign_2169B_ddr5_persist_yes_userdata_yes.bin.mbn Different
DigestsToSign_nv00000000.bin.mbn Different
DigestsToSign_pre_provision.bin.mbn Different
DigestsToSign_provision_hynix.bin.mbn Different
DigestsToSign_provision_micron.bin.mbn Different
DigestsToSign_provision_samsung.bin.mbn Different
DigestsToSign_provision_toshiba.bin.mbn Different
ProFile.xml Different
super.0.48453346.img Different
userdata.img Different
This is for 2169b ?
Can you upload those :
prog_firehose_ddr4.elf
prog_firehose_ddr4_fwupdate.elf
prog_firehose_ddr5.elf
prog_firehose_ddr5_fwupdate.elf
prog_firehose_lite.elf
StratOS_HTC said:
This is for 2169b ?
Can you upload those :
prog_firehose_ddr4.elf
prog_firehose_ddr4_fwupdate.elf
prog_firehose_ddr5.elf
prog_firehose_ddr5_fwupdate.elf
prog_firehose_lite.elf
Click to expand...
Click to collapse
the projectid is 2169B
Found out something new when updating via ota.
[ro.build.version.ota]: [RMX3081NV44_11.A.44_1440_202111092109]
Well I found out that the encrypted super sparsed image (system.img) consist out of multiple 3 superx*.img.
The NVid can be get from ota, so mine is NV44
nv_idnv_textsuper_0_pathsuper_1_pathsuper_2_path1000100EUEXsuper.0.35e5269c.imgsuper.1.de62627a.imgsuper.2.3e674d94.img1010001TRsuper.0.35e5269c.imgsuper.1.de62627a.imgsuper.2.bd4abb42.img10000101EU-NONEEAsuper.0.35e5269c.imgsuper.1.de62627a.imgsuper.2.358c76e4.img10000111UAsuper.0.35e5269c.imgsuper.1.de62627a.imgsuper.2.0d48ab09.img10001010GBsuper.0.35e5269c.imgsuper.1.de62627a.imgsuper.2.745e1476.img00000000GBsuper.0.35e5269c.imgsuper.1.de62627a.imgsuper.2.745e1476.img
Last 2 digits (for mine GDPR) are in hex, so : 44#h=68#d=01000100#b
So mine id="01000100" text="EUEX"
[ro.product.name]: [RMX3081EEA]
or via shell : adb shell getprop ro.build.oplus_nv_id
1st and last have different ID and same all 3 super, in majority the difference is NV ID and the super2.
Since oppo/realme for android11 doesn't allow change on the geo location as it were on previous version, only change via NV, but it has to be done vith developer/production credential, not the after sale (can only flash same ProjID-PCB).
Looking forward just for feedback regarding the info from getprop [ro.build.version.ota] and the original rom ( contents of the super_map.txt included in tho original OFP's zip).
Since all superx*.img is AVB encrypted by default and mounted as system :
boot:fstab.default :
Code:
system /system ext4 ro,barrier=1,discard wait,avb=vbmeta_system,logical,first_stage_mount,avb_keys=/avb/q-gsi.avbpubkey:/avb/r-gsi.avbpubkey:/avb/s-gsi.avbpubkey
system_ext /system_ext ext4 ro,barrier=1,discard wait,avb=vbmeta_system,logical,first_stage_mount
product /product ext4 ro,barrier=1,discard wait,avb=vbmeta_system,logical,first_stage_mount
vendor /vendor ext4 ro,barrier=1,discard wait,avb=vbmeta_vendor,logical,first_stage_mount
system_ext and product and vendor is also mounted
Looking for feedback for getprop [ro.build.version.ota]
and the super_map.txt from the original flashed OFP.
Thank you for the support.
@StratOS_HTC officially released bootloader unlock for my version, and it is GDPR, in my case it was just use the deep test app and unlock by fastboot normally
HI.
There is no official release of the deep test for GDPR [EU] RMX3081.
on EXPORT https://forum.xda-developers.com/t/rmx3081-deep-testing-app-export.4389025/post-86265113 it work, have test it.
On GDPR :
It could be there is something wrong with my flashing back from EXPORT --> GDPR or something else ?
StratOS_HTC said:
HI.
There is no official release of the deep test for GDPR [EU] RMX3081.
on EXPORT https://forum.xda-developers.com/t/rmx3081-deep-testing-app-export.4389025/post-86265113 it work, have test it.
On GDPR :
View attachment 5517603
It could be there is something wrong with my flashing back from EXPORT --> GDPR or something else ?
Click to expand...
Click to collapse
it could be your app or a version that works for the app hasn't arrived yet, I'll send you the app that worked for me, test it out
Thank you.
It's the same.Same error still exists on mine GDPR [EU] rom .44.
The files are exactly the same.
Realme 7 5G, RMX2111 -> flashed RMX2111EU_11_A.22. -> region changed to Multilingual EX -> unlocked bootloader with In Depth test -> updated to RMX2111PU_11_A.35 with ota ozip (PU version, Brazil), rooted with Magisk.
System update cannot find ota update to Android 11 (with vpn also). I cannot find any ota firmware. Therefore I think the only way is to flash full firmware which can be downloaded.
I have found two firmwares:
RMX2111GDPR_11_C.09
RMX2111export_11_C.06
Can you explain which version is better? Are there any differences in system functionalities? I would like also to unlock bootloader and root the phone.
Moreover, what is the difference in super.img regions? I have a possibility to choose the following:
GDRP firmware
01000100,EUEX01101011,IT-TIM00000000,IT-TIM
Export firmware
00000000,EXPORT00011010,TWOP00011110,AU00101100,SGOP00111000,MYOP00111001,TH01111011,MX10000010,HK10000011,SA10010110,IL10011110,BR
I have found such information:
GDPR for mostly Europian and other countries where they implemented GDPR rules for customers data privacy. so GDPR ROMs shouldn't leak or transfer any data to other countries or any other activities without consumer knowledge. if they found any violation then its offensive. India like countries doesn't follow GDPR so company can use or fetch the customers data without their consent in any name and use its business purpose. in GDPR they shouldn't do like that. so GDPR gives more data privacy and safety to users
Click to expand...
Click to collapse
Data privacy is the only difference?
Related
I've been examining CSC's with a hex editor an they seem to be some kind of *.nb0 imagefile containing a RAW filesystem with a *.CAB inside that contains a *.rgu and an a *.reg with the custom settings fot the zone/operator code (XEN, XEC, etc.). I tried to hexedit it but I can't calcule the md5 checksum, it seems to be located at the bottom header of the file but doesn't match with any of file's sections or the whole rest of the binary before the checksum code. Anyone could upload AnDim's new HTCRIE (the one with OMNIA 7 support) to see if it helps editing this kind of *.nb0 ??
Edit: HCTRIE has a fixed method for *.nb0 reading that is only compatible with *.nb0 files containing typical partitions (ULDR, SLDR ,etc) and also is not capable of writting changes so there is no way to create custom csc's for now. I will be investigating for more ways to calculate the image checksum.
Only for development purposes:
Download Hashcheck-less* firmware flasher
*The actual checking is done but it allways says that the firmware's md5 matches the binary header and allows you to flash. I still have to change the code so it shows the error message but allows you to continue.
MD5 chechsum is not the main problem
I uploaded Andim's tools here: http://forum.xda-developers.com/showthread.php?t=1117513.
Any information on the flash-tool is very welcome. But, as xbores already stated, the MD5 is not the main problem. If you manage to create a file that will be accepted by the flash-tool, then there is another problem. The rom-files are signed as "WP7_PRODUCT". The bootloader checks this. If the signature is not valid (which happens when the file is tampered with), the bootloader will probably refuse to boot. So you would also need a patched bootloader. I have no idea how difficult that is. I would assume it isn't to hard to do. But if that were true, then probably other people would already have done it already.
If we have a patched bootloader that accepts cooked roms, and a patched flash-tool or correct checksum calculation, so we can actually flash the cooked rom, that would open up a lot of possibilities. I don't have time to spend to on this, but maybe in the future I will have a look at it. Any info is very appreciated.
Patching the tool would be so easy as I have located the code section where it decides to show md5 hash error or continue with the flash process. It would just require to replace a "jz" instruction by "jmp" one in the code with a hex editor.
It would be thankful that those who downloaded the Hascheck-less flasher reported if it was useful for something...
The absolute hash that checks the flash tool is simple MD5, just depends on from where to where (probably from beginning to the last few bytes except the WP_PRODUCT and the md5 hash itself?).
The main problem is the data between 64h and 8000h - they are signature. I am trying to figure out how is it signed, but it is all weird.
In case of CSC, it seems like it is 1byte per ~512B.
In case of eboot, it is 1byte per ~1024B.
In case of PDA, it is 1byte per ~25kB.
Anyone knows anything about Ra000FF and signing it?
I'm not so sure that it is a signature, if you compare different csc's you find repeating parts in it. And that is IMHO not very typical for signatures.
Is there a thread anywhere describing Ra000FF? I already found file size(without MD5 at the end), size of signature what ever thingy and size of eboot image + entry point.
I did a bit of research and I think I have most (pretty much all?) parts of it. When I get home, I will post my findings.
Code:
Ra000FF container
HEADER:
Offset Length [B] Encoding Description
00 8 Big Endian Ra000FF\x0B
08 2 ?? -- "imagestart" (D000FF)
0C 2 ?? -- "imageend" (D000FF)
11 1 Always 24
15 1 Always 01
18 2 Always 04 80
1D 2 Little Endian Sector size (IMGFS, imageupdate = 808; CSC, eboot = 80)
1F 4 Little Endian File content size in sectors: content size = (value*sector size - (8000 + 13F)) (beginning and ending headers)
The content starts at offset 8000
FOOTER (last 13F bytes)
00 1 Always 7E
04 1 Content type (CSC = A9, EBOOT=C7, IMAGEUPDATE=B8, PDA (IMGFS)=B8, PHONE (Radio)=D6)
05 - 11B In case of PHONE -- some unknown data (another hashes? Some XORs?), in other cases always filled with 00s
11C - 127 Target device type (WP7_PRODUCT or WP7_ENGINEER)
12C - 13B 10 Hash of (whole?) file - probably MD5 (10 bytes)
13C 1 Always 7D
13D - 13F 3 Filled with 00s
ALL NUMBERS ARE IN HEX!
OndraSter said:
The absolute hash that checks the flash tool is simple MD5, just depends on from where to where (probably from beginning to the last few bytes except the WP_PRODUCT and the md5 hash itself?).
Click to expand...
Click to collapse
I have tried the md5 from diferent sections and it doesn't work anyway the goal here is to edit the *.cab.pkg as the md5 checksum check can be bypassed with my patched tool (tested changing random bits inside the imgfs). The *.cab.pkg with header MSCF and ending with an FF heap till the end of the IMGFS is signed with the same certificate as the *.dsm inside it (both can be extracted). As the *.cab.pkg is loaded by the the kernel and not by the bootloader the signature could be meaningless here if the *.cab.pkg inside the IMGFS is properly edited. Considering the FF heap as remaining space we could even add more registry tweaks that would also be loaded at first boot.
Also this is the full set of image signature types:
WP7_ENGINEER_4K
WP7_ENGINEER
WP7_PRODUCT_4K
WP7_PRODUCT
ROISSY_ENGI_4K
ROISSY_ENGI
ROISSY_PROD_4K
ROISSY_PROD
Isn't the CSC file checked when uploading to phone for the certificate signature (RSA MD5, RSA SHA1? Who knows - I don't) in the beginning of the file (from offet 0x64) too?
OndraSter said:
Isn't the CSC file checked when uploading to phone for the certificate signature (RSA MD5, RSA SHA1? Who knows - I don't) in the beginning of the file (from offet 0x64) too?
Click to expand...
Click to collapse
My patched tool ignores md5. It was as simple as changing a jz instruction by a jmp and now no matter if the md5 checksum is correct or not it allways says it's ok (even trough the checking routine is done md5 ok => md5 ok and md5 wrong => md5 ok). About the top header binary sections I don't know but for sure my patched tool allows you to flash images with incorrect md5 checksum.
Yes, but try really flashing some device with not proper signature at offset $64 and down.
I talked with Olipro and this should be similar to R000FF - these data are signed with RSA MD5, every block in file. When data block is sent to phone, it is checked against that ^ and if it is okay, the data is written to NAND. I am not talking about the bottom, I am talking about the top.
Hi, everybody.
Sorry if I post this thread in wrong section.
Howewer I hope that this thread would be an aid for thus want to try the different beta builds of our phone.
Ok. So.
1. Dual SIM B170 --- B188 --- (possible 190 or 194) --- B524 --- B550.
- all is fluent.
2. Single SIM B171 --- B525
- all is fluent
- howewer this build cannot upgrade to B550
- seems that developpement freeze at beta build stage (waiting for final build)
- oh, and surprise: You CAN use dual SIM. Yes its true, i flashed over dual sim model (so i guess that this works only on Dual Sim models)
3. Chinese firmware B535 (--- exist the beta build 551, but that doesnt leaked)
- all is fluent
BUT. The BIG difference between these builds is that the Chinese firmware come with MANY more functions, than the others: SmartCare, Camera modes, Barcodes in Messaging, Yellow Pages in Dialer, and so Many others (maybe I would collect them for the whole list)
So I use the Chinese build. With little tweak is wery well usable. You have little areas with chinese options (for example you must change the keyboard from chinese to huawei swype), but it isnt annoying.
Oh, and if you register an huawei account on chinese site, well, you have many other possibilities from this build.
I recommend this build over the others.
P.S. I would make a voting for those builds too but i dont know how (maybe the moderators...)
i have got b150... can i go for b170?
tamaskurti said:
BUT. The BIG difference between these builds is that the Chinese firmware come with MANY more functions, than the others: SmartCare, Camera modes, Barcodes in Messaging, Yellow Pages in Dialer, and so Many others (maybe I would collect them for the whole list)
So I use the Chinese build. With little tweak is wery well usable. You have little areas with chinese options (for example you must change the keyboard from chinese to huawei swype), but it isnt annoying.
Oh, and if you register an huawei account on chinese site, well, you have many other possibilities from this build.
I recommend this build over the others.
P.S. I would make a voting for those builds too but i dont know how (maybe the moderators...)
Click to expand...
Click to collapse
I've read that some are using the chinese version, but i couldn't found info how to get it.
All HowTos und firmware links lead to C432B550 or C432B524 in the end.
Could you post details how to get the chines beta on an european phone?
Norikio said:
I've read that some are using the chinese version, but i couldn't found info how to get it.
All HowTos und firmware links lead to C432B550 or C432B524 in the end.
Could you post details how to get the chines beta on an european phone?
Click to expand...
Click to collapse
Hm. I was sure that was here on xda, but anyway. I would quote.
Hello,
Finally we get EMUI 4.0 on P8 Lite. Few days ago I decided to change the location of my phone ALE-L21 because China goes beta test of 6.0 but with Chinese firmware installed on the B230 on ALE-UL00. And today the new Android 6.0 was successfully installed on my phone!
Cheers
FIRST and foremost you need change the location!!! to
unicomelectric/cn
To install OTA(EMUI 4.0) update is necessary to change your location and the Chinese version of the software B230
So here the OTA B535
Just put update.zip(1.1GB) into dload folder on your SDCard or internal memory!!! Then install as local update!
Guide how to install EMUI 4.0 Android 6.0 ALE-UL00C00B535 on device ALE-L21(P8 Lite)
Requirements
1.Unlocked bootloader
2. Rooted device
How to Change Region of Your Huawei Honor 4C [Root]
You can change the region of your Huawei Honor 4C and gain the ability to flash firmware from other countries by a few tweaks to the files that hold country settings. This step-by-step tutorial will guide you through the entire process and provide you with the files required.
Huawei Honor 4C
1. Requirements
Full root access
ES File Explorer (Root Explorer is not recommended at all!)
Backup of your current stock recovery and custom recovery
Full Nandroid backup of all partitions
OEM Info File (download here)
Warning: Although you might find this tempting, there’s a high chance that you’ll brick your phone in the process. That’s why you’re strongly advised to keep a handy nandroid backup. We hold no responsibility for any kind of damage caused during or after this procedure. You proceed entirely at your own risk!
2. Procedure
Step 1: First of all, find out your current vendor/country info. One way to do this is by dialing *#*#2846579#*#* – from the menu that pops up go to Network Information > Vendor/Country Info. Some of the vendors/countries are:
hw/spcseas – Malaysia
unicomelectric/cn – China
hw/meafnaf – Pakistan
mts/by – Belarus
Step 2: Now that you know your region information, open ES File Explorer and turn “Root Explorer” on from the menu in the sidebar. Select “/” (device) from the bar above and go to “Data”. Open custom.bin using the ES Note Editor. You’ll see the same vendor and country information in this file as you previously saw in engineering mode. Clear the text and insert the text corresponding to the region you wanna shift to. For example, if I were moving from Pakistan to Malaysia, I’d clear “hw/meafnaf” from custom.bin and insert “hw/spcseas” instead.
When you’re done, save the file and make sure its permissions are set to rw-rw-rw in its properties.
Step 3: Now download the OEM Info package from above and extract it. Inside the oeminfo folder, take the oeminfo file of the country you’re shifting to and copy it to [/device]/dev/block/hi_mci.0/by-name/. Replace the file that’s already present in by-name folder. I repeat – replace the file – don’t delete it! Make sure you’re doing this only through ES File Explorer. Make sure this file has rwx rwx rwx permissions.
Step 4: Finally, if you’ve done everything right, reboot your phone and check your vendor and country info again by dialing *#*#2846579#*#* in the dialer.
Step 5: Now you should be able to flash any firmware from the region you now have. In case you’re seeing “balong” in Settings > Update as your version number it means that you now won’t be able to receive any online updates. You don’t really need to worry about it. Simply download the firmware and flash it through the forced SD upgrade method (you know the one – Vol up + Vol down + Power).
______________________________________________________________________
Change location on your device to unicomelectric/cn
a) Copy file oeminfo to internal memory or SD Card
b) Replace oeminfo on path /dev/block/platform/hi_mci.0/by-name with downloaded one. Reboot
Instalation procedure
a) Downgrade to B052(fastboot) make wipe!
b) Install B230(fastboot) Make two wipe!!!
c) Install B535 as local update(put the update.zip on dload folder in internal memory) make wipe!
DONE!
PS: sokkoban was the autor (look at his label):
h t t p : / / huaweip8lite.blogspot . ro
I managed to find the thread, it's a bit messy because the Opening Post is deleted and i had to find all the filse cluttered over the thread.
Installation went quite smooth, but i'm a little bit worried because Model Number says hi6210sft, but that's something i can probably fix inside the build.prop.
so thanks tamaskurti for the info.
You guys think the best firmware is the chineese one ? I have all the files downloaded on my laptop but I doubt in installing it
look at:
h t t p : / / forum.xda-developers.com / p8lite / general / ale-ul00-t3339897
Honestly, i am disappointed with b550 official europe build.
I was on chinese b535 build, witch its beta, howewer, it has lot more functions than the europe builds. I wait for the final marshmallow build from chinese market, because, their rom is more ellaborated than the others. Sorry, huawei europe, but in comparison with chinese market, the final build seems for me that an early beta or alpha build.
Is there a way to get the Chinese version camera app to our phones (meaning official MM update)?
I recently bricked my EVA-AL00 from installing Magisk and I'm using Tecalote's post (https://forum.xda-developers.com/showpost.php?p=77560239&postcount=27389) to resolve it.
I downloaded the update zip file (first result on https://pro-teammt.ru/firmware-database/?firmware_model=eva-al00&firmware_page=0), extracted, then used the Extractor software to extract UPDATE.APP. However, the Extractor tool did not show either ramdisk.img or boot.img. Only files are: CURVER.img, EFI.img, PACKAGE_TYPE.img, SHA256RSA.img, VERLIST.img, VERSION.img, crc.img and cust.img.
Could someone please help me find the right file?
george.tian said:
I recently bricked my EVA-AL00 from installing Magisk and I'm using Tecalote's post (https://forum.xda-developers.com/showpost.php?p=77560239&postcount=27389) to resolve it.
I downloaded the update zip file (first result on https://pro-teammt.ru/firmware-database/?firmware_model=eva-al00&firmware_page=0), extracted, then used the Extractor software to extract UPDATE.APP. However, the Extractor tool did not show either ramdisk.img or boot.img. Only files are: CURVER.img, EFI.img, PACKAGE_TYPE.img, SHA256RSA.img, VERLIST.img, VERSION.img, crc.img and cust.img.
Could someone please help me find the right file?
Click to expand...
Click to collapse
It must be FullOTA-MF, not OTA-MF, you must first unzip update.zip and then open update.app by Huawei Update Extractor.
You can also download b540 FullOTA from Firmware Finder, see eg
https://forum.xda-developers.com/showpost.php?p=78511904&postcount=1261
IMO, would be better to obtain support if you asked through HWOTA7 thread
Anyway, on my Mega, there are various stock kernels, ramdisks, etc from b535, b539 and b540, including b540 ramdisk patched for Magisk v18.
I've been using it and several other users and it worked fine
https://mega.nz/#F!JwkVyRya!Rb7OUE0z3PEpXBRxGOM-vQ
However, if you recived OTA Patch02 for b540, you will need to patch/install Magisk by checking both Preserving Encryption and Preserving AVB - for b535, b539 and b540 before Patch02, Preserving AVB was not needed. (only Preserve Encryption)
I'm currently back on b535, but with OTA Patch02, you can find on my Mega also its patched ramdisk, but again, because of Patch02, it was needed now to check also Preserve AVB.
If you are already on b540 with Patch02, I"m not sure if its stock ramdisk is the same as for b540 before Patch02 (probably yes, because OTA Patch02 was only few MB)
You can also extract ramdisk from your currently installed firmware directly from Oreo TWRP, go to Advanced, Terminal and use the command
Code:
dd if=/dev/block/bootdevice/by-name/ramdisk of=/external_sd/ramdisk.img
Extracted ramdisk.img will be saved to external SD card.
You can do the same from TWRP also for kernel and system - however, not for data partition (since TWRP lacks support to read encrypted data partition)
Hey please I'm looking for boot _recovery_crc.img
Eteon x said:
Hey please I'm looking for boot _recovery_crc.img
Click to expand...
Click to collapse
Hi there,
Without information about which device you have (model number, Android version, build number, custom version) it is not possible to give you a suitable tip.
It would also be helpful to know why you need a specific image.
Up to Android 7 there was a boot.img and a recovery.img, as well as a recovery2.img.
From Android 8 on there was no longer a boot.img, but instead the ramdisk.img. And for the recovery the so-called recovery_ramdisk.img.
Both images are different for each firmware, which is why precise information is necessary. The images can be extracted from the Update.App.
To do this, the firmware suitable for the device must be downloaded.
A xxx.crc.img is meaningless because it's just a checksum and not an image to flash!
Tecalote said:
Hi there,
Without information about which device you have (model number, Android version, build number, custom version) it is not possible to give you a suitable tip.
It would also be helpful to know why you need a specific image.
Up to Android 7 there was a boot.img and a recovery.img, as well as a recovery2.img.
From Android 8 on there was no longer a boot.img, but instead the ramdisk.img. And for the recovery the so-called recovery_ramdisk.img.
Both images are different for each firmware, which is why precise information is necessary. The images can be extracted from the Update.App.
To do this, the firmware suitable for the device must be downloaded.
A xxx.crc.img is meaningless because it's just a checksum and not an image to flash!
Click to expand...
Click to collapse
I was trying to flash an XML file from a board firmware using IDT and it's showing me that
Eteon x said:
I was trying to flash an XML file from a board firmware using IDT and it's showing me that
Click to expand...
Click to collapse
Your Screenshot shows a Huawei p10 VTR Board firmware.
But this Thread is for P9, not for P10.
Is your device a Huawei P10?
Please ask in the Huawei P10 Forum.
I can't help you with IDT flashing method.
I worked for such cases only with ChimeraTool and sometimes with DC Phoenix. (Both are paid Services)
Open phone app dial *#899#
Tap on software version
Check if it matches with mine.
First create a backup folder and move these images
1)Patch boot.img with Magisk app.
2)Unlock your bootloader. (In depth test
Link: https://drive.google.com/file/d/1F43p7WggEYIIKe8CwilTg41su3W8S3du/view)
3)Disable dm verity.
4)Flash patched boot image.
Hi all,
Thanks for the great work on Magisk.
Predicament - need to be rooting multiple S20 devices often.
Current Process - Unlock Bootloader, Setup Phone (install Magisk) -> Copy AP File -> Patch File in Magisk App ->> Copy Patched TAR to PC -> Use Odin to Flash. Rinse and Repeat...
So my question is.... is there a better way to do this and speed up the process for multiple phones?
My main queries...
1 . Does the patch process do the same thing (i.e. generate the same AP file) on all of the devices (same model)
1a. If so then can i just flash the same patched file to all phones?
2. Can the patching file from within the Magisk app be done on a PC instead to prevent needing to copy file to/from the phone and use the Magisk app - i.e. can i emulate it or extract the patching logic to run elsewhere?
3. Any other suggestions to automate/speed up this process??
Many thanks!
1. Patching can be done from any phone and not just the target device.
2. If all phones are on same firmware version and are same device without any changes (same model, same region etc...), Then you can use the same patch file used on 1 successful phone to other.
3. Patching can only be done by Android app.
Thanks for the quick response, that's good news!
Out of interest why the is patching only possible from Android? can this process not be extracted and ran on a PC to modify the boot file?