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
As many S/W co. required to license it's product to their user, many required you to have the Device ID to install. I know one of them is Mapping / GPS S/W; Destinator.
Other devices, this no. is included / reported under Device Information (Start > System > Device Information), but unique to this mdl. it is not listed (other HTC made products have it), so the Question is how do you find it?
I called the HTC Support (outsourced to India / Pakistan I think, all of my 3 calls answered by their accented tech supports), low level tech know nothing, even they don't know if such exist. After this call, I kept searching and accidentally stumble to Windows Update Icon in Settings and attempted to do the update. Unexpectedly, the update was completed w/o any, my system is up-to-date, I supposed, and in the log report through this process, there it is ... the Device ID no. is revealed.
I called HTC support again, and discuss this particular subject, as I expected, this 2nd low level tech support do not know anything too, just as the first. So, I asked to be connected to the supervisory tech support and was promised that he would call me back.
The supervisor tech support called approx. 45 min. later. Yes, as I expected, he insisted that no such thing in this device known as the Device ID, though I mentioned to every one (all 3 of them), that, such, existed in my other 10+ previous devices I owned and majority of them are made by HTC.
And, obviously we debated and they feel strongly that they know better ... hallooo ... they may do on other subject, but on this particular one ... ??? ??? ???
My point is: I sincerely hope that their (HTC team that developed the x7501) to include this information in their future update (either through ROM or Device Info) so we can use S/W that requires it.
Hallooo ... ooo ... HTC ... ... ...
So, for you that need this info, here is how:
Start > Settings > System > Windows Update ... and view / read the log after finish, in it you will find your unique Device ID and IMEI no. as well (the IMEI no. is also available through Device Information)
Device ID on Advantage x7501 / Athena
Forgot to mention:
You need to be connected to the Internet to get the update and produce the log!
Sorry guys n gals ...
Thanks, I haven't needed that info yet, but nice to know where I can get it.
Device ID
hi everybody,
i just want 2 know how can i find my ( Device ID ) for my Htc Hero.
thnx alot.
joker5089 said:
hi everybody,
i just want 2 know how can i find my ( Device ID ) for my Htc Hero.
thnx alot.
Click to expand...
Click to collapse
searching for your answer here would be agood start
http://forum.xda-developers.com/forumdisplay.php?f=511
Devise id
Thanks for the info
But i have a htc touch 2
And it does not have an windows update in the settings, so any help for my problem?
As im trying to install tom-tom and activate maps and download maps and it is asking for my devise id
and it gives me an example : A1B2.....
hkusuma said:
So, for you that need this info, here is how:
Start > Settings > System > Windows Update ... and view / read the log after finish, in it you will find your unique Device ID and IMEI no. as well (the IMEI no. is also available through Device Information)
Click to expand...
Click to collapse
And if you do not have Windows Update on your device like on mine, using the Athena_SPL1.2_WM6.1_B20931_WWE_R6.1-MiChY
Hi,
I am new to this forum, I am having a problem in my mobile Bluetooth receiving mechanism for which I need your expert opinions.
The problem is that when someone (either through PC / mobile) send multiple files through Bluetooth to my mobile I have to accept each number of files separately by going again and again in the notification area and after clicking the file and click 'accept'. In short if someone send me 5 files I have to go to the notifications 5 times and have to click accept 5 times as well.
I want to know is this the standard feature or I have some problem in my set? I am not using any apps for this purpose just using the standard feature of the set.
Kindly help me in this regards.
Following are the details of my Android Set:
Set Name : Star A5000 Android 2.2 Dual Sim
Model Number: e1000_pxht2 2010/11/16 11:8:23
Android Version: 2.2.1
Baseband Version: MAUI.10A.W10.48. 2010/11/29 22.57
KERNEL VERSION: 2.6.32.9
[email protected]#1
thu Dec 16 14:03:12 CST 2010
Build Number: ALPS.10Y.W10.48 p27.MP.VO
thats just how Bluetooth file transfer works bro. You could zip up the files and just unzip it when you receive them.
I have checked the same feature on another Samsung android phone and the phone receive continuously all the files without separately accepting the files in notification area.
yeah well Samsung is crap anyway so don't be mad you don't have a Samsung its just the Bluetooth that ya got and the company that made your os hasn't enabled all the bells and whistles its probably a dated most general version available. Nothing you can do other than check out the different apps if there are any availble. Or archive the files and unzip them so you only have to do it once. I don't know much about the device you have but not everything is capable of doing 100 things at once. Patience my friend patience.
If anyone know please answer the question.....
Question: are those sending devices already paired with your phones ?
Try 1: Mark the sending device as "trusted" after you pair (might depend on your device how to do it in the bluetooth settings), this way no further notice will appear in accepting the files that you are getting from the other phone or pc.
Try 2: Use a 'folder browsing' (not 'object push') profile for transfering files.
Take a look at this neat program to handle bluetooth connection from your PC, I find it really useful (free & lightweight & works)
ObexCommander
Hey guys!
I´m new here and I hope you can help me with some questions... I didn´t know if I´m right here, so please correct me if I do something wrong
My "setup":
- Samsung S3 international with CM13
I like to create a global "Content Filter", which filters files (pictures, videos, documents, etc.) on my smartphone. So what I mean is something like what the UserManager (sorry I can´t poste the Link to Android API) from Android framework does:
User A (owner) creates pictures with the camera, download files, etc. and if User B (guest) logs in, User B can´t access the files from User A and vice versa.
The diffrent part is that I like to "hide" or better make them not accessable by custom criteria - for example "only pictures from the last two hours will be shown to User B". And the main point ist that every application gets the same content.
I thought I have to edit and extend the internal/external storage functions (or ContentProvider?) by my custom filter. Later there will be a system app for controlling the behavior of this filter.
Now there are some question, which I ask myself:
- Is it possible to implement this functionality in Android specific code and not in device specific code? So is it possible to make it portable for other devices and Android versions (Custom ROM, manufacture ROM or the pure Stock Android from Google´s Nexus phones) without "much" effort?
- Does it make more sense to use the original Stock Android instead of Cyanogenmod to reach the portability?
- Where do I have to start? I downloaded the source Code of CM13 for the Samsung S3. But how I ask before - is there a generic way for all devices and android versions? I started to look into the framework specific code of android (system/frameworks/base/... ). I thougth I can build the filter between the api calls (java -> jni bridge -> c/c++), but that would be not the right place, yes?
I hope someone understand my plan and can help me with some informations and tipps or where I have to look to get them!
Thanks!!
Fabian
I think you might mean the profile system that android used to have on ICS?.
Unfortunately I can't answer why they removed that feature. Does the phone not have an option or something if you have 2 or more google accounts registered to the device?..
Beamed in by telepathy.