Related
My phone have stucked in safe mode long time（so sad...）,because the volume button are very difficult to control.I try to research some information:
frameworks/base/policy/src/com/android/internal/policy/impl/PhoneWindowManager.java
feMode= menuState > 0 ....................................." this line change into "mSafeMode = false "
So I extract system.sin from Adroid 4.3 TFT，and open it.But the file “frameworks” isn"t have base file,if I find,I also don't konw how to edit java file,replace the file and pack them...
Moreover，the file ”qwerty.kl“，if I delete the “key 114 VOLUME_DOWN"&"key 115 VOLUME_UP ",would I enter safe mode when boot？
Can anyone give me advice？I am not good at English，thanks a lot...
MESSAGE ME FOR THE DOWNLOADABLE FILES, I CANNOT PUT THE LINK, IM JUST A NEW MEMBER HERE. THANK YOU
REQUIREMENTS
adb and USB drivers (if you’re already installed this drivers, skip this)
QPST
Hex Editor
IMEI Converter
.qcn file
Rooted phone (recommended)
Getting your IMEI:
You can get your IMEI at your phone factory box or inside the phone, and take note them to notepad.
Setting up your phone:
Go to Settings/About and rapidly tap the Build Number, until the “You are now a developer” appears, then go back to Settings/Developer options.
Enable USB debugging mode
Connect your device to your computer, and if your phone notifies an RSA key, press Remember my Choice, and press Allow/Accept.
Go to Command Prompt or Windows PowerShell on your computer, then type this command:
Code:
adb shell
su
setprop sys.usb.config diag,adb
Don’t disconnect your phone. We will use it later on QPST.
Converting IMEI to Hex values:
Open IMEI Converter.exe
Type your IMEI 1 then press convert, copy the converted IMEI to your notepad.
Type your IMEI 2 then press convert, copy again the converted IMEI to your notepad.
Editing your .qcn file:
Open the .qcn file you’ve downloaded on HxD
Find (Ctrl +F) “08 8A 56 48 03 42 40 12 43”, set Datatype to “Hex-values,” and Search Direction to “All.”
Replace it with your converted IMEI 1 earlier.
Find again “08 8A 56 48 03 42 40 12 24”
Replace it with your converted IMEI 2 earlier.
Save it to Desktop for easy find.
Restoring .qcn:
Install QPST.exe or Setup.exe, and wait to finish installation.
After the installation, search and open QPST Configuration.
Go to Ports/Add New Port, uncheck “Show Serial and USB/QC Diagnostics only,” click OK.
A new port will appear on the box.
Go to Start Clients/Software Download. Navigate to “Restore” tab.
If your Device/COM appears on “Port,” browse your .qcn file that you edited earlier, and open it.
Click “Start,” and wait for the process to finish.
Exit QPST and reboot your device.
Finally, checking your IMEI:
On your device, go to Dialer/Phone, then dial *#06#.
It will show the 2 IMEIs of your device.
CONGRATULATIONS!!!!!!!!!!!!!
:victory::victory::victory::victory::good::laugh:
HELP
Does it need to be rooted? I have non-rooted, stock Android One 2nd-Gen that have NO SIGNAL. All connections (WiFi, Bluetooth) are OK. Cellular signal is NOT OK.
HEXEDIT
i put the qcn on hexedit and search with the converted imei NO MATCH FOUND where i did it wrong
turx said:
Does it need to be rooted? I have non-rooted, stock Android One 2nd-Gen that have NO SIGNAL. All connections (WiFi, Bluetooth) are OK. Cellular signal is NOT OK.
Click to expand...
Click to collapse
if you managed to switch on your diag mode without rooting then its OK. Otherwise you can' t use
Code:
phone:$ su
.
Qcn
bro i need qcn file for Find (Ctrl +F) “08 8A 56 48 03 42 40 12 43
bro my mi a1 is not showing imei and have noo network signal, please share files so i can perform above operation
no works in Huawei kirin 960 ????
aureliomilitao said:
no works in Huawei kirin 960 ????
Click to expand...
Click to collapse
bro its work only qualcom
[email protected] said:
i put the qcn on hexedit and search with the converted imei NO MATCH FOUND where i did it wrong
Click to expand...
Click to collapse
same here bro plzz help somebody
Imei related issue
In. Hex editor when i search in converted imei it says cant find plzz help
I did it on my Redmi 7 device QFIL status is successful but imei is not updating
This Method is only valid for Qualcomm devices ,what for MTK devices like redmi note 8 pro like stuffs plz reply
Note 8 Qualcomm after restore QCN imei back but signals not working, what missing ?
PHONE IS ROOTED BUT DIAG MODE NOT SHOWING
Redmi Note 8T, phone is rooted.
adb shell
willow:/ $ su
Permission denied
13|willow:/ $
Hi all!
I have an asus memo pad me176cx. I did some stuff with it and now it seems bricked, but not fully (as I hope...).
But I am not very experienced user with android, so I have a few adjacent questions to define myself in root concepts.
On general - I tried to install debian linux on my tablet. Looking ahead - i managed to run installer. But in order...
My actions before i got brick.
I got an issue similar to this one after updates. There i saw that tablet has a kind of uefi. And i decided to run debian. Prepared usb-installer, connected that one and keyboard via OTG by hub(i have one with led indicator). I pressed F2 and power button on tablet, and saw uefi. There did boot override -> UEFI jet flash. And debian installer ran succesfully.
But after about a minute on-hub led becomes dark, as did flash led. Kbd was not working. At that moment i was on network config step and decided to reboot tablet. Power button about 10sec - and all over again. But after a while - same issue. It would not be nice if flash comes down while packages copying - I thought. And... Of cause boot into uefi to search some otg-power-options (btw i got same behaviour with otg in uefi and was forced to make changes quickly or reboot).
I don`t remember what option exactly i changed, but i have only hw buttons on tablet working. No otg at all (led is always dark now, no flash none kbd works), no touchscreen (i have twrp installed and checked there).
Finally, what works.
I can press vol+ - vol- - pwr, then see "Fastboot startnig... #1 #2 #3" on display - and get into some mode, called DNX (as i googled).
Code:
fastboot devices
shows my tablet. But i can flash only osloader partition. Other way - error, unsupported operation. Also i can command
Code:
fastboot boot droidboot.img
and get into bootloader. This case at the bottom of screen shown "Waiting for fastboot cmd...". But
Code:
fastboot devices
shows notheng. Any other fastboot commands stuck on "wating for any device...". But with vol-buttons i can choose recovery mode, then press power and get into twrp and look on "Swipe to allow filesystem modification". But as far as touchscreen dows not work (as otg-keyboard) - i can`t do anything else. adbd seems not started yet, as
Code:
adb devices
shows nothing (or micro-usb plug simply disabled with uefi). And that is all, i can`t do anything else...
In fine, my questions are:
Mode started by "vol+ - vol- - pwr" - does it DNX or fastboot? How to find out what commnds i can run there? (At the moment I know 2 only: flash osloader and boot). Why flash ESP, erase, even get [some_var] does not work here? Is there a way to re-flash or reset uefi settings from this mode?
Or any other ways to reset uefi? (as possible without microwave...)
Also, what difference between osloader and bootloader? I suggest that osloader is a partition and bootloader is a program placed in that partition. But what exactly i do with command "fastboot flash osloader efilinux.efi"?
Sorry for lot of text, but I actualy don`t know how this modes called and got confused. Any help would be appriciated.
Anyway, thanks a lot!
mk3pq28 said:
I don`t remember what option exactly i changed, but i have only hw buttons on tablet working. No otg at all (led is always dark now, no flash none kbd works), no touchscreen (i have twrp installed and checked there).
Click to expand...
Click to collapse
I think I've seen some option that changes the way USB OTG is set up. By changing it you have probably disabled USB OTG entirely now... :/
mk3pq28 said:
Mode started by "vol+ - vol- - pwr" - does it DNX or fastboot?
Click to expand...
Click to collapse
DNX
mk3pq28 said:
How to find out what commnds i can run there? (At the moment I know 2 only: flash osloader and boot). Why flash ESP, erase, even get [some_var] does not work here?
Click to expand...
Click to collapse
DNX is not a full fastboot implementation. It runs in the firmware, somewhere during early UEFI initialization. It's mostly designed for recovery when the (Android) bootloader is no longer working. The two commands you know are the only ones I'm aware of, sorry :/
mk3pq28 said:
Is there a way to re-flash or reset uefi settings from this mode?
Or any other ways to reset uefi? (as possible without microwave...)
Click to expand...
Click to collapse
I can imagine that it is possible but I have to admit that I don't know how. For example there is Intel® Platform Flash Tool Lite that allows re-flashing pretty much all of the device, but I'm not sure where you'd get the factory files. At the moment, I don't have any suggestions how to solve your problem... :/
mk3pq28 said:
Also, what difference between osloader and bootloader? I suggest that osloader is a partition and bootloader is a program placed in that partition. But what exactly i do with command "fastboot flash osloader efilinux.efi"?
Click to expand...
Click to collapse
osloader refers to the EFI application that is started. efilinux.efi is an Android bootloader for UEFI. In this case it's not actually written persistently somewhere, it is just loaded into RAM and then executed.
lambdadroid,
first of all - thanks a lot for your participating!
So, after your clarification I made a few suggestions.
lambdadroid said:
I can imagine that it is possible but I have to admit that I don't know how. For example there is Intel® Platform Flash Tool Lite that allows re-flashing pretty much all of the device, but I'm not sure where you'd get the factory files.
Click to expand...
Click to collapse
First one. I installed it and downloaded service firmware. Flash tool found my tablet and showed some info:
Plaform: Intel Corporation
Hardware: Intel Android AD
Status: DNX_OS
Connected on port: 0/1 (number of usb port, i think)
DnX SN: Baytrail<some>
Then i selected service firmware and flash tool showed me flash.xml in "flash file" field. Everything looks normal at the moment, until i pressed flash)
The only one record appeared in log below: "Failed to reboot the device. Flash failed". And i don`t know someshing else i can make here.
I am new here and can`t post links to outside, but i googled some more meaningful examples of log by my error. And as i understood chain of commands - flash tool does exactly same as i did. I.e. flashes osloader in dnx mode, then boots in fastboot and flashes another partitions there. Correct me if i`m wrong but it does not seems for my case, unfortunately
And the second one, more complex.
I had googled a lot about uefi and it`s settings location. I found out that "settings" made in uefi are stored in memory called NVRAM. It is non-volatile and can not be reset by battery disconnected (yes, i tried that, ofc). But there should be a flag called NVRAM_IS_VALID. And once it gets disabled - uefi is forced to reset all the settings to defaults next boot time. I`m not sure, but looks like my solution!
And I can suggest two ways of setting this flag.
lambdadroid said:
osloader refers to the EFI application that is started. efilinux.efi is an Android bootloader for UEFI.
Click to expand...
Click to collapse
First one - uefi shell. If i can replace bootloader, may it be a shell? I downloaded one from github (a link should be here ) but have no success yet. It`s size about 930kb, but my working one bootloader - is 2mb. And when i make flash - nothing happens:
Code:
# fastboot flash osloader Shell.efi
target didn't report max-download-size
sending 'osloader' (929 KB)...
Nothing more. Maybe there should be some special kind of uefi-shell for android? Or I can`t flash nothing but bootloder into osloader partition at all? But even if i`m succeed - i`m not sure that uefi would not disable otg before shell get running.
So my second and the last sugesstion. It`s fully theoretical, but... I need to write a custom efi app (.efi files are kind of applications for uefi, written in c, right?) that would be flashed into osloader and should disable NVRAM_IS_VALID flag (ohh, does that flag exists at all?...). Does it possible?
Anyway, thanks a lot for any help!
mk3pq28 said:
I installed it and downloaded service firmware. Flash tool found my tablet and showed some info:
Plaform: Intel Corporation
Hardware: Intel Android AD
Status: DNX_OS
Connected on port: 0/1 (number of usb port, i think)
DnX SN: Baytrail<some>
Then i selected service firmware and flash tool showed me flash.xml in "flash file" field. Everything looks normal at the moment, until i pressed flash)
The only one record appeared in log below: "Failed to reboot the device. Flash failed". And i don`t know someshing else i can make here.
I am new here and can`t post links to outside, but i googled some more meaningful examples of log by my error. And as i understood chain of commands - flash tool does exactly same as i did. I.e. flashes osloader in dnx mode, then boots in fastboot and flashes another partitions there. Correct me if i`m wrong but it does not seems for my case, unfortunately
Click to expand...
Click to collapse
Okay, yeah, that's very well possible. I've never used that tool and don't know what it does.
mk3pq28 said:
I had googled a lot about uefi and it`s settings location. I found out that "settings" made in uefi are stored in memory called NVRAM. It is non-volatile and can not be reset by battery disconnected (yes, i tried that, ofc). But there should be a flag called NVRAM_IS_VALID. And once it gets disabled - uefi is forced to reset all the settings to defaults next boot time. I`m not sure, but looks like my solution!
Click to expand...
Click to collapse
It makes sense that the settings are stored in the NVRAM. But that's about all I can comment on; I'm not sure if that flag exists on this tablet or even if it will reset to the correct results.
mk3pq28 said:
uefi shell. If i can replace bootloader, may it be a shell? I downloaded one from github (a link should be here ) but have no success yet. It`s size about 930kb, but my working one bootloader - is 2mb. And when i make flash - nothing happens:
Code:
# fastboot flash osloader Shell.efi
target didn't report max-download-size
sending 'osloader' (929 KB)...
Nothing more. Maybe there should be some special kind of uefi-shell for android? Or I can`t flash nothing but bootloder into osloader partition at all? But even if i`m succeed - i`m not sure that uefi would not disable otg before shell get running.
Click to expand...
Click to collapse
You may need to run "fastboot boot droidboot.img" (or any other image) too to have Fastboot run the EFI application. The Shell application will then likely ignore the additional boot image. However, as you mention, I believe that OTG will get disabled before the shell is running. The UEFI shell application is no different from the UEFI Setup as far as OTG is concerned. So if you are unable to enter the setup with F2 then the UEFI shell will probably not work either. So even if the Shell starts, I doubt that you will be able to run commands.
And no, there is no special kind of UEFI Shell for Android. This is all unrelated to Android actually.
mk3pq28 said:
It`s fully theoretical, but... I need to write a custom efi app (.efi files are kind of applications for uefi, written in c, right?) that would be flashed into osloader and should disable NVRAM_IS_VALID flag (ohh, does that flag exists at all?...). Does it possible?
Click to expand...
Click to collapse
That's actually something I considered suggesting yesterday. I decided against it because it's obviously not trivial and I'm not sure if EFI applications can actually access that flag or BIOS settings in general... However, I can assist you with how to write EFI applications in general. They are usually written in C and then compiled using some funky compiler flags and tools to .efi.
An example for a very simple EFI application is "bootstrap.efi" that is used in me176c-boot. The source for it is available at https://github.com/me176c-dev/me176c-boot/tree/master/bootstrap
In me176c-boot it runs as first EFI application and checks if the tablet was booted due to charger insertion; if yes then it sets an EFI variable. I'm not sure if the flag you mention is exposed as an EFI variable. However, persistent EFI variables are also stored in the NVRAM, so that might be something to look at. It's built using Meson (see meson.build). The build script might be of help to you.
lambdadroid said:
That's actually something I considered suggesting yesterday. I decided against it because it's obviously not trivial and I'm not sure if EFI applications can actually access that flag or BIOS settings in general...
Click to expand...
Click to collapse
But I don`t see any other kind of solution.
lambdadroid said:
It makes sense that the settings are stored in the NVRAM. But that's about all I can comment on; I'm not sure if that flag exists on this tablet or even if it will reset to the correct results.
Click to expand...
Click to collapse
I think it won`t get worse anyway, so...
Thanks a lot for your general information about efi. I took that and was able to get started. I did some experiments and had interesting results. Little notice - i`m on debian.
At first
I had installed gnu-efi and mason. Also googled "Hello world" in efi-style. I still cant post links to outside but the code is below. Looking ahead - had no result with one Print because it was closed very fast so i added a loop.
Code:
#include <efi.h>
#include <efilib.h>
EFI_STATUS
EFIAPI
efi_main (EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
{
InitializeLib(ImageHandle, SystemTable);
for (int i = 0; i < 5000; ++i)
{
Print(L"B It works!!!\r\n");
}
return EFI_SUCCESS;
}
Looks simple.
Also i took your meson.build and replaced file names with mine. But i got a few conpilation errors so i had removed some keys from target. Here it is:
Code:
project('tutorial', 'c')
arch = host_machine.cpu_family()
efi_include_dir = '/usr/include/efi'
efi_include = include_directories(
efi_include_dir,
join_paths(efi_include_dir, arch),
is_system: true
)
efi_lds = '/usr/lib/elf_' + arch + '_efi.lds'
efi_crt = '/usr/lib/crt0-efi-' + arch + '.o'
bootstrap_lib = shared_library('bootstrap',
'hello_efi.c',
include_directories: [efi_include],
objects: [efi_crt],
link_args: [
'-T', efi_lds,
'-nostdlib',
'-z', 'nocombreloc',
'-Wl,-Bsymbolic',
'-lefi', '-lgnuefi'
]
)
objcopy = find_program('objcopy')
custom_target('bootstrap.efi',
output: 'bootstrap.efi',
input: bootstrap_lib,
command: [objcopy,
'--target=efi-app-' + arch,
'-j', '.text',
'-j', '.sdata',
'-j', '.data',
'-j', '.dynamic',
'-j', '.dynsym',
'-j', '.rel',
'-j', '.rela',
'-j', '.reloc',
'@[email protected]', '@[email protected]'
],
install: true,
install_dir: ''
)
hello_efi.c contains source code from above.
This is my first meson build so if yoy see some obvious mistakes or excess options - i would be much appreciated if you point on them.
At second
I created builddir, commanded "meson" and "ninja" and got such output:
Code:
[1/3] Compiling c object '[email protected]/hello_efi.c.o'
../hello_efi.c: In function ‘efi_main’:
../hello_efi.c:13:9: warning: passing argument 1 of ‘Print’ from incompatible pointer type [-Wincompatible-pointer-types]
Print(L"B It works!!!\r\n");
^~~~~~~~~~~~~~~~~~~~
In file included from ../hello_efi.c:2:0:
/usr/include/efi/efilib.h:404:1: note: expected ‘CHAR16 * {aka short unsigned int *}’ but argument is of type ‘int *’
Print (
^~~~~
[3/3] 'Generating bootstrap.efi with a custom command.'
I am not very familiar with C and can`t get rid of warning to print my message properly. As far as Print requires CHAR16 pointer only first symbol is printed. How to properly get and array of CHAR16 from "a string"?
Anyway, it`s a bite of success.
And at third, final
I was very happy and connected tab (in DNX, ofc) with pc and commaned: "fastboot flash osloader bootstrap.efi".
Code:
target didn't report max-download-size
sending 'osloader' (44 KB)...
And nothing more. Command is still running untill tablet reboot. But!
I have another ont efilinux.efi was downloaded from somewhere. And it flashes correctly! The only difference is on size: 44KB vs 2MB.
I did some research with dd-util and found one interesting thing. It is allowed to flash osloader partition in dnx mode with completely any binary data within (nearly) 1MB .. 20MB. In this case "fastboot flash osloader ..." says OK twice and finishes properly.
So, my flow after compilation have a such look (2057216 - is a size of my working example efilinux.efi)
Code:
$ dd if=/dev/zero of=container.efi count=2057216 iflag=count_bytes
$ dd if=bootstrap.efi of=container.efi conv=nocreat,notrunc
# fastboot flash osloader container.efi
# fastboot boot droidboot.img
... and i have a char 'B' on screen printed 5000 times. I think it`s another one bite of success
But i can`t find any docs for efi.h (efilib.h). Which capabilities they provides? What is set of functinos?
There is another example with
Code:
uefi_call_wrapper(ST->ConOut->OutputString, 2, ST->ConOut, L"Hello World!\n");"
but it is not obvious how to work with uefi services in this way.
I googled that most of uefi settings are stored in "Setup" variable. I think it may be useful at least to print them. But don`t know how, yet.
I will google it further but in general i don`t know what is the next step should be.
Also i have an idea to use such trick to flash efi-shell. But didn`t tried yet.
mk3pq28 said:
At first
I had installed gnu-efi and mason. Also googled "Hello world" in efi-style. I still cant post links to outside but the code is below. Looking ahead - had no result with one Print because it was closed very fast so i added a loop.
Code:
#include <efi.h>
#include <efilib.h>
EFI_STATUS
EFIAPI
efi_main (EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
{
InitializeLib(ImageHandle, SystemTable);
for (int i = 0; i < 5000; ++i)
{
Print(L"B It works!!!\r\n");
}
return EFI_SUCCESS;
}
Looks simple.
Also i took your meson.build and replaced file names with mine. But i got a few conpilation errors so i had removed some keys from target. Here it is:
Code:
project('tutorial', 'c')
arch = host_machine.cpu_family()
efi_include_dir = '/usr/include/efi'
efi_include = include_directories(
efi_include_dir,
join_paths(efi_include_dir, arch),
is_system: true
)
efi_lds = '/usr/lib/elf_' + arch + '_efi.lds'
efi_crt = '/usr/lib/crt0-efi-' + arch + '.o'
bootstrap_lib = shared_library('bootstrap',
'hello_efi.c',
include_directories: [efi_include],
objects: [efi_crt],
link_args: [
'-T', efi_lds,
'-nostdlib',
'-z', 'nocombreloc',
'-Wl,-Bsymbolic',
'-lefi', '-lgnuefi'
]
)
objcopy = find_program('objcopy')
custom_target('bootstrap.efi',
output: 'bootstrap.efi',
input: bootstrap_lib,
command: [objcopy,
'--target=efi-app-' + arch,
'-j', '.text',
'-j', '.sdata',
'-j', '.data',
'-j', '.dynamic',
'-j', '.dynsym',
'-j', '.rel',
'-j', '.rela',
'-j', '.reloc',
'@[email protected]', '@[email protected]'
],
install: true,
install_dir: ''
)
hello_efi.c contains source code from above.
This is my first meson build so if yoy see some obvious mistakes or excess options - i would be much appreciated if you point on them.
At second
I created builddir, commanded "meson" and "ninja" and got such output:
Code:
[1/3] Compiling c object '[email protected]/hello_efi.c.o'
../hello_efi.c: In function ‘efi_main’:
../hello_efi.c:13:9: warning: passing argument 1 of ‘Print’ from incompatible pointer type [-Wincompatible-pointer-types]
Print(L"B It works!!!\r\n");
^~~~~~~~~~~~~~~~~~~~
In file included from ../hello_efi.c:2:0:
/usr/include/efi/efilib.h:404:1: note: expected ‘CHAR16 * {aka short unsigned int *}’ but argument is of type ‘int *’
Print (
^~~~~
[3/3] 'Generating bootstrap.efi with a custom command.'
I am not very familiar with C and can`t get rid of warning to print my message properly. As far as Print requires CHAR16 pointer only first symbol is printed. How to properly get and array of CHAR16 from "a string"?
Anyway, it`s a bite of success.
Click to expand...
Click to collapse
I believe the compiler argument that avoids this error is -fshort-wchar, but you seem to have removed all c_args: https://github.com/me176c-dev/me176c-boot/blob/master/bootstrap/meson.build#L33 All of these compiler arguments have a purpose, can you check which one is causing errors exactly and post the error here?
mk3pq28 said:
And at third, final
I was very happy and connected tab (in DNX, ofc) with pc and commaned: "fastboot flash osloader bootstrap.efi".
Code:
target didn't report max-download-size
sending 'osloader' (44 KB)...
And nothing more. Command is still running untill tablet reboot. But!
I have another ont efilinux.efi was downloaded from somewhere. And it flashes correctly! The only difference is on size: 44KB vs 2MB.
I did some research with dd-util and found one interesting thing. It is allowed to flash osloader partition in dnx mode with completely any binary data within (nearly) 1MB .. 20MB. In this case "fastboot flash osloader ..." says OK twice and finishes properly.
So, my flow after compilation have a such look (2057216 - is a size of my working example efilinux.efi)
Code:
$ dd if=/dev/zero of=container.efi count=2057216 iflag=count_bytes
$ dd if=bootstrap.efi of=container.efi conv=nocreat,notrunc
# fastboot flash osloader container.efi
# fastboot boot droidboot.img
Click to expand...
Click to collapse
That's weird, the size shouldn't matter at all. But it doesn't really matter, as long as it works.
mk3pq28 said:
But i can`t find any docs for efi.h (efilib.h). Which capabilities they provides? What is set of functinos?
There is another example with
Code:
uefi_call_wrapper(ST->ConOut->OutputString, 2, ST->ConOut, L"Hello World!\n");"
but it is not obvious how to work with uefi services in this way.
I googled that most of uefi settings are stored in "Setup" variable. I think it may be useful at least to print them. But don`t know how, yet.
I will google it further but in general i don`t know what is the next step should be.
Click to expand...
Click to collapse
Generally, the interface exposed by gnu-efi is according to the UEFI specification: http://www.uefi.org/sites/default/files/resources/UEFI Spec 2_7_A Sept 6.pdf
In there you can find a list of protocols you can use, e.g. search for the "OutputString" method used above.
uefi_call_wrapper is an implementation detail of gnu-efi, but basically it's uefi_call_wrapper(<method>, <number of parameters>, <parameters...>).
The main remaining question, and the one I can't really help you with is how you can reset your BIOS settings using the UEFI application API. Maybe something to look at first would be the "Variable Services" (see UEFI specification). Maybe you can change one of the EFI variables to restore the default BIOS settings.
lambdadroid said:
I believe the compiler argument that avoids this error is -fshort-wchar, but you seem to have removed all c_args: https://github.com/me176c-dev/me176c-boot/blob/master/bootstrap/meson.build#L33 All of these compiler arguments have a purpose, can you check which one is causing errors exactly and post the error here?
Click to expand...
Click to collapse
Yes, this key removed warning. Thanks.
lambdadroid said:
Generally, the interface exposed by gnu-efi is according to the UEFI specification: http://www.uefi.org/sites/default/files/resources/UEFI Spec 2_7_A Sept 6.pdf
In there you can find a list of protocols you can use, e.g. search for the "OutputString" method used above.
Click to expand...
Click to collapse
Exactly one i`m looking for. Thanks again!
Unfortunately there is nothing about NVRAM_IS_VALID there.
But there is a function called "ResetSystem()" (p.269). It should reset the entire platform as written in doc.
My code:
Code:
#include <efi.h>
#include <efilib.h>
EFI_STATUS
EFIAPI
#define SLEEP 100
efi_main (EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
{
InitializeLib(ImageHandle, SystemTable);
for (int i = 0; i < SLEEP; ++i)
{
Print(L"It works!!! #%d", i);
uefi_call_wrapper(ST->ConOut->OutputString, 2, ST->ConOut, L"\r\n");
}
int res = uefi_call_wrapper(RT->ResetSystem, 4, EfiResetCold, EFI_SUCCESS, 0, NULL);
for (int i = 0; i < SLEEP; ++i) Print(L"%d\r\n", res);
return EFI_SUCCESS;
}
}
Yes, i`d noticed that "The ResetSystem() function does not return".
But i`m not sure that i call it properly.
When i run the code above - it prints the message 100 times, then screen blinks and the next message appears: "EFILINUX ERROR [start_boot_logic:498] No valid target found.
Fallbacking to MOS" in about 3 sec. Looks like there no reboot in this case because of the intel logo is not shown. I have no system on my tablet, but it`s another story.
The main point is there is no black screen with intel logo for about 15-20 sec as in case of normal boot.
In addition i tried to change call with:
Code:
uefi_call_wrapper(RT->ResetSystem, 4, L"Wrong_argument", EFI_SUCCESS, 0, NULL)
and it prints "968832152" return code. Does it fail somewhere before ResetSystem() or exactly inside?
So am i calling this function correctly?
mk3pq28 said:
Yes, this key removed warning. Thanks.
Exactly one i`m looking for. Thanks again!
Unfortunately there is nothing about NVRAM_IS_VALID there.
But there is a function called "ResetSystem()" (p.269). It should reset the entire platform as written in doc.
My code:
Code:
#include <efi.h>
#include <efilib.h>
EFI_STATUS
EFIAPI
#define SLEEP 100
efi_main (EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
{
InitializeLib(ImageHandle, SystemTable);
for (int i = 0; i < SLEEP; ++i)
{
Print(L"It works!!! #%d", i);
uefi_call_wrapper(ST->ConOut->OutputString, 2, ST->ConOut, L"\r\n");
}
int res = uefi_call_wrapper(RT->ResetSystem, 4, EfiResetCold, EFI_SUCCESS, 0, NULL);
for (int i = 0; i < SLEEP; ++i) Print(L"%d\r\n", res);
return EFI_SUCCESS;
}
}
Yes, i`d noticed that "The ResetSystem() function does not return".
But i`m not sure that i call it properly.
When i run the code above - it prints the message 100 times, then screen blinks and the next message appears: "EFILINUX ERROR [start_boot_logic:498] No valid target found.
Fallbacking to MOS" in about 3 sec. Looks like there no reboot in this case because of the intel logo is not shown. I have no system on my tablet, but it`s another story.
The main point is there is no black screen with intel logo for about 15-20 sec as in case of normal boot.
In addition i tried to change call with:
Code:
uefi_call_wrapper(RT->ResetSystem, 4, L"Wrong_argument", EFI_SUCCESS, 0, NULL)
and it prints "968832152" return code. Does it fail somewhere before ResetSystem() or exactly inside?
So am i calling this function correctly?
Click to expand...
Click to collapse
I'm afraid ResetSystem() is not what you are looking for: ResetSystem() is only used to reboot the system, it does not "reset" any settings. So the screen flashes and you see that message because the tablet is restarted normally. (The bootloader you are using displays an error if you reboot without setting a "reboot target").
So you need to find some other method, or entirely different solution unfortunately. I just did a bit of research myself, but unfortunately didn't find anything of help..
Hello everyone, I found a recovery tool on the open spaces of the Chinese Internet. This tool is for NE2210 only. It's in Chinese, but I don't think there should be any problems using it. Write who used.
Unbrick
The Msm tool is missing the FTLibBase.dll file it wont work. Just to let you know.
Canuck Knarf said:
The Msm tool is missing the FTLibBase.dll file it wont work. Just to let you know.
Click to expand...
Click to collapse
what is the file responsible for FTLibBase.dll ??
For me. I'm using win 11 and the Msm tools will not open .??? Maybe it a win 11 thing. It starts to open but then errors pop up missing the dill file . Did you install it by an exe file.
I want to try it ...lol...I have one more boot loop / dead battery 10 plus pro
I have been trying this fast boot command to get battery up enough to load boot file, vender_boot and vbmeta file. But after it dose a factory wipe ...kills battery wont reboot.
Using this command i started out with 6708 volts of battery took running command in fastboot 30 minutes to get to 6762 volts. So command dose work .
@Echo off
:start
fastboot getvar battery-voltage
fastboot reboot-bootloader
ping /n 6 localhost >nul
goto start
I need the command to just keep repeating by itself...i can leave it sit there for hours...Can you help ?
Canuck Knarf said:
For me. I'm using win 11 and the Msm tools will not open .??? Maybe it a win 11 thing. It starts to open but then errors pop up missing the dill file . Did you install it by an exe file.
Click to expand...
Click to collapse
I have w11, program starts normal, but not connected server.(((
VovaHouse said:
what is the file responsible for FTLibBase.dll ??
Click to expand...
Click to collapse
Can't you replace this file with OnePlus 9 pro msm tool i don't know where it's for but as long you get the msm tool work then it shouldn't be a problem ain't it ?
bir çözüm buldun mu? Aynı hata bende de var
Did you find a solution? i have the same error
Buyukturk said:
Did you find a solution? i have the same error
Click to expand...
Click to collapse
yeah....MSM and pay
Canuck Knarf said:
yeah....MSM and pay
Click to expand...
Click to collapse
unfortunately i couldn't find it
Canuck Knarf said:
evet.... MSM ve ödeme
Click to expand...
Click to collapse
nasıl çözdün bana yardımcı olurmusun
Buyukturk said:
unfortunately i couldn't find it
Click to expand...
Click to collapse
You can find it in the www
Prob is the msm Tool need a auth. (Acc)
DO NOT BUY ONEPLUS 10 PRO THEY DO NOT PROVIDE ANY TOOLS FROM UNBRICK
DO NOT BUY ONEPLUS 10 PRO THEY DO NOT PROVIDE ANY TOOLS FROM UNBRICK
Sorry for the delayed absence .... lol.. its been a trivial one. But I have been working DILIGENTLY on Oneplus Tools, and ONLY Oneplus Tools... (CanuckKnarf can verify this...)
Ok without breaking "responsible disclosure" guidelines... I can hopefully either clear up some of the chatter ive read up til now, as well as provide some important info which may inspire someone here with a new avenue as to how to attack this thing head on.
Let me start with the most recent statements about the missing files first.
If you have Windows (doesnt matter which version) and you have been running ANY of the official builds of the MSM Tool... (Official releases show an icon like pictured here
{
"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"
}
#1
unofficial (repacked for whatever reason) look like this:
#2
Now while there is no inherent threat to either version... the ones of the LATTER style, MAY OR MAY NOT run, when attempting to execute them. This is because the person who packaged it, MIGHT NOT have been doing so from the actual applications data folder in windows. Allow me to explain:
When you run #1 , that file unpacks itself and generates a folder inside your "/users/appdata/local/" folder and its usually along the lines of "OPPO Flash Tool Series 4.1" .... or a variant of that. IN THIS FOLDER is the actual files for which your MSMTOOL loads all of its config, dll, and other run codes from.
--Now this folder might not be generated if you are already running from a complete msmtool build. a complete build should have several dll's, several folders, and the actual program that is being called, 'FTGUIDev.exe" <-- This is your flash loader! .. This is the Alpha and the Omega so to speak of the MSM TOOL... #2, is the MSM equivalent of a Windows Installer REPACK. I have seen these range from 4mb all the way up to 9gb ... this is because some authors choose to repack the EXACT FW build that is to be used with it! (*** Important note!*** The version of the MSM Tool you are using plays a definitive roll as to whether you have a successful flash, or a fail!. OPPO HAS PLAYED THE SNEAKY ROLE AGAIN, AND IN CERTAIN RELEASES OF THE OTA FW FILES THAT ARE DISTRIBUTED, THEY MAKE A SMALL CHANGE TO ONE OR MORE FILES, WHICH WILL THROW OFF THE FIRMWARE INTEGRITY CHECK!.... BUT INSTEAD OF THE ERROR READING "INTEGRITY FAIL", YOU WILL GET .... PHONE MISMATCH... INVALID HANDLE.... VALIDATION FAIL... OR MAYBE FAIL INTEGRITY.... <----- These errors USED to have individual meaning, but OPPO choose to use them to provide misdirection as to what actually occurred. (( I have found a way to FORGE a passing INTEGRITY CHECK... but i cant disclose that yet, sry)) So now they do not want you to actually have the identifier as to what exactly went wrong that blocked your flash... the validation check is INSTANT... the whole 15 second pause is purely for dramatical effect. The very moment your phone connects in the msmtool and it hits 3%, it has already either PASSED or FAILED the AUTH SIGN requirement... which is LIGHT YEARS down the line from the Integrity Check.
Anyways my point is: If you go to you "appdata/local" msm folder, you shouold be able to pull ANY DLL that is being requested by your programs. The entire library is is locked exclusively to the GENERATION of flash tool available... ie version 4.1 folder will have DLL's for any 4.1.x.x msmtool ... same with version 5.1 => 5.1.x.x. While this is not a perfect science... it is a start, so if you run into any MSM tools that you download and are not able to run, it is because you dont have a full build from that series already installed on your machine. When these guys repack, they might not understand that by NOT packing up all the files DIRECTLY from that Appdata folder, and including ALL of the other folders, they are handicapping those who download them. Easier explanation to offer is this: Beatbreakee has been running Flash Tool v 4.1.7.2 on his machine, and it is the full build being launched from the APPDATA folder... CHRIS has been running 4.1.5.1 and its from an alternate location that DOES have the proper dll files, but they are already registered in his system from usage, and he does not realize that the alternate location is merely a shadow copy and that actual file is linking to his appdata folder.: A new HACKED msm tool comes out, but its a repack and lets say 4.2.0.1 (this is all fake... dont go looking for this hacked version , it dont exist) .... Now the repack is missing some vital DLL files, much like some of you are experiencing. The reason SOME can load and SOME cannot, is because they may have ran a FULL tool from the generation that the repack comes from.... if you have, then windows has already registered the correct DLL files, so it will load like normal.... if you HAVE NOT, you will get missing DLL errors. BUT BEWARE... There is a HIDDEN verification that is of the actual msmtool itself. It will cause you to fail , if the check does not pass, and when altering any portion of the msmtool, i have seen EVERY mod fail this check.
Oppo is smart... they placed PLAIN TEXT files that give the exact FILENAME, CRC, and SIG data for EVERY file that MSM will interact with INCLUDING ITSELF. But these plain text files are backdoor checked by encrypted SIGNED verification files, that check for any modifications to the plain text or xml files. If you alter one of the files or replace it... IT FAILS INSTANTLY... sha doesnt match... if you touch one of the SIG checker files it fails... MSMTool knows the SIG checkers, SIG... kinda a DOUBLE check... but they did this on purpose because they knew ppl would take the bait, and by doing so, thinking they will circumvent the CHECKS... they are actually making the checks work PERFECTLY. The ONLY way around this is through SOMEONE , who is great with DLL and EXE files... and can physically REMOVE or PATCH OUT the 2 checks for the application, as well as the fw integrity. Both validations work to ensure the OTHERS security as well... so if you bypass one validation, the other will fail you for "No validation" of the other file! (make any sense?) They watch each other when getting validated to see if any funny business is going on... any "Malarkey" and they will fail themselves to protect the package. You need to Remove, or patch out BOTH of these checks, which is slightly above my pay grade. If you can remove both of those, and it works, you will be able to have an MSM Tool that can have its config altered to remove model match, project id, and much more, as well as a tool that will accept ANY fw package as long as its in the correct structure. (That is where my info stops because saying more will put me in violation for now) ....
The SECOND bit of info is this:
The 'AUTH SIGN' is not a file generated from any server.... the connection to the server is simply to have it send a PING response back to the application from your phone. That is literally ALL the AUTH SIGN is... now its far more complex than im making it sound because i have yet to generate a valid AUTH but i am working on it. IT COMES from an APK Intent on your phone.... ( a hint is its one of the hidden QTI apk's) .... this apk responds to the PING request, with all of the info that is required as the AUTH .... Now dont get this confused with the MSM AUTH from the application.... The AUTH i am discussing is the one that says "YES" or "NO" when you ask the app to flash your fw.. An invalid response will trigger a NO... because the PING is an IRL stamp that cant be captured and replayed, as its literally specific to the millisecond... But again it is YOUR PHONE that is generating it.... so the MSM TOOL requires an AUTHENTICATED login, before it will communicate to the OPPO server, and tell it to send a PING request to your phone, which then gets sent via USB to your computer. What we have to do is figure out HOW to generate that PING request ourselves.... If we can somehow open a secondary command window, and freeze the process as soon as it requests the AUTH SIGN... then have the command to request the PING, already typed and ready to go in that second window.... and UNFREEZE at the exact same time as we send the command... we should be able to generate the request before the MSM Tool can revalidate itself, which it does before it makes the request. As long as the request is completed BEFORE the OFFICIAL request is made by the server, then it should ignore any other response.... 1st come 1st served.
Thats really all i can say... but sorry to all of you who have wondered if OPPO has made me disappear , or sent a wetwork agent after me... lol
I am just working round the clock on this as well as my normal life.... so i will be sporadic, but as i make breakthroughs i will update... so i hope SOME of that clears SOME things up.. but i leave you with this:
{ "d:193] [E2DBA579] [COM5] <COMMAND> <?xml version=\"1.0\" encoding=\"UTF-8\" ?>\n<data>\n<getsigndata value=\"ping\" />\n</data>\n[2023/03/06 07:24:12][0x34c4][QCFirehose::resolveLogs:55] [E2DBA579] [COM5] <DEVICE LOG> INFO: Calling handler for getsigndata\n[2023/03/06 07:24:12][0x34c4][QCFirehose::resolveLogs:55] [E2DBA579] [COM5] <DEVICE LOG> WARN: format error, i=0\n[2023/03/06 07:24:12][0x34c4][QCFirehose::resolveLogs:55] [E2DBA579] [COM5] <DEVICE LOG> ERROR: cannot get oplusreserve1/opporeserve1. i" }
Its the actual full data from the application attempting to get the AUTH SIGN.... maybe looking over it you might find some insight.
***back to the caves.... see yall in a bit!****
(and btw.. if you attempt to bypass the LOGIN, you will automatically fail the SW integrity check... you need to find a way to REMOVE this completely, and not with a hex editor... the actual instruction must be removed, and then the subsequent request must be removed again from the actual FLASH function called during the AUTH SIGN request, because IT checks for the valid login again. Remove both and you will have an MSM TOOL with a blank slate. The tools themselves are NOT bundled with the individual FW digest data... they simply follow the instructions given in the packages. If you know what files you can and cannot alter, plus you replace the CRC in the checker file, with the NEW valid crc for the edited file, and you make sure to change the metadata of the files you altered , so that they match again with the other files besides them, you can FOOL the Package validation... <--- a key point in being able to flash altered firmware!... Package Validation Fail = Flash Fail!... Stay Vigilant"
beatbreakee said:
Sorry for the delayed absence .... lol.. its been a trivial one. But I have been working DILIGENTLY on Oneplus Tools, and ONLY Oneplus Tools... (CanuckKnarf can verify this...)
Ok without breaking "responsible disclosure" guidelines... I can hopefully either clear up some of the chatter ive read up til now, as well as provide some important info which may inspire someone here with a new avenue as to how to attack this thing head on.
Let me start with the most recent statements about the missing files first.
If you have Windows (doesnt matter which version) and you have been running ANY of the official builds of the MSM Tool... (Official releases show an icon like pictured here View attachment 5855327 #1
unofficial (repacked for whatever reason) look like this: View attachment 5855329 #2
Now while there is no inherent threat to either version... the ones of the LATTER style, MAY OR MAY NOT run, when attempting to execute them. This is because the person who packaged it, MIGHT NOT have been doing so from the actual applications data folder in windows. Allow me to explain:
When you run #1 , that file unpacks itself and generates a folder inside your "/users/appdata/local/" folder and its usually along the lines of "OPPO Flash Tool Series 4.1" .... or a variant of that. IN THIS FOLDER is the actual files for which your MSMTOOL loads all of its config, dll, and other run codes from.
--Now this folder might not be generated if you are already running from a complete msmtool build. a complete build should have several dll's, several folders, and the actual program that is being called, 'FTGUIDev.exe" <-- This is your flash loader! .. This is the Alpha and the Omega so to speak of the MSM TOOL... #2, is the MSM equivalent of a Windows Installer REPACK. I have seen these range from 4mb all the way up to 9gb ... this is because some authors choose to repack the EXACT FW build that is to be used with it! (*** Important note!*** The version of the MSM Tool you are using plays a definitive roll as to whether you have a successful flash, or a fail!. OPPO HAS PLAYED THE SNEAKY ROLE AGAIN, AND IN CERTAIN RELEASES OF THE OTA FW FILES THAT ARE DISTRIBUTED, THEY MAKE A SMALL CHANGE TO ONE OR MORE FILES, WHICH WILL THROW OFF THE FIRMWARE INTEGRITY CHECK!.... BUT INSTEAD OF THE ERROR READING "INTEGRITY FAIL", YOU WILL GET .... PHONE MISMATCH... INVALID HANDLE.... VALIDATION FAIL... OR MAYBE FAIL INTEGRITY.... <----- These errors USED to have individual meaning, but OPPO choose to use them to provide misdirection as to what actually occurred. (( I have found a way to FORGE a passing INTEGRITY CHECK... but i cant disclose that yet, sry)) So now they do not want you to actually have the identifier as to what exactly went wrong that blocked your flash... the validation check is INSTANT... the whole 15 second pause is purely for dramatical effect. The very moment your phone connects in the msmtool and it hits 3%, it has already either PASSED or FAILED the AUTH SIGN requirement... which is LIGHT YEARS down the line from the Integrity Check.
Anyways my point is: If you go to you "appdata/local" msm folder, you shouold be able to pull ANY DLL that is being requested by your programs. The entire library is is locked exclusively to the GENERATION of flash tool available... ie version 4.1 folder will have DLL's for any 4.1.x.x msmtool ... same with version 5.1 => 5.1.x.x. While this is not a perfect science... it is a start, so if you run into any MSM tools that you download and are not able to run, it is because you dont have a full build from that series already installed on your machine. When these guys repack, they might not understand that by NOT packing up all the files DIRECTLY from that Appdata folder, and including ALL of the other folders, they are handicapping those who download them. Easier explanation to offer is this: Beatbreakee has been running Flash Tool v 4.1.7.2 on his machine, and it is the full build being launched from the APPDATA folder... CHRIS has been running 4.1.5.1 and its from an alternate location that DOES have the proper dll files, but they are already registered in his system from usage, and he does not realize that the alternate location is merely a shadow copy and that actual file is linking to his appdata folder.: A new HACKED msm tool comes out, but its a repack and lets say 4.2.0.1 (this is all fake... dont go looking for this hacked version , it dont exist) .... Now the repack is missing some vital DLL files, much like some of you are experiencing. The reason SOME can load and SOME cannot, is because they may have ran a FULL tool from the generation that the repack comes from.... if you have, then windows has already registered the correct DLL files, so it will load like normal.... if you HAVE NOT, you will get missing DLL errors. BUT BEWARE... There is a HIDDEN verification that is of the actual msmtool itself. It will cause you to fail , if the check does not pass, and when altering any portion of the msmtool, i have seen EVERY mod fail this check.
Oppo is smart... they placed PLAIN TEXT files that give the exact FILENAME, CRC, and SIG data for EVERY file that MSM will interact with INCLUDING ITSELF. But these plain text files are backdoor checked by encrypted SIGNED verification files, that check for any modifications to the plain text or xml files. If you alter one of the files or replace it... IT FAILS INSTANTLY... sha doesnt match... if you touch one of the SIG checker files it fails... MSMTool knows the SIG checkers, SIG... kinda a DOUBLE check... but they did this on purpose because they knew ppl would take the bait, and by doing so, thinking they will circumvent the CHECKS... they are actually making the checks work PERFECTLY. The ONLY way around this is through SOMEONE , who is great with DLL and EXE files... and can physically REMOVE or PATCH OUT the 2 checks for the application, as well as the fw integrity. Both validations work to ensure the OTHERS security as well... so if you bypass one validation, the other will fail you for "No validation" of the other file! (make any sense?) They watch each other when getting validated to see if any funny business is going on... any "Malarkey" and they will fail themselves to protect the package. You need to Remove, or patch out BOTH of these checks, which is slightly above my pay grade. If you can remove both of those, and it works, you will be able to have an MSM Tool that can have its config altered to remove model match, project id, and much more, as well as a tool that will accept ANY fw package as long as its in the correct structure. (That is where my info stops because saying more will put me in violation for now) ....
The SECOND bit of info is this:
The 'AUTH SIGN' is not a file generated from any server.... the connection to the server is simply to have it send a PING response back to the application from your phone. That is literally ALL the AUTH SIGN is... now its far more complex than im making it sound because i have yet to generate a valid AUTH but i am working on it. IT COMES from an APK Intent on your phone.... ( a hint is its one of the hidden QTI apk's) .... this apk responds to the PING request, with all of the info that is required as the AUTH .... Now dont get this confused with the MSM AUTH from the application.... The AUTH i am discussing is the one that says "YES" or "NO" when you ask the app to flash your fw.. An invalid response will trigger a NO... because the PING is an IRL stamp that cant be captured and replayed, as its literally specific to the millisecond... But again it is YOUR PHONE that is generating it.... so the MSM TOOL requires an AUTHENTICATED login, before it will communicate to the OPPO server, and tell it to send a PING request to your phone, which then gets sent via USB to your computer. What we have to do is figure out HOW to generate that PING request ourselves.... If we can somehow open a secondary command window, and freeze the process as soon as it requests the AUTH SIGN... then have the command to request the PING, already typed and ready to go in that second window.... and UNFREEZE at the exact same time as we send the command... we should be able to generate the request before the MSM Tool can revalidate itself, which it does before it makes the request. As long as the request is completed BEFORE the OFFICIAL request is made by the server, then it should ignore any other response.... 1st come 1st served.
Thats really all i can say... but sorry to all of you who have wondered if OPPO has made me disappear , or sent a wetwork agent after me... lol
I am just working round the clock on this as well as my normal life.... so i will be sporadic, but as i make breakthroughs i will update... so i hope SOME of that clears SOME things up.. but i leave you with this:
{ "d:193] [E2DBA579] [COM5] <COMMAND> <?xml version=\"1.0\" encoding=\"UTF-8\" ?>\n<data>\n<getsigndata value=\"ping\" />\n</data>\n[2023/03/06 07:24:12][0x34c4][QCFirehose::resolveLogs:55] [E2DBA579] [COM5] <DEVICE LOG> INFO: Calling handler for getsigndata\n[2023/03/06 07:24:12][0x34c4][QCFirehose::resolveLogs:55] [E2DBA579] [COM5] <DEVICE LOG> WARN: format error, i=0\n[2023/03/06 07:24:12][0x34c4][QCFirehose::resolveLogs:55] [E2DBA579] [COM5] <DEVICE LOG> ERROR: cannot get oplusreserve1/opporeserve1. i" }
Its the actual full data from the application attempting to get the AUTH SIGN.... maybe looking over it you might find some insight.
***back to the caves.... see yall in a bit!****
(and btw.. if you attempt to bypass the LOGIN, you will automatically fail the SW integrity check... you need to find a way to REMOVE this completely, and not with a hex editor... the actual instruction must be removed, and then the subsequent request must be removed again from the actual FLASH function called during the AUTH SIGN request, because IT checks for the valid login again. Remove both and you will have an MSM TOOL with a blank slate. The tools themselves are NOT bundled with the individual FW digest data... they simply follow the instructions given in the packages. If you know what files you can and cannot alter, plus you replace the CRC in the checker file, with the NEW valid crc for the edited file, and you make sure to change the metadata of the files you altered , so that they match again with the other files besides them, you can FOOL the Package validation... <--- a key point in being able to flash altered firmware!... Package Validation Fail = Flash Fail!... Stay Vigilant"
Click to expand...
Click to collapse
Thanks for all of the work you have been putting in! I will not give up hope lol, sorry I'm not a dev smart enough to help but I wish everyone luck...
beatbreakee said:
-snip-
Click to expand...
Click to collapse
Glad to see you still around, I was definitely in the boat of thinking someone shut ya down for good. Keep it up man, I'm sure as we rally we'll get there eventually.
I bricked my redmi 9C after patching a dtbo file from the stock rom to a dtbo partition with adb tools. I've tried everything, please help. I'll give more information if you need. When i connect it to my pc and hold all the buttons at the same time, it connects for some seconds but then it disconnects.
EllsCafe said:
I bricked my redmi 9C after patching a dtbo file from the stock rom to a dtbo partition with adb tools. I've tried everything, please help. I'll give more information if you need. When i connect it to my pc and hold all the buttons at the same time, it connects for some seconds but then it disconnects.
Click to expand...
Click to collapse
Tried to do the combo button and plug in on fastboot?
zSyntex said:
Tried to do the combo button and plug in on fastboot?
Click to expand...
Click to collapse
It doesn't even boots to the fastboot
I am in a similar situation. I have a 9C NFC (angelican) and I first accidentally flashed to wrong global ROM (I used the "angelica" global 12.0.22 ROM for 9C, not the "angelican" ROM for 9C NFC). After that I couldn't get into fastboot, but I could hear the buzzer when I tried to power on the device, but got a black screen. Later I tried the MTK bypass tool (start tool, hold down volume-up, plug in USB), which worked, and I could then run the SP Flash Tool. I used the correct ROM this time (angelican 12.0.16) and used the "Download only" option. It ran for a few minutes, but ended with an error (STATUS_EXT_RAM_EXCEPTION (0xC0050005)). While googling around for a solution the device disconnected from the USB, and ever since I have been unable to get any kind of response from it - it appears to be dead. Black screen, not recognized as a USB device of any kind when connected to the computer, no buzzer etc.
my9mi said:
I am in a similar situation. I have a 9C NFC (angelican) and I first accidentally flashed to wrong global ROM (I used the "angelica" global 12.0.22 ROM for 9C, not the "angelican" ROM for 9C NFC). After that I couldn't get into fastboot, but I could hear the buzzer when I tried to power on the device, but got a black screen. Later I tried the MTK bypass tool (start tool, hold down volume-up, plug in USB), which worked, and I could then run the SP Flash Tool. I used the correct ROM this time (angelican 12.0.16) and used the "Download only" option. It ran for a few minutes, but ended with an error (STATUS_EXT_RAM_EXCEPTION (0xC0050005)). While googling around for a solution the device disconnected from the USB, and ever since I have been unable to get any kind of response from it - it appears to be dead. Black screen, not recognized as a USB device of any kind when connected to the computer, no buzzer etc.
Click to expand...
Click to collapse
It gives this error when trying to do python main.py
Traceback (most recent call last):
File "C:\Users\Elliot\Desktop\bypass_utility-v.1.4.2\bypass_utility-v.1.4.2\main.py", line 3, in <module>
from src.exploit import exploit
File "C:\Users\Elliot\Desktop\bypass_utility-v.1.4.2\bypass_utility-v.1.4.2\src\exploit.py", line 2, in <module>
from serial.serialutil import SerialException
ModuleNotFoundError: No module named 'serial'
EllsCafe said:
It gives this error when trying to do python main.py
Traceback (most recent call last):
File "C:\Users\Elliot\Desktop\bypass_utility-v.1.4.2\bypass_utility-v.1.4.2\main.py", line 3, in <module>
from src.exploit import exploit
File "C:\Users\Elliot\Desktop\bypass_utility-v.1.4.2\bypass_utility-v.1.4.2\src\exploit.py", line 2, in <module>
from serial.serialutil import SerialException
ModuleNotFoundError: No module named 'serial'
Click to expand...
Click to collapse
I fixed that error but now it says
Traceback (most recent call last):
File "C:\Users\Elliot\Desktop\bypass_utility-v.1.4.2\bypass_utility-v.1.4.2\main.py", line 213, in <module>
main()
File "C:\Users\Elliot\Desktop\bypass_utility-v.1.4.2\bypass_utility-v.1.4.2\main.py", line 37, in main
raise RuntimeError("Default config is missing")
RuntimeError: Default config is missing
I got mks to work and said this:
Traceback (most recent call last):
File "C:\Users\Elliot\Desktop\bypass_utility-v.1.4.2\bypass_utility-v.1.4.2\main.py", line 213, in <module>
main()
File "C:\Users\Elliot\Desktop\bypass_utility-v.1.4.2\bypass_utility-v.1.4.2\main.py", line 58, in main
result = exploit(device, config.watchdog_address, config.payload_address, config.var_0, config.var_1, payload)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\Elliot\Desktop\bypass_utility-v.1.4.2\bypass_utility-v.1.4.2\src\exploit.py", line 32, in exploit
udev = usb.core.find(idVendor=0x0E8D, idProduct=0x3)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\Elliot\AppData\Local\Programs\Python\Python311\Lib\site-packages\usb\core.py", line 1309, in find
raise NoBackendError('No backend available')
usb.core.NoBackendError: No backend available
I don't really know what this means but at least my pc detects it without doing anything, I hope xiaomitool or SP Flash tool works