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
Hi folks,
Although I am generally not timid about modding certain products (such as my computers and TiVo), I do like to first take my time before diving in until I'm sure I've read most of the relevant threads and have gathered up the complete suite of software tools in one place. The resources on this site and the work of folks such as DCD and nueChem are amazing and outstanding and I want to say thanks for that.
As of yesterday, I felt read to take the plunge installing the bootloader, 3.27 radio ROM and DCD 2.3.2 kitchen build on my XV6800. However, I didn't just go with the stock kitchen. I added a couple of additional OEM packages from Alex.Kaiser.v4.OEM.Packages (the nue LED and audioparam packages and Resco File Explorer 2007 in particular).
The updating went great and I was able to OTA reprogram my phone without needing to call Verizon. However, I noticed that something wasn't right.
First, my phone had no connection data onboard so the phone didn't know to dial #777 for a data link and my attempts to enter this manually didn't give me any success.
Second, my PC wouldn't see the device unless I deselected the "advanced network features" (or similar, I forget the exact wording) checkbox.
Third, I couldn't install CAB files. They'd terminate immediately with an "installation was unsuccessful" message.
Finally, once I was able to establish a connection to the PC, I could add and remove files from the device *only* from the PC. Attempts to delete files from the device itself were met with a file permissions error.
After playing around for a while trying every tweak I could think of, I tried using Resco Explorer and, after a few minutes, got a registration code error/warning message. This made me wonder if this package was the problem: preventing certain types of file access due to it being in a limited-functionality mode from lack of a proper reg code.
So, I rebuilt the ROM without it and now all is well! I'm loving the new dialer and comm manager as well as the active GPS (I've tested it only with Google Maps and GPSToday so far and it gets to within half a block). Not sure how well EV-DO Rev A is working yet. I tethered the phone and ran an online speed check, obtaining 1.2Mbps download but only 60kbps upload. It's possible this is related to my local coverage (Nyack, NY), so I'll try this again from a known-good Rev A area.
Anyway, just wanted to relay my experience in case it proved useful to anyone.
One other thing: I used PIM Backup to backup my data beforehand since my sycing is generally done on my work machine and I was doing the ROM updating from home. Upon restore, it wouldn't restore my email messages because it didn't find the corresponding account. So, it's important to note that this account info isn't backup up and that you first need to create the account before doing the restore step (making sure to name the account the same as before so that it matches up).
David
"Chris Walsh, member of the ChevronWP7 team has posted a workaround on its blog letting carrier-branded HTC users emulate a non-branded Windows Phone 7 in order to apply the update immediately. The procedure "un-brands" the HTC device and tricks the system into believing it is carrier independent and good to go for the update. Please note that the hack is for HTC devices only and is an advanced technique. Check out the source link if you want to apply' be warned though, you're doing it at your own risk!"
Source: Pocketnow Story Article
Chris Walsh Blog Here: "My Coding Adventure":
Content:
Chris Wash said:
Howdy!
So NoDo was finally released this morning. Well, for the EU people anyway (don’t get me started).
Windows Phone 7, by default, stores your operator identifier in a sneaky registry key, which is checked by the Windows Update Client running on the phone. This identifier is then used to check if the updates have been approved for your operator. If they are slow, like Telstra here is in Australia, you’re going to be waiting a long time.
So, let’s tell you how you can “un-brand” (this won’t remove the boot splash screen) your phone so it appears to be a generic handset to the Update Servers.
Your device needs to be dev-unlocked for this to work. Sorry folks.
Download this zip file and deploy the 3 xap files onto your device.
Run the ChevronWP7.Ringtones.xap and wait till it displays “Ringtones added… and CustClear.provxml underneath”
Run the TouchXplorer app, navigate to My DocumentsMy Ringtones click on CustClear.provxml and select Copy from the Application Bar.
Navigate back inside TouchXplorer to the Windows folder.
Select paste from the Application Bar, this should scroll right to the bottom and put a copy of CustClear.provxml in the Windows folder.
Now run the Connection Setup application and click on the Ok button (it’s the one with the tick).
And now you’re done and free to re-connect to Zune and check for updates.
Again, this is ONLY for HTC devices.
Click to expand...
Click to collapse
I didn't get the NoDo and my device is "up to date"T-T
That seems to be updating people from 7004 to 7008 who previously couldn't get the 7008 update. Only a very few people seem to have had success moving from the 7389(RC) to 7390. Even those using unbranded handsets aren't seeing the updates.
MS are world class experts at pissing off there customers
Infuriated-Germ said:
That seems to be updating people from 7004 to 7008 who previously couldn't get the 7008 update. Only a very few people seem to have had success moving from the 7389(RC) to 7390. Even those using unbranded handsets aren't seeing the updates.
MS are world class experts at pissing off there customers
Click to expand...
Click to collapse
What I posted was to remove the operator part of the updates, MSFT still region block updates. Which is why some are having success with German VPN providers.
OK Guys ... finally managed to get my Mozart updated to NoDo.
Used the intructions from here (lots of unsuccessful reports for Mozart apparently)
http://pocketnow.com/windows-phone/force-wp7-nodo-update-for-some-unlocked-phones
Lots of users also reporting success over on the Omnia forums with some more giving some handy tips
http://forum.xda-developers.com/showthread.php?t=1011663
I only used the first link & followed it precisely.
Also before making the first VPN connection I flushed the DNS cache on my laptop to remove stale entries (from command line type "ipconfig /flushdns")
Also when Zune presents the update and you get to "Step 2", you need to disconnect the VPN connection and browse to google on a browser otherwise it just sits at 0% and fails (because it has the VPN gateway metric sitting in your PC's route table with a lower value than your proper default gateway).
1st Attempt failed.
2nd Attempt found the update and failed because Zune stopped responding and crashed (because I disconnected VPN too early ... before "Step 2" on Zune)
3rd attempt Success and kept ALL my settings
For the sake of making it quicker (whole process took 45 mins for me) remove all media (mp3 & Videos etc) from your phone or your backup stage (on Zune) will take that much longer.
Success
I did my phone today using Walshies blog instructions for debranding and then for getting NoDo. Worked like a dream.
Pro = I has NoDo
Cons = No more sideloading apps. Every side loaded app I had requests deletion when run now.
Overall I'm a happy little vegemite.
Thanks Walshieau, great stuff, from you and the Chevron team.
BlueAnt1958 said:
I did my phone today using Walshies blog instructions for debranding and then for getting NoDo. Worked like a dream.
Pro = I has NoDo
Cons = No more sideloading apps. Every side loaded app I had requests deletion when run now.
Overall I'm a happy little vegemite.
Thanks Walshieau, great stuff, from you and the Chevron team.
Click to expand...
Click to collapse
Dude don't scare me. I have done exactly according the instructions and everything worked perfectly.
My Mozart got an February update first, and after updating to 7008, it is now preparing to update to NoDo.
Most of my apps are sideloaded, it would be hell if I had to install em all again.
Hello there!
Any news on a generic ROM for UK. I currently have a branded Orange UK ROM and I've read the European ROM changes the keyboard??? What exactly does it do to the keyboard?
Copying from my previous post:
I made a tool to "force update" my phone (Honor View 10, European/C432 model), and I thought I'd share it in case anybody wants to give it a try.
Notes
It is Windows-only (Specifically Windows 10 (64-bit), build 1809, although it probably works fine for most/all other versions of Windows)
It requires .NET Framework to be installed on your computer. It can be downloaded from here
It might cause some anti-virus programs to flag it due to the nature of the tool (although nothing on VirusTotal detects it as malware)
Currently, a lot of stuff is hard-coded (source code available below), including the path to HiSuite.exe. If the path to your HiSuite installation isn't "C:\Program Files (x86)\HiSuite\HiSuite.exe" (or "C:\Program Files\HiSuite\HiSuite.exe" in the case of 32-bit Windows), the tool won't work
It's currently only supposed to work with the BKL-L09 (C432) model. Do not use this tool if you do not have the BKL-L09 (C432) model
If you are on 32-bit Windows (your HiSuite installation path is "C:\Program Files\HiSuite" instead of "C:\Program Files (x86)\HiSuite"), download the HuaweiUpdaterWin32.7z file. Otherwise, download the regular HuaweiUpdater.7z file
And, of course, please use the tool at your own risk. I'm not responsible if the update somehow ends up breaking your phone.
Usage
Connect your phone to your computer through USB
Before proceeding, make sure HiSuite isn't running. Open Task Manager (Ctrl+Alt+Del -> Task Manager or Ctrl+Shift+Escape) and make sure "Huawei PC Suite" (hisuite.exe) isn't running. If it's running, right-click and select "End Task" to kill the process
Run "Launcher.exe" and HiSuite should open
Click on the "Update" button. There should be a red dot on it
Wait for HiSuite to finish installing the update on your phone
Source code can be found here: https://github.com/Smaehtin/HuaweiUpdater
Here's a version that should work for the Indian (C675) variant.
Reserved
can not download the indian version link
ram161287 said:
can not download the indian version link
Click to expand...
Click to collapse
Strange, maybe it works with TinyUpload:
HuaweiUpdater(C675).7z
HuaweiUpdater(C675)Win32.7z
It worked! I updated to Android 9.0 with EMUI 9. Thanks, mate!
Does it revert your phone to factory setting?
The procedure worked like a charm! I'm on Pie now
All apps and settings stayed untouched, no factory reset.
Works great for the Indian variant:good:
You sir are amazing..tyvm
Thanks for the method mate.
Smaehtin said:
Here's a version that should work for the Indian (C675) variant.
Click to expand...
Click to collapse
I will try this today. Btw, can you just elaborate what is your approach for this solution? I mean the other Firmware finder solution masks your DNS and then updates the firmware and ROM. 2hat does your solution do? I am not a developer but just wanted to know how does it actually work. If it's too technical or difficult to explain, let it be. Just being curious. Thanks and happy new year dude
Will try tonight and feedback
kavee.gauravjoshi said:
I will try this today. Btw, can you just elaborate what is your approach for this solution? I mean the other Firmware finder solution masks your DNS and then updates the firmware and ROM. 2hat does your solution do? I am not a developer but just wanted to know how does it actually work. If it's too technical or difficult to explain, let it be. Just being curious. Thanks and happy new year dude
Click to expand...
Click to collapse
The way the FunkyHuawei and Firmware Finder method works is by you configuring your network to use their DNS server. A DNS server is what is used on the internet for "resolving" a domain name (like google.com, .xda-developers.com, hicloud.com, etc.) into an IP address. So, when a "client" (either your computer when using HiSuite to check for updates or your phone) asks for the IP address of query.hicloud.com (used for update checking), instead of giving you the IP address of Huawei's update server like a normal DNS server would, it gives you the IP address of FunkyHuawei/Firmware Finder's update server.
So now, whenever you do an update check, you're not talking with Huawei's update server but a "fake" server, but your phone/computer isn't aware of this (well ...), and when your phone/computer asks this server if updates are available and if your phone is allowed to install the update, the server will just say "Yeah, here's the update, go ahead and install it".
My method is similar in some ways. What it does is "hooking" the HiSuite process. This allows my tool to intercept and alter communication between HiSuite and Huawei's update server, and by spoofing some requests/responses, it acts somewhat in the same way a "fake" server would. So, when HiSuite asks the update server if there are any updates available for your phone, the update server will say "Nope, no new updates at the moment" - but my tool will intercept that and overwrite the response with a "Yep, here's the update" instead.
Hopefully that explains things
Not to shabby
Launcher.exe not working for me on Windows 7 Please help
Smaehtin said:
The way the FunkyHuawei and Firmware Finder method works is by you configuring your network to use their DNS server. A DNS server is what is used on the internet for "resolving" a domain name (like google.com, .xda-developers.com, hicloud.com, etc.) into an IP address. So, when a "client" (either your computer when using HiSuite to check for updates or your phone) asks for the IP address of query.hicloud.com (used for update checking), instead of giving you the IP address of Huawei's update server like a normal DNS server would, it gives you the IP address of FunkyHuawei/Firmware Finder's update server.
So now, whenever you do an update check, you're not talking with Huawei's update server but a "fake" server, but your phone/computer isn't aware of this (well ...), and when your phone/computer asks this server if updates are available and if your phone is allowed to install the update, the server will just say "Yeah, here's the update, go ahead and install it".
My method is similar in some ways. What it does is "hooking" the HiSuite process. This allows my tool to intercept and alter communication between HiSuite and Huawei's update server, and by spoofing some requests/responses, it acts somewhat in the same way a "fake" server would. So, when HiSuite asks the update server if there are any updates available for your phone, the update server will say "Nope, no new updates at the moment" - but my tool will intercept that and overwrite the response with a "Yep, here's the update" instead.
Hopefully that explains things
Click to expand...
Click to collapse
Thanks for this great explaination. I think i understood now. Why don't you include this in your initial posts? Its a nice learning for noobs like me. Just a suggestion. I feel there is very little *educating* material for Honor devices like the one you told about, or about rooting, or downgrading etc., at least for view 10. Unlike OnePlus devices. So I feel this might educate people who are just enthusiast, non technical and want to know few things.
Btw, the tool didn't work for my Indian model. Guess, because I am on EMUI 9.0 beta already. But thanks for the information
Shivang003 said:
Launcher.exe not working for me on Windows 7 Please help
Click to expand...
Click to collapse
Same for me, any solution for that please reply if any.
No luck. Tried 2-3 times, even made the changes to FF DNS so that firmware is approved but nothing on hisuite.
May be I am on EMUI 9.0 beta thats the reason its not showing anything but will eork for EMUI 8 users.
works great mate! thanks for your work and sharing!