OK IMEI-CHECK charge £20 to unlock the phone, and I say fair enough. Why am I posting this? Did you know that their method is probably writing a NEW locking code using some other algorithm? If you run their software, it will inflate and write (about 4K of data if i remember correctly) in the part of the Radio ROM, where you only get access from the bootloader (memory address h'0' to h'10000'). Now here's the thing: I bet if I call T-mobile and ask for the unlocking code, it won't work in my phone, as these guys are actually modifying the Radio ROM without even telling you. Have you guys thought about insurance? For those who don't pay £9.99 or whatever extra cover, what if you pricey and precious pda goes bonkers? I think they should tell you *before* doing anything, about any possible problems.
Come on you guys, someone said he has compiled a few logs/imei numbers. Let's crack this thing, it has been done before for xda I and II, why can't we do it for IIs/IIi?
If that's the case, then I wonder what's in those .uif files they ask you to send back to them? Could it be a backup of the sections of the radio ROM that they're replacing?
Also, if they're writing a fixed set of data to the radio ROM, how come everyone seems to have different unlock codes? Could they be replacing the actual algorithm that calculates the unlock code so that it only accepts certain combinations of codes from them?
-no1
Just had another thought - what if they're replacing code in the radio ROM with code from the Himalaya so that the unlock process then works in the same way as the Himalaya?
Has anyone tried using the xda2unlock tool after running the program from IMEI-Check??? I can't test this just now, so it's just a guess.
-no1
Could they be replacing the actual algorithm that calculates the unlock code so that it only accepts certain combinations of codes from them?
Click to expand...
Click to collapse
Yes I believe that's what they actually do. I tried to run their utility with a debugger but it does not allow execution as long as a debugger is running, nice one IMEI-CHECK. However, I have done a full USB port logging when the utility runs and I found out that they write a new image between addresses 0 and 10000 of the radio rom, and that they also read from 3FC000 the first 4000 bytes, and from FFFEF000 the first 20 bytes.
Yesterday I discovered something odd...after running their application, and by inserting a different SIM card, the attempts counter for the unlocking code had a negative value of several millions. Now I suspect that by writing in adresses 0-10000, i think they replace the default unlocking utility which allows to enter the code.
Another idea I will try will be to run a debugger in the PDA (if I can find one) and see if I can capture the memory address with which it compares the input code.
Come on guys, especially you who did the unlocking utility for XDA II!! Give us some help here!!!!
Zouganelis,
That's excellent that you've been able to sniff the USB traffic. Keep up the investigations!
I wonder why they'd need to read sections of the ROM? If they're replacing the calculation algorithm section of the ROM with their own code, then they should already know how to calculate the unlock code - i.e. they shouldn't need the user to send them back the .uif file.
This makes me wonder if the code they are replacing is just a copy of the code from another device e.g. the Himalaya.
If they are replacing with code from the Himalaya then the unlock process may revert back to how it works on the Himalaya.
Has anyone been able to test this by running the xda2unlock tool for the Himalaya *after* running the IMEI-Check program?
Does anyone have the source code for xda2unlock by the way? I tried searching for it, but it doesn't seem to be available.
-no1
Another thing, does anyone know if it's possible to back up and restore this secret area of the radio ROM using the backup to SD method? I assume that when you dump your radio ROM to SD card it's not including this part of the ROM???
I want to be able to fully restore any bits that the IMEI-Check tool is changing, just in case.
-no1
Come on guys, anyone else trying to crack this thing? We need someone who knows how to disassamble/reverse engineer this log file. It can't be that hard! Also, I think the key to understanding what their little proggy does, is to manage to run a debugger when the unlock program runs. It has some mechanism of detecting a running debugger and it quits if you have a debugger running at the same time. I bet my MDA III that some experienced programmer can overcome this and fool their application? I am running out of ideas guys and I am really against paying these thieves 20 quid for nothing. They MUST have done this using the previous unlocking methods for XDA I and II. Does any1 know who did those unlockign utilities? These guys must help us!!!
Have you tried to run OllyDbg as a debugger tool to see what is happening? Your earlier findings were very interesting...let me study this and get back to you all...
One remark upfront though: I do not think they are modifying your Radio ROM....this would mean that if you upgrade/replace your current Radio ROM, you would be SIM-lock free...and I do not think that is the case...
OK, some initial observations:
1. Lousy software...hard to use for novices...why have the phone enter BL mode automatically (using enterBL.exe)...I think we can do better!
2. Since the phone must be in BL mode, I do think it extracts some info from the radio ROM, but the SIM-Lock could also reside in the Extended ROM, since this is usually customized by the provider?
3. Interesting to see that the same proggie and procedure is used for all XDA-X models
4. Can anyone post a file (output of the proggie) of what they have mailed these folks, as an example?
5. I was always under the impression that the SIM-Lock resides in the SIM itself, so this is a software workaround? What happens if you upgrade your ROMs...you need to go through this process again? Does anyone have experience with this?
Thanks, and let's get this thing cracked!
HappyGoat,
My understanding is that SIM lock is implemented by the phone itself rather than the SIM card.
In the case of our HTC devices, there seems to be a small area of the radio ROM that does not get written to (even when you upgrade your ROM). This area is where the SIM lock is located, and probably other information such as your IMEI number.
This is probably why your IMEI and SIM lock information never get replaced when you upgrade your ROMs. I seem to remember that an older version of the xda2unlock tool was able to change your IMEI number but it got pulled for legal reasons.
When I unlocked my Himalaya, it stayed unlocked even after later upgrading the ROMs, so the state of the SIM lock is being stored somewhere. It can't be on the SIM because what if you change your SIM after you unlock it? The phone would need to be able to read your old SIM to check if the phone is locked!
Zouganelis,
Have you got any idea if it's possible to back up the areas of the radio ROM you mentioned to SD card? Like the current SD card backup method, but getting ALL of it?
-no1
Happygoat and no1,
i am pretty sure they write to the radio ROM some data they inflate from their "unlocking" executable file. How do I know this? Well, when I put a different SIM into my XDA IIs, after I enter the pin code, the simlock application comes up (simlock.exe under \windows\) which checks for the correct unlocking code. Now usually, you have 3 attempts available to do this, before the phone locks and says "contact customer services" or whatever. After I run their application, the counter had a value of -2billion or something, making it impossible to lock it. Interestingly enough, the memory adresses to which they WRITE, are between 0 and 10000. Is it a coincidence the simlock.exe application is 10.5kB? I don't think so!! i think they write their own simlock application to reset the counter, and then they read from 3FC000 the first 4000 bytes, and from FFFEF000 the first 20 bytes. The simlock code MUST be here!! i will post the log from the USB port sniffing tomorrow, as I don't have these files right now. It's pretty obvious to see how the bootloader works. Anyone with past experience especially with CE based devices will be able to figure out how to read these last two chunks of the radio rom.
Here's a link with some interesting files, RED has posted in the past:
http://www.pgwest.com/phone-files/
Username: xda
Passwrod: blueangel
I do agree with no1 regarding the simlock, I think this is exactly the way it works.
no1, I don't know how to do any backup to the SD card, but if you really know what you are doing in the bootloader, try reading from the memory addresses I mentioned earlier.
Keep it up guys, i think we know what their software does, we now need to find out how to read properly the output log.
Regards,
Zouga
Hi zouganelis and no1,
Thanks for the explanations and comments...all makes sense to me now, excellent.
Zouganelis, thanks for the website...that is the stuff I was looking for, cheers!
I do indeed think we are close...will report back later.
So... if they need the .uif file AND the IMEI number, could it just be a case of using the IMEI code to decrypt the contents of the .uif file? In other words the IMEI code is the decryption key??? But what kind of encryption are they using?
I think they used simple XORing in the past for encrypting the radio, OS, and extended ROMs, but this changed slightly for the Blueangel. I wonder if they used a similar method?
-no1
Interesting thought...and a simple one...which explains they can turn around a request so quickly...
You might be correct...the IMEI could bear the encrypted code for simlock or not. Nowadays, encryption standards are:
DES
MD5
SHA
DES is relatively easy to "crack", SHA being the hardest...they are one-way encryptions, which mean they can not be reversed. The only way to get a match is to try...I have numerous proggies for this and will explore this option...
OK, did some more googling, found the following. There appear to be only 3 companies or people who can do this, which makes it even more interesting...
1. www.imei-check.com (UK)
- Download proggie
- Send them back the output and EMEI number
- Receive unlock code
2. Ebay guy (Canada): http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=43312&item=5763970199&rd=1&ssPageName=WDVW
- Sends you software
- You will run this software and it will generate a log file (data cable required).
- You'll need to email us this log file and we will send you the unlock code with instructions as soon as possible
Looks like same procedure as EMEI-CHECK
3. www.UnLockItNow.com (Company in Malta): http://www.unlockitnow.com/remote/unlock/by_cable/Pocket_PC/unlock/XDA_IIs_unlock.php
Not sure what process they use, but looks the same.
-----------------------------------------
Then I also came across this interesting story: http://www.modaco.com/index.php?showtopic=200968
This guy writes (edited):
I happend across an official O2 email address that I sent an (abbreviated) SIM unlock request, briefly stating why I needed my XDA IIs to be SIM unlocked, and providing my O2 account number and the handset IMEI number. 30 minutes later and I was emailed back an unlock code.
No ifs, no buts, no questions asked and no payment required.
I placed my Orange SIM card in the IIs, waited for it to boot, entered the code and was greeted with "Unlock Code Accepted." Both dialling out and receiving calls on my Orange account no problemo.
...
Bearing the above in mind, I'm not going to directly post the email address, but will gladly pass it on via PM.
Click to expand...
Click to collapse
The interesting part here is that he only had to give his EMEI number, nothing else...and received an unlock code.
If you take the official route of unlocking your phone through your network provider, all they need is your IMEI number because they can calculate your unlock code from that.
I'm not 100% certain how the process works, but I'm fairly sure the algorithm they use to generate the unlock code is different for each handset manufacturer. I think the network provider either has to send your IMEI to the handset manufacturer for them to calculate the unlock code, or possibly the provider is given a database of unlock codes for all the handsets they purchase. This might explain why it sometimes takes them a few days or weeks to get back to you with the unlock code.
So figuring out how they convert the IMEI number to the unlock code would be another way to attack the problem. Although, I think it would probably be very difficult to figure out what hashing algorithm they're using to generate the code. But if it can be done, then it would certainly make things a hell of a lot easier!
-no1
SH*TE I have been writing a post for about half an hour now explaining the files and as soon as I logged in it was lost. :evil: :evil: :evil: :evil: :evil:
Anyways, here we go again. I am posting the files I promised yesterday. The are three JPEGs which are handwritten notes from the first time I run their application, and a log file from the second time I run the application. Here's the thing: the first time, the software send a read command for the addresses 0-10000 of the radio rom (rrbmc x 0 10000) and store in the x variable. Then it probably compared the checksum with their data, and it didn't match, so they deleted this part of the rom (rerase 0 10000) and they written their own version of it stored in a vector called data (rw data 0 10000). So far so good.
The second time I run the software, it sent again the rrbmc command but this time it didn't erase or written anything, so I guess it does actually what I said before with the checksum.
Another important remark:
The first time I run the software, the software requested some information from the device (rinfo) and the xda replied:
BlueAngel B120 C6B23C704A59520150993080051FF87B
After it finished writing, it sent the same command once more and this time the xda replied:
BlueAngel B120 C6 BE3A709999541E509810802FD775B0
Now the second time I run the application, the rinfo command returned:
BlueAngel B120 C6BC3C70B329B2B1509980809FE49B11
Can these be some form of HEX encryption keys or something?
Happygoat maybe you could use them in your nice proggies?
Anyhow, I think this is all for now. The commands in the logs should be straight forward to understand, it's just the data part which needs real decoding of some sort.
Hope it helps, regards Zouga
Zouga,
Thanks alot for the info...and your patience!
I downloaded a program called USB Monitor, which supposedly logs all data transferred via the USB port...is that the proggie you used as well?
What I want to do is run the IMEI-CHECK program on my device a few times in a row..since it was never SIMLOCKED, I wonder what the output will be...and if they will be different.
I suggest other people run this software as well with a USB port logger, so we can compare logs, and perhaps figure out precisely what we need to do.
Regarding the encryption, I will have a look. I do not think that the data you gave me (C6BC3C70B329B2B1509980809FE49B11) is encrypted...looks like plain ol' HEX to me...will do some more research.
What I think would be the ultimate solution, is to develop an app that calculates the unlock code based upon IMEI number...easy to use, no workarounds, and something I understand: Encryption...
Yes, I am biased...but I am reading up on ass'y code right now to get my arms around this thing...so bare with me...
Hi HappyGoat,
It's good that finally you guys got interested in this! Yes it is the same piece of software I used to sniff the port, it would be interesting to see the output of your unlocked device. Could you please post it as soon as you have it? I hope we can crack this!!
Come on guys, don't just complain for the £20 charge, give us some help here!! We should all run the software and log the data to compare them, as HappyGoat suggested. Then we should all be HappyXdaUsers
Looking forward to some news,
Zouga
Zouga,
Can't download the zip file (bottom one) for some reason...reports that file can not be found...can you try again please?
Cheers,
HG
Working on modding a rom, but I can't figure this out - the internet works, I can browse just fine, send and receive text messages and calls, but when i try to set up Google I get an error saying I don't have a network connection OR a reliable connection can't be established. here's the logcat from the portion I think is causing the problem.
E/ActivityThread( 1183): Failed to find provider info for android.server.checkin
E/copybit ( 80): copyBits failed (Invalid argument)
E/libagl ( 80): copybit failed (Unknown error: -22)
I/XT9IME ( 226): [finishInput]
I/HTCIMEService( 226): [setWCLText]: wclText=, candIdx=0
I/HTCIMEService( 226): [finishInput]:
I/ActivityManager( 80): Displayed activity com.android.setupwizard/.LoginActiv
ityTask: 530 ms (total 530 ms)
Click to expand...
Click to collapse
Anyone know what might be causing this? Do you need any more information from me? I've checked and double checked, my APN information is all correct and I have a connection from T-Mobile.
OK, I think I figured out the problem - Google settings provider says (logcat) it was built for SDK 7 and this rom is running 6. I tried to simply trick the system to think it was 7 by editing the build.prop but that didn't change a thing.
I've also gotten several logcat errors on boot that say "wrong APN" even though it actually has the right APN (I can receive calls, make them, browse the web, etc) and I've confirmed by APN settings with T-Mobile.
Finally, I'm also getting some errors in logcat saying that the apk's were made for AOSP, but this is a release (Hero port). Not really sure where to start looking for a resolution.
I'm still reading through pdk.android.com, all of cyan's information and a ton of other documentation from other coders, btu I can't find direct reference to these problems. How do I delve deeper into my logcat? Where do I find information on these problems?
Any suggestions on the best way to track this down would be helpful and more than appreciated, I'm still elarning HOW to debug.
I'm just looking for a point in the right direction, something I can research - you don't have to fix the problem for me
EDIT: I think it might actually be the libs - specifically android_runtime and android_servers