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