Develop Bugs

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.

Random MAC Address Issue Explored and Illuminated

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?

Extract Windows RT product key without jailbreak or PC

This tool can be used on Windows RT 8.0 to extract a product key without needing either a Windows PC or a jailbreak. Copy this into Notepad and save it as a .bat file. Double-click it and it'll print out your product key, and you can copy it from that console window.
I've only tested this on Windows RT 8.0. It also seems to work on Windows 8.0 (i.e. x86 versions). No idea what happens on 8.1.
Code:
::' Windows RT 8.0 Product Key Dumper by Myria of xda-developers.com
::' Original Windows 8.0 VBScript by janek2012 of mydigitallife.info
::' Batch+VBScript hybrid trick by dbenham of stackoverflow.com
::' Fix for keys starting with N by Osprey00 of xda-developers.com
::'
::' Windows RT doesn't let unsigned VBScript use WScript.Shell, which is
::' required in order to read the registry in VBScript. So instead, we
::' have a batch file call reg.exe to do the registry lookup for us, then
::' execute the VBScript code. Might as well do things this way, since
::' it would really suck to write this math in batch...
::' --- Batch portion ---------
rem^ &@echo off
rem^ &call :'sub
::' If we were run from double-clicking in Explorer, pause.
rem^ &if %0 == "%~0" pause
rem^ &exit /b 0
:'sub
::' Read the registry key into VBScript's stdin.
rem^ &("%SystemRoot%\System32\reg.exe" query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v DigitalProductId | cscript //nologo //e:vbscript "%~f0")
::'rem^ &echo end batch
rem^ &exit /b 0
'----- VBS portion ------------
'WScript.Echo "begin VBS"
' Get registry data that was piped in
RegData = ""
Do While Not WScript.StdIn.AtEndOfStream
RegData = RegData & WScript.StdIn.ReadAll
Loop
' Remove any carriage returns
RegData = Replace(RegData, ChrW(13), "")
' Split into lines
RegLines = Split(RegData, ChrW(10))
' Sanity checking on data
If (RegLines(0) <> "") Or (RegLines(1) <> "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion") Then
WScript.Echo "Got invalid header trying to run reg.exe"
WScript.Quit(1)
End If
If Left(RegLines(2), 38) <> " DigitalProductId REG_BINARY " Then
WScript.Echo "Got invalid value list trying to run reg.exe"
WScript.Quit(1)
End If
' Get hex string
HexString = Mid(RegLines(2), 39)
If (Len(HexString) Mod 2) <> 0 Then
WScript.Echo "Got an odd number of hex digits in REG_BINARY data"
WScript.Quit(1)
End If
' Convert to byte array
Dim ByteArray()
ReDim ByteArray((Len(HexString) / 2) - 1) ' VBScript is just weird with array dimensions >.<
For i = 0 To (Len(HexString) - 2) Step 2
ByteArray(i / 2) = CInt("&H" + Mid(HexString, i + 1, 2))
Next
Key = ConvertToKey(ByteArray)
WScript.Echo Key
' janek2012's magic decoding function
Function ConvertToKey(Key)
Const KeyOffset = 52 ' Offset of the first byte of key in DigitalProductId - helps in loops
isWin8 = (Key(66) \ 8) And 1 ' Check if it's Windows 8 here...
Key(66) = (Key(66) And &HF7) Or ((isWin8 And 2) * 4) ' Replace 66 byte with logical result
Chars = "BCDFGHJKMPQRTVWXY2346789" ' Characters used in Windows key
' Standard Base24 decoding...
For i = 24 To 0 Step -1
Cur = 0
For X = 14 To 0 Step -1
Cur = Cur * 256
Cur = Key(X + KeyOffset) + Cur
Key(X + KeyOffset) = (Cur \ 24)
Cur = Cur Mod 24
Next
KeyOutput = Mid(Chars, Cur + 1, 1) & KeyOutput
Last = Cur
Next
' If it's Windows 8, put "N" in the right place
If (isWin8 = 1) Then
keypart1 = Mid(KeyOutput, 2, Cur)
insert = "N"
KeyOutput = keypart1 & insert & Mid(KeyOutput, Cur + 2)
End If
' Divide keys to 5-character parts
a = Mid(KeyOutput, 1, 5)
b = Mid(KeyOutput, 6, 5)
c = Mid(KeyOutput, 11, 5)
d = Mid(KeyOutput, 16, 5)
e = Mid(KeyOutput, 21, 5)
' And join them again adding dashes
ConvertToKey = a & "-" & b & "-" & c & "-" & d & "-" & e
' The result of this function is now the actual product key
End Function

Myriachan said:
This tool can be used on Windows RT 8.0 to extract a product key without needing either a Windows PC or a jailbreak. Copy this into Notepad and save it as a .bat file. Double-click it and it'll print out your product key, and you can copy it from that console window.
I've only tested this on Windows RT 8.0. It also seems to work on Windows 8.0 (i.e. x86 versions). No idea what happens on 8.1.
Click to expand...
Click to collapse
Works great on 8.1 RT too. Thanks!

Great work, Myriachan. I'd already gotten my code via other means, but I ran the script to verify that it gets the same key and it does. As Subsonic44 wrote, it does work on 8.1.
If anyone forgets how to copy it to the clipboard from the command prompt: tap and hold (or right-click) anywhere in the window, select Mark, highlight the key and tap and hold (or right-click) anywhere again.

Where I have to use the product key I get?

hisoft said:
Where I have to use the product key I get?
Click to expand...
Click to collapse
When you install this: DRIVERS FOR SURFACE RT ONLY___MICROSOFT WINDOWS RT 8 1 WITH OFFICE 2013 RT RTM WOA ENGLISH DVD-WZT
you have to use an install key that won't activate. You will need to change your product key back to your original that you copied down using this tool in order to activate your new 8.1 Windows RT.

Subsonic44 said:
When you install this: DRIVERS FOR SURFACE RT ONLY___MICROSOFT WINDOWS RT 8 1 WITH OFFICE 2013 RT RTM WOA ENGLISH DVD-WZT
you have to use an install key that won't activate. You will need to change your product key back to your original that you copied down using this tool in order to activate your new 8.1 Windows RT.
Click to expand...
Click to collapse
Thank you for the answer. If I can find some free time I may have to try it. :good:

Myriachan,
Thank you very much for doing this! Before proceeding with my 8.1 RTM upgrade, I would like to confirm one thing: your scripted returned a strange key (see below).
C:\Users\XXXX>rem &
XXXXX-XXXXX-XXXXX-XXXXX-CBV2
Press any key to continue . . .
Notice the last tuple only contains 4 characters. Can this possibly be correct?
Thanks in advance,
Rich
==========================
UPDATE: I retrieved my key using WinTK on another machine. Looks like there is a displacement issue.
X????-?????-?????-????7-CBV2 - using this tool
NX???-?????-?????-?????-7CBV2 - using WinTK

rabilancia said:
Myriachan,
C:\Users\XXXX>rem &
XXXXX-XXXXX-XXXXX-XXXXX-CBV2
Press any key to continue . . .
Notice the last tuple only contains 4 characters. Can this possibly be correct?
Thanks in advance,
Rich
Click to expand...
Click to collapse
Just checked mine and it only has 4 characters in the last group. I think you are fine.

rabilancia said:
UPDATE: I retrieved my key using WinTK on another machine. Looks like there is a displacement issue.
X????-?????-?????-????7-CBV2 - using this tool
NX???-?????-?????-?????-7CBV2 - using WinTK
Click to expand...
Click to collapse
[EDIT: The following doesn't solve the issue, so don't bother with it, but the code change in my later post does. Myriachan has added that change to the first post, so if you've just now created the batch file, you already have the fix.]
It seems to me that janek2012's function may not account for the possibility of 'N' being the very first character of the product key. Find this line 2/3rds of the way into his function...
Code:
keypart1 = Mid(KeyOutput, 2, Cur)
...and replace it with...
Code:
If (Cur = 0) Then
keypart1 = Mid(KeyOutput, 1, 1)
Else
keypart1 = Mid(KeyOutput, 2, Cur)
End If
I've done a little testing and that seems to solve it, but I had to make an assumption without having an actual key that starts with 'N'. If it doesn't solve it, Myriachan may have a better idea.

Osprey00,
That "seems" to be working. Thank you very much! As I reported in an update above, I got my key another way. I am now successfully running RT 8.1 RTM on my Surface RT. Interestingly, I did change the script as you suggested, ran it on RT 8.1 and found out that the key on RT 8.1 is entirely different than the one I used to activate RT 8.1. Hmmm....
Thanks again,
Rich

rabilancia said:
Osprey00,
That "seems" to be working. Thank you very much! As I reported in an update above, I got my key another way. I am now successfully running RT 8.1 RTM on my Surface RT. Interestingly, I did change the script as you suggested, ran it on RT 8.1 and found out that the key on RT 8.1 is entirely different than the one I used to activate RT 8.1. Hmmm....
Thanks again,
Rich
Click to expand...
Click to collapse
Well, in that case, my modification probably doesn't work. It ought to return the same key that you got via WinTK and activated with. If it's different, then it's likely wrong. Thanks for trying, though. It was worth a shot. I guess that I'll leave it to Myriachan to solve.

Osprey00 said:
Well, in that case, my modification probably doesn't work. It ought to return the same key that you got via WinTK and activated with. If it's different, then it's likely wrong. Thanks for trying, though. It was worth a shot. I guess that I'll leave it to Myriachan to solve.
Click to expand...
Click to collapse
I don't know anything about the Microsoft product key algorithm itself, so I can't fix it directly. If you have the source code to a tool that does work with such keys, even in another language like C++, I could figure it out and update my tool to support it.
Melissa

Let's try this again. If anyone with the issue (to re-iterate, you get a key with only 4 characters in the last set) wants to test this, find this line of janek2012's function...
Code:
KeyOutput = Replace(KeyOutput, keypart1, keypart1 & insert, 2, 1, 0)
...and replace it with this...
Code:
KeyOutput = keypart1 & insert & Mid(KeyOutput, Cur + 2)
Verify that against what another tool told you is your key and let us know if it checks out.
For the curious, what I believe is the issue is that the original function doesn't work for when the 'N' is the first character of the product key. In that particular case, keypart1 is set to "" (because there are no characters in front of 'N' when it's the first character) and the Replace function, therefore, ends up searching for "" and not finding it, so 'N' doesn't get inserted into the string anywhere (leaving the key one character short).

Osprey00 said:
Verify that against what another tool told you is your key and let us know if it checks out.
For the curious, what I believe is the issue is that the original function doesn't work for when the 'N' is the first character of the product key. In that particular case, keypart1 is set to "" (because there are no characters in front of 'N' when it's the first character) and the Replace function, therefore, ends up searching for "" and not finding it, so 'N' doesn't get inserted into the string anywhere (leaving the key one character short).
Click to expand...
Click to collapse
I've incorporated your change into the code and credited you. Thanks! =^-^=
The refurbished ASUS x86 laptop I bought to experiment with the x86 version of Secure Boot happens to have a Windows 8.0 CD key that starts with N, so I was able to test the new version. =) (It had the missing letter problem with the previous version.)

Myriachan said:
I've incorporated your change into the code and credited you. Thanks! =^-^=
The refurbished ASUS x86 laptop I bought to experiment with the x86 version of Secure Boot happens to have a Windows 8.0 CD key that starts with N, so I was able to test the new version. =) (It had the missing letter problem with the previous version.)
Click to expand...
Click to collapse
Works now on my 8.1 RTM Surface. My "N" now shows up. Thanks!

Excellent work.

Nice, I have a question.
I recently stumbled upon a bat file sent to someone @ MS for a problem they where having with Windows activation on there RT.
Inside it shows the bat script clearing the activation files and registering keys for both Windows RT and Office, this maybe useful if for some reason my Surface 2 becomes deactivated, the problem is I don't know my office 2013 key...any idea's on how to get that?
I attached the bat file as i found it in case anyone wants it. (dunno who's keys are in there)

Find Product Key Batch File for Windows RT 8
Hi folks,
I have a VivoTab TF600 that hit the BSOD issue shortly after a Win 8.1 Patching cycle.
It originally hit error Code 0xc0000001 all the time.
After executing many suggestions from the Web on how to fix it, I now hit
a. Error code 0x0000005c
b. Parameters
i. 0x00000110
ii. 0x05250631
iii. 0x00000014
iv. 0xc0000001
First, then after a reboot, it hits the Code 0xc0000001
I tried the FIndProductKey.Bat file on this tablet and received:
"Error: The System was unable to find the specified registry key or value.
Got invalid header trying to run reg.exe" ( Which is echo'd from the Batch )
What would contribute to give that error ?
*** Found a work-around ***
Copy the SOFTWARE hive from the C:\Windows\System32\Config directory to the USB.
Plug it into a AMD or x86 based Windows 7 Machine and run ProduKey. Change the source to read the hive. And that's it, the key for the Win 8 RT OS and 2013 Office was displayed.
Thanks

Windows 8 RT Original Product Key
Hi folks,
Once Win 8.1 is on the platform, the original product key is lost. ( Unless you squirrelled away the Hives somewhere )
I understand that it`s linked to the firmware on the Tablet.
( In this case the ASUS T600TF )
When Win 8 RT Setup runs from the original image, it must compare the Input key with the once it`s expecting.
The Windows 8.1 key definitely does not work.
Anyone aware of a way to decode the original key through Windows RE ?
Thanks

I am a non-programmer. Can you elaborate the instruction a little simpler?
I really appreciate your contribution to the forum. However, I don't really get what you mean because i am a non-programmer. Can you make your instruction simpler so that i can follow your instruction to solve my surface RT problems. My window RT is not activated and all MS office apps did not work at all. Thank you in advance for your kind contribution to solve activation problem. also what do you mean by "change the source to read the hive"?
dalexop said:
Hi folks,
I have a VivoTab TF600 that hit the BSOD issue shortly after a Win 8.1 Patching cycle.
It originally hit error Code 0xc0000001 all the time.
After executing many suggestions from the Web on how to fix it, I now hit
a. Error code 0x0000005c
b. Parameters
i. 0x00000110
ii. 0x05250631
iii. 0x00000014
iv. 0xc0000001
First, then after a reboot, it hits the Code 0xc0000001
I tried the FIndProductKey.Bat file on this tablet and received:
"Error: The System was unable to find the specified registry key or value.
Got invalid header trying to run reg.exe" ( Which is echo'd from the Batch )
What would contribute to give that error ?
*** Found a work-around ***
Copy the SOFTWARE hive from the C:\Windows\System32\Config directory to the USB.
Plug it into a AMD or x86 based Windows 7 Machine and run ProduKey. Change the source to read the hive. And that's it, the key for the Win 8 RT OS and 2013 Office was displayed.
Thanks
Click to expand...
Click to collapse

How to find original build version when soft bricked?

Ok, I have searched the internet and these forums for hours and have not seen an answer to this anywhere.
I can't believe I'm the only person who has ever wanted to know how to determine this information!
I repair Nexus 7 2013 as a hobby - usually with broken screens, but now and then buy a soft bricked one.
I have the same issue every time - trying to find what is the original build number when it is soft bricked and you can't access Recovery either. I have even tried to see if Asus has a cross reference of serial number to original build number - no they don't.
I use the Wug tool and so far the score is 3 saved, one that even has Wug stumped, and the one I'm working on tonight that I simply can't get to work.
I always have to guess and try versions. tonight I've tried the single version of 4.4.4 and 3 other version of 5 to 6. Each time the best that I can get is a sluggish boot that usually eventually freezes while trying to run setup. That is BEST CASE. Worst case would take pages to describe. It sort of works on lmy47v a little and not at all on any other build. Manufacture date is March 2015.
If I didn't know better, if this was a PC, I would say there is a bad RAM chip.
Regardless, I would feel a lot happier if I knew I was installing the right build which leads back to the original question - how do you find the original build if it's soft bricked?
Thanks to anybody who can answer this!

Do this:
PC: download TWRP image, e.g. twrp-2.8.6.0-flo.img
N7: boot in fastboot mode
PC run: fastboot boot twrp-2.8.6.0-flo.img
N7: in TWRP UI mount system
PC run: adb shell cat /system/build.prop > build.prop.txt
View build.prop.txt on PC:
Code:
ro.build.id=LMY48Y
ro.build.display.id=cm_flo-userdebug 5.1.1 LMY48Y ceb9c142ee test-keys
ro.build.version.incremental=ceb9c142ee
But why do you bother to restore "original build number"?
Most of them are locked and will lose all data in the process of unlocking.
Then why not flash the latest OS image?

k23m said:
Do this:
PC: download TWRP image, e.g. twrp-2.8.6.0-flo.img
N7: boot in fastboot mode
PC run: fastboot boot twrp-2.8.6.0-flo.img
N7: in TWRP UI mount system
PC run: adb shell cat /system/build.prop > build.prop.txt
View build.prop.txt on PC:
Code:
ro.build.id=LMY48Y
ro.build.display.id=cm_flo-userdebug 5.1.1 LMY48Y ceb9c142ee test-keys
ro.build.version.incremental=ceb9c142ee
But why do you bother to restore "original build number"?
Most of them are locked and will lose all data in the process of unlocking.
Then why not flash the latest OS image?
Click to expand...
Click to collapse
Thanks for your reply. No less complicated way to find that out eh? I'm afraid that's a bit over my head (or perhaps its just the way its worded - no offense intended). If it was PC, and particularly DOS, I would be laughing.
When nothing else was working on this particular tablet, I did try for the heck of it to use the Wug toolkit to root and install TWRP, and it would just lock up and never install - no error messages or anything.
As far as why not use the most recent image, there are lots of opinions, and the majority I have ever read says if you don't use the original build you will get all kinds of problems right up to completely bricking the device. Since you have to take every opinion with a grain of salt, it just seems to make sense to use what it came with. 2 out of 3 tablets I have been able to do that with I have be able to save. Only 1 where I used a random build worked.

consumer61 said:
No less complicated way to find that out eh?
Click to expand...
Click to collapse
The simplest way is to check it in stock recovery but you say it is not an option...
consumer61 said:
the majority I have ever read says if you don't use the original build you will get all kinds of problems right up to completely bricking the device
Click to expand...
Click to collapse
Please post a link to one of them.

k23m said:
Please post a link to one of them.
Click to expand...
Click to collapse
I wish I could. Just random things read from hundreds of pages over a couple of years, and of course when you look for them you can't find them. I have on and off been trying to find an answer to this question for over a year.
Even the wug toolkit encourages you to make a backup of your own system rather than re-flash a random stock image. Since as soon as you unlock you lose everything anyway, there hardly seems any purpose to a backup as opposed to just re-flashing with the newest version - ergo that also leads you to believe you need to use the exact version that was there before.
I don't discount the possibility that even though not said, what was actually meant was that each device model has a version specific to it. Again, that was never clearly said, I am just using logic based on your concept that you can install any image at all, with absolutely no issue.

consumer61 said:
I wish I could... when you look for them you can't find them.
...rather than re-flash a random stock image.
Click to expand...
Click to collapse
That's it, all those horror stories are from "random stock" flashers. If you choose wisely the very latest stock image then there is no danger whatsoever.
Let's talk about the latest case - is it unlocked already?

I was able to unlock, but could not access recovery - when booting to recovery it would still just sit at the Google logo.
In order, I tried from the list that comes up on the Wug tool, a 6.01 version, then lmy47v, then lmy48g, then finally thought I would try going back quite far since there was only one version for 4.4.4 - ktu84p, then finally lmy48t.
With tiny variations, all had the exact same result - no errors when wiping or reloading. The circling balls would just around as normal, then eventually grind to halt - moving a tiny bit every 5-30 seconds. After maybe an hour, sometimes you would finally get the normal "pick your language" screen, although most times, after about 30 min I would just shut it down and power it back on.
That would result in sometimes getting the "pick a language". Sometimes able to get as far as entering a gmail address, but the system would always lag - registering a touch many seconds after doing it. Once single time, I got a full boot up. Then it came up with the OTA as it should. ran it, and back to soft bricked.
Also a couple of the times I was able to get it to boot, as soon as you would reboot, it would be back to soft bricked.
Motherboard got exceptionally hot, and battery was down to 18% once, and 27% another time from full charge - so it was working abnormally hard
I have been playing with and building pc' etc since the Vic 20, C 64 and so on, and it behaves just like a bad RAM chip. I did find a post on here saying the Kingston/Toshiba chip can get corrupted and must be replaced, with a link to the same guy selling MB on ebay - can't remember his id on here, but here is the ebay sale:
http://www.ebay.ca/itm/121637666631?_trksid=p2055119.m1438.l2649&ssPageName=STRK:MEBIDX:IT
Overall this is similar behaviour although not quite as bad, as the other motherboard that stumped Wug. He finally said it must be hardware in that case, and I certainly tend to think the same thing here.

consumer61 said:
He finally said it must be hardware in that case, and I certainly tend to think the same thing here.
Click to expand...
Click to collapse
Let's find out exactly. As you are comfortable with DOS then the following should be piece of cake:
download twrp-2.8.6.0-flo.img from https://dl.twrp.me/flo/
go to Wug(NRT)\data folder - can you see fastboot.exe and adb.exe there?
boot the Nexus in fastboot mode (when off press power+vol.down), connect it to your PC
in Wug's data folder open a DOS command window and copy/paste: fastboot boot twrp-2.8.6.0-flo.img [Enter]
when TWRP is up and running, copy/paste in the DOS: adb shell dmesg > dmesg.txt [Enter]
you will find dmesg.txt in Wug's data folder
zip up the file and attach it to your next post
This is THE hardware log and another chance to play with DOS-like stuff :laugh:

Ok excellent instructions. (did tech support for years).
I had pulled the MB and replaced it, so I just switched it back.
Install TWRP worked fine. TWRP screen came up.
Typed command for the msg file, and dos error was "error: device '<null>' not found
I know of TWRP, but have never used it. I hit the centre button on the screen which brought up what appears may be an install log, and its full of errors.
Goes down over a full screen, but the common statement is:
"unable to find partition size for /boot" /recovery /misc and about 15 more lines.
Also other errors like unable to mount cache, data, system
I just took a photo of the screen but it seems you can't post actual images, only links to images stored on the internet, not something off your hard drive.
Just to let you know, I did try various spacing around the dmesg > dmesg.txt command just to be sure, same error every time.
Now that is from the TWRP screen with all the buttons on it. If you meant for me to open a certain function of TWRP, I didn't.
Regards,
UPDATE: had a brainwave and loaded up Wugfresh and device manger. Showed exclamation mark beside the device so re-installed adb driver. Now the log worked. It is only 64k, and both the twrp photo and the log file should be attached now.

I looked through the log, and even not knowing the internals of the system that well, only one part stood out as appearing bad:
<3>[ 0.277130] msm_gpiomux_install: write failure: -22
<3>[ 0.277221] msm_gpiomux_install: write failure: -22
<3>[ 0.277404] msm_gpiomux_install: write failure: -22
<3>[ 0.277496] msm_gpiomux_install: write failure: -22
<3>[ 0.277648] msm_gpiomux_install: write failure: -22
<3>[ 0.277740] msm_gpiomux_install: write failure: -22
<6>[ 0.278656] Registering gpio keys
<6>[ 0.278778] Reconfigure VOL_UP(GPIO155) and VOL_DOWN(GPIO189) with PMIC
<4>[ 0.278991] 8921_l17: Failed to create debugfs directory
<4>[ 0.280609] ------------[ cut here ]------------
<4>[ 0.280700] WARNING: at arch/arm/mach-msm/subsystem_restart.c:573 subsys_restart_init+0xd8/0x104()
<4>[ 0.280883] Modules linked in:
<4>[ 0.281066] [<c0015f44>] (unwind_backtrace+0x0/0x11c) from [<c007ae88>] (warn_slowpath_common+0x4c/0x64)
<4>[ 0.281250] [<c007ae88>] (warn_slowpath_common+0x4c/0x64) from [<c007aeb8>] (warn_slowpath_null+0x18/0x1c)
<4>[ 0.281433] [<c007aeb8>] (warn_slowpath_null+0x18/0x1c) from [<c0c0c600>] (subsys_restart_init+0xd8/0x104)
<4>[ 0.281616] [<c0c0c600>] (subsys_restart_init+0xd8/0x104) from [<c0008718>] (do_one_initcall+0x8c/0x15c)
<4>[ 0.281799] [<c0008718>] (do_one_initcall+0x8c/0x15c) from [<c0c00a24>] (kernel_init+0xe8/0x1a4)
<4>[ 0.281982] [<c0c00a24>] (kernel_init+0xe8/0x1a4) from [<c000fdf8>] (kernel_thread_exit+0x0/0x8)
<4>[ 0.282104] ---[ end trace ff63e6c2cba9c001 ]---

consumer61 said:
Typed command for the msg file, and dos error was "error: device '<null>' not found
Click to expand...
Click to collapse
When TWRP is running please type adb devices and it should respond like:
Code:
List of devices attached
087777e8 recovery
If not, re-plug USB cable, check Windows device manager for new hardware. You may need ADB driver but Wug would install it before.
Please upload the picture(s) to http://imgur.com/?noFlash
We don't need to interact with TWRP for this task at all.
Btw, TWRP was not flashed, but only temporarily booted so you may need to repeat it all over again.
Cheers

I suspect you were writing your reply above, as I updated the info. Please see the end of page 1 - the photo and the log file are attached.
simply put is was my mess up - adb had to be re-installed every time you plug a device in when running XP Pro. (Yes I know XP. Hate 7 and 8 and 10, but this is the last version where you had SOME semblance of control over your own computer lol)
Thanks!

consumer61 said:
I suspect you were writing your reply above, as I updated the info. Please see the end of page 1 - the photo and the log file are attached.
simply put is was my mess up - adb had to be re-installed every time you plug a device in when running XP Pro. (Yes I know XP. Hate 7 and 8 and 10, but this is the last version where you had SOME semblance of control over your own computer lol)
Thanks!
Click to expand...
Click to collapse
Yes.
I use Linux and ...XP too :highfive:
Please check my last post here.

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!