Random MAC Address Issue Explored and Illuminated - Samsung Galaxy Nexus

Below is probably an excessive amount of explanation of everything I have dug up on this issue. If you aren’t interested in the details, the numbered points should be fine. The rest aims at assisting people who know more than me to possibly arrive at a solution as no one appeared interested in fixing it. So hopefully this info will show that this is indeed a problem and not the intended behavior for these devices.
So while bored and tired of signing into my school network every day, I spent a good chunk of Friday looking into the issue I and others have had of getting a random wifi MAC address every time we boot our phones. Initially, I just set out to attempt to lock in one of the random addresses until I wiped my phone. For that would be miles above it randomizing every boot. What I discovered, however, was that there is a great deal more to this issue than has been shared in any of the threads I have found. I will outline my findings below and then attempt to explain them in more detail.
There was a rumor floating around that Samsung/Google did this intentionally in order to avoid having to purchase a range of MAC addresses for these phones. This is decidedly FALSE and something I have never been able to accept, but now I have proof:
As shown in posts around the web, there exists code in the Kernel for generating a random MAC. What is not shown, however, is that this is simply a backup case if the kernel isn’t explicitly passed in a MAC. I was able to find my correct MAC in the HIDDEN file: “/factory/wifi/.mac.info”. This address was 1 higher than the Bluetooth MAC that is displayed which is how they are typically distributed to these devices, sequentially
This discovered MAC address has the first 3 digits of “2C:44:01” which seem to match the addresses reported for people who don’t have the randomizing issue. It also matches the address people have had before it changed to being random: (https://community.verizonwireless.com/thread/767358)
The findings indicate that this issue is entirely software based OR possible to fix in software, at the very least.
The bad news: I don’t actually have a solution for fixing the problem the ‘correct’ way, as it is likely an issue with the boot loader. That said, I think it is highly probable that given the MAC exists on disk, the kernel/rom could be modified to read it from there and provide a solid fix, at least temporarily.
If you know of this issue, you have likely seen the randomizing code in the kernel. What you haven’t seen, is the code that comes directly before it. I’ll try to explain it the best I can for those not versed in the wonders of C and pointers using the “//” comments as the actual code has none. I pulled the file from francos source as I had no desire to download the entire AOSP source.
/arch/arm/mach-omap2/board-tuna-wifi.c:
Code:
[COLOR="DarkGreen"]//This stores the mac address, it is set by DEFAULT to 00:90:4C:00:00:00
//and this is why all random MAC’s have the first 3 octets as 00:90:4C[/COLOR]
static unsigned char tuna_mac_addr[IFHWADDRLEN] = { 0,0x90,0x4c,0,0,0 };
[COLOR="DarkGreen"]//This function is passed in a string on the kernel command line
//which is SUPPOSED to hold the wifi cards MAC address[/COLOR]
static int __init tuna_mac_addr_setup(char *str)
{
char macstr[IFHWADDRLEN*3];
char *macptr = macstr;
char *token;
int i = 0;
[COLOR="DarkGreen"]//If the string passed in is empty, we exit, leaving the
//default address intact[/COLOR]
if (!str)
return 0;
pr_debug("wlan MAC = %s\n", str); [COLOR="DarkGreen"] //Print to dmesg the passed in string[/COLOR]
if (strlen(str) >= sizeof(macstr)) [COLOR="DarkGreen"]//If not in the correct format, exit[/COLOR]
return 0;
strcpy(macstr, str);
[COLOR="DarkGreen"]//Copy the MAC over one byte at a time and convert the string into a
//machine-readable value[/COLOR]
while ((token = strsep(&macptr, ":")) != NULL) {
unsigned long val;
int res;
if (i >= IFHWADDRLEN)
break;
res = strict_strtoul(token, 0x10, &val);
if (res < 0)
return 0;
tuna_mac_addr[i++] = (u8)val;
}
return 1;
}
[COLOR="DarkGreen"]//This function will correctly accept and set the MAC, IF it is passed one
//We will see shortly the problem lies in the fact that it is passed nothing
//and this causes a random MAC to be used[/COLOR]
Code:
[COLOR="DarkGreen"]//This function simply tells the linux kernel to call the above function with the
//value that it is passed in on the command line[/COLOR]
__setup("androidboot.macaddr=", tuna_mac_addr_setup);
Code:
[COLOR="DarkGreen"]//Now is the “offending code” as it has been put
//The code is fairly straightforward and simply checks
//that the correct arguments are passed and that it is on
//the intended hardware but…[/COLOR]
static int tuna_wifi_get_mac_addr(unsigned char *buf)
{
int type = omap4_tuna_get_type();
uint rand_mac;
if (type != TUNA_TYPE_TORO)
return -EINVAL;
if (!buf)
return -EFAULT;
[COLOR="DarkGreen"]//Now, this code DOES randomize the MAC address. But this is ONLY done
//if the default address as shown above is still set. This would mean that
//the first function was passed in nothing or that it was unable to parse what
//it was given correctly.[/COLOR]
if ((tuna_mac_addr[4] == 0) && (tuna_mac_addr[5] == 0)) {
srandom32((uint)jiffies);
rand_mac = random32();
tuna_mac_addr[3] = (unsigned char)rand_mac;
tuna_mac_addr[4] = (unsigned char)(rand_mac >> 8);
tuna_mac_addr[5] = (unsigned char)(rand_mac >> 16);
}
memcpy(buf, tuna_mac_addr, IFHWADDRLEN);
return 0;
}
So now we know that having a random MAC address is not intentional, or at least not the default behavior. Now we will take a step out, to the kernel command line which is the mechanism from which the kernel is intended to receive a MAC address. This can be found in the ‘dmesg’ log or often in crash reports. The great beauty of this is that it also includes the bootloader and radio versions which will allow us to determine if it is limited to certain bootloaders or is a universal problem. (# is replaced for paranoia to protect the innocent)
Kernel command line: console=ttyFIQ0 androidboot.console=ttyFIQ0 mem=1G vmalloc=768M omap_wdt.timer_margin=30 no_console_suspend androidboot.serialno=################ androidboot.bootloader=PRIMELA03 androidboot.baseband=I515.FA02 lcd_bootfb=0xbea70000 mms_ts.panel_id=18 androidboot.cdma=I515.FA02 androidboot.macaddr=
Kernel command line: console=ttyFIQ0 androidboot.console=ttyFIQ0 mem=1G vmalloc=768M omap_wdt.timer_margin=30 no_console_suspend androidboot.serialno=################ androidboot.bootloader=PRIMELA03 androidboot.baseband=I515.FA02 lcd_bootfb=0xbea70000 mms_ts.panel_id=18 androidboot.cdma=I515.FA02 androidboot.macaddr=2C:44:01:##:##:##
Already we can see important similarities and differences. My kernel command line (top) and this random log I found through Google both have the same EVERYTHING; 4.0.4 bootloader and radios. The glaring difference being that my ‘androidboot.macaddr’ is blank, and theirs is not. Here are a few more for completeness:
Kernel command line: console=ttyFIQ0 androidboot.console=ttyFIQ0 mem=1G vmalloc=768M omap_wdt.timer_margin=30 no_console_suspend androidboot.serialno=################ androidboot.bootloader=PRIMEKL01 androidboot.baseband=I9250XXKL1 lcd_bootfb=0xbea70000 mms_ts.panel_id=18 androidboot.macaddr=
Kernel command line: console=ttyFIQ0 androidboot.console=ttyFIQ0 mem=1G vmalloc=768M omap_wdt.timer_margin=30 no_console_suspend androidboot.serialno=################ androidboot.bootloader=PRIMEKJ10 androidboot.baseband= lcd_bootfb=0xbea70000 mms_ts.panel_id=18 androidboot.macaddr=
Kernel command line: console=ttyFIQ0 androidboot.console=ttyFIQ0 mem=1G vmalloc=768M omap_wdt.timer_margin=30 no_console_suspend androidboot.serialno=################ androidboot.bootloader=PRIMEKL01 androidboot.baseband=I515.EK04 lcd_bootfb=0xbea70000 mms_ts.panel_id=18 androidboot.cdma=I515.EK06 androidboot.macaddr=
Here we have a GSM nexus, unknown model, and a CDMA Nexus on 4.0.3 bootloaders and radios, all failing to pass in a mac. It is worth mentioning that I reflashed my nexus to 4.0.2 rom and bootloader/radios and locked the bootloader only to have the problem persist. From this it should be reasonable to conclude that this problem happens on most bootloader versions but is also not guaranteed to happen with any version. Admittedly, I don’t know any other way that arguments would be passed into the kernel other than the bootloader so more insight on this might be able to help in crafting a solution.
As I mentioned above, what I believe to be the correct MAC does exist on the phone under /factory/wifi/ in the hidden file ‘.mac.info’. Additionally, the Bluetooth MAC is under the file /factory/bluetooth/bt_addr. While I was unable to find a reference to the wifi mac, I did find a line for the Bluetooth mac under the root directory in ‘/init.tuna.rc’ Line 103: setprop ro.bt.btaddr_path “/factory/bluetooth/bt_addr”. My first guess would be that a fix can’t be as simple as adding a line to point a property to the correct wifi address, but before this I had never touched Android or Linux source so I would love to be wrong about this.
Finding all of this info took about an hour, failing to find a solution took a bit longer than that. Hopefully someone with some/any experience can find this useful and at the very least be on the lookout for a solution in their ongoing hacking and cracking. If you have any corrections or insight into all of this please share. As I mentioned, prior to this I had only the experience of using C/C++ and writing my own OS for a small board computer, but had never touched the Android/Linux source. If anything I said was wrong/incomplete/unclear, please please tell me!

Thanks for the doing a bunch of research on this! I have this issue and it's incredibly annoying as my workplace uses MAC filtering which requires me to sign-in again after every reboot!

Thanks. I just started getting this issue today.

it seems that the Kernal devs are including a little patch to their projects, Lean Kernel on Gummy 1.2.2 seems to have halted this randomizing, im still with a MAC that was left from the Randomiziation, but at least thats stopped for the time being on my Gnex, i found the .bin file on my phone one time that contained my original MAC, and it would be nice to do like i did with my Droid X with this exact issue.. (started on the DX when i flashed a CM rom on it. , just like the issue surfaced on my Gnex when i flashed a AOKP rom)
go do a google search for the randomizing issue (as of this date), you will see that there is a quick and dirty (but working) fix for this... if you are willing to run Lean Kernel
http://lmgtfy.com/?q=galaxy+nexus+random+wifi+MAC

I wouldn't call it a fix, but I have seen it and it should work well enough as a workaround until Samsung/Google can hopefully fix the underlying problem.

Franco also incorporated this fix into his kernel in the nightly updates. I agree it's not a perfect fix, but I don't really care what the MAC address is as long as I don't have to enable the WiFi every morning at work anymore!!

Does anyone know if you can use this info for creating a macchanger program just like what's available for desktop Linux?
It's kinda ironic that this is a bug for some people but it would be a great feature for me.
I want to be able to spoof MAC addresses because some public spaces give free internet access to wifi devices but only for a limited time.
Sent from my HSPA+ Nexus Prime using Tapatalk 2

Solved
I noticed today that my phone has this problem, and figured out how to solve it the "right" way (no kernel hacks). I'd like to share what I found.
This post mentions that the bootloader's "param" partition contains the wifi MAC address at offset 0x0c90. I dumped the param partition from my phone, opened it in a hex editor, and found nothing but zero bytes at that location. I inserted the correct MAC address there, flashed it back, and lo and behold, it shows up in the "androidboot.macaddr" option, and in the Android OS.
Here's a step-by-step, with a caveat: carelessly changing things in your param partition may brick your phone. The steps below worked for me, but be very careful that you're making the change in the right place.
Determine what your wifi MAC ought to be. As mentioned in the OP, it can be found in /factory/wifi/.mac.info, and it's probably one greater than your Bluetooth MAC, which you can find by turning on Bluetooth and looking in the phone's status screen in settings.
Dump your param partition to a file, using the directions here. (Ignore the lock/unlock stuff, though it's a good idea to unlock your bootloader before doing this. You only need to dump the partition once.)
Copy the param file to your computer and open it in a hex editor. (Or just use a hex editor on your phone, I guess.) If you don't have a hex editor, try HxD.
Go to address 0x0c90. You should find a bunch of zero bytes there. Enter your MAC address as a colon-separated ASCII string, just the way it's written in the .mac.info file, starting at 0x0c90. If you've done it correctly, you should've overwritten 17 bytes that were originally all zero, and the MAC address should be visible in your hex editor's ASCII view.
Save the modified file with a different name. (Don't overwrite the original.) Check that the file size hasn't changed: it should be exactly 8388608 bytes, the same as the unmodified one. If yours is bigger, it probably means you inserted new bytes rather than overwriting existing ones.
Flash the modified file back to your phone's param partition. You can do this with the "dd" command in the same way that you originally dumped it (just swap the "if=" and "of=" filenames), but I did it using fastboot, just to ensure that I could do it that way, in case the change somehow prevented Android from booting and I needed to flash the original params back. A command like "fastboot flash param param-modified.img" should do the trick, assuming your bootloader is unlocked.
Reboot the phone. If you did the previous step using fastboot, choose the "Restart bootloader" option to make sure the bootloader reads the modified params before you choose "Start" to boot Android.
Once booted, make sure your wifi is turned on, then go to Settings -> About phone -> Status, and check the MAC address to verify that the change worked. (If it didn't for some reason, I'd recommend flashing the original param file back, in case you accidentally changed the wrong thing.)
In case it's relevant, I'm using the PRIMELC03 bootloader from Verizon's JRO03O OTA.

There's nothing in /factory/wifi/ on my phone.. unless my file manager doesn't show hidden files even when it set to show hidden files

CodedChaos said:
There's nothing in /factory/wifi/ on my phone.. unless my file manager doesn't show hidden files even when it set to show hidden files
Click to expand...
Click to collapse
There is a file in mine.
Will the next nexus have a longer screen?

I like Mac spoofing, this should be a feature
Sent from my Galaxy Nexus using Tapatalk 2

Excellent! This worked great, thanks for the info. Ill update the OP at some point to add your info. Might even try to whip up a quick app to automate the process because this was the most crazy annoying problem I have encountered with my phone and I can't imagine how many people have had it. Thanks again!

Wyzard256 said:
I noticed today that my phone has this problem, and figured out how to solve it the "right" way (no kernel hacks). I'd like to share what I found.
This post mentions that the bootloader's "param" partition contains the wifi MAC address at offset 0x0c90. I dumped the param partition from my phone, opened it in a hex editor, and found nothing but zero bytes at that location. I inserted the correct MAC address there, flashed it back, and lo and behold, it shows up in the "androidboot.macaddr" option, and in the Android OS.
Here's a step-by-step, with a caveat: carelessly changing things in your param partition may brick your phone. The steps below worked for me, but be very careful that you're making the change in the right place.
Determine what your wifi MAC ought to be. As mentioned in the OP, it can be found in /factory/wifi/.mac.info, and it's probably one greater than your Bluetooth MAC, which you can find by turning on Bluetooth and looking in the phone's status screen in settings.
Dump your param partition to a file, using the directions here. (Ignore the lock/unlock stuff, though it's a good idea to unlock your bootloader before doing this. You only need to dump the partition once.)
Copy the param file to your computer and open it in a hex editor. (Or just use a hex editor on your phone, I guess.) If you don't have a hex editor, try HxD.
Go to address 0x0c90. You should find a bunch of zero bytes there. Enter your MAC address as a colon-separated ASCII string, just the way it's written in the .mac.info file, starting at 0x0c90. If you've done it correctly, you should've overwritten 17 bytes that were originally all zero, and the MAC address should be visible in your hex editor's ASCII view.
Save the modified file with a different name. (Don't overwrite the original.) Check that the file size hasn't changed: it should be exactly 8388608 bytes, the same as the unmodified one. If yours is bigger, it probably means you inserted new bytes rather than overwriting existing ones.
Flash the modified file back to your phone's param partition. You can do this with the "dd" command in the same way that you originally dumped it (just swap the "if=" and "of=" filenames), but I did it using fastboot, just to ensure that I could do it that way, in case the change somehow prevented Android from booting and I needed to flash the original params back. A command like "fastboot flash param param-modified.img" should do the trick, assuming your bootloader is unlocked.
Reboot the phone. If you did the previous step using fastboot, choose the "Restart bootloader" option to make sure the bootloader reads the modified params before you choose "Start" to boot Android.
Once booted, make sure your wifi is turned on, then go to Settings -> About phone -> Status, and check the MAC address to verify that the change worked. (If it didn't for some reason, I'd recommend flashing the original param file back, in case you accidentally changed the wrong thing.)
In case it's relevant, I'm using the PRIMELC03 bootloader from Verizon's JRO03O OTA.
Click to expand...
Click to collapse
OMG Thank you...This fixed my problem. Definitely worked for my randomizing MAC address on my Toroplus Galaxy Nexus.

Go to address 0x0c90. You should find a bunch of zero bytes there
^^ I did the param dump and there is no such address in the file.

wildtouch said:
Go to address 0x0c90. You should find a bunch of zero bytes there
^^ I did the param dump and there is no such address in the file.
Click to expand...
Click to collapse
Same here...
4.2.1 stock rooted

AHA! I have not used a hex editor since the Atari Falcon 030 days I just remembered that you dont do a normal Control-F to find 0x0c90 and you (depending on the editor) dont need the 0x... so after "Going To" 0c90 it jumped to the spot and I entered the MAC, saved the file, pushed to the sdcard, flashed it with dd and rebooted. BOOM! My MAC is now correct!
FTW, Thanks you so much Wyzard256!

So I'm curious - if I were to flash a full stock image using flash.all would it correct the MAC address randomization? I really don't trust myself with a hex editor.
Sent from my Galaxy Nexus using xda premium

Tried with the JDQ39 factory image, and indeed that does not correct the randomized MAC address. Oh well, guess I'll be random.
Sent from my Xoom using xda premium

This is pretty awesome. Wyzard256's post should be added to the OP and stickied though with a warning that it can be risky and may mess up your phone if you're not careful. I did it and I'm good.
Sent from my Galaxy Nexus using Tapatalk 2

orthonovum said:
AHA! I have not used a hex editor since the Atari Falcon 030 days I just remembered that you dont do a normal Control-F to find 0x0c90 and you (depending on the editor) dont need the 0x... so after "Going To" 0c90 it jumped to the spot and I entered the MAC, saved the file, pushed to the sdcard, flashed it with dd and rebooted. BOOM! My MAC is now correct!
Click to expand...
Click to collapse
I opened the param file using a Hex editor on my phone and I don't have this entry either - I have 00000c8d and 00000c96, but no 00000c90. I'd try editing one of those two but after the warning ("carelessly changing things in your param partition may brick your phone") I'm too scared to randomly edit it.
--Oh! I just randomly clicked. It looks like I can access 0x0c90 if I choose 0x8d and "scroll to the right" on this editor. So 0x0c90 only corresponds to one of the pairs of numbers in my MAC address - I ultimately need to edit 0x0c90 through 0x0c95, right?
Trying this out now...
It looks like it didn't work..? Maybe I did it wrong. Phone's not bricked though!
EDIT: It definitely didn't work - my MAC still starts with "00:90:4c" and changes every time I reboot.
The only thing I can think I did wrong was the re-uploading of the param file. I did the inverse dd method, explicitely:
Code:
adb shell
su
dd if=/sdcard/param.unlocked2.img of=/dev/block/platform/omap/omap_hsmmc.0/by-name/param
exit
exit
I had renamed the file to param.unlocked2.img. So does this look correct?

Related

What we have tried and where to go from here

Ok, so we haven't had quite as much luck yet as we would have liked, but I think as we continue to try out different approaches we will have some luck. I think it might be beneficial for us to have a an overview of what has been tried and what has been attempted thus far. So here is a list of things people have tried (please feel free to add anything that I may have left out or accidentally overlooked).
Registry Edit to access Zune storage
I believe this was the first approach that people took to gaining access to the KIN, and this link provides a great walkthrough.​
Bitpim
This is a pretty good overview of what has been attempted through Bitpim. Recently some have even tried using some other software, namely CDMA Workshop, (Look at the last post of the page.) I would suggest that we also try a couple more:
RevSkills
UniCDMA​
Nvidia Tegra Flash
I forgot this when I first posted.​
OpenZDK
This was another potential since much of the hardware, namely the processor is the same on both the kin and zune.​
Looking for clues in the log files
To put it simply in the hidden menu there is an option to have system log s emailed to you. I tried reading through some and noticed some of the events and files that the KIN uses, but have not had any luck yet.​
FTP
This link is the same as the link for the Log Files above.​
Export/Import in hidden Menu
Once again, the linked used here is the same one for Log Files and FTP.​
Please add anything that I may have left out, either different approaches or links to helpful information. I haven't had a chance to tinker with RevSkills too much yet, but it looks real promising.
Ah, we mods like these threads. Keep it up. Stickied.
The hidden import feature becomes active if you create a contact while using
qpst. It imports but I don't know where it put that info.
Interesting to note is that None of my phone entered contacts show up in qpst.
It is like that directory is mapped to some other place.
I was able to create directories and added txt files using qpst that remain even after power cycling the phone. I haven't found any of this using the phone yet.
I am getting the same results as you when I use the EFS manager and service programming. I can create files and make changes and they last after reboot.
I find it odd that when I export contacts from the hidden menu the file is visible in windows explorer if I have edited the registry as noted in the first post. I find this odd because everything else that is visible on the device using this method is related to the Zune, i.e. photos, music, and videos.
I have started looking back at some of the log files that I had the phone email me through the hidden menu and I have found some AT commands for the phone along with some other information. Here is a little bit of one file that I just started sorting through. The formatting isn't perfect because the log files have a lot of unreadable characters, but I have bolded files and commands. I also left everything in the case (upper and lower) as I found it in the file. The name of this file is:
MICROSOFT-PMX-DEBUGSTRINGPROVIDER-CHANNEL.02.clg
MPM_MainsSmThread
MPM_BB_STATE_NORMAL_ON_PRE_UPDATE
MPM_BB_USB_DRIVER_LOAD_UPDATE_EVENT, dwWaitTime: -1
MPM_Util:USB Client 1 has been Loaded
MPM_Util:USB Client 2 has been !UnLoaded!
CDMA Radio Updeate: Text stored version : v0.4.727
CDMA Radio Update:Registry Key version: v0.4.727
CDMA Radio Update: Current Modem version: v0.4.727
MPM_MainsSmThread
MPM_BB_STATE_NORMAL_ON_PRE_UPDATE
MPM_MainsSmThread
MPM_BB_UPDATE_REQ_EVENT - No modem update is needed
MPM_MainsSmThread
MPM_BB_STATE_NORMAL_ON_POST_UPDATE
MPM_END_RSTISR_REQ_EVENT, dwWaitTime: -1
MPM_MainsSmThread
MPM_BB_STATE_NORMAL_ON_POST_UPDATE
MPM_END_RSTISR_REQ_EVENT MODEM RESET ISR Init Completed.
MPM_MainsSmThread
MPM_BB_STATE_NORMAL_ON_POST_UPDATE
MPM_POWER_ON_REQ_EVENT, dwWaitTime: -1
RILNDIS: GetPacketInterface Initialize = c117d634
Shutdown = c117c4e4
RILDrv : i : Accumulated response (1) : <cr><lf>
IOPTMODE: 6 <cr><lf>
RILDrv : i : Sending cmd: ATV0E0X3 <cr>
RILDrv : t : LoadEriData : Opening file
\RoamingIndicator\eri.bin
RILDrv : i : Accumulated response (1) : ATV0E0X3 <cr> 0 <cr>
RILDrv : t : LoadEriData:
\RoamingIndicator\eri.bin not exist. Err 0x00000002
RILDrv : i : Sending cmd:
AT+cstt=0, 1, 75, 85, 95, 100 <cr>
RILDrv : t : LoadEriData: Opening file
\Windows\eri.bin
RILDrv : i : Accumulated response (1) : 0 <cr>
RILDrv : i : Sending cmd :
AT+CSTT=1,1,18,22,26,30 <cr>
PMIC Boot cookie: rb7262h
RILDrv : i : Accumulated response (1) : 0 <cr>
RILDrv : i : Sending cmd :
AT+CSQT=1<cr>
RILDrv : i : Accumulated response (1) : 0 <cr>
RILDrv:i: Sending cmd:
AT+GMI; +GMM; +GMR; +CKEYPAD?25<cr>
RILDrv:i: Accumulated response: +CKEYPAD:25
RILDrv:i: Accumulated response (2): equesting :
IUSBON, USBST, New PLMST, timestamp, 10, 2,2944 <cr><lf>
RILDrv:i:Accumulated response(1): +IQMIREADY <cr><lf>
+IUSBON<cr><lf>+IECHO: Requesting:IUSBON, USBST,
New PLMST, timestamp, 10, 2, 2944 <cr><lf>
RILDrv:i: ParseNotificationOEM: +IQMIREADY: SetEvent for QMI Init
RILDrv:i: Accumulated response(1): +IUSBON<cr><lf> +IECHO:
Requesting: IUSBON, USBST, New PLMST, timestamp, 10, 2, 2944<cr><lf>
RILDrv:i: Accumulated response(1): +IECHO:
Requesting: IUSBON, USBST, New PLMST, timestamp, 10, 2, 2944<cr><lf>
RilDrv:arseGetEquipmentInfo Modem Version: 727
I found out one more thing, if you use the s+l+power comination when the phone is powered off and connected to the computer another USB device is found. I just found this thanks to conflipper's early work We will have to come up with some sort of driver for this now.
Here is the name of the device and the hardware IDs
Microsoft Pink Bootstrap
USB\VID_045E&PID_2345&REV_0000
USB\VID_045E&PID_2345
I also just found this hardware id when having the computer turned off and plugged into the pc. When I hold down u+s+b+power Windows finds another device with the following name and hardware IDs (According to what I have found online this VID is Nvidia.) So this might be where we can use the tegra chipset stuff.
APX
USB\VID_0955&PID_7416&REV_0103
USB\VID_0955&PID_7416
Thought I would also add that my phone is currently unusable, but on the positive side, I wouldn't found those other two usb hardware IDs if this hadn't happened. Sidenote, I was using QPST Configuration program, and I right clicked on the my phone in the active phones tab. I then clicked on "Configure service to port mapping..." and added one property (unforturnately, I can no longer go back to the window because the program doesn't recognize my phone now). At this point, my phone rebooted and is now stuck trying to boot up.
I don't think it is completely bricked, but I fear that until we pull a rom it is probably useless because it is stuck in a constant cycle trying to reboot. The only way to stop this is to remove the battery. I have since tried using the various key combinations provided by conflipper and have found that the bootstrapper combination (s+l+power) would probably work if we had a rom. I then tried the hard reset combination (c+b+power) which initially looks like it might work but then it gets stuck in the cycle of rebooting.
I am going to continue working on it, hoping that somehow now that I might have some extra sort of access to hardware, but I am afraid my contributions may be limited until we are able to pull a rom.
Sorry to hear that. There has to be a way of getting it out of the loop.
RevSkills Hardware Log.
Diag Port Supported Command List.
7E - TRS FRM MSG supported.
5A - CHECK AKEY supported.
59 - EFS CMD supported.
58 - GET IS95B supported.
57 - SET MAX SUP CH supported.
56 - SUP WALSH CODES supported.
55 - FER INFO supported.
51 - GET FEATURES supported.
49 - READ PRL supported.
47 - UNKNOWN unknown response:
45 - GET CDMA RSSI unknown response:
44 - CHANGE SERIAL MODE unknown response:
43 - GET PARAMETER unknown response:
42 - UNKNOWN unknown response:
40 - SET PILOTS unknown response:
3F - GET STATE unknown response:
3E - UNKNOWN unknown response:
3D - CONF SLEEP unknown response:
3C - GET PACKET SEQNO unknown response:
22 - DISPLAY EMU supported.
04 - PEEK DWORD supported.
03 - PEEK WORD supported.
02 - PEEK BYTE supported.
01 - Show ESN supported.
00 - Version Info supported.
Click to expand...
Click to collapse
(the phone rebooted many times while doing this test, hence the unknown responses).
I tested more of the options provided by the free version of Revskills and it was kind of funny to see how the keyboard emulator worked, but only for numbers.
After all the reboots and so, i got some hex descriptions for errors in a new folder, called Err. Uploaded a new screenshot from that folder contents.
Easy CDMA just lets you browse the filesystem we already know.... not so much fun.
Little update.
You seem to be able to enter the recovery mode holding the U S B + power option but, as i tried right now, also using "Volume -" + power as stated for other tegra devices. Can't check if that loads ok on the computer, as i dont have the usb cable here right now.
OOPS I made a mistake. I am not seeing anything using windows 7 using u+S+B and power up. Should I disable zune, change registry for zune back to normal etc??
You shouldn't have to because the device has a different hardware id, so the drivers installed for the zune portion aren't applicable. Try turning your phone off, plugging in the usb cable and then using the key combinations. If the new hardware message box doesn't appear, you should still see an unkown device in device manager.
Also you have to hold the u+s+b+power for a few seconds before it will be recognized. When I have done this the screen stays blank on my phone and the only way I know it is working is through Windows.
Using Windows 7 OS. I had to uninstall the zune driver located in portable devices in the device manager then it found new APX device and i was able to point to the NVIDIA driver. Tried ruining the phone (Flashing android to it) as in another thread but it also got stuck on the flashing prompt. Restarted phone normally and the windows found another device and loaded the zune drivers back.
Incidently, holding the volume down and power on does the same as the U+S+B+Power and is easier on the fingers.
Thanks and keep up the great work.
I again may have spoken to soon. I cannot duplicate the above scenario anymore.
I also can no longer transfer pictures taken with my phone on to my pc. I can add pictures to the phone from pc and back but not the ones taken with the camera. Originally I could with zune software. The folders for uploaded pictures are different then the ones taken with the phone. I really think that I screwed something in the phone up by playing with qpst and others.
I'm not sure about what you did there, but in my testing & curiosity purposes trials, i wasnt able to alter the device (do a write to memory), so i doubt that qpst or the others did it for you.
Also, according to coinflipper notes, the kin has several layers, including the SBL that is the one operating with the os directly (the "Ms Pink bootstrap" device), not the recovery mode, which basically put us handling a modem....
I'm trying some things, but no results yet... gonna take some time....
I have changed the USB password and added contacts (somewhere) while writing to the device using qpst. I changed the password to 000001. Is this a different part of memory I am fooling with?
Thanks
I am not sure. I have no previous experience with any phone deving nor Qualcomm tools. Just pointed what coinflipper said.
I said "basically a modem", cause you got diag(nostics) mode within a com port, and some users (in other posts) showed logs with AT commands.
I'm working with some tools to connect to the device, but using the driver we all got (zune software). Not promising anything, just peeking around some tests.
@mcdietz
Here I pasted a public output of the linux command "lsusb -vv" (ultraverbose) where Kin (factory default settings) values are.
http://pastebin.com/rZscb9wz
Is useful for usb access to the kin. Use at will.
I have been testing usb connections to the kin devices (the ones we used in this forum) and i checked this:
Kin mode (normal Zune mode):
- Using MTP protocol:
-- You can browse files/folders/track related to Zune values using the lib-mtp tools in the system you like.
-- You can format the device (zune related folders) & delete zune files using the lib-mtp tools.
-- You can't download files from the device using the lib-mtp tools (kin doesn't allow you to)
-- You can't upload files to the device using the lib-mtp tools (kin doesn't allow you to)
- Using raw USB:
-- You can Write & Read values to the device (Kin VID 0x045e, PID 0x0641). Protocol allowed: MTP
Click to expand...
Click to collapse
Of course, Zune software does use this mode and is allowed to write to the filesystem. But that's because before doing so, it uses MTP protocol values to send and receive crypto values based on JANUS from Microsoft (Microsoft DRM for Mobile Devices) and after crypto relationships, the usb commands enable the "Connected" window at the Kin.
Capturing and replaying this values over usb does not work (ever) and does not work for the kin (had to try), so no go-go from here. Also, we cannot know if it would be able (dreaming after bypassing the DRM) to go outside the pictures/music/etc folders.
On the other hand, MTP tools reports that our little friend is able to reproduce the following files:
Firmware file
MediaCard
Abstract Playlist file
Abstract Album file
JPEG file
Microsoft Windows Media Video
MPEG-4 Part 14 Container Format (Audio+Video Emphasis)
Advanced Audio Coding (AAC)/MPEG-2 Part 7/MPEG-4 Part 3
MPEG-4 Part 14 Container Format (Audio Emphasis)
Microsoft Advanced Systems Format
Microsoft Windows Media Audio
ISO MPEG-1 Audio Layer 3
Click to expand...
Click to collapse
Where firmware is strange and good but the question is... how to upload the firmwares files (you can get zune firmwares from the net) to the zune software on the device (and run them)?.
It's more interesting when you notice that firmwares contain "Zboot.bin" which is "Tegra device bootloader" but, sadly, doesnt work with nvflash because of what I said below. Those updates are WinCE updates too...
APX mode (nvidia "flashing" mode), with or without Nvidia driver.
- Using nvflash
-- You can't start flashing due to writing to usb error
-- Following attemps block the nvflash and device access.
- Using raw USB:
-- You can't Write or Read values to the device (APX VID 0x0955, PID 0x7416). Protocol allowed: None
Click to expand...
Click to collapse
This matches the post where coinflipper told us that you cannot dump the rom image.
Microsoft Pink Bootstrap (No driver):
- Using raw USB:
-- You can Write & Read values to the device (Kin VID 0x045e, PID 0x2345). Protocol allowed: Unknown
-- Phone answers "01" to all the write requests i did (from "00" to "FF").
Click to expand...
Click to collapse
markspace. com/kin/
Here's some software that was developed for it, but I'm guessing it is only client end?
I'm not allowed to link, so assemble the spaces yourself please
The link for the download (direct) , being for Mac(only) is:
http://www.markspace.com/kin/download.php
But you must register to get an activation code from the main page (posted by shlhu). It will need internet access to activate the software during installation and reboot after it.
Requires Itunes (for audio sync), Iphoto (for image, also have started it once), and Quicktime (for video).
I tested it with a fresh installed Snow Leopard and i can say that it works. I dunno how it does (without zune installed), but it works.
Unfortunately, i wasnt able to analyze the usb transmission there, so i cant compare with the windows one. If it can skip the JANUS drm, then we may have a chance. If it is the same process as windows... we are done... lol.

[HOW-TO] [CDMA] Backup your HA and AAA keys

Sometimes when you flash a new radio, or you mess around in QPST you can break your data. Whats behind the breakage you may ask? Its your AAA and HA shared secrets.
A little background information:
The HA key is what gets you 1x data on your carrier. This is carrier specific, however is NOT phone specific. This could be google'd if you really required it.
The AAA key:
This IS device specific, you cant google it. Its connected to your account, and the way to get it is not what some consider easy. This is what gets you EVDO speeds, with out it you are stuck on 1x. If you call your carrier they will not give it to you either.
Continuing on to more information...
We will need a few tools to backup the keys, some free some not.
Team BlueRidge Sense 2.1 (it contains proper apps for using DM PORT)
QPST (free find it online)
CDMA Workshop (the demo should be fine, you could also borrow it)
HTC DIAG drivers (Just google it and find the installation guide)
Time
A hex editor
Now for the fun.... (If something seems too vague, google it)
First, we must get msl, use the app MSL Reader in the market.
Now, dial ##PORT# on the you will get a menu, hit enable, and then
go ahead and enter your MSL.
Now, lets open QPST, set up the phone, and go to EFS in the services tab of QPST
Now in EFS, make a folder called "open sesame door" without quotes all lower case in the root directory of the file system
reboot your phone
Now---- Open CDMA workshop and connect to the com port of your phone
Lets do memory read here, see where stuff is
Readable area from: 013D:0000
Unreadable area from: 01EA:0000
Readable area from: C000:0000
Process is stopped at: C0F1:0000
That says, we can read 013D:0000 and C000:0000 Ill save you time and tell you we need to dump 013D:0000 however (for all vm ive seen)
So now, lets go back to cdma workshop (should be there already) and choose to read Memory, make sure eeprom is not checked
Start address will be 013D:0000 (what i mentioned earlier)
size 99999999
This will scan the phone and dump everything into a .bin
Lets get a snack while this dumps... It will take a while
_________________________________________________
Okay, now the thing is dumped, lets call this scan1.bin
Open this in hex now, and hit ctrl+f
search for the word "secret" No quotes of course
now (for vm) you will see vmug33k that is your HA key, the first one showed under secret is ALWAYS HA key
look down one line, whalla, your aaa key is right below. (BACK THIS UP email it to yourself take a picture, ect, DONT LOOSE IT EVER, YOU WONT GET IT BACK)
so now you have your keys backed up, i cant tell you what you can or cannot do with them, it is up to you the end user, however i cannot endorse flashing phones or any illegal activity. In the mannor I am providing this, it is to ONLY save your aaa key incase of a bad radio flash, if you ever find a leaked radio.
You're right Simon, you will not get that AAA secret back, better hope you have warranty if you lose it (i know from experience). Thanks for this.
On another note, do you know if their is a way to increase max speaker volume through qpst on this phone?
Does it allow you to write also?
What do you mean write?
To another device
Sent from my HTC_A510c using Tapatalk
You can but I can not say how as it's illegal in some cases. If you, the end user choose to, it is up to you. I can not endorse it, however, I can say, qpst is your friend
Sent from my HTC_A510c using Tapatalk
You say line below but that's a bit vague seeing as you don't say what offset length your using. Are you using 8, 10, 16 offset or what?
How long is the AKEY?
I'm a bit confused. I had it with QXDM but it doesn't work under Vista so I can't look it up the easy way.
Any help would be appreciated.
QXDM runs on Win7, don't know why it wouldn't on Vista... [the key is one must run it in XP compatibility mode]. That being said, the above tutorial references a tool in QPST [which doesn't require compatibility mode] called EFS Explorer; then switches to CDMA ware. It works as prescribed; no QXDM needed [QXDM didn't work for me attempting the easy way; doesn't display second set of info].
On specific question, if you open the dumped file in a hex editor [like HxD], you can visually see your aaa key after searching, as the tutorial suggests you do. I didn't need to put any offsets in my hex editor. You will find the aaa key to be 10 characters I believe for our phones [or more [[double that]] in binary].
Hope that helps; thanks for the tut Simon.
Rob
Sent from my PC36100 using Tapatalk 2

[Q] Mod Windows RT to enable Remote Desktop

In the past, Windows has had editions for consumers that did not include Remote Desktop enabled. Usually there was a patch to enable it. Recently it has been proved how there is almost no difference between Windows 8 and Windows RT and that RT is just a port of Windows 8. So what about all the system files? They can be changed just like x86 Windows. So what about enabling Remote Desktop, so we don't need a ARM remote app that we need to unlock Windows for, and we can use what comes with Windows. In the past we modified the termsrv.dll file and changed some registry settings. I've included the Windows 8 and the Windows RT versions of termsrv.dll so that maybe some clever ones might try and crack a solution to enabling it on Windows RT.
sionicion said:
In the past, Windows has had editions for consumers that did not include Remote Desktop enabled. Usually there was a patch to enable it. Recently it has been proved how there is almost no difference between Windows 8 and Windows RT and that RT is just a port of Windows 8. So what about all the system files? They can be changed just like x86 Windows. So what about enabling Remote Desktop, so we don't need a ARM remote app that we need to unlock Windows for, and we can use what comes with Windows. In the past we modified the termsrv.dll file and changed some registry settings. I've included the Windows 8 and the Windows RT versions of termsrv.dll so that maybe some clever ones might try and crack a solution to enabling it on Windows RT.
Click to expand...
Click to collapse
termsrv is a system service and how can we use a modified termsrv.dll before we use the Jailbreak tool?maybe we can edit termsrv.dll in the memory.
We can't, I suspect. Even after jailbreaking, the lack of a signature on a system file may be a problem. It's worth a shot, though.
termsrv.dll -should- be a usermode library that would be editable after the jailbreak.
I am able to take ownership of the file and replace it. But it won't use the termsrv.dll from my windows 8… I'm almost positive it is because the dll is different depending on architecture. But it should be as easily replaceable as any system file on windows 8, am I right? I don't see why it wouldn't but I could be wrong.
Yeah, pretty much. You definitely won't be able to use the Win8 version (x86 machine code, ARM processor, not gonna fly...) but a modified version of the Windows RT version might work. Bear in mind that since modifying the DLL will invalidate the signature, this won't work if the signature validation is enforced (i.e. you'll have to jailbreak).
Should be possible using the Remote Debugging Tools or, even better, cdb. Put it in a .cmd file in autorun and voila
clrokr said:
Should be possible using the Remote Debugging Tools or, even better, cdb. Put it in a .cmd file in autorun and voila
Click to expand...
Click to collapse
Please!! Remote desktop would be awesome enabled on the Surface RT, if someone could work on it I know a lot of people would be very grateful!
I've already posted a method that should enable RDP here: http://forum.xda-developers.com/showpost.php?p=36386089&postcount=211 - no need to patch DLL, and would work on an a locked device. But you'll have to manually edit binary registry value, instead of using a provided tool.
I have not tested RDP, but after using this method I was able to recover an option of joining device to Active Directory domain (it was blocked by the similar policies).
mamaich said:
I've already posted a method that should enable RDP here: http://forum.xda-developers.com/showpost.php?p=36386089&postcount=211 - no need to patch DLL, and would work on an a locked device. But you'll have to manually edit binary registry value, instead of using a provided tool.
I have not tested RDP, but after using this method I was able to recover an option of joining device to Active Directory domain (it was blocked by the similar policies).
Click to expand...
Click to collapse
Can you share how you managed to get the rt joined to a domain?
mamaich said:
I've already posted a method that should enable RDP here: http://forum.xda-developers.com/showpost.php?p=36386089&postcount=211 - no need to patch DLL, and would work on an a locked device. But you'll have to manually edit binary registry value, instead of using a provided tool.
I have not tested RDP, but after using this method I was able to recover an option of joining device to Active Directory domain (it was blocked by the similar policies).
Click to expand...
Click to collapse
Wouldn't both methods work though? Your method works by enabling features from other editions by telling Windows that's what edition it is running. It disables it when the Software Protection service restores it to the original template according to the edition. By patching the DLL file, you could trigger Remote Desktop to work without it needing to check in with the kernel policies.
I mean unless you have a way to modify these policies without all the extra occuring, it would work. But Bitlocker and the Software Protection service getting involved...it just sounds like a lot of extra work for something much bigger in the end, and I know there must be an easier way to force Remote Desktop to work without listening to these policies because it has been done in the past.
mamaich said:
I've already posted a method that should enable RDP here: http://forum.xda-developers.com/showpost.php?p=36386089&postcount=211 - no need to patch DLL, and would work on an a locked device. But you'll have to manually edit binary registry value, instead of using a provided tool.
I have not tested RDP, but after using this method I was able to recover an option of joining device to Active Directory domain (it was blocked by the similar policies).
Click to expand...
Click to collapse
I tried to enable one of the Remote Desktop vars last night, allowRemoteConnections I think it was called, but I didn't get anything from it.
mamaich said:
I've already posted a method that should enable RDP here: http://forum.xda-developers.com/showpost.php?p=36386089&postcount=211 - no need to patch DLL, and would work on an a locked device. But you'll have to manually edit binary registry value, instead of using a provided tool.
I have not tested RDP, but after using this method I was able to recover an option of joining device to Active Directory domain (it was blocked by the similar policies).
Click to expand...
Click to collapse
Again, please if you were able to join an RT to the domain. Please let me know what you did. Would love to not get prompted to log in into PowerShell.
apatcas said:
Again, please if you were able to join an RT to the domain. Please let me know what you did. Would love to not get prompted to log in into PowerShell.
Click to expand...
Click to collapse
As I've already wrote - use this method: http://forum.xda-developers.com/showpost.php?p=36386089&postcount=211
1. Edit registry:
Code:
HKEY_LOCAL_MACHINE\SYSTEM\Setup
SetupType=1
CmdLine="cmd.exe"
and reboot. You will enter the setup mode. You would not see the mouse cursor in this mode, and you'll need a hardware keyboard.
2. Open this reg_binary value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ProductOptions\ProductPolicy. Look for unicode string "WorkstationService-DomainJoinEnabled", it is near offset 0x4000. Look at this screenshot:
http://imageshack.us/photo/my-images/526/35796208.png/
Select the "00" byte that follows the zero byte after the 64 (64 00 == unicode "d" letter) as you see on the screenshot. Overwrite it with 01. Be careful not to insert a byte, you need to overwrite the existing byte!
3. Rename sppsvc.exe to anything else so that it would not run on boot and reset ProductPolicy ("ren sppsvc.exe sppsvc.bak")
4. Reboot. Now the option to join the domain would be available.
I have not tried to add workstation to domain myself - try that and post here. After adding to domain you may try to rename sppsvc.bak back to sppsvc.exe as otherwise you'll get the "unactivated" Windows RT. I think that this would only remove the add to domain UI, but the RT would be still domain-joined.
I've tried to edit the remote desktop settings keys - this unblocked the corresponding options in the computer settings, but I was unable to connect. Maybe this is due to absence of RDP code in terminal server service - I don't see anyone listening port 3398 though TermServer service is running.
mamaich said:
As I've already wrote - use this method: http://forum.xda-developers.com/showpost.php?p=36386089&postcount=211
1. Edit registry:
Code:
HKEY_LOCAL_MACHINE\SYSTEM\Setup
SetupType=1
CmdLine="cmd.exe"
and reboot. You will enter the setup mode. You would not see the mouse cursor in this mode, and you'll need a hardware keyboard.
2. Open this reg_binary value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ProductOptions\ProductPolicy. Look for unicode string "WorkstationService-DomainJoinEnabled", it is near offset 0x4000. Look at this screenshot:
http://imageshack.us/photo/my-images/526/35796208.png/
Select the "00" byte that follows the zero byte after the 64 (64 00 == unicode "d" letter) as you see on the screenshot. Overwrite it with 01. Be careful not to insert a byte, you need to overwrite the existing byte!
3. Rename sppsvc.exe to anything else so that it would not run on boot and reset ProductPolicy ("ren sppsvc.exe sppsvc.bak")
4. Reboot. Now the option to join the domain would be available.
I have not tried to add workstation to domain myself - try that and post here. After adding to domain you may try to rename sppsvc.bak back to sppsvc.exe as otherwise you'll get the "unactivated" Windows RT. I think that this would only remove the add to domain UI, but the RT would be still domain-joined.
I've tried to edit the remote desktop settings keys - this unblocked the corresponding options in the computer settings, but I was unable to connect. Maybe this is due to absence of RDP code in terminal server service - I don't see anyone listening port 3398 though TermServer service is running.
Click to expand...
Click to collapse
Joined... Nice find.
apatcas said:
Joined... Nice find.
Click to expand...
Click to collapse
Have it remained domain-joined after restoring the original sppsvc.exe?
You have to return it back, otherwise you'll be annoyed with the activation reminders.
mamaich said:
Have it remained domain-joined after restoring the original sppsvc.exe?
You have to return it back, otherwise you'll be annoyed with the activation reminders.
Click to expand...
Click to collapse
We could possibly patch sppsvc to not check, then start the service up after jailbreaking it.
I'm honestly not sure if this would be considered piracy or not, though.
Edit: I used the program to set every value to 1 in setup mode (The latest jailbreak tool works in setup mode), and I didn't see any change for anything dealing with RDP.
Edit 2: Perhaps I shouldn't have set 'Disable' to 1. Regardless, I set it to 0 and the options popped up, but I can't get anything to go. As mamaich stated, I'm not seeing anything listening on port 3389. netstat -a -b on a desktop with it enabled says it's opened by CryptSvc, but I'm not seeing anything with CryptSvc that's not there on the tablet. That could just be netstat guessing which service running under svchost is actually running it, too.
netham45 said:
We could possibly patch sppsvc to not check, then start the service up after jailbreaking it.
I'm honestly not sure if this would be considered piracy or not, though.
Edit: I used the program to set every value to 1 in setup mode (The latest jailbreak tool works in setup mode), and I didn't see any change for anything dealing with RDP.
Edit 2: Perhaps I shouldn't have set 'Disable' to 1. Regardless, I set it to 0 and the options popped up, but I can't get anything to go. As mamaich stated, I'm not seeing anything listening on port 3389. netstat -a -b on a desktop with it enabled says it's opened by CryptSvc, but I'm not seeing anything with CryptSvc that's not there on the tablet. That could just be netstat guessing which service running under svchost is actually running it, too.
Click to expand...
Click to collapse
I think we must hack the dll file.But I find when I edit a byte in the dll,the service was not able to start.
apatcas said:
Joined... Nice find.
Click to expand...
Click to collapse
So is it true? that your device stays domain-joined after you restore sppsvc.exe?
@ Netham45, you could try to open up W81x86 termsrv.dll and go to these hex locations to find out what functions needed patching.
Hashes
File: W81x86\termsrv.dll
CRC-32: 202cd912
MD4: a879d39b8fbcd968b525af05a66aaf2c
MD5: 7a8e1158291cf4c8d8474a2091b9bf6d
SHA-1: e10028b074d24605e05b5e0bafd42f6a93ac01ad
1550F-15520
17428
A1B29
Then go into WinRT termsrv.dll, jump to those functions by name (because offsets will be different between x86 and RT) and Jmp or Nop as needed for WinRT. Afterwords it could be added via CDB / KD on-the-fly.

Uconnect 8.4 ver 17.11.07 trying to "root"

I was posting some questions in the "Rooted Jeep Cherokee '14 Uconnect" thread but I've started this new thread for the 17.xx versions because the methods (if we are able to identify them) aren't the same as the 16.33.29 and earlier firmwares...
I am still trying to crack into that unit with the 17.11.07 software. I have a D-Link USB Ethernet but its a HW revision D and I believe I would need a B if we can get ethernet enabled at all.
Also, if we can get Ethernet enabled we will still need to get SSH password or key.
devmihkel said:
For good or for bad NOT everything appears correct, except the running 17.x version... As of now neither the "commercial jailbreak" supports new versions (well yes they were using exactly the same file to start with Also 16.51.x or newer appears to be no go: uconnect-8-4-8-4an-update
EDIT: haven't got 17.09.07 to try, but on 17.11.07 manifest.lua has changed and the last block/ search keyword is "ota_update" instead. Otherwise all the same, image valid after the edit and script.sh gets fired - at least on 16.33.29 that is @HanJ67 Did you actually try to mount installer.iso after the edit and checked /etc/manifest.lua for the end result before?
Click to expand...
Click to collapse
devmihkel said:
Yeah, 2nd attempt is much better as last lua block is correctly terminated and your script might actually run, but unfortunately no successful 17.x runs have been reported so far SWF scripts are not involved in update/jail-breaking run, these ones become relevant only once you are in (and need to enable some app or wifi or navi features etc). Afaik 17.x blocks ethernet dongle usage as well, but let's see if even the USB driver/link gets activated at all?
Click to expand...
Click to collapse
Do you have a 16.33.29 version I can try this on? I'm wondering if it will get me far enough to execute the "manifest.lua HD_Update" hack you and @HanJ67 were discussing.
I've used the 17.43.01, then finally found a 17.11.07 and had no luck there either.
In my latest attempts on the 17.11.07, I was able to hex edit the "ifs-cmc.bin" on the UPD and replaced the SSH-RSA key with my own. I think this bin will be flashed to the MMC during an update.
That SWDL.UPD got past the initial check and rebooted into update mode, but then it fails the second ISO check and loops. I had to use an unmodified image to finish the update and get back up and running.
I keep reading about making changes only after the 2048 Byte mark in the older versions with the "S" at 0x80. Is this still relevant
in later ISO/UPD images and to the second ISO check?
Right now, I'm looking to find a way to disable that check so that my modified .bin will be written to disk? I think this route would work to also modifying and getting WiFi enabled after a flash of the edited image.
If I had I 16.33.29 or similar older UPD version to attempt the HD_UPDATE hack in the Manifest.lua file I would give that a shot to be thorough.
Do You have an idea how to connect by USB2LAN adapter to uConnect ?
Do You know if there is an UART pins on the mainboard ?
itsJRod said:
I was posting some questions in the "Rooted Jeep Cherokee '14 Uconnect" thread but I've started this new thread for the 17.xx versions because the methods (if we are able to identify them) aren't the same as the 16.33.29 and earlier firmwares...
I am still trying to crack into that unit with the 17.11.07 software. I have a D-Link USB Ethernet but its a HW revision D and I believe I would need a B if we can get ethernet enabled at all.
Also, if we can get Ethernet enabled we will still need to get SSH password or key.
Do you have a 16.33.29 version I can try this on? I'm wondering if it will get me far enough to execute the "manifest.lua HD_Update" hack you and @HanJ67 were discussing.
I've used the 17.43.01, then finally found a 17.11.07 and had no luck there either.
In my latest attempts on the 17.11.07, I was able to hex edit the "ifs-cmc.bin" on the UPD and replaced the SSH-RSA key with my own. I think this bin will be flashed to the MMC during an update.
That SWDL.UPD got past the initial check and rebooted into update mode, but then it fails the second ISO check and loops. I had to use an unmodified image to finish the update and get back up and running.
I keep reading about making changes only after the 2048 Byte mark in the older versions with the "S" at 0x80. Is this still relevant
in later ISO/UPD images and to the second ISO check?
Right now, I'm looking to find a way to disable that check so that my modified .bin will be written to disk? I think this route would work to also modifying and getting WiFi enabled after a flash of the edited image.
If I had I 16.33.29 or similar older UPD version to attempt the HD_UPDATE hack in the Manifest.lua file I would give that a shot to be thorough.
Click to expand...
Click to collapse
Hello, any news about it?
hi,
can you explain how to change SSH key in "ifs-cmc.bin" file?
thanks a lot
itsJRod said:
I was posting some questions in the "Rooted Jeep Cherokee '14 Uconnect" thread but I've started this new thread for the 17.xx versions because the methods (if we are able to identify them) aren't the same as the 16.33.29 and earlier firmwares...
I am still trying to crack into that unit with the 17.11.07 software. I have a D-Link USB Ethernet but its a HW revision D and I believe I would need a B if we can get ethernet enabled at all.
Also, if we can get Ethernet enabled we will still need to get SSH password or key.
Do you have a 16.33.29 version I can try this on? I'm wondering if it will get me far enough to execute the "manifest.lua HD_Update" hack you and @HanJ67 were discussing.
I've used the 17.43.01, then finally found a 17.11.07 and had no luck there either.
In my latest attempts on the 17.11.07, I was able to hex edit the "ifs-cmc.bin" on the UPD and replaced the SSH-RSA key with my own. I think this bin will be flashed to the MMC during an update.
That SWDL.UPD got past the initial check and rebooted into update mode, but then it fails the second ISO check and loops. I had to use an unmodified image to finish the update and get back up and running.
I keep reading about making changes only after the 2048 Byte mark in the older versions with the "S" at 0x80. Is this still relevant
in later ISO/UPD images and to the second ISO check?
Right now, I'm looking to find a way to disable that check so that my modified .bin will be written to disk? I think this route would work to also modifying and getting WiFi enabled after a flash of the edited image.
If I had I 16.33.29 or similar older UPD version to attempt the HD_UPDATE hack in the Manifest.lua file I would give that a shot to be thorough.
Click to expand...
Click to collapse
sofro1988 said:
Hello, any news about it?
Click to expand...
Click to collapse
I have not had had much time to work on this.
I actually had an idea last week that brought me back to this. I plan to use a custom flash drive to present an unmodified ISO for verification, then swap nand to an identical image that has been he's edited to enable usb Ethernet and add a custom key for ssh access.
I thought to stack a NAND on top of the original on a is flash drive, then breakout the Chip Enable pin to a switch. I've seen this done for with guys modifying game consoles to be able to run modified firmware.
Once the 2nd NAND is in place I will restore an image of the original nand containing the unmodified update, then hex edit the required portions to allow access after updating.
If this method works, I should be able to pass the verification with the original nand chip, then switch it (hopefully there's a big enough window to do this by hand) then present the modified nand before it begins the flash procedure.
Hopefully someone more intimately familiar with the update scripts can verify I'm not missing anything in the process
Tajadela said:
hi,
can you explain how to change SSH key in "ifs-cmc.bin" file?
thanks a lot
Click to expand...
Click to collapse
I used a hex editor to find the Ssh RSA key and replace it. This passed the initial check to reboot into update mode, but wouldn't pass the full check in update mode. I'm hoping my attempt below will pass that check and still update with the modifications.
itsJRod said:
I used a hex editor to find the Ssh RSA key and replace it. This passed the initial check to reboot into update mode, but wouldn't pass the full check in update mode. I'm hoping my attempt below will pass that check and still update with the modifications.
Click to expand...
Click to collapse
thanks for answer.
I saw an ssh key with the hex editor, but I would like to see exactly what you have replaced.
if it's not too much trouble, it would be interesting to see with some screenshots the changes you've made.
So we could work on two fronts. The idea of the double nand is good, but not very simple to make ...
Just thinking out loud here, when you say it passes the initial check, does it then give you any confirmation of that or any message on the screen before rebooting to upgrade mode?
Sent from my CLT-L09 using Tapatalk
SquithyX said:
Just thinking out loud here, when you say it passes the initial check, does it then give you any confirmation of that or any message on the screen before rebooting to upgrade mode?
Sent from my CLT-L09 using Tapatalk
Click to expand...
Click to collapse
I tried much the same thing -- the swdl.upd is another CDROM filesystem:
martinb$ file swdl.upd
swdl.upd: ISO 9660 CD-ROM filesystem data 'CDROM'
It contains three more .iso files : installer.iso, primary.iso, and secondary.iso
installer.iso is a CDROM image, but is not mountable on my linux system
primary.iso is a CDROM image, and has the usual /bin, /etc/, and /usr filesystem for an install
the /bin directory has one file - update_nand
the /etc directory has the usual mfgVersiontxt, nand_partion.txt, system_etfs_postinstall.txt, system_mmc_postinstall.txt and version.txt
the /usr/share directory is all the firmware for various components - EQ, HD_FIRMWARE, IFS, MMC_IFS_EXTENSION,OTA,SIERRA_WIRELESS,V850, and XM_FIRMWARE
What's interesting to me is that they did update the SIERRA_WIRELESS firmware -- and have done some housecleaning:
Code:
#---------------------------------
# sierra_wireless_disable_flowcontrol.file
# \d == 1 second delay
SAY " Send AT \n"
'' AT\r
OK \d
SAY "Disable flow control\n"
'' at+ifc=0,0\r
OK \d
SAY "Send SMS command CNMI\n"
'' at+cnmi=2,1,0,1,0\r
OK \d
SAY "Clear emergency number list\n"
'' AT!NVENUM=0\r
OK \d
SAY "Set emergency number to 911\n"
'' AT!NVENUM=1,"911"\r
OK \d
SAY "Save Setting\n"
'' at&w\r
OK \d
#---------------------------------
Also in the IFS directory, when you hexedit the ifs-cmc.bin file it reveals another little treat... an SSH root public key ( not as nice as a private key, but hey )
(Sorry about the formatting, this is cut/paste right out of the hex editor)
Code:
ssh-rsa [email protected]
2E..IwU.Q....njle8r9nrJ7h8atg4WfqswU0C0Rk/Ezs/sQs5ZA6ES82MQONjHBd7mw
uo8h0xfj3KeeSHMXCEBpmU26guNE4EqfvdioLFCDUxtvMYswlUZjsvd/NYz9lnUZg2hy
pwzFQjXgSzmHVrHjkKKvq7Rak/85vGZrJKxlvHnowA8JIl1tVNVQjPMNgDDJabaETtfw
LL1KlvAzI81cKOG/3IRn9lU6qyYqyG+zYoza0nN\..7/AtxdL481k81Go5c3NQTnkl2U
68lbu8CpnwrYCU098owLmxdI4kF5UOL4R61ItJuwz30JSESgT..!8RDgM6XEiHUpK9yW
vvRg+vbGWT/oQn0GQ== [email protected]
in /usr/share/MMC_IFS_EXTENSION/bin/cisco.sh and dlink.sh there's another good hint - what adapter you need for USB ethernet
Code:
#!/bin/sh
# Handle an Ethernet connection via the CISCO Linksys USB300M adapter
or
Code:
#!/bin/sh
# Handle an Ethernet connection via the D-Link DUB-E100 adapter
The static IP it brings up if no DHCP is offered is : 192.168.6.1
There's tons more in there -- like the V850 chip has access to the Sierra Wireless CDMA modem, but can configure it for voice calls through the car speakers:
"AT!AVSETPROFILE=8,1,1,0,5" ( embedded in the cmcioc.bin update file )
secondary.iso is a CDROM image and only has /etc/ and /usr
the /etc/ directory has speech_mmc_preinstall.txt and xlets_mmc1_preinstall.txt
the /usr/ directory has /usr/share/speech and /usr/share/xlets ( tons of information about sensors in the car, etc in xlets )
martinbogo1 said:
I tried much the same thing -- the swdl.upd is another CDROM filesystem:
martinb$ file swdl.upd
swdl.upd: ISO 9660 CD-ROM filesystem data 'CDROM'
It contains three more .iso files : installer.iso, primary.iso, and secondary.iso
installer.iso is a CDROM image, but is not mountable on my linux system
primary.iso is a CDROM image, and has the usual /bin, /etc/, and /usr filesystem for an install
the /bin directory has one file - update_nand
the /etc directory has the usual mfgVersiontxt, nand_partion.txt, system_etfs_postinstall.txt, system_mmc_postinstall.txt and version.txt
the /usr/share directory is all the firmware for various components - EQ, HD_FIRMWARE, IFS, MMC_IFS_EXTENSION,OTA,SIERRA_WIRELESS,V850, and XM_FIRMWARE
What's interesting to me is that they did update the SIERRA_WIRELESS firmware -- and have done some housecleaning:
Code:
#---------------------------------
# sierra_wireless_disable_flowcontrol.file
# \d == 1 second delay
SAY " Send AT \n"
'' AT\r
OK \d
SAY "Disable flow control\n"
'' at+ifc=0,0\r
OK \d
SAY "Send SMS command CNMI\n"
'' at+cnmi=2,1,0,1,0\r
OK \d
SAY "Clear emergency number list\n"
'' AT!NVENUM=0\r
OK \d
SAY "Set emergency number to 911\n"
'' AT!NVENUM=1,"911"\r
OK \d
SAY "Save Setting\n"
'' at&w\r
OK \d
#---------------------------------
Also in the IFS directory, when you hexedit the ifs-cmc.bin file it reveals another little treat... an SSH root public key ( not as nice as a private key, but hey )
(Sorry about the formatting, this is cut/paste right out of the hex editor)
Code:
ssh-rsa [email protected]
2E..IwU.Q....njle8r9nrJ7h8atg4WfqswU0C0Rk/Ezs/sQs5ZA6ES82MQONjHBd7mw
uo8h0xfj3KeeSHMXCEBpmU26guNE4EqfvdioLFCDUxtvMYswlUZjsvd/NYz9lnUZg2hy
pwzFQjXgSzmHVrHjkKKvq7Rak/85vGZrJKxlvHnowA8JIl1tVNVQjPMNgDDJabaETtfw
LL1KlvAzI81cKOG/3IRn9lU6qyYqyG+zYoza0nN\..7/AtxdL481k81Go5c3NQTnkl2U
68lbu8CpnwrYCU098owLmxdI4kF5UOL4R61ItJuwz30JSESgT..!8RDgM6XEiHUpK9yW
vvRg+vbGWT/oQn0GQ== [email protected]
in /usr/share/MMC_IFS_EXTENSION/bin/cisco.sh and dlink.sh there's another good hint - what adapter you need for USB ethernet
Code:
#!/bin/sh
# Handle an Ethernet connection via the CISCO Linksys USB300M adapter
or
Code:
#!/bin/sh
# Handle an Ethernet connection via the D-Link DUB-E100 adapter
The static IP it brings up if no DHCP is offered is : 192.168.6.1
There's tons more in there -- like the V850 chip has access to the Sierra Wireless CDMA modem, but can configure it for voice calls through the car speakers:
"AT!AVSETPROFILE=8,1,1,0,5" ( embedded in the cmcioc.bin update file )
secondary.iso is a CDROM image and only has /etc/ and /usr
the /etc/ directory has speech_mmc_preinstall.txt and xlets_mmc1_preinstall.txt
the /usr/ directory has /usr/share/speech and /usr/share/xlets ( tons of information about sensors in the car, etc in xlets )
Click to expand...
Click to collapse
Have you tried connecting to it?
Sent from my iPhone using Tapatalk
sofro1988 said:
Have you tried connecting to it?
Sent from my iPhone using Tapatalk
Click to expand...
Click to collapse
I managed to connect with the cisco adapter (usb / ethernet), but I don't know the root password. is the problem at the moment insurmountable ..
Using a cisco connector, I have gotten the ethernet to come up, but that's it. At the moment, there doesn't seem to be anything I can connect to.
@Tajadela - sounds like you at least were able to either SSH or telnet in to a port... I'm on software version 17.43.01 .. which are you on, and what year vehicle? ( Jeep Grand Cherokee, 2015, Uconnect 8.4AN with the 3G Sierra Aircard modem for Sprint )
martinbogo1 said:
Using a cisco connector, I have gotten the ethernet to come up, but that's it. At the moment, there doesn't seem to be anything I can connect to.
@Tajadela - sounds like you at least were able to either SSH or telnet in to a port... I'm on software version 17.43.01 .. which are you on, and what year vehicle? ( Jeep Grand Cherokee, 2015, Uconnect 8.4AN with the 3G Sierra Aircard modem for Sprint )
Click to expand...
Click to collapse
I connected in telnet on a uconnect 6.5 with firmware 15.xx.xx. You can connect to Uconnect with static IP it brings up if no DHCP is offered is: 192.168.6.1
itsJRod said:
I used a hex editor to find the Ssh RSA key and replace it. This passed the initial check to reboot into update mode, but wouldn't pass the full check in update mode. I'm hoping my attempt below will pass that check and still update with the modifications.
Click to expand...
Click to collapse
after rsa key replaced, do you have recalculate the checksum of UPD file?
have you replaced the first 64 bytes of the file?
thanks
@itsJRod, isn't it that you would like to explain the procedure to replace the RSA key in the swdl file? thank you
Hello,
have you made any progress? I am a bit lost. I put the EU uconnect MY15 to US dodge charger MY16 and Perf Pages were working fine even on 16.16.13, although after upgrade to 17.x (17.46.0.1 right now) I am meeting the problem of expired subscription (which is not possible to have on EU radio).
I am considering basically three solutions:
a) going back to US radio, but modify the language pack/nav/FM frequencies (it is doable, but I do not know how, although I can pay for it relatively less than time invested)
b) downgrade to 16.16.13 - I have no clue how to do it, I tried to put swdl.upd with swdl.iso as and installer.iso with no luck of course.
c) take xlets from KIM2/ of 16.16.13 to KIM23 of 17.46.0.1 secondary.iso - this is probably preferred way but I do not know how to make it to pass ISO validation.
Of course root on uconnect is extremely nice to have but I will be fully satisfied with Perf Pages working again.
Hello.
I'm hoping the community can help me out. I have a RAM 1500 with the RA4 (was running the 17.11.07 software that I got pushed to me OTS style a couple years ago. Since them problems, radio turn on delay, no GPS and cellular phone warning popup.
I was told to do the 18.45 update which I got from driveuconnect.com, but this has essentially bricked my radio with the "bolo update failed" error and it is looping continuously
I have tried many ways to modify the update software's manifest.lua script to try to get rid of the sierra wireless portion by manually editing, hex editing, etc but always get the "please insert the USB card" screen.
Uconnect is obviously completely worthless to help me and the dealer wants me to pay them money to tell me what I already know. I know I can pay 300 and send my radio to infotainemnt.com to get it repaired, but I would like to solve this on my own is possible, because I would like to further modify the software to make it more custom and unique.
From my reading the 17x version keeps you from downgrading to a version that can be hacked easily.
Everything seems like it should be pretty straight forward as I have a lot of experience in programming and embedded devices.
It seems they are validating the ISOs using some mechanism, I believe I have tried all of tricks/methods
I have searched the code to see if I can find the iso MD5 or SHA256 hashes that ioc_check is probably using to figure out I changed somethign but nothing work.
I have even tried the swapping the flash drives after validation but it seems they are using the ISos they already copied to continue the process, I then end u getting some invalid errors or the update just crashes out
I got other updates from the link: http://www.mydrive.ch/
http://www.mydrive.ch/http://www.mydrive.ch/
username: [email protected]
Password: gasolio
Havent tried all of them yet, but pretty sure they wont work, due to the 17x security changes.
Any help would be appreciated grealty, I really dont want to shell out any cash for something a company told me to to and due to their screw up with bricking modems, this is now bricking my radio.
Thanks to all in advance !!!
djmjr77 said:
Hello.
I'm hoping the community can help me out. I have a RAM 1500 with the RA4 (was running the 17.11.07 software that I got pushed to me OTS style a couple years ago. Since them problems, radio turn on delay, no GPS and cellular phone warning popup.
I was told to do the 18.45 update which I got from driveuconnect.com, but this has essentially bricked my radio with the "bolo update failed" error and it is looping continuously
I have tried many ways to modify the update software's manifest.lua script to try to get rid of the sierra wireless portion by manually editing, hex editing, etc but always get the "please insert the USB card" screen.
Uconnect is obviously completely worthless to help me and the dealer wants me to pay them money to tell me what I already know. I know I can pay 300 and send my radio to infotainemnt.com to get it repaired, but I would like to solve this on my own is possible, because I would like to further modify the software to make it more custom and unique.
From my reading the 17x version keeps you from downgrading to a version that can be hacked easily.
Everything seems like it should be pretty straight forward as I have a lot of experience in programming and embedded devices.
It seems they are validating the ISOs using some mechanism, I believe I have tried all of tricks/methods
I have searched the code to see if I can find the iso MD5 or SHA256 hashes that ioc_check is probably using to figure out I changed somethign but nothing work.
I have even tried the swapping the flash drives after validation but it seems they are using the ISos they already copied to continue the process, I then end u getting some invalid errors or the update just crashes out
I got other updates from the link: http://www.mydrive.ch/
http://www.mydrive.ch/http://www.mydrive.ch/
username: [email protected]
Password: gasolio
Havent tried all of them yet, but pretty sure they wont work, due to the 17x security changes.
Any help would be appreciated grealty, I really dont want to shell out any cash for something a company told me to to and due to their screw up with bricking modems, this is now bricking my radio.
Thanks to all in advance !!!
Click to expand...
Click to collapse
Just to follow up for anyone who reads this in the future.
I was able to get my uconnect working again a few minutes ago.
As my previous post stated I got stuck in the "bolo update failed" loop.
I downloaded the UCONNECT_8.4AN_RA4_16.33.29_MY16.exe update from the url posted in my previous comment.
I did the S Byte HEX Mod to the swdl.iso file, loaded it and the swdl.upd file on a thumb drive. Used Hxd on windows. Followed the section in the Uconnect exploitation PDF:
https://www.google.com/url?sa=t&source=web&rct=j&url=http://illmatics.com/Remote%2520Car%2520Hacking.pdf&ved=2ahUKEwjZsOGNl5nyAhWhGVkFHZy2AnAQFnoECAcQAg&usg=AOvVaw0NAi3a1eh-IRd3n1VHv-ys
When I plugged it in, it started with the update process, after the first unit, the screen said the Uconnect had to restart, please wait..
And whalaa my radio worked again!!! It even says it has the 18.45 firmware on it.. go figure.. Navigation still does not work, but thats most likely because the sierra wireless card is bad.
I cannot say for sure the S Byte thing did anything, because I'm not messing with this anymore, almost had to buy a new radio.
I would say try it with out, then with it if it doesn't work.
This could also be a fluke with my particular unit, but at least its something else to try than pay 600+ dollars!!
Good luck to anyone else who goes through this mess!!!
djmjr77 said:
Just to follow up for anyone who reads this in the future.
I was able to get my uconnect working again a few minutes ago.
As my previous post stated I got stuck in the "bolo update failed" loop.
I downloaded the UCONNECT_8.4AN_RA4_16.33.29_MY16.exe update from the url posted in my previous comment.
I did the S Byte HEX Mod to the swdl.iso file, loaded it and the swdl.upd file on a thumb drive. Used Hxd on windows. Followed the section in the Uconnect exploitation PDF:
https://www.google.com/url?sa=t&source=web&rct=j&url=http://illmatics.com/Remote%2520Car%2520Hacking.pdf&ved=2ahUKEwjZsOGNl5nyAhWhGVkFHZy2AnAQFnoECAcQAg&usg=AOvVaw0NAi3a1eh-IRd3n1VHv-ys
When I plugged it in, it started with the update process, after the first unit, the screen said the Uconnect had to restart, please wait..
And whalaa my radio worked again!!! It even says it has the 18.45 firmware on it.. go figure.. Navigation still does not work, but thats most likely because the sierra wireless card is bad.
I cannot say for sure the S Byte thing did anything, because I'm not messing with this anymore, almost had to buy a new radio.
I would say try it with out, then with it if it doesn't work.
This could also be a fluke with my particular unit, but at least its something else to try than pay 600+ dollars!!
Good luck to anyone else who goes through this mess!!!
Click to expand...
Click to collapse
I created an account just to reply to this and All I have to say is you're literally an absolute life saver. I've been working on this every day for two weeks now, trying every trick people said, trying every USB, every format, every version and nothing ever worked from me. Uconnect support was absolutely no help and it was a lot of back-and-forth finger pointing and no you need to reach out to this person between them and the dealership. Dealership tried to charge me for a Proxy Alignment when I asked to just update my damn radio stuck in this loop.
I have a 2015 Jeep Cherokee 8.4AN VP4 NA Head Unit 68238619AJ. I was updating from 17.11.07 to 18.45.01 and got stuck at the step 11 1% and would get a failed sierra wireless every time and then got in that "bolo update failed" loop..Well to fix it just now all I did was download the UCONNECT_8.4AN_RA4_16.33.29_MY16.exe update from the url posted in the previous comment and quick format to FAT32 on a 16GB Micro Center USB extracted the files from 16.33.29 to the USB with 7ZIP, plugged in like normal and BOOM it ran the first step restarted and I had a working radio again showing update 18.45.01.
(So i'm assuming you don't have to do the S Byte thing I didn't even mess with it I just used the 16.33.29 to bypass step 11 since that version only has 14 steps and 18.45.01 was already preloaded from attempting before. My navigation still is the wrong address but I don't care about all that just thankful to have my radio back before my wife killed me for trying to update it by myself. )
I hope this helps someone else one day because it took some deep research and hours on hours of forum hoping to finally find the solution. <3
djmjr77 said:
Just to follow up for anyone who reads this in the future.
I was able to get my uconnect working again a few minutes ago.
As my previous post stated I got stuck in the "bolo update failed" loop.
I downloaded the UCONNECT_8.4AN_RA4_16.33.29_MY16.exe update from the url posted in my previous comment.
I did the S Byte HEX Mod to the swdl.iso file, loaded it and the swdl.upd file on a thumb drive. Used Hxd on windows. Followed the section in the Uconnect exploitation PDF:
https://www.google.com/url?sa=t&source=web&rct=j&url=http://illmatics.com/Remote%2520Car%2520Hacking.pdf&ved=2ahUKEwjZsOGNl5nyAhWhGVkFHZy2AnAQFnoECAcQAg&usg=AOvVaw0NAi3a1eh-IRd3n1VHv-ys
When I plugged it in, it started with the update process, after the first unit, the screen said the Uconnect had to restart, please wait..
And whalaa my radio worked again!!! It even says it has the 18.45 firmware on it.. go figure.. Navigation still does not work, but thats most likely because the sierra wireless card is bad.
I cannot say for sure the S Byte thing did anything, because I'm not messing with this anymore, almost had to buy a new radio.
I would say try it with out, then with it if it doesn't work.
This could also be a fluke with my particular unit, but at least its something else to try than pay 600+ dollars!!
Good luck to anyone else who goes through this mess!!!
Click to expand...
Click to collapse
Do you have another link to download the UCONNECT_8.4AN_RA4_16.33.29_MY16.exe files? I am trying to help a friend of mine they way this helped me. Thank you again for this!

2017 Fire HD 10: Unbricking from anti-rollback

Disclaimer: To go through with this, you will have to open up your device to get access to the back of the PCB. This is not for everyone. If you encounter issues, I (or the others here) will try to help you, but the risk is all yours.
First, credit where credit is due. To xyz` for coming up with this and taking the time to help and to k4y0z for helping me get unstuck multiple times.
What's the purpose of this thread, you ask? It's to recover from a bricked 2017 Fire HD 10 as a result of sideloading to a lower version (from anti-rollback). This thread is not about rooting or other apps. Numerous threads of that type exist on these forums. If your device can get to the "amazon" screen or the "Fire" screen, do not waste your time here. Questions unrelated to anti-rollback unbricking will be mostly ignored.
This has only been tested on Linux (Ubuntu 16.04). In general, getting familiar with Linux (as opposed to Windows) can make all the difference in projects like these.
1. Make sure your device is powered off and disconnected from your PC.
2. Take off the back cover, remove the pieces of tape from the battery and display connectors, disconnect the battery and display cables, unscrew the PCB (11 screws), and gently lift it up. Take care not to rip the speaker wires from the board. (To unbrick, you do not have to connect the battery.)
3. Download and extract the contents of unbrick_suez.zip (attached).
4. Navigate to the root of the extracted archive and open a terminal there.
5. Optional: If you see serial port errors, disable or remove modem manager as root (command may vary with distro; try one or more of these commands in Ubuntu 16.04):
Code:
sudo apt-get remove modemmanager
sudo apt-get remove --auto-remove modemmanager
sudo systemctl stop ModemManager.service
6. Run the unbricking script as root:
Code:
sudo ./bootrom.sh
You should see it waiting for the bootrom. Let it be and do the following with the PCB.
7. Connect the microUSB end of the cable to the PCB. This is the more physically-challenging end of the connection. Leave open the PC side.
8. Short the point (highlighted in blue in the attached picture) to ground. Work with what you're comfortable with, but here's my approach (use M/M jumper wire if you have access to it):
a. Gently nudge one end of the wire into the metal case of the SD slot so that it stays in place (keyword: gently). This frees up one hand. You need just enough grip to ensure it doesn't fall off unexpectedly.
b. Hold the other tip of the jumper wire to the point highlighted in blue.
c. Connect the other end of the USB cable to your Linux box (remove the jumper wire when you're instructed to and press Enter on your keyboard).
You should see the following:
Code:
[email protected]:~/Desktop/unbrick_suez$ sudo ./bootrom.sh
[2019-02-03 12:28:08.466131] Waiting for bootrom
[2019-02-03 12:35:22.602290] Found port = /dev/ttyACM0
[2019-02-03 12:35:22.602653] Handshake
[2019-02-03 12:35:22.603225] Disable watchdog
* * * Remove the short and press Enter * * *
[2019-02-03 12:35:27.691503] Init crypto engine
[2019-02-03 12:35:27.709450] Disable caches
[2019-02-03 12:35:27.709854] Disable bootrom range checks
[2019-02-03 12:35:27.721298] Load payload from ../brom-payload/build/payload.bin = 0x45D0 bytes
[2019-02-03 12:35:27.724457] Send payload
[2019-02-03 12:35:28.262081] Let's rock
[2019-02-03 12:35:28.262834] Wait for the payload to come online...
[2019-02-03 12:35:31.824056] all good
[2019-02-03 12:35:31.824533] Check GPT
[2019-02-03 12:35:33.103565] gpt_parsed = {'lk': (20480, 2048), 'recovery': (174080, 34816), 'MISC': (123904, 1024), 'cache': (3515392, 868352), 'tee1': (22528, 10240), 'dkb': (18432, 2048), '': (0, 1), 'userdata': (4383744, 56687583), 'system': (208896, 3306496), 'PMT': (7168, 9216), 'tee2': (32768, 10240), 'proinfo': (1024, 6144), 'reserved': (124928, 16384), 'metadata': (43008, 80896), 'boot': (141312, 32768), 'kb': (16384, 2048)}
[2019-02-03 12:35:33.103747] Check boot0
[2019-02-03 12:35:34.291300] Check rpmb
[2019-02-03 12:35:34.499043] Downgrade rpmb
[2019-02-03 12:35:34.501403] Recheck rpmb
[2019-02-03 12:35:35.392720] rpmb downgrade ok
It should complete in a few seconds.
9. Unplug the USB cable after "rpmb downgrade ok" appears in the terminal.
10. Put your device back together (PCB and display/battery cables). Do not screw the PCB in or snap the back cover until you confirm your device has been unbricked.
11. Depress the power button (with your nail or a suitable tool) to turn on your device. (If it doesn't turn back on, hold it down for a few seconds. If you hear a ding, that's usually a good sign.) This can be challenging for the uninitiated, but don't complain. Obviously, it's better to verify unbricking now than after you put everything back together.
12. If the device turns back on, you can shut it down and put everything back together. If it does not turn back on, connect it to your PC and see what shows up with lsusb. Time to troubleshoot.
If you have questions, read the two linked threads above. If you cannot find the answer to your question(s), post here. If you append this entire OP to your post (instead of snipping most/all of it), I will, on general principle, ignore your post.
Source code: https://github.com/retyre/amonet/tree/mt8173
@retyre
Awesome effort! But best not to brick it in the first place!
If you want a new challenge, I suggest Fire HD 6/7 2014 on eBay. I need instructions for it, I have 2 very weird bricks
I get an error at wait for payload to come on line. Runtime error. Received {} instead of expected pattern. Format data runtime error received b instead of expected pattern.
DragonFire1024 said:
I get an error at wait for payload to come on line. Runtime error. Received {} instead of expected pattern. Format data runtime error received b instead of expected pattern.
Click to expand...
Click to collapse
I've started over a few times. The same result. I'll post a more detailed log when I get home. This is coming from the same tablet I tried to flash with the unlock.
Sent from my Amazon KFSUWI using XDA Labs
My Fire HD has erased part of the system file, so a boot loop has occurred. I tried adb sideload but never went back. Is it possible to reset factory by application this method?
Sorry Machine Translation.
86chan said:
My Fire HD has erased part of the system file, so a boot loop has occurred. I tried adb sideload but never went back. Is it possible to reset factory by application this method?
Sorry Machine Translation.
Click to expand...
Click to collapse
You can try. It won't cause anymore damage.
Sent from my Amazon KFSUWI using XDA Labs
This method worked and unbricked my 2017 HD 10 after a bad firmware flash. Had to run the script twice, the first time succeeded but the tablet didn't boot up. May have been completely out of battery after running itself down in a media loader bootloop all night but after a short charge the low battery icon flashed and back in business. Also helps to have a friend ready to plug/unplug the USB and hit enter when required, it's a very small spot on the board that you're shorting.
The hardest part was getting the shell off, once you unclip the sides you'll feel it's still "stuck" because there are 3 more clips about 1.5-2" from the left side of the tablet, starting 3" from the bottom. You just have to force them and the shell will pop off. Be careful they clip back in when you reassemble or they will push against the screen and cause white spots.
Thank you retyre for your efforts amongst many posts here, without this guide I'd be stuck with a paperweight. For anyone else with a hard bricked HD 10 2017 model, you've got nothing to lose giving this a go!
followed instructions from this post and from xyz prev one..and this is how it went..
1. try used USB 3 plug no success
2. try used USB 2 worked with no problems..now my Fire HD 10 is alive again..
OS used Ubuntu 18.04
all the thanks to you guys @retyre @k4y0z @xyz
First, Thank you for posting.
i have looked around the solution for bricked fire hd 10.
But, i have same problem like @DragonFire1024.
this is the log
[email protected]:~/Downloads$ sudo ./bootrom.sh
[2019-03-12 04:13:38.983635] Waiting for bootrom
[2019-03-12 04:13:48.574166] Found port = /dev/ttyACM0
[2019-03-12 04:13:48.578815] Handshake
[2019-03-12 04:13:48.586267] Disable watchdog
* * * Remove the short and press Enter * * *
[2019-03-12 04:13:53.935066] Init crypto engine
[2019-03-12 04:13:54.383858] Disable caches
[2019-03-12 04:13:54.391831] Disable bootrom range checks
[2019-03-12 04:13:54.616303] Load payload from ../brom-payload/build/payload.bin = 0x45D0 bytes
[2019-03-12 04:13:54.621105] Send payload
[2019-03-12 04:14:03.086231] Let's rock
[2019-03-12 04:14:03.093481] Wait for the payload to come online...
Traceback (most recent call last):
File "main.py", line 92, in <module>
main()
File "main.py", line 57, in main
load_payload(dev, "../brom-payload/build/payload.bin")
File "/home/skyhyung/Downloads/modules/load_payload.py", line 143, in load_payload
dev.wait_payload()
File "/home/skyhyung/Downloads/modules/common.py", line 171, in wait_payload
raise RuntimeError("received {} instead of expected pattern".format(data))
RuntimeError: received b'' instead of expected pattern
[email protected]:~/Downloads$
Click to expand...
Click to collapse
i am debugging it.
the result of self.dev.read(4) is null at module/common.py 169 line
i run the script on vmware ubuntu 16.04
---------- Post added at 10:24 PM ---------- Previous post was at 10:10 PM ----------
i solved it
i changed the TIMEOUT value to 10 from 5 at modules/common.py line 11
then, it works
@DragonFire1024
please try it like me
Thanks you.
Thanks you! I did restore my devices.
Hi everyone,
I'm trying to do as guided but get stuck at the step number 6, go this message:
[email protected]:~/Desktop/unbrick_suez$ sudo ./bootrom.sh
[sudo] password for nkp:
Traceback (most recent call last):
File "main.py", line 3, in <module>
from common import Device
File "/home/nkp/Desktop/unbrick_suez/modules/common.py", line 6, in <module>
import serial
ModuleNotFoundError: No module named 'serial'
Click to expand...
Click to collapse
I've already run commands in step number 5.
These operated on Ubuntu 18.10 on Dell E4200. Please help me solve this. Thank a lots!
nkphuongxp said:
Hi everyone,
I'm trying to do as guided but get stuck at the step number 6, go this message:
I've already run commands in step number 5.
These operated on Ubuntu 18.10 on Dell E4200. Please help me solve this. Thank a lots!
Click to expand...
Click to collapse
Install python3, PySerial, adb, fastboot dos2unix. For Debian/Ubuntu something like this should work:
Code:
sudo apt update
sudo add-apt-repository universe
sudo apt install python3 python3-serial android-tools-adb android-tools-fastboot dos2unix
Original credit to @k4y0z. Definitely check out the original guide this is based on.
@retyre may want to link original thread in OP or atleast add the prerequisite installs.
nujak said:
Install python3, PySerial, adb, fastboot dos2unix. For Debian/Ubuntu something like this should work:
Code:
sudo apt update
sudo add-apt-repository universe
sudo apt install python3 python3-serial android-tools-adb android-tools-fastboot dos2unix
Original credit to @k4y0z. Definitely check out the original guide this is based on.
@retyre may want to link original thread in OP or atleast add the prerequisite installs.
Click to expand...
Click to collapse
Hi nujak,
Thank you for your additional guide, I've followed these above steps and successfully run the script.
After that, I press power button for few seconds and hear a ding sound but nothing happen then, I do this for several times but it results the same.
Now I will try to charge it and waiting for lucky thing happen :angel:
P/S: tried to reconnect LCD cable and I can see things running on screen. Thank retyre for this topic!
nkphuongxp said:
Install python3, PySerial, adb, fastboot dos2unix. For Debian/Ubuntu something like this should work:
Hi nujak,
Thank you for your additional guide, I've followed these above steps and successfully run the script.
After that, I press power button for few seconds and hear a ding sound but nothing happen then, I do this for several times but it results the same.
Now I will try to charge it and waiting for lucky thing happen :angel:
P/S: tried to reconnect LCD cable and I can see things running on screen. Thank retyre for this topic!
Click to expand...
Click to collapse
The location of that cable and with very little slack make it a real pain. If you're sure you're done with the board, a small piece of electrical tape should keep it snug.
Sent from my Amzn KFFOWI using XDA Labs
DragonFire1024 said:
The location of that cable and with very little slack make it a real pain. If you're sure you're done with the board, a small piece of electrical tape should keep it snug.
Sent from my Amzn KFFOWI using XDA Labs
Click to expand...
Click to collapse
Thanks for your enthusiasm, surely I would do that.
One more thing I had to deal with is that I need do adb sideload 5.6.0.0 (update-kindle-40.5.9.5_user_595457020.bin) firmware (from 2017) to make my HD 10 2017 be able to boot into Home screen; otherwise, I would be stuck at Fire OS logo and "Optimising system storage and applications" screen (used adb sideload 5.3.6.4 April 2019)
Doesn't this method work on virtual linux?
I tried but it didn't go on while 'waiting for bootrom' message is on.
Is there anyone tried this, please let me know. Thank you.
------------------------------------------------------------------------------------
I tried actual linux and it worked.
So don't try virtual linux with this problem. Thank you.
Tried several time with same error as below. May you please help~ thanks in advance.
I am on Ubuntu 16.04
error message:
[email protected]:~$ sudo ./bootrom.sh
[2019-05-12 22:43:59.642617] Waiting for bootrom
[2019-05-12 22:44:48.137029] Found port = /dev/ttyACM0
[2019-05-12 22:44:48.146033] Handshake
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 495, in read
raise SerialException('device reports readiness to read but returned no data (device disconnected or multiple access on port?)')
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "main.py", line 92, in <module>
main()
File "main.py", line 54, in main
handshake(dev)
File "/home/yhuang168/modules/handshake.py", line 9, in handshake
dev.handshake()
File "/home/yhuang168/modules/common.py", line 100, in handshake
c = self._writeb(b'\xa0')
File "/home/yhuang168/modules/common.py", line 95, in _writeb
return self.dev.read()
File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 505, in read
raise SerialException('read failed: %s' % (e,))
serial.serialutil.SerialException: read failed: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
yhuang168 said:
Tried several time with same error as below. May you please help~ thanks in advance.
I am on Ubuntu 16.04
error message:
[email protected]:~$ sudo ./bootrom.sh
[2019-05-12 22:43:59.642617] Waiting for bootrom
[2019-05-12 22:44:48.137029] Found port = /dev/ttyACM0
[2019-05-12 22:44:48.146033] Handshake
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 495, in read
raise SerialException('device reports readiness to read but returned no data (device disconnected or multiple access on port?)')
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "main.py", line 92, in <module>
main()
File "main.py", line 54, in main
handshake(dev)
File "/home/yhuang168/modules/handshake.py", line 9, in handshake
dev.handshake()
File "/home/yhuang168/modules/common.py", line 100, in handshake
c = self._writeb(b'\xa0')
File "/home/yhuang168/modules/common.py", line 95, in _writeb
return self.dev.read()
File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 505, in read
raise SerialException('read failed: %s' % (e,))
serial.serialutil.SerialException: read failed: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
Click to expand...
Click to collapse
Reset the terminal. Carefully disconnect the tablet from PC and open the back and disconnect the battery cable. Repeat the script with the battery unplugged. Make sure you have as close to a full charge as possible or you will have to perform a few other steps because the tablet won't stay powered on long enough for the payload to fully loaded.
DragonFire1024 said:
Reset the terminal. Carefully disconnect the tablet from PC and open the back and disconnect the battery cable. Repeat the script with the battery unplugged. Make sure you have as close to a full charge as possible or you will have to perform a few other steps because the tablet won't stay powered on long enough for the payload to fully loaded.
Click to expand...
Click to collapse
Thanks a lot for the reply. However, the battery was disconnected per prior instructions. I did close the terminal and tried again several times, same errors occurred. After the handshake, I keep getting :"device reports readiness to read but returned no data' errors...
Any advises will be much appreciated .
[email protected]:~$ sudo ./bootrom.sh
[2019-05-12 22:43:59.642617] Waiting for bootrom
[2019-05-12 22:44:48.137029] Found port = /dev/ttyACM0
[2019-05-12 22:44:48.146033] Handshake
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 495, in read
raise SerialException('device reports readiness to read but returned no data (device disconnected or multiple access on port?)')
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "main.py", line 92, in <module>
main()
File "main.py", line 54, in main
handshake(dev)
File "/home/yhuang168/modules/handshake.py", line 9, in handshake
dev.handshake()
File "/home/yhuang168/modules/common.py", line 100, in handshake
c = self._writeb(b'\xa0')
File "/home/yhuang168/modules/common.py", line 95, in _writeb
return self.dev.read()
File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 505, in read
raise SerialException('read failed: %s' % (e,))
serial.serialutil.SerialException: read failed: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

Categories

Resources