Add debug proxy for tunnel interface#353
Conversation
dmissmann
force-pushed
the
dm-debugproxy
branch
from
029e238 to
9e9c009
Compare
| > f.ex. "ios launch com.apple.Maps" | ||
| ios forward [options] <hostPort> <targetPort> Similar to iproxy, forward a TCP connection to the device. | ||
| ios dproxy [--binary] [--mode=<all(default)|usbmuxd|utun>] [--iface=<iface>] [options] Starts the reverse engineering proxy server. | ||
| ios dproxy [options] [--binary] [--mode=<all(default)|usbmuxd|utun>] [--iface=<iface> --address=<ipv6addrr> --rsd-port=<port>] Starts the reverse engineering proxy server. |
There was a problem hiding this comment.
Isn't address and port already part of [options]? Ref: https://github.com/danielpaulus/go-ios/blob/main/main.go#L134
The pattern in this snippet use to work for me, haven't tested for a while now:
ios dproxy [--binary] [--mode=<all(default)|usbmuxd|utun>] [--iface=<iface>] [options]
|
|
||
| func decodeRemoteDtx(w io.Writer, r io.Reader) error { | ||
| for { | ||
| m, err := dtx.ReadMessage(r) |
There was a problem hiding this comment.
I wonder if we can make this work with fragmented messages out of box, using DecodeNonBlocking() just like it's used by TestFragmentedMessage unit tests.
| if i == 0x29b00b92 { | ||
| return remoteXpc | ||
| } | ||
| if string(b[:3]) == "y[=" { |
There was a problem hiding this comment.
Isn't this magic also 4 bytes long?
| outErr := decodeHttp2(outgoing.w, outFile, true) | ||
| inErr := decodeHttp2(incoming.w, inFile, false) | ||
| if err := errors.Join(outErr, inErr); err != nil { | ||
| //return err |
There was a problem hiding this comment.
Do we want to keep this?
| ) | ||
|
|
||
| func Live(ctx context.Context, iface string, provider ios.RsdPortProvider, dumpDir string) error { | ||
| return errors.New("capturing traffic on the utun interface is only supported on MacOS") |
There was a problem hiding this comment.
Does this still hold true?
There was a problem hiding this comment.
Can go-ios sniff tunnels created by itself running on a separate process?
There was a problem hiding this comment.
it should work on linux as well. however, after changing it to build everywhere the build fails on linux. And I think initially the motivation was that this anyways is mainly used on MacOS I would expect that you always want Xcode/MacOS to perform a certain action that we want to capture
pcap is not exclusive to MacOS
This reverts commit 75917bd.
2 participants
We can simply use a pcap library to capture the communication going over the tunnel interface (it't not encrypted at that point).
usbmuxd and utun captured traffic are put into separate subdirectories in a dump. Their content is also slightly different. With utun we already put the service name in the directory name, and we try to decode the content when possible (currently we do this for
http2,RemoteXPCandDTX)