so heres what the OTP guys are doing...
Be prepared... this is a VERY long detailed post...
so what they are basically doing is....
they are running their own "last pass" kind of server from AWS... Where they are daily logging in to their amazon web server account, and updating the MSM TOOL login, so that it refreshes every time one of them needs to pull an OTP. But its up to whoever admins the account as to how long tokens last for.
then they created (or cloned) that GA_Login tool, which is just a general purpose login tool which can be made to work with any app. It comes with modified code so that you can attach it to any program written under a certain language. (different versions of the login tool for different program languages) Then the tool officially has access to manipulate the login values of whatever app.
I believe the tool has legit licenses with the companies otherwise they would be violating the reverse engineering laws, and everyone who is profiting from it would be subject to an arresting offense! That would depend on the companies to press charges. But its easy to gain permission from a company for this purpose because you arent altering the code, only adding further security to mask passwords!
So the OTP being generated, are just a valid login that is masked by a secure password masking system. Unfortunately it is unable to be decrypted due to mitigations involved with packet capture and the login relies on an internet connection. Now unfortunately thru further inspection, the OFP flashing app DOES maintain a secure check of the VIP Authentication signature, and that signature is verified on the phone itself through a command called by the Linux Library "Libqmi" ... this can be built and programmed by anyone, but the actual procedure for JUST doing a VIP Auth signature, is not detailed on how to perform this.
THIS is what the QFIL application is doing when the sahara programmer is called.... the sahara programmer has a heavily encrypted HASHING ALGORITHM which sends one value to your phone, and then your phone verifies and calculates a response to send back to the Sahara.... The sahara already knows the correct answer even though it sits waiting, and if a single character is off, then sahara shuts down the communication portal, and sends us back an error. At that time, the phone is stuck in perpetual FAILED mode, and needs to be reset in order to try again.
The problem with this is that during a FULL BRICK state, meaning no communication without shorting the Test Points, while the battery is disconnected, then there is no way to get a valid time stamp from your device. The timestamp is part of the sahara's calculation. Thus this is why manually flashing thru QFIL continues to fail. The PATCHED Firehose loaders, simply have the TIMESTAMP requirement removed from the calculation, so that the only thing verified is the devices SOC and board information.
The MSM ONLINE tool, does its own timestamp calculations and intercepts the communication of the Sahara, then injects the current valid timestamp in real time, which then gives the approved signature to the sahara, and authorizes your flash.
Conclusion: Someone who has .elf file coding skills needs to completely disassemble the loader, which can be pulled from ANY OP 10series.... or actually ANY Snapdragon 845 r 1, based phone, and compare that to several other loaders of recent related chipsets... ie Snapdragon 845 r 2, or possibly even Snapdragon 865... but if they are fluent enough working with elf files, they should be able to locate the instruction code that requests a timestamp, as part of the signature, and delete/disable that requirement. THEN recompile that loader and we will have the file needed from OFFLINE flashes via the patched MSM Tool, or Qfil.
The login is the ONLY requirement of the MSMTool!
It is the sahara firehose itself that is killing our ability to continue flashing once the login is bypassed. Whether the phone is in brickstate or not has no value to the value being submitted to the sahara. OPPO programmed our phones to interrupt communication thru the USB, on a BUTTON, or ADB request to enter EDL mode. This is why when connecting via the command line, or thru the recovery mode shortcut, there is a slight 3-5 second delay until your phone is detected in 9008 mode.
1. When entering by holding the VOL buttons and plugging the usb in, the phone loses communication to the TIMESTAMP function, which makes the sahara fail offline, due to no MSM Tool server intervention. (remember the MSM server is not maintained by OPPO, but is actually built by Qualcomm... they just provide access to OPPO for repair functions.)
^^This will cause QFIL to fail, because a valid VIP cant be generated without the timestamp! ... But the MSM server can interject the correct timestamp being that its online and always in sync^^
2. When entering EDL via cli, the phone is SUPPOSED to go straight into QCOMM DOWNLOAD MODE... with no interruption, but OPPO amended a "Reboot" command into the opperand forcing the usb to lose connection to the board and breaking the sync, and thus forcing the timestamp to be invalid once the connection is made again with the programmer.
^^This is why COLOROS is a game changer... Because they pushed their own, RECOVERY, and FASTBOOT protocols as overlays of the REAL Qcomm Recovery and Fastboot. Recovery and Fastboot are requirements of Qcomm/Android devices. But HOW they are laid out to us are completely up to the manufacturers. The ColorOS Recovery, and Fastboot (D) that is made by OPPO, alters the timestamp being generated, to force a standard 12hr format instead of 24hr ... Sahara doesnt know wtf AM, or PM is... so anything from ColorOS is gibberish in the timestamp.
THERE IS ONE CAVEAT...
All androids with altered Fastboot and Recovery protocols, ,MUST include a "Debug Boot Image". These actually communicate to the Qualcomm diagnostic function. Although atm i have no idea how to BOOT into these images, as they are not the same as the normal .img files we use for everything else. Calling on one of these images, is a process completely different than standard android boot.img ... so again i believe this to be one of the functions of LIBQMI .... this library makes a connection to the device over usb but more importantly the SERIAL communicator console on the board. Once this communication is connected, you have full control over all partitions/filesystems inside the entire device, without regulation. You could technically tell your smartphone it is now a smart TOASTER, (but this would certainly crash immediately without the proper functions being built into the chipset.)
So now i task ANYONE who might have decent Linux knowledge to research QMI and how it communicates, to find the proper commands/access to call upon the Debug.img , which you can pull our of any downloaded fw.
I will still be working on alternate methods, but as of now QMI seems to be our only answer.
And final statement. OTP cannot be spoofed in any method to gain authorized MSM access, anymore than you being able to spoof authentication into a "last pass" account to gain control over someones password collection. They both maintain about the same level of encryption.
I hope thats detailed enough to get to everyones thoughts, as i probably wont be able to answer anything much deeper for the time being. I have personally put myself into a financial situation, by the amount of time i have devoted to this, and now need to create a miracle or 2 in order to recover from the domino effect that i hadnt realized i triggered until today. Sorry i couldnt do a hell of a lot more... if i had the financial resources to not worry about bills for a month or two i could totally crack this thing wide open, and probably put a devastating hurt on OPPO in the process... but Electricity, Rent, Car, Insurance, Food, and general living, all factor in to the amount of time i can spend on this. (which sucks because bounties are upwards of 50K or more for the discovery of holes in the functions i was working on, and according to Qcomm i was very close to a pretty high critical cve being declared!)
