Can't start traffic analysis: Starting mitmproxy failed after a timeout.

[techware01]

Hey, was trying to run this project to test an app and see how it works. Setting up an android emulator, installing an app etc. with tweasel-cli worked with not issue. But when it comes to traffic-recording the mitmproxy part fails for me:

file:///home/**/tweasel/node_modules/cyanoacrylate/dist/index.js:261
            if (e.name === "TimeoutError") throw new (0, $kYxtx$TimeoutError)("Starting mitmproxy failed after a timeout.");
                                                 ^

TimeoutError: Starting mitmproxy failed after a timeout.
    at file:///home/**/tweasel/node_modules/cyanoacrylate/dist/index.js:261:50
    at async startTrafficCollection (file:///home/**/tweasel/node_modules/cyanoacrylate/dist/index.js:258:9)
    at async file:///home/**/tweasel/test.js:25:5

Node.js v18.17.1

I already tried running the post install script for this project again to see if this brings any errors and checked the cache for the existence of python file. That works. But I couldn't find the .venv directory mentioned in https://github.com/tweaselORG/cyanoacrylate/issues/12.

Any ideas what I could do to get this running?

[baltpeter]

Hey, thanks for creating the issue!

The location of the venv has actually changed since #12. We have abstracted that functionality out into a separate library.

You should now find the venv in ~/.cache/autopy/venv/cyanoacrylate (on Linux). Can you check whether ~/.cache/autopy/venv/cyanoacrylate/bin/mitmdump exists?

If it does, do you get any errors when trying to run ~/.cache/autopy/venv/cyanoacrylate/bin/mitmdump manually (should just work, even without activating the venv)?

Here's the output I get:

[10:26:59.058] HTTP(S) proxy listening at *:8080.

If that also works, here's the full command that cyanoacrylate will try to run[^nit]:

[^nit]: Well, almost… We actually also use a --quiet flag but that obviously isn't helpful for debugging. Also, hardump will be set to a randomly generated filename each time.

~/.cache/autopy/venv/cyanoacrylate/bin/mitmdump -s ~/.cache/cyanoacrylate/mitmproxy-addons/ipcEventsAddon.py -s ~/.cache/cyanoacrylate/mitmproxy-addons/har_dump.py --set hardump=/tmp/d37ba19b255d806b9ba08013289904ae.har --set ipcPipeFd=1 --mode wireguard

Do you see any problems when running that manually? Here's my output again for reference:

[10:34:32.468] Loading script /home/benni/.cache/cyanoacrylate/mitmproxy-addons/ipcEventsAddon.py
[10:34:32.469] Loading script /home/benni/.cache/cyanoacrylate/mitmproxy-addons/har_dump.py
cyanoacrylate:{"status": "proxyChanged", "context": {"isRunning": false, "servers": [{"type": "wireguard", "description": "WireGuard server", "fullSpec": "wireguard", "isRunning": false, "lastException": null, "listenAddrs": [], "wireguardConf": null}]}}
[10:34:32.474] WireGuard server listening at *:51820.
------------------------------------------------------------
[Interface]
PrivateKey = <redacted>
Address = 10.0.0.1/32
DNS = 10.0.0.53

[Peer]
PublicKey = Gbgxoz8b+08BgxYAvheM6OmFT09aaSQxtURWYShm9i0=
AllowedIPs = 0.0.0.0/0
Endpoint = 10.0.0.68:51820
------------------------------------------------------------
cyanoacrylate:{"status": "proxyChanged", "context": {"isRunning": false, "servers": [{"type": "wireguard", "description": "WireGuard server", "fullSpec": "wireguard", "isRunning": true, "lastException": null, "listenAddrs": [["0.0.0.0", 51820]], "wireguardConf": "[Interface]\nPrivateKey = <redacted>\nAddress = 10.0.0.1/32\nDNS = 10.0.0.53\n\n[Peer]\nPublicKey = Gbgxoz8b+08BgxYAvheM6OmFT09aaSQxtURWYShm9i0=\nAllowedIPs = 0.0.0.0/0\nEndpoint = 10.0.0.68:51820"}]}}
cyanoacrylate:{"status": "running"}
^Ccyanoacrylate:{"status": "done"}
[10:34:37.251] HAR dump finished (wrote 259 bytes to file)

[techware01]

Hey, thank you very much for the detailed explanation. That brought me to the issue! Probably from earlier tests with mitmproxy I had some old CA files in /home/$USER/.mitmproxy/ owned by root. When running your command as non root user it failed opening them. After deleting the directory it worked just fine.

[baltpeter]

Great, glad to hear that! I've opened #44 to see whether we can provide more helpful information if mitmproxy fails to start.