diff options
| author | 2009-08-20 03:42:52 +0200 | |
|---|---|---|
| committer | 2009-08-20 06:51:10 +0200 | |
| commit | 1a0c58e4062da7db73b4c08963f741cf016f6aa5 (patch) | |
| tree | b250f094e978d48622ecf652e28e9f3b68873893 /README | |
| parent | f4854f3fd725b5ba49cd5157d941783cffa08c04 (diff) | |
| parent | 79ca4d9a3c3a82bb5a3f9be1ac7a2533c7a89b05 (diff) | |
| download | usbmuxd-1a0c58e4062da7db73b4c08963f741cf016f6aa5.tar.gz usbmuxd-1a0c58e4062da7db73b4c08963f741cf016f6aa5.tar.bz2 | |
Merge the two development histories
Diffstat (limited to 'README')
| -rw-r--r-- | README | 150 |
1 files changed, 100 insertions, 50 deletions
| @@ -1,27 +1,103 @@ | |||
| 1 | This is an implementation of the iPhone/iPod Touch USB connection protocol. | 1 | Background |
| 2 | 2 | ========== | |
| 3 | The server should be mostly compatible with the original Apple usbmuxd | 3 | |
| 4 | protocol. This means that a single client lib should be able to interoperate | 4 | 'usbmuxd' stands for "USB multiplexing daemon". To the user/developer what it |
| 5 | with both. Apple has now introduced a new plist-based version of the protocol | 5 | actually does is to proxy requests over a USB cable on directly to a listening |
| 6 | which works in essentially the same way but uses XML-based plists as | 6 | TCP port on the iPhone. |
| 7 | command/response payloads instead of binary blobs. The outer binary protocol is | 7 | |
| 8 | still the same used but now the only command/response format is 8 (plist). | 8 | Multiple connections to different TCP ports can happen in parallel. An example |
| 9 | 9 | (and useful) tool called 'iproxy' is included that allows you to forward | |
| 10 | The server is under the usbmuxd directory. You'll need CMake and libusb 1.0 to | 10 | localhost ports to the device---allows SSH over USB on jailbroken devices, or |
| 11 | build it. Due to a bug in zero-length packet handling, you'll need either the | 11 | allowing access the lockdown daemon (and then to all of the file access, sync, |
| 12 | git version of libusb or 1.0.3, whenever it comes out. | 12 | notification and backup services running on the device). |
| 13 | 13 | ||
| 14 | There is a Python client library in the python-client directory. It should be | 14 | This higher-level layers are handled by libiphone. The version of libiphone |
| 15 | compatible with Windows, Linux, and OSX (using the Apple usbmuxd on Win and OSX) | 15 | compatible with the 'usbmuxd' infrastructure is called 'libiphone-usbmuxd'. |
| 16 | tcprelay.py implements a TCP connection forwarder that lets you pipe TCP | 16 | 'ifuse' is then able to sit on top of this. |
| 17 | connections to localhost to the phone. Run it with --help for usage. The Python | 17 | |
| 18 | client lib is also compatible with the new plist-based protocol and should | 18 | There is also a Python implementation of the client library in the python-client |
| 19 | automatically select it if it sees such a server. However, you need Python 2.6 | 19 | library, and an example tcprelay.py which performs a similar function to iproxy. |
| 20 | for Windows and Linux in this case, since the plistlib module doesn't come with | 20 | This implementation supports OSX and Windows and the new iTunes plist-based |
| 21 | older versions under these OSes (not that you'll have a server that supports | 21 | usbmuxd protocol, so it is portable and will run on those operating systems with |
| 22 | this protocol under Linux. TODO: does Windows iTunes use this yet?) | 22 | no modification, using Apple's native usbmuxd. This is useful if you need to |
| 23 | 23 | tunnel to your phone from another OS in a pinch. Run python tcpclient.py --help | |
| 24 | ARCHITECTURE | 24 | for usage information. |
| 25 | |||
| 26 | Building | ||
| 27 | ======== | ||
| 28 | |||
| 29 | mkdir build | ||
| 30 | cd build | ||
| 31 | cmake .. | ||
| 32 | make | ||
| 33 | sudo make install | ||
| 34 | |||
| 35 | Running (with magic) | ||
| 36 | ==================== | ||
| 37 | |||
| 38 | (Unplug + replug your iPhone) | ||
| 39 | ./iproxy 2222 22 & | ||
| 40 | ssh -p 2222 root@localhost | ||
| 41 | |||
| 42 | Hopefully you get the normal SSH login prompt. You may still lots of debugging | ||
| 43 | output for the moment. If this is getting in the way of your ssh login, then | ||
| 44 | run the 'ssh' command from a different xterminal | ||
| 45 | or virtual console. | ||
| 46 | |||
| 47 | |||
| 48 | Running (without magic) | ||
| 49 | ======================= | ||
| 50 | |||
| 51 | If 'udev' is _not_ automatically running on your machine and picking up the new | ||
| 52 | .rules file, you will need to start usbmuxd by hand first. Check it's running | ||
| 53 | and that there is only one copy with 'ps aux | grep | ||
| 54 | usbmuxd'. | ||
| 55 | |||
| 56 | sudo usbmuxd -U -v -v & | ||
| 57 | ./iproxy 2222 22 & | ||
| 58 | ssh -p 2222 root@localhost | ||
| 59 | |||
| 60 | |||
| 61 | Tip: Starting SSH if disabled | ||
| 62 | ============================= | ||
| 63 | |||
| 64 | If your iphone is rooted, but SSH isn't started and you _cannot_ (for instance, | ||
| 65 | cracked/broken screen) get to the Services control panel on the device, then you | ||
| 66 | can start the SSH service over the USB by | ||
| 67 | mounting the (jailbroken) filesystem. | ||
| 68 | |||
| 69 | You will need to mount it usbing 'ifuse --afc2' (to access the root directory of | ||
| 70 | the device), and then edit: | ||
| 71 | |||
| 72 | /Library/LaunchDaemons/com.openssh.sshd.plist | ||
| 73 | |||
| 74 | to _remove_ the lines: | ||
| 75 | |||
| 76 | <key>Diabled</key> | ||
| 77 | <true/> | ||
| 78 | |||
| 79 | Reboot the device and then sshd should be running. | ||
| 80 | |||
| 81 | TODO | ||
| 82 | ==== | ||
| 83 | |||
| 84 | The server currently assumes that the phone is well-behaved and does not do a | ||
| 85 | bunch of checks like looking for the expected SEQ and ACK numbers from it. This | ||
| 86 | is normally not an issue, but it's annoying for debugging because lost packets | ||
| 87 | (which shouldn't happen, but can happen if the code is buggy) mean that stuff | ||
| 88 | gets out of sync and then might crash and burn dozens of packets later. | ||
| 89 | |||
| 90 | The server needs more testing, and some optimizing. | ||
| 91 | |||
| 92 | Someone should probably do some edge-case testing on the TCP stuff. | ||
| 93 | |||
| 94 | The outgoing ACK handling on the server probably needs some thought. Currently, | ||
| 95 | when there's an outstanding ACK, we send it after a timeout (to avoid sending | ||
| 96 | a no-payload ACK packet for everything the phone sends us). However, there's | ||
| 97 | probably a better way of doing this. | ||
| 98 | |||
| 99 | Architecture information | ||
| 100 | ======================== | ||
| 25 | 101 | ||
| 26 | The iPhone / iPod Touch basically implements a rather strange USB networking | 102 | The iPhone / iPod Touch basically implements a rather strange USB networking |
| 27 | system that operates at a higher level. It is of course completely proprietary. | 103 | system that operates at a higher level. It is of course completely proprietary. |
| @@ -90,9 +166,6 @@ Note that all normal packets need to have flags set to ACK (and only ACK). There | |||
| 90 | is no support for, erm, not-acking. Keep the ack number field valid at all | 166 | is no support for, erm, not-acking. Keep the ack number field valid at all |
| 91 | times. | 167 | times. |
| 92 | 168 | ||
| 93 | |||
| 94 | GOTCHAS AND ANNOYANCES | ||
| 95 | |||
| 96 | The usbmuxd CONNECT request port field is byte-swapped (network-endian). This is | 169 | The usbmuxd CONNECT request port field is byte-swapped (network-endian). This is |
| 97 | even more annoying for the plist based protocol, since it's even true there | 170 | even more annoying for the plist based protocol, since it's even true there |
| 98 | (where the field is plain text). So even for the plain text int, you need to | 171 | (where the field is plain text). So even for the plain text int, you need to |
| @@ -123,26 +196,3 @@ at non-16k boundaries that are multiples of 512, but that seems to work fine. I | |||
| 123 | guess the ZLPs might cause spurious 0-byte transfers to show up on RX if things | 196 | guess the ZLPs might cause spurious 0-byte transfers to show up on RX if things |
| 124 | line up right, but we ignore those. By the way, the maximum packet/transfer size | 197 | line up right, but we ignore those. By the way, the maximum packet/transfer size |
| 125 | is 65535 bytes due to the 16-bit length header of the usbmux protocol. | 198 | is 65535 bytes due to the 16-bit length header of the usbmux protocol. |
| 126 | |||
| 127 | TODO | ||
| 128 | |||
| 129 | The server currently assumes that the phone is well-behaved and does not do a | ||
| 130 | bunch of checks like looking for the expected SEQ and ACK numbers from it. This | ||
| 131 | is normally not an issue, but it's annoying for debugging because lost packets | ||
| 132 | (which shouldn't happen, but can happen if the code is buggy) mean that stuff | ||
| 133 | gets out of sync and then might crash and burn dozens of packets later. | ||
| 134 | |||
| 135 | The server needs a proper front-end (i.e. daemonizing, commandline options, | ||
| 136 | etc), more testing, and some optimizing. | ||
| 137 | |||
| 138 | Someone should probably do some edge-case testing on the TCP stuff. | ||
| 139 | |||
| 140 | At some point we should probably write a C client lib. | ||
| 141 | |||
| 142 | The outgoing ACK handling on the server probably needs some thought. Currently, | ||
| 143 | when there's an outstanding ACK, we send it after a timeout (to avoid sending | ||
| 144 | a no-payload ACK packet for everything the phone sends us). However, there's | ||
| 145 | probably a better way of doing this. | ||
| 146 | |||
| 147 | |||
| 148 | |||
