Old post text:
Mmm as I am far from a selfish guy, and have been asked about this, i think that i will share in an independent thread for anyone to see. Note that this comes from my own ideas, not tested as i cannot use MTP protocol anymore. Responsability Disclaimer This may be agains DCMA or laws about reversing in your country. It's not probably being that way as is a development to interoperate with an unsupported OS (linux) and its one of the exceptions, but i'm not responsable for any liability you can have or imagine. What is this for? This is the procedure to follow before thinking in hacking the phone itself, trying to get to write and read files from the device. It could faild and serve to no purpose or be gold, depending on the success of the tests. In the best case, this will lead to the reading and writing of files at will to the device storage. USB protocol Pre-Knowledge (fast) I know you dont wanna know about it, and i am far from an expert but i must just express that USB devices support two operations: Bulk Transfers -> Big chunks of data, used mostly for the common data transfers up to 512Bytes per transmission (at a max/time). Interrupt Transfers -> Short chunks of data, used for changing settings on the device or short burst of information. For your personal knowledge, MTP protocol instructions are bunch of hex codes and they use bulk transfers for all of the MTP instructions. Required items - Gathering - Working Kin - Windows OS as host OS - USB sniffer / monitor (I like Usblyzer, has trial for 30 days) - CPU with virtualization capabilities (google how to check) - Vmware - Mac OSX image dvd (Snow leopard) - Software & registration from MacSpace for Kin Media Sync Procedure - Unplug the kin & close all zune software opened. - Install OSX in an vmware machine - Install and setup Kin Media sync for mac - Kill the process that launches zune when you plug the device ("ZuneLauncher.exe") - Plug the kin now. Use a port where no other device is, so try to put it not together with other usb device like mouse/keyboard which could send packets and confuse the capture. - Install and setup usb sniffer for windows. --- Set it to sniff/capture at the USB port where the kin is (it's a tree view structure, so easy to see where to put the check). Dont do it at the left of the KIN device!!! do it on the bus/port as you will disconnect the kin later. Press start capture. --- Open the zune software and visually check that the sniffer is capturing data (eeeeeeeeeeeeaaaaaaasssssyyyyyyy as it appears there). If it doesnt, you'r doing it wrong, probably cause the port/bus issue. --- Close zune --- Reset the capturing (stop, dont save, start). - Open the virtual machine if it isnt. - In the virtual machine you should have Kin Media Sync installed, which autolaunches if you have plugged the phone (virtually). - In the virtual machine window bottom right (vmware border) you will see an item with usb icon. Hover over it and see if the tooltip says KIN. If there are more, look for the right one. Right-Click on it and pick "Connect (Disconnect from host". - Hopefully, the usb sniffer on Windows would turn mad and begin capturing data, while Kin Media Sync is opening on the OSX virtual machine. - I cant remember if it does put the label "Connected" at the Kin (you should remember that window from the Zune syncing :P). If it does, close Kin Media Sync and stop the capture on the windows usb sniffer. Else, do a sync before closing (doesnt matter what). - Save the captured log as a file (in my case, Usblyzer file). Yeah, but why this is better than other software? Other users (and myself) have tried software that uses the MTP software which has some success on getting info from the device but fail when it comes to do reading or writing to the device. I guess it's probably because the rest of the protocol, the private part that microsoft uses (MTPz) has some control values through the usb that turn on/off device properties, among ones is the one to write/read files. My first idea was to understand this through the Zune software, but as i said many times, it uses DRM (Janus) to protect the songs (sigh!) and the mtp specification varies if using DRM protection, so i can never find out a way to solve it, without hacking the Zune software cryptography itself (not my intention at all) or became an old man finding how to bypass it. In any case, the Zune software does a RSA challenge-response handshake to the kin before calling to MTP-OpenSession, i can assure that, so its out of reach. On the other hand Kin Media Studio for the OSX has no official DRM and it can just do easy syncing, so it's pretty much obvious for a dev guy (i am, haha) that its an easiest way to replicate. So i tried to go that way and i was correct, so it just does normal operations through usb and control interrupts. The problem is that the native sniffers from OSX only capture 16 bytes of data through the usb bus, so messages over that cipher were not reachable for me at the moment. I contacted apple USB master guys about getting a bigger limit, and the resumed answer was something (just much more politely) like: "you'r screwed & stuck with 16 bytes". So the only approach is to emulate Kin Media Sync in an OSX virtual machine under a windows os machine for the best sniffer software. Another bad point for the fruit logo machines.... (and i'm an owner... imagine a hater!). Here is why I stopped, as my normal working device (laptop) is kinda old and has no VMX/virtualization support, so i couldnt setup the virtual machine for OSX, stopping all the needed setup. From sniffed data to magic At this point, comes the complicate part. Understanding & testing the packets sent to the device to make things work. This is the part where i was going to operate with a new device or my current one if it wasnt bricked/stuck. The problem appears with this structure (what is on the logged sniffed session): - Plug the device - Device <-> OS Handshake (Interrupt/Bulk transfers possible) - Kin media sync queries (Interrupt transfers) - Kin media write/read enable (Interrupt transfers) - Kin media MTP Open session (Bulk transfer) - Kin media MTP GetStorageInfo (Bulk transfer) ..... more MTP xxxxx (bulk transfer) - Kin media MTP Close session (bulk transfer) - Kin media write/read disable (Interrupt transfers) - Kin media bye bye sync queries (Interrupt transfers) (if unplugged, the ones below) - Device <-> OS Goodbye (Interrupt/Bulk transfers possible) - UnPlug the device As some of you may realize, normal MTP software used didnt make the "read/write enable" cause the kin is not a standard device. So they fail. Once some person identifies which of this interrupt values make the kin "Connected" window shown and also enables it to be writable, profit comes. So to test this and later make it published, you need a program to communicate with the device itself and do what some of you called "send hex codes to the kin" (which technically is "bulk and interrupt transfering values to the kin") There seems to be none, so i code one from scratch and could polish it a bit and giveaway as a Netbeans C++ proyect. I had some success and it works ok as i reused it(almost all the code) to operate my G15 on linux, iluminating keys and using the LCD pixels. This can brick my device? The short answer to this is NO. The long answer is no again, but cannot be sure of what happens enabling the the device settings while testing. It may become frozen and need to be restarted for example. During the few test i made, mine refused to operate within my usb program and it was autosolved by libmtp-tools, which did a protocol reboot and it just work as is without doing nothing. Anyway, i was aware that it was better than getting stuck with the phone "as is". mmm All being said above, i just leave space for you guys to think what you wanna do with the info and questions that may appear.