[OnePlus 10 Pro] beatbreakee:
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"