INFORMATION REGARDING DB2020 PHONES (K800/K610/P990/M600/804S/904S etc.)
--------------------------------------------------------------------------------
This thread is intended for providing general information about the upcoming models based on the new DB2020 chip"set". It also serves the purpose of explaining the "how's" and why's regarding the unlocking/flashing of these.
First of all, DB2020 stands for Digital Baseband 2020. It's the next generation baseband "processor" from SE. It incorporates new security measures, so the old method of breaking into DB2010/DB2012 (it's predecessors) is useless against it.
Now, later SE security is/was actually very strong and therefore hard to break. It's RSA-based, meaning that it's based on public and private certificates and keys. These two are calculated based on huge prime numbers that cannot be "reversed", meaning that there is no way to calculate the private key based on the public key nor vice versa. Anything encrypted with the public key can be decrypted using the private key. The two "peers" share their public keys allowing them to decrypt eachothers "messages". For more information on RSA, please consult "http://en.wikipedia.org/wiki/Rsa".
As far as I've gathered, the "loaders" (programs) used by SE to communicate with phones either on the production line or at service centers are "signed" using a similar system (again, consult Wikipedia). An initial communication channel has to be set up, then a loader must be sent to the phone. It is through this loader that operations take place. E.g. if you want to flash a phone, you send a loader to it, this loader then listens for a flashfile to be transmitted and writes it to the memory.
Previous ways of breaking into SE phones were based on vulnerabilities in these loaders, somehow allowing developers to perform their own operations instead of their original intention. Unlocking for instance, requires an almost impossible to get access level and smartcard (holding the CSCA key, allowing a new security zone to be written and signed) for SE's own service solution, called EMMA (now counting version 3/III). Cloning this smartcard or getting the CSCA key out of it has yet to be done, if it is at all possible, the key never leaves the smartcard, calculations are made by the card itself (smartcards are very advanced, some hold 200Mhz processors, for example your average satellite-TV card).The card also holds the algorithm/mechanism for challenge/response authentication with the phone.
DB2020 is completely rewritten from scratch, I gather. They have been thinking "security" all the way through it's development as opposed to the apparent make-shift solutions found in earlier versions. This calls for new tactics by "SE-tool" developers.
The standalone version of SETool has been available for over a year now, it has served it's customers well, to say the least, but it has one major flaw; It's based on security holes found in SE security. The communication between SETool and a phone can easily be eavesdropped upon ("sniffing"), allowing other developers to copy and steal the exploitation code and then incorporate this into their own tools. The earliest public third-party SE service software was developed by "Daniel Henzulea"/zulea. At this time, SE (then simply "Ericsson") security was scarce. As it improved, new players came into the game, namely the_laser and Lead. Lately, these two have been supplying the solutions for breaking SE security, incorporating these into their own tools. zulea has been stealing these solutions and been incorporating them into his own, cheap, semi-working tool, ruining the third-party SE service software market, as anyone can afford and get it. His tool has it's own forum, filled with "less fortunate" people from the shallower end of the gene-pool living under the illusion that zulea is the biggest genious ever to have lived. When I feel down, I take a peek at that forum, reminding me how "fortunate" I really am .
Understandable enough, neither Lead nor the_laser finds this rather amusing. For SETool customers, this means that the old standalone solution must be put aside, at least for a while. The new solution has a server-client model, meaning that all important calculations are performed by the server. The communication between the software and phone will be phone-dependant, meaning it cannot be sniffed and applied to another phone. This way zulea (and others) are prevented from stealing the solution.
The new system will soon be in place, allowing at least flashing (unlocking is on it's way) of SE DB2020 models (Sharp models will not be supported at first). Some practical information on what this means for each user:
1: You will need an internet connection for servicing DB2020 models (the old models will remain supported in standalone mode). You don't need a fast connection, only small amounts of data will be transmitted.
2: You will need "credits"/"logs" for servicing DB2020 models. These prevent "stealers" from simply forwarding traffic. They also provide money for the SETool team (for buying prototype/new models, researching them and so on).
3: Each SETool card owner will have three free credits per day, allowing him/her to fully service one DB2020 phone per day without having to pay for it (if we look besides the cost of the card). One for "Complete phone" flashing, one for unlocking, and one for read/write GDFS. You could also use all three credits for unlocking, allowing you to unlock three phones per day for free. Prices for extra credits won't be steep, I gather, Unlocker will provide them soon enough. Credits won't span to the next day if you don't use them.
4: If a security hole is found in DB2020, support will be implemented into the standalone software.
Thats all I could think of, of any importance at least. I look forward to your feedback, but again; spare the crap . Also, if I'm wrong about anything, please correct me. I've taken a few educated guesses and shortcuts, it's late
I will update this post and wipe all others regularly to create better oversight and reability. [s:10]
--------------------------------------------------------------------------------
This thread is intended for providing general information about the upcoming models based on the new DB2020 chip"set". It also serves the purpose of explaining the "how's" and why's regarding the unlocking/flashing of these.
First of all, DB2020 stands for Digital Baseband 2020. It's the next generation baseband "processor" from SE. It incorporates new security measures, so the old method of breaking into DB2010/DB2012 (it's predecessors) is useless against it.
Now, later SE security is/was actually very strong and therefore hard to break. It's RSA-based, meaning that it's based on public and private certificates and keys. These two are calculated based on huge prime numbers that cannot be "reversed", meaning that there is no way to calculate the private key based on the public key nor vice versa. Anything encrypted with the public key can be decrypted using the private key. The two "peers" share their public keys allowing them to decrypt eachothers "messages". For more information on RSA, please consult "http://en.wikipedia.org/wiki/Rsa".
As far as I've gathered, the "loaders" (programs) used by SE to communicate with phones either on the production line or at service centers are "signed" using a similar system (again, consult Wikipedia). An initial communication channel has to be set up, then a loader must be sent to the phone. It is through this loader that operations take place. E.g. if you want to flash a phone, you send a loader to it, this loader then listens for a flashfile to be transmitted and writes it to the memory.
Previous ways of breaking into SE phones were based on vulnerabilities in these loaders, somehow allowing developers to perform their own operations instead of their original intention. Unlocking for instance, requires an almost impossible to get access level and smartcard (holding the CSCA key, allowing a new security zone to be written and signed) for SE's own service solution, called EMMA (now counting version 3/III). Cloning this smartcard or getting the CSCA key out of it has yet to be done, if it is at all possible, the key never leaves the smartcard, calculations are made by the card itself (smartcards are very advanced, some hold 200Mhz processors, for example your average satellite-TV card).The card also holds the algorithm/mechanism for challenge/response authentication with the phone.
DB2020 is completely rewritten from scratch, I gather. They have been thinking "security" all the way through it's development as opposed to the apparent make-shift solutions found in earlier versions. This calls for new tactics by "SE-tool" developers.
The standalone version of SETool has been available for over a year now, it has served it's customers well, to say the least, but it has one major flaw; It's based on security holes found in SE security. The communication between SETool and a phone can easily be eavesdropped upon ("sniffing"), allowing other developers to copy and steal the exploitation code and then incorporate this into their own tools. The earliest public third-party SE service software was developed by "Daniel Henzulea"/zulea. At this time, SE (then simply "Ericsson") security was scarce. As it improved, new players came into the game, namely the_laser and Lead. Lately, these two have been supplying the solutions for breaking SE security, incorporating these into their own tools. zulea has been stealing these solutions and been incorporating them into his own, cheap, semi-working tool, ruining the third-party SE service software market, as anyone can afford and get it. His tool has it's own forum, filled with "less fortunate" people from the shallower end of the gene-pool living under the illusion that zulea is the biggest genious ever to have lived. When I feel down, I take a peek at that forum, reminding me how "fortunate" I really am .
Understandable enough, neither Lead nor the_laser finds this rather amusing. For SETool customers, this means that the old standalone solution must be put aside, at least for a while. The new solution has a server-client model, meaning that all important calculations are performed by the server. The communication between the software and phone will be phone-dependant, meaning it cannot be sniffed and applied to another phone. This way zulea (and others) are prevented from stealing the solution.
The new system will soon be in place, allowing at least flashing (unlocking is on it's way) of SE DB2020 models (Sharp models will not be supported at first). Some practical information on what this means for each user:
1: You will need an internet connection for servicing DB2020 models (the old models will remain supported in standalone mode). You don't need a fast connection, only small amounts of data will be transmitted.
2: You will need "credits"/"logs" for servicing DB2020 models. These prevent "stealers" from simply forwarding traffic. They also provide money for the SETool team (for buying prototype/new models, researching them and so on).
3: Each SETool card owner will have three free credits per day, allowing him/her to fully service one DB2020 phone per day without having to pay for it (if we look besides the cost of the card). One for "Complete phone" flashing, one for unlocking, and one for read/write GDFS. You could also use all three credits for unlocking, allowing you to unlock three phones per day for free. Prices for extra credits won't be steep, I gather, Unlocker will provide them soon enough. Credits won't span to the next day if you don't use them.
4: If a security hole is found in DB2020, support will be implemented into the standalone software.
Thats all I could think of, of any importance at least. I look forward to your feedback, but again; spare the crap . Also, if I'm wrong about anything, please correct me. I've taken a few educated guesses and shortcuts, it's late
I will update this post and wipe all others regularly to create better oversight and reability. [s:10]