Quote:
Originally Posted by Geronino  I still believe, this way could be a solution.
Just to downgrade the baseband. |
Nope, it isn't.
The thing you unload to run BBUpdaterExtreme isn't the baseband. It's CommCenter. You stop CommCenter so that you can talk to the baseband without interference.
The decision as to whether to accept a proposed baseband that you upload is left entirely up to the current baseband. The flow is basically:
(a) get baseband's attention
(b) through a series of loading stages, upload the proposed new baseband to the existing one. It's put in RAM temporarily for this part.
(c) After the entire new proposed baseband is uploaded, some basic checks are done: (1) Is this baseband properly signed? (2) Has any part of it been tampered with, including its version number? (3) IS THE VERSION YOU SENT ME LESS THAN THE VERSION I'M RUNNING?
That third check is what kills the deal. The baseband simply rejects as invalid a proposed new baseband whose version is lower than itself. And you can't trick it into thinking the version is higher than it is because of checks (c)(1) and (c)(2) above.
So after that long upload stage, where the proposed baseband is stored in RAM, a verification stage goes on. It quickly decides at that point to simply reject the proposed baseband.
Because the version number is "protected" with a signed hash, you can't tamper with it undetected. If you try, the exisiting baseband sees an invalid signed hash and just drops your proposed baseband from consideration.
NOTE: The Tsamba "solution" consists of *stock* versions of the BBUpdaterExtreme and baseband files. The only thing additional in their package is the erotic sound files. Erotic sound files won't affect in any way shape or form the flow I've described above.