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?

[Q] Mod Windows RT to enable Remote Desktop

In the past, Windows has had editions for consumers that did not include Remote Desktop enabled. Usually there was a patch to enable it. Recently it has been proved how there is almost no difference between Windows 8 and Windows RT and that RT is just a port of Windows 8. So what about all the system files? They can be changed just like x86 Windows. So what about enabling Remote Desktop, so we don't need a ARM remote app that we need to unlock Windows for, and we can use what comes with Windows. In the past we modified the termsrv.dll file and changed some registry settings. I've included the Windows 8 and the Windows RT versions of termsrv.dll so that maybe some clever ones might try and crack a solution to enabling it on Windows RT.

sionicion said:
In the past, Windows has had editions for consumers that did not include Remote Desktop enabled. Usually there was a patch to enable it. Recently it has been proved how there is almost no difference between Windows 8 and Windows RT and that RT is just a port of Windows 8. So what about all the system files? They can be changed just like x86 Windows. So what about enabling Remote Desktop, so we don't need a ARM remote app that we need to unlock Windows for, and we can use what comes with Windows. In the past we modified the termsrv.dll file and changed some registry settings. I've included the Windows 8 and the Windows RT versions of termsrv.dll so that maybe some clever ones might try and crack a solution to enabling it on Windows RT.
Click to expand...
Click to collapse
termsrv is a system service and how can we use a modified termsrv.dll before we use the Jailbreak tool?maybe we can edit termsrv.dll in the memory.

We can't, I suspect. Even after jailbreaking, the lack of a signature on a system file may be a problem. It's worth a shot, though.

termsrv.dll -should- be a usermode library that would be editable after the jailbreak.

I am able to take ownership of the file and replace it. But it won't use the termsrv.dll from my windows 8… I'm almost positive it is because the dll is different depending on architecture. But it should be as easily replaceable as any system file on windows 8, am I right? I don't see why it wouldn't but I could be wrong.

Yeah, pretty much. You definitely won't be able to use the Win8 version (x86 machine code, ARM processor, not gonna fly...) but a modified version of the Windows RT version might work. Bear in mind that since modifying the DLL will invalidate the signature, this won't work if the signature validation is enforced (i.e. you'll have to jailbreak).

Should be possible using the Remote Debugging Tools or, even better, cdb. Put it in a .cmd file in autorun and voila

clrokr said:
Should be possible using the Remote Debugging Tools or, even better, cdb. Put it in a .cmd file in autorun and voila
Click to expand...
Click to collapse
Please!! Remote desktop would be awesome enabled on the Surface RT, if someone could work on it I know a lot of people would be very grateful!

I've already posted a method that should enable RDP here: http://forum.xda-developers.com/showpost.php?p=36386089&postcount=211 - no need to patch DLL, and would work on an a locked device. But you'll have to manually edit binary registry value, instead of using a provided tool.
I have not tested RDP, but after using this method I was able to recover an option of joining device to Active Directory domain (it was blocked by the similar policies).

mamaich said:
I've already posted a method that should enable RDP here: http://forum.xda-developers.com/showpost.php?p=36386089&postcount=211 - no need to patch DLL, and would work on an a locked device. But you'll have to manually edit binary registry value, instead of using a provided tool.
I have not tested RDP, but after using this method I was able to recover an option of joining device to Active Directory domain (it was blocked by the similar policies).
Click to expand...
Click to collapse
Can you share how you managed to get the rt joined to a domain?

mamaich said:
I've already posted a method that should enable RDP here: http://forum.xda-developers.com/showpost.php?p=36386089&postcount=211 - no need to patch DLL, and would work on an a locked device. But you'll have to manually edit binary registry value, instead of using a provided tool.
I have not tested RDP, but after using this method I was able to recover an option of joining device to Active Directory domain (it was blocked by the similar policies).
Click to expand...
Click to collapse
Wouldn't both methods work though? Your method works by enabling features from other editions by telling Windows that's what edition it is running. It disables it when the Software Protection service restores it to the original template according to the edition. By patching the DLL file, you could trigger Remote Desktop to work without it needing to check in with the kernel policies.
I mean unless you have a way to modify these policies without all the extra occuring, it would work. But Bitlocker and the Software Protection service getting involved...it just sounds like a lot of extra work for something much bigger in the end, and I know there must be an easier way to force Remote Desktop to work without listening to these policies because it has been done in the past.

mamaich said:
I've already posted a method that should enable RDP here: http://forum.xda-developers.com/showpost.php?p=36386089&postcount=211 - no need to patch DLL, and would work on an a locked device. But you'll have to manually edit binary registry value, instead of using a provided tool.
I have not tested RDP, but after using this method I was able to recover an option of joining device to Active Directory domain (it was blocked by the similar policies).
Click to expand...
Click to collapse
I tried to enable one of the Remote Desktop vars last night, allowRemoteConnections I think it was called, but I didn't get anything from it.

mamaich said:
I've already posted a method that should enable RDP here: http://forum.xda-developers.com/showpost.php?p=36386089&postcount=211 - no need to patch DLL, and would work on an a locked device. But you'll have to manually edit binary registry value, instead of using a provided tool.
I have not tested RDP, but after using this method I was able to recover an option of joining device to Active Directory domain (it was blocked by the similar policies).
Click to expand...
Click to collapse
Again, please if you were able to join an RT to the domain. Please let me know what you did. Would love to not get prompted to log in into PowerShell.

apatcas said:
Again, please if you were able to join an RT to the domain. Please let me know what you did. Would love to not get prompted to log in into PowerShell.
Click to expand...
Click to collapse
As I've already wrote - use this method: http://forum.xda-developers.com/showpost.php?p=36386089&postcount=211
1. Edit registry:
Code:
HKEY_LOCAL_MACHINE\SYSTEM\Setup
SetupType=1
CmdLine="cmd.exe"
and reboot. You will enter the setup mode. You would not see the mouse cursor in this mode, and you'll need a hardware keyboard.
2. Open this reg_binary value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ProductOptions\ProductPolicy. Look for unicode string "WorkstationService-DomainJoinEnabled", it is near offset 0x4000. Look at this screenshot:
http://imageshack.us/photo/my-images/526/35796208.png/
Select the "00" byte that follows the zero byte after the 64 (64 00 == unicode "d" letter) as you see on the screenshot. Overwrite it with 01. Be careful not to insert a byte, you need to overwrite the existing byte!
3. Rename sppsvc.exe to anything else so that it would not run on boot and reset ProductPolicy ("ren sppsvc.exe sppsvc.bak")
4. Reboot. Now the option to join the domain would be available.
I have not tried to add workstation to domain myself - try that and post here. After adding to domain you may try to rename sppsvc.bak back to sppsvc.exe as otherwise you'll get the "unactivated" Windows RT. I think that this would only remove the add to domain UI, but the RT would be still domain-joined.
I've tried to edit the remote desktop settings keys - this unblocked the corresponding options in the computer settings, but I was unable to connect. Maybe this is due to absence of RDP code in terminal server service - I don't see anyone listening port 3398 though TermServer service is running.

mamaich said:
As I've already wrote - use this method: http://forum.xda-developers.com/showpost.php?p=36386089&postcount=211
1. Edit registry:
Code:
HKEY_LOCAL_MACHINE\SYSTEM\Setup
SetupType=1
CmdLine="cmd.exe"
and reboot. You will enter the setup mode. You would not see the mouse cursor in this mode, and you'll need a hardware keyboard.
2. Open this reg_binary value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ProductOptions\ProductPolicy. Look for unicode string "WorkstationService-DomainJoinEnabled", it is near offset 0x4000. Look at this screenshot:
http://imageshack.us/photo/my-images/526/35796208.png/
Select the "00" byte that follows the zero byte after the 64 (64 00 == unicode "d" letter) as you see on the screenshot. Overwrite it with 01. Be careful not to insert a byte, you need to overwrite the existing byte!
3. Rename sppsvc.exe to anything else so that it would not run on boot and reset ProductPolicy ("ren sppsvc.exe sppsvc.bak")
4. Reboot. Now the option to join the domain would be available.
I have not tried to add workstation to domain myself - try that and post here. After adding to domain you may try to rename sppsvc.bak back to sppsvc.exe as otherwise you'll get the "unactivated" Windows RT. I think that this would only remove the add to domain UI, but the RT would be still domain-joined.
I've tried to edit the remote desktop settings keys - this unblocked the corresponding options in the computer settings, but I was unable to connect. Maybe this is due to absence of RDP code in terminal server service - I don't see anyone listening port 3398 though TermServer service is running.
Click to expand...
Click to collapse
Joined... Nice find.

apatcas said:
Joined... Nice find.
Click to expand...
Click to collapse
Have it remained domain-joined after restoring the original sppsvc.exe?
You have to return it back, otherwise you'll be annoyed with the activation reminders.

mamaich said:
Have it remained domain-joined after restoring the original sppsvc.exe?
You have to return it back, otherwise you'll be annoyed with the activation reminders.
Click to expand...
Click to collapse
We could possibly patch sppsvc to not check, then start the service up after jailbreaking it.
I'm honestly not sure if this would be considered piracy or not, though.
Edit: I used the program to set every value to 1 in setup mode (The latest jailbreak tool works in setup mode), and I didn't see any change for anything dealing with RDP.
Edit 2: Perhaps I shouldn't have set 'Disable' to 1. Regardless, I set it to 0 and the options popped up, but I can't get anything to go. As mamaich stated, I'm not seeing anything listening on port 3389. netstat -a -b on a desktop with it enabled says it's opened by CryptSvc, but I'm not seeing anything with CryptSvc that's not there on the tablet. That could just be netstat guessing which service running under svchost is actually running it, too.

netham45 said:
We could possibly patch sppsvc to not check, then start the service up after jailbreaking it.
I'm honestly not sure if this would be considered piracy or not, though.
Edit: I used the program to set every value to 1 in setup mode (The latest jailbreak tool works in setup mode), and I didn't see any change for anything dealing with RDP.
Edit 2: Perhaps I shouldn't have set 'Disable' to 1. Regardless, I set it to 0 and the options popped up, but I can't get anything to go. As mamaich stated, I'm not seeing anything listening on port 3389. netstat -a -b on a desktop with it enabled says it's opened by CryptSvc, but I'm not seeing anything with CryptSvc that's not there on the tablet. That could just be netstat guessing which service running under svchost is actually running it, too.
Click to expand...
Click to collapse
I think we must hack the dll file.But I find when I edit a byte in the dll,the service was not able to start.

apatcas said:
Joined... Nice find.
Click to expand...
Click to collapse
So is it true? that your device stays domain-joined after you restore sppsvc.exe?

@ Netham45, you could try to open up W81x86 termsrv.dll and go to these hex locations to find out what functions needed patching.
Hashes
File: W81x86\termsrv.dll
CRC-32: 202cd912
MD4: a879d39b8fbcd968b525af05a66aaf2c
MD5: 7a8e1158291cf4c8d8474a2091b9bf6d
SHA-1: e10028b074d24605e05b5e0bafd42f6a93ac01ad
1550F-15520
17428
A1B29
Then go into WinRT termsrv.dll, jump to those functions by name (because offsets will be different between x86 and RT) and Jmp or Nop as needed for WinRT. Afterwords it could be added via CDB / KD on-the-fly.

windows rt rtm

MICROSOFT.WINDOWS.RT.8.1.WITH.OFFICE.2013.RT.RTM.WOA.ENGLISH.DVD-WZT
MICROSOFT.WINDOWS.RT.8.1.ADK.KIT.WOA.RTM-WZT
Thats all I want to say

windowsrtc said:
MICROSOFT.WINDOWS.RT.8.1.WITH.OFFICE.2013.RT.RTM.WOA.ENGLISH.DVD-WZT
MICROSOFT.WINDOWS.RT.8.1.ADK.KIT.WOA.RTM-WZT
Thats all I want to say
Click to expand...
Click to collapse
Anyone tried it yet? Looks like a risky process.

windowsrtc said:
MICROSOFT.WINDOWS.RT.8.1.WITH.OFFICE.2013.RT.RTM.WOA.ENGLISH.DVD-WZT
MICROSOFT.WINDOWS.RT.8.1.ADK.KIT.WOA.RTM-WZT
Thats all I want to say
Click to expand...
Click to collapse
Thanks. Unfortunately, what I gather from what I'm reading is that that image does not contain drivers. You need to manually add the drivers to the image before you install. If you don't, you'll brick your tablet, according to WZT. People may want wait a little bit until there are clear directions and a few people who can verify that they worked (i.e. that they installed 8.1 without any problems).
Additional note: It sounds like the driver package is only for the Surface RT, so users with other Windows RT tablets (ex. ASUS VivoTab RT) may brick their tablets if they try to use it. They'll have to wait until someone releases a driver package for their model (which WZT says might have to be taken from the Preview build).

Osprey00 said:
Even more unfortunately, while WZT has teased info about the driver package, they haven't actually leaked it yet.
Click to expand...
Click to collapse
This part isn't actually true, for what it's worth- it's included with the main download.

jhoff80 said:
This part isn't actually true, for what it's worth- it's included with the main download.
Click to expand...
Click to collapse
Oh, OK. I didn't catch that. They made it appear as though it was a separate download. Ah, you're right: there they are.

just run setup.exe
all drivers for surface are build in
BTW:I have rollback to 8.0 again

Osprey00 said:
...users with other Windows RT tablets (ex. ASUS VivoTab RT) may brick their tablets if they try to use it.
Click to expand...
Click to collapse
It is very difficult to brick an RT device. You can always recover it if you can boot to USB, and you have a recovery image and familiar with windows command line tools (diskpart, dism and so on).
Unfortunatley I'm on a business trip and can't create an upgrade instruction for VivoTab users. But there is nothing difficult - as we already have all needed drivers on a recovery partition, and all you need - just insert them into WIM using the Wzor's instructions from his original post on ru-board.

Installed this tonight. Note that drivers are NOT included in the iso from Wzor.
Extract boot.wim and install.wim from Wzor's iso, inject Wzor's RTM drivers via dism, commit, put boot.wim and install.wim with drivers back into iso, image to USB drive. I installed from within RT using setup (keeping nothing).
You have to use the default key on installation. You need to find out your actual RT key before you do this otherwise you end up with a non-activated RT 8.1 and no key. Export DigitalProductId and DigitalProductId4 from HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion and obtain your key. Instructions on how to here.
Works great. In the short amount of time I've been testing everything works perfectly OK, including all my accessories. (discussion here).

mamaich said:
It is very difficult to brick an RT device. You can always recover it if you can boot to USB, and you have a recovery image and familiar with windows command line tools (diskpart, dism and so on).
Click to expand...
Click to collapse
I figured as much, but not everyone may have the recovery image or the knowledge, and, for them, a dead device that they're unable to recover is as good as a brick. Regardless, I just wanted to pass along the same language that WZT used so that I'm not guilty of misrepresenting the risks or responsible if someone can't fix what he got himself into.
derausgewanderte said:
Installed this tonight. Note that drivers are NOT included in the iso from Wzor.
Extract boot.wim and install.wim from Wzor's iso, inject Wzor's RTM drivers via dism, commit, put boot.wim and install.wim with drivers back into iso, image to USB drive. I installed from within RT using setup (keeping nothing).
You have to use the default key on installation. You need to find out your actual RT key before you do this otherwise you end up with a non-activated RT 8.1 and no key. Export DigitalProductId and DigitalProductId4 from HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion and obtain your key. Instructions on how to here.
Works great. In the short amount of time I've been testing everything works perfectly OK, including all my accessories. (discussion here).
Click to expand...
Click to collapse
Thanks for your instructions and verifying that it works. The original instructions don't mention writing down your current key first. While I likely would've done that anyways, it's re-assuring to see it in writing, just in case. I might give this a go tomorrow.

FYI, there's now an ISO with the Surface RT drivers baked in, so that users don't have to use DISM to add them manually. The release name is:
DRIVERS FOR SURFACE RT ONLY___MICROSOFT WINDOWS RT 8 1 WITH OFFICE 2013 RT RTM WOA ENGLISH DVD-WZT
Note that it's only for the Surface RT, not other RT tablets.
Also note that you need the installation key, and, also, before installation, you need to export and decrypt your retail 8.0 key. Information on that is available here

Osprey00 said:
Also note that you need the installation key, and, also, before installation, you need to export and decrypt your retail 8.0 key. Information on that is available here
Click to expand...
Click to collapse
and here is the direct link to Osprey00's post with a way of getting the key if you only have your RT.

Good news!
I'll just wait till some skillful surface owner gets the jailbreak and then update!

huslterose said:
Good news!
I'll just wait till some skillful surface owner gets the jailbreak and then update!
Click to expand...
Click to collapse
[EDIT: Never mind. I misunderstood.]
I don't follow. There's nothing to "jailbreak" and it can't get much easier than it is now (outside of simply waiting until Microsoft rolls out 8.1 via Automatic Updates). You just follow instructions to find out your 8.0 key, install the 8.1+drivers ISO (not the one in the OP; the one that I listed a few posts up) with a general installation key, then activate 8.1 with your 8.0 key.

Osprey00 said:
I don't follow. There's nothing to "jailbreak" and it can't get much easier than it is now (outside of simply waiting until Microsoft rolls out 8.1 via Automatic Updates). You just follow instructions to find out your 8.0 key, install the 8.1+drivers ISO (not the one in the OP; the one that I listed a few posts up) with a general installation key, then activate 8.1 with your 8.0 key.
Click to expand...
Click to collapse
I think he is referring to the lack of jailbreak on 8.1 for unsigned desktop apps - a feature which should have been in the OS from the start, instead microsoft wasted time patching the exploit the jailbreak used and destroyed the usefulness of the tablet for some.
He was probably intending to say something along the lines of him not updating to 8.1 until after someone makes a new jailbreak for it.
If you can live without the jailbreak, thats fine. Windows store is a bit too limited in my opinion, but it will grow (still gutted they blocked access to both localhost for network connections and COM ports in windows apps though).

SixSixSevenSeven said:
I think he is referring to the lack of jailbreak on 8.1 for unsigned desktop apps - a feature which should have been in the OS from the start, instead microsoft wasted time patching the exploit the jailbreak used and destroyed the usefulness of the tablet for some.
He was probably intending to say something along the lines of him not updating to 8.1 until after someone makes a new jailbreak for it.
If you can live without the jailbreak, thats fine. Windows store is a bit too limited in my opinion, but it will grow (still gutted they blocked access to both localhost for network connections and COM ports in windows apps though).
Click to expand...
Click to collapse
Ah! Gotcha. It slipped my mind that the jailbreak for unsigned apps not working in 8.1 is a valid reason for not upgrading, so I was thinking that he was waiting for something to make the upgrade, itself, even easier. Thanks for the clarification.

@Osprey00 - is there a direct link perhaps

aooga said:
Could someone please post instructions on how to decrypt the registry values? The link that was posted is down. Thanks.
Click to expand...
Click to collapse
Sure. There are a few different ways to do it. In order of simplest to most complicated...
METHOD 1 - Can be done solely from Windows RT (any version):
1. Follow these instructions to create a batch file.
2. Run the batch file on the tablet to get your key.
3. Either write the key down or right-click anywhere in the window, select Mark, highlight the key, right-click again (which will copy the key to the clipboard), paste the key into a text file and then copy that text file to another computer or backup drive.
4. Optional, but recommended: Check that the key is valid by inputting it into a key checker, such as The Ultimate PID Checker. If it tells you that the key is invalid, then try one of the other two methods.
METHOD 2 - Requires regular, non-RT Windows (XP/Vista/7/8):
1. In RT, open the charms bar, click Search, enter "Regedit" and run Regedit.
2. Export HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion to a .reg file.
3. Copy that .reg file to your non-RT Windows.
4. On your non-RT Windows (all remaining steps will be done there), right-click the .reg file and choose Edit. Change "CurrentVersion" to "CurrentVersionRT". Re-save the file.
5. Double-click on the .reg file and import it.
6. Download and install WinTK.
7. Run WinTK, paste "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersionRT" (without quotes) into the field and press the Decrypt button.
*If, for some reason, WinTK won't run, you can try this: download and unzip Produkey, run Regedit, export your CurrentVersion key to a backup .reg file, change the key name in your RT .reg file from "CurrentVersionRT" back to "CurrentVersion", remove all values in your RT .reg file except for DigitalProductId and DigitalProductId4 (make sure that they're NOT the ones under the DefaultProductKey sub-branch), import that (thus overwriting your Windows key with your Windows RT key), run Produkey, write down the Product Key, then import the backup .reg file to restore your Windows key (important, obviously).
8. Write down the product key.
9. Optional, but recommended: Check that the key is valid by inputting it into a key checker, such as The Ultimate PID Checker. If it tells you that the key is invalid, then try one of the other two methods.
10. Optional: Open Regedit again and delete the CurrentVersionRT key, just to clean up.
METHOD 3 - Can be done solely from Windows RT, but only on 8.0 (won't work on 8.1 Preview or 8.1 RTM) and is more complicated than Method 1:
1. Download and unzip the RT jailbreak tool.
2. Run RunExploit.bat. Choose 'R' from the menu. Let it finish, then press any key when it asks you to.
3. Download and install Win86emu.
4. Download and unzip Produkey.
5. Open the charms bar, click Search, enter "Regedit" and run Regedit.
6. Export HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion to a .reg file.
7. Find the Win86emu tile (icon is "x86") on your Start screen, flick down on it to bring up the options bar and tap Open File Location... or, at the Desktop, you can browse to C:\ProgramData\Microsoft\Windows\StartMenu\Programs\win86emu.
8. Double-tap the "x86 Registry Editor" shortcut.
9. In that registry editor, import the .reg file that you exported in step 4. This will import the settings into the special x86 registry that the emulator created when you installed it and which all x86 programs (including Produkey) will think is the real registry.
10. Double-tap the "Run x86 Program" shortcut.
11. Browse to and select the produkey.exe that you unzipped in step 2.
12. Find the Product Key listed for Windows in the window that appears and write it down. If nothing appears, click on Select Source and verify that it's searching the local computer (top-most radio button).
13. Optional, but recommended: Check that the key is valid by inputting it into a key checker, such as The Ultimate PID Checker. If it tells you that the key is invalid, then try one of the other two methods.
If one method doesn't seem to work for you, try one of the others.

Osprey00 said:
Sure. There are a few different ways to do it. I'll describe two...
...
Hopefully, I didn't forget any steps from either of those methods.
Click to expand...
Click to collapse
Thanks!. Now just waiting to download the iso. Its taking an age.
EDIT: mydigitallife was hacked...thats why the links are down.

aooga said:
Thanks!. Now just waiting to download the iso. Its taking an age.
EDIT: mydigitallife was hacked...thats why the links are down.
Click to expand...
Click to collapse
thanks for the info. was about to search for reasons. hacked by MS?

derausgewanderte said:
thanks for the info. was about to search for reasons. hacked by MS?
Click to expand...
Click to collapse
Yeah I was clueless why it wasn't working, so I just looked at their facebook page.
Would putting a link like this on XDA be considered warez? If not, can someone who has already downloaded the ISO with drivers upload it somewhere? There is no way I'm waiting till Oct. 16

[Q][HELP] Activation Failed after Downgrade

Hi,
i bought a new Surface RT (verison 1) and it was running windows 8.1. I wanted to jailbreak, so I downloaded the 8 recovery file from Microsoft (see url below)) and the installation from usb worked perfectly.
However now it is saying the the Surface is not activated and that the product key is invalid as it has been used too many times.. I never entered a product key so I guess it's either one that's rolled into the recovery file or it's my 8.1 key which doesn't work for 8.
Has anybody experienced this before? What's my best option? Trig0r has kindly provided with access to his ftp so I could download either 8 or 8.1.
I would be very greatful of any advice, tips or experiences.
Thank you
Microsoft download url:
microsoft.com/surface/en-gb/support/warranty-service-and-recovery/surface-rt-startup-error-0xc000000d#download
EDIT / UPDATE:
For anyone else that may have this issue.
I downloaded the RT 8 recovery image and the usb tool mentioned in this thread (the same recovery image as user Trig0r has)
http://forum.xda-developers.com/showpost.php?p=43597775&postcount=32
I then logged in and went to "settings" which brought up the information saying windows was not activated. I then clicked "Contact Support" (or somerthing similar). It then asked me for my location. I chose UK which then provided me with a number to activate over the phone. It provided me with a code which worked perfectly.