my phone is dead nokia x2 please help me sir - X2 Q&A, Help & Troubleshooting

CreateFile failed to create valid handle to device. The requested resource is in use
Exception:
System.ComponentModel.Win32Exception (0x80004005): CreateFile failed to create valid handle to device. The requested resource is in use
at Nokia.Merak.UsbDeviceIo.WinUsbIpen()
at Nokia.Merak.UsbDeviceIo.UsbDeviceIo..ctor(String devicePath)
at Nokia.Delta.Messaging..ctor(ConnectionDetails details)
at Nokia.CareSuite.PlugIns.DeltaRecovery.RecoveryDialog.RecoveryDialogModel.ChangeDeviceMode()
at Nokia.CareSuite.PlugIns.DeltaRecovery.RecoveryDialog.RecoveryDialogModel.Flash()
at Nokia.CareSuite.PlugIns.DeltaRecovery.RecoveryDialog.RecoveryDialogModel.<HandleDownloadVariantPackageCompleted>b__14(Object state)
this is log for eroo code nokia care suite how to fix it
icant turn on my mobile

Related

[SOLUTION] Application Deployment fault codes

Getting a error in the Application Deployment from Windows Phone Developer Tools? This might help.
0x8973180E : Zune software is not installed. Please install the latest version of Zune software.
0x8973180F : Incorrect version of the Zune softeware installed. Please download the latest version.
0×89731810 : Corrupted device configuration. To correct this problem, reinstall Visual Studio 2010 Express for Windows Phone.
0×89731811 : Zune software is not started. Please try again from the Zune to ensure that the software is running.
0×89731812 : Connection to device failed. Please ensure the phone is connected and the not on the lock screen.
0×89731813 : Application failed to start. Please ensure that the device has been registered and unlocked. Explanation on how to register can be found here.
0×81030110 : Failed to install the application. Runtime error has occurred. Capabilities WMAppManifest.xml file located in the attribute content is incorrect.
0×81030118 : Installation of the application failed. Device is developer locked. Register for the developer unlock program before deploying the application.
0×81030119 : You cannot install the application. You have reached the maximum number of applications being developed for the device can be installed on this development. Please uninstall a previous developer application.
0x8103010B : App is not compatible with HD2, can not be resolved.
If you're having a other error then please post them in this thread, I'll ad the code to this post.
Thank you is the magic word
Source
http://forum.xda-developers.com/showthread.php?t=916555
Updated....
stephandelaat said:
Updated....
Click to expand...
Click to collapse
Yeah it's good now, i don't think it's compatible but something like so...

failed to unbrick my hard bricked x2 using nokia care suite

this is the error log i am getting
Failed using Sahara protocol
Exception:
Nokia.Delta.Gemini.EmergencyDownload.EmergencyDownloadException: Failed using Sahara protocol ---> Nokia.Delta.Gemini.EmergencyDownload.SaharaException: Received packet was not of hello packet type
at Nokia.Delta.Gemini.EmergencyDownload.Sahara.Handshake(Mode mode)
at Nokia.Delta.Gemini.EmergencyDownload.Sahara.Download(String filePath)
at Nokia.Delta.Gemini.EmergencyDownload.EmergencyDownload.SetToFirehoseMode()
--- End of inner exception stack trace ---
at Nokia.Delta.Gemini.EmergencyDownload.EmergencyDownload.SetToFirehoseMode()
at Nokia.CareSuite.PlugIns.DeltaRecovery.RecoveryDialog.RecoveryDialogModel.Flash()
at Nokia.CareSuite.PlugIns.DeltaRecovery.RecoveryDialog.RecoveryDialogModel.<HandleDownloadVariantPackageCompleted>b__15(Object state)
please help me
harish120 said:
this is the error log i am getting
Failed using Sahara protocol
Exception:
Nokia.Delta.Gemini.EmergencyDownload.EmergencyDownloadException: Failed using Sahara protocol ---> Nokia.Delta.Gemini.EmergencyDownload.SaharaException: Received packet was not of hello packet type
at Nokia.Delta.Gemini.EmergencyDownload.Sahara.Handshake(Mode mode)
at Nokia.Delta.Gemini.EmergencyDownload.Sahara.Download(String filePath)
at Nokia.Delta.Gemini.EmergencyDownload.EmergencyDownload.SetToFirehoseMode()
--- End of inner exception stack trace ---
at Nokia.Delta.Gemini.EmergencyDownload.EmergencyDownload.SetToFirehoseMode()
at Nokia.CareSuite.PlugIns.DeltaRecovery.RecoveryDialog.RecoveryDialogModel.Flash()
at Nokia.CareSuite.PlugIns.DeltaRecovery.RecoveryDialog.RecoveryDialogModel.<HandleDownloadVariantPackageCompleted>b__15(Object state)
please help me
Click to expand...
Click to collapse
I've got the same problem, many times I flash it's my nokia x2. After that, i put out my nokia battery, and move the RM-XXXX to C:\ProgramData\Nokia\Packages\Products\
Flash it again, and supprised me, it works wellllllll.
maybe you do it to work for you, or try to run as administator "nokia care suite"
holyeyed said:
I've got the same problem, many times I flash it's my nokia x2. After that, i put out my nokia battery, and move the RM-XXXX to C:\ProgramData\Nokia\Packages\Products\
Flash it again, and supprised me, it works wellllllll.
maybe you do it to work for you, or try to run as administator "nokia care suite"
Click to expand...
Click to collapse
can you explain in detail...
Where did you place your rom, if its in programe files, so change to programe data, run right click on nokia care suite and run as administator, then do it.
Note, you should take out all sim card and memory card from phone before flash.
holyeyed said:
I've got the same problem, many times I flash it's my nokia x2. After that, i put out my nokia battery, and move the RM-XXXX to C:\ProgramData\Nokia\Packages\Products\
Flash it again, and supprised me, it works wellllllll.
maybe you do it to work for you, or try to run as administator "nokia care suite"
Click to expand...
Click to collapse
I tried nokia care suit to refurbish my phone but kt doesn't connect with my phone. Please help

Problem with Android Studio 1.4 when creating a new Java Class "

The error that shows Android Studio is the following:
Unable to parse template "Class"
Error message: Cannot modify a read-only directory 'D:\Users\david.t_92\AppData\Local\Android\sdk\platforms\android-23\android.jar!\android\app'.
I try to make almost everything and nothing Works
Please help
david.t_922 said:
The error that shows Android Studio is the following:
Unable to parse template "Class"
Error message: Cannot modify a read-only directory 'D:\Users\david.t_92\AppData\Local\Android\sdk\platforms\android-23\android.jar!\android\app'.
I try to make almost everything and nothing Works
Please help
Click to expand...
Click to collapse
Did you got the solution, I too facing this issue

Android Studio - Gradle Sync Issue, Cannot find a solution!

Hi Guys,
Would anyone be able to guide me in the right direction as to why I'm seeing this issue in Android Studio?
Notes: This is a first time install Error: Gradle sync failed: Unable to find method 'com.google.common.io.Resources.asCharSource(Ljava/net/URL;Ljava/nio/charset/CharsetLcom/google/common/io/CharSource;'. Consult IDE log for more details (Help | Show Log)
I can send anyone a screenshot of the error in more detail if needed.
Kind Regards,
The log is here:
"2016-12-20 23:03:43,146 [ 12922] WARN - nal.AbstractExternalSystemTask - Unable to find method 'com.google.common.io.Resources.asCharSource(Ljava/net/URL;Ljava/nio/charset/CharsetLcom/google/common/io/CharSource;'.
com.intellij.openapi.externalSystem.model.ExternalSystemException: Unable to find method 'com.google.common.io.Resources.asCharSource(Ljava/net/URL;Ljava/nio/charset/CharsetLcom/google/common/io/CharSource;'.
at com.android.tools.idea.gradle.project.ProjectImportErrorHandler.createUserFriendlyError(ProjectImportErrorHandler.java:288)
at com.android.tools.idea.gradle.project.ProjectImportErrorHandler.getUserFriendlyError(ProjectImportErrorHandler.java:196)
at com.android.tools.idea.gradle.project.AndroidGradleProjectResolver.getUserFriendlyError(AndroidGradleProjectResolver.java:401)
at org.jetbrains.plugins.gradle.service.project.GradleProjectResolver$ProjectConnectionDataNodeFunction.fun(GradleProjectResolver.java:772)
at org.jetbrains.plugins.gradle.service.project.GradleProjectResolver$ProjectConnectionDataNodeFunction.fun(GradleProjectResolver.java:752)
at org.jetbrains.plugins.gradle.service.execution.GradleExecutionHelper.execute(GradleExecutionHelper.java:238)
at org.jetbrains.plugins.gradle.service.project.GradleProjectResolver.resolveProjectInfo(GradleProjectResolver.java:112)
at org.jetbrains.plugins.gradle.service.project.GradleProjectResolver.resolveProjectInfo(GradleProjectResolver.java:73)
at com.intellij.openapi.externalSystem.service.remote.RemoteExternalSystemProjectResolverImpl$1.produce(RemoteExternalSystemProjectResolverImpl.java:41)
at com.intellij.openapi.externalSystem.service.remote.RemoteExternalSystemProjectResolverImpl$1.produce(RemoteExternalSystemProjectResolverImpl.java:37)
at com.intellij.openapi.externalSystem.service.remote.AbstractRemoteExternalSystemService.execute(AbstractRemoteExternalSystemService.java:59)
at com.intellij.openapi.externalSystem.service.remote.RemoteExternalSystemProjectResolverImpl.resolveProjectInfo(RemoteExternalSystemProjectResolverImpl.java:37)
at com.intellij.openapi.externalSystem.service.remote.wrapper.ExternalSystemProjectResolverWrapper.resolveProjectInfo(ExternalSystemProjectResolverWrapper.java:49)
at com.intellij.openapi.externalSystem.service.internal.ExternalSystemResolveProjectTask.doExecute(ExternalSystemResolveProjectTask.java:51)
at com.intellij.openapi.externalSystem.service.internal.AbstractExternalSystemTask.execute(AbstractExternalSystemTask.java:138)
at com.intellij.openapi.externalSystem.service.internal.AbstractExternalSystemTask.execute(AbstractExternalSystemTask.java:124)
at com.intellij.openapi.externalSystem.util.ExternalSystemUtil$3.execute(ExternalSystemUtil.java:419)
at com.intellij.openapi.externalSystem.util.ExternalSystemUtil$4$2.run(ExternalSystemUtil.java:500)
at com.intellij.openapi.progress.impl.CoreProgressManager$TaskRunnable.run(CoreProgressManager.java:563)
at com.intellij.openapi.progress.impl.CoreProgressManager$2.run(CoreProgressManager.java:142)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:446)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:392)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:54)
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:127)
at com.intellij.openapi.progress.impl.ProgressManagerImpl$1.run(ProgressManagerImpl.java:126)
at com.intellij.openapi.application.impl.ApplicationImpl$8.run(ApplicationImpl.java:369)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
2016-12-20 23:03:43,172 [ 12948] WARN - radle.project.ProjectSetUpTask -
2016-12-20 23:03:43,172 [ 12948] INFO - radle.project.ProjectSetUpTask - Unable to find method 'com.google.common.io.Resources.asCharSource(Ljava/net/URL;Ljava/nio/charset/CharsetLcom/google/common/io/CharSource;'."
Upgrade or reinstall
Did you try to reinstall android studio ? I think it has something to do with jar version mismatch

General Unbrick OP10 Pro (NE2210)

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.

Categories

Resources