Test whether appstraction and cyanoacrylate work on Windows (under WSL) #25
Comments
baltpeter
changed the title
|
OK, I can confirm that an MRE for the IPC communication doesn't work on Windows.
import { execa } from 'execa';
(async () => {
const proc = execa('python', ['script.py'], { stdio: ['pipe', 'pipe', 'pipe', 'ipc'] });
proc.on('message', (message) => {
console.log(111, message);
});
const res = await proc;
console.log(222, res);
})();
import os
import json
ipcPipeFd = 3
res = os.write(ipcPipeFd, bytes(json.dumps("hi") + '\n', 'utf8'))
print(f"res: {res}")This will never print |
|
Curiously, the Python process does print 222 {
command: 'python script.py',
escapedCommand: 'python script.py',
exitCode: 0,
stdout: 'res: 5',
stderr: '',
all: undefined,
failed: false,
timedOut: false,
isCanceled: false,
killed: false
}If I instead change (Changing it to |
|
I got a little closer with https://www.npmjs.com/package/@kldzj/named-pipes, which is an abstraction over named pipes for both Linux and Windows. The script is mostly adapted from the README.
import { createNamedPipe } from '@kldzj/named-pipes';
import { execa } from 'execa';
const pipe = createNamedPipe();
console.log('Path to socket:', pipe.path);
const sender = pipe.createSender();
const receiver = pipe.createReceiver();
await sender.connect();
await receiver.connect();
receiver.on('data', (c) => console.log(c.toString()));
sender.once('connected', () => {
execa('python', ['script-pipe.py', pipe.path]).then(() => pipe.destroy());
});
import json
import sys
pipe_path = sys.argv[1]
with open(pipe_path, 'wb', buffering=0) as pipe:
message = json.dumps("hi").encode('utf-8')
pipe.write(message)This still works fine on Linux and it correctly creates a pipe on Windows, but the Python code for writing to it is wrong. |
|
A few things I tried, unsuccessfully:
|
|
Seems like you did all the work I did again. When I tried this, I came to the conclusion, that the easiest and most elegant solution would be to just use There is already python library for |
|
Are the pipes also failing on WSL, or did you only test them on pure Windows? I think they are not our only problem when porting to Windows. E.g. our paths are all formatted for UNIX operating systems. |
|
I only tested Windows, not WSL.
I don't think that should be a problem:
|
|
Also works fine in Python:
|
|
OK, so I underestimated the amount of work necessary to get However, we would depend on a fairly unstable module there, which I don't like, so I want your opinion, @baltpeter. |
|
The other option would be to implement some kind of complicated socket logic (Thank you for nothing, Windows. Why does everything need to be so complicated with you.). |
|
Random thought: The reason we switched to the IPC mechanism in the first place was because we didn't receive the stdout from mitmproxy in time (maybe due to flushing problems). Now that we use our own mitmproxy script anyway, wouldn't it make sense to check whether we can go back to stdout (with judicious flushing after every message) before implementing our own Windows layer thingy? |
|
We don't use our own mitmproxy script. I abandoned that because I realized it added no value. But I guess I could try that again, maybe that is the easiest way. |
|
I meant the addon, not the script. |
|
Should be possible to write to stdout from there as well, shouldn't it? |
|
I mean, I can just use |
|
It seems like it works like that. We can just set |
|
The structure of a venv on Windows and *nix are annoyingly quite different. Linux: Windows (no packages installed yet): |
|
Oops, accidentally posted these in the wrong issue:
|
|
And here we have a commit just for Mr. "why don't you just grep?" @zner0L. :P |
|
Oh joy. |
|
Apparently, the solution is genuinely to call There is a wrapper for that but I think we can manage on our own. |
|
Are you kidding me, Windows? -.- |
|
And, of course, using |
|
There is also a |
|
Thank you kind strangers on the internet who and the same problem and wrote a literal friggin' native Rust module to send Ctrl + C to a process. <3 Thanks to you, it wööörks!
|
|
I am ever so slightly worried about the fact that no traffic was recorded for any of the apps I tried, though. .D |
|
One problem: The first time I started mitmproxy, I dismissed the Windows Firewall dialog, assuming it would come back the next time. That was a mistake. It didn't and I subsequently forgot about it. In "Windows Defender Firewall", I clicked "Allow an app or feature through Windows Defender Firewall", "Change Settings" and then set "Python" as allowed:
But that isn't enough. I think the HTTPS certificate is still broken. |
|
Indeed HTTP traffic is recorded, but HTTPS traffic errors. |
|
Amazingly enough, the path to the mitmproxy CA is the same on Windows. :D |
|
sigh There's a Why? Because we are splitting on |
|
HTTPS traffic! \o/
|
|
I haven't tested the emulator, but between tweaselORG/cyanoacrylate#19 and tweaselORG/appstraction#61, Windows support should be mostly read. For Android at least. I haven't looked at iOS at all, yet. |
|
I sometimes get this error: Pretty sure that is the problem I was expecting here: tweaselORG/cyanoacrylate#19 (comment) |
|
Here's the script I used for testing (based on the example): import { readdir } from 'fs/promises';
import path from 'path';
import { pause, startAnalysis } from 'cyanoacrylate';
(async () => {
const apkFolder = 'C:\\Users\\root\\Downloads\\single-apks';
console.log('starting');
const analysis = await startAnalysis({
platform: 'android',
runTarget: 'device',
capabilities: ['frida', 'certificate-pinning-bypass'],
targetOptions: {
},
});
console.log('started');
await analysis.ensureDevice();
console.log('ensured.');
const apks = await readdir(apkFolder);
for (const apkFile of apks) {
console.log(apkFile);
const appAnalysis = await analysis.startAppAnalysis(path.join(apkFolder, apkFile));
console.log('ana started');
await appAnalysis.installApp();
console.log('installed');
await appAnalysis.setAppPermissions();
console.log('perms set');
await appAnalysis.startTrafficCollection();
console.log('traffic started');
await appAnalysis.startApp();
console.log('app started');
await pause(6_000);
console.log('paused');
await appAnalysis.stopTrafficCollection();
console.log('traffic stopped');
const result = await appAnalysis.stop();
console.log('app stopped');
await appAnalysis.uninstallApp();
console.log('uninstalled');
console.dir(result, { depth: null });
console.log('\n\n');
}
await analysis.stop();
console.log('done');
})(); |
|
And these were my setup steps:
mkdir ca-test
cd ca-test
npm init --yes
npm i cyanoacrylate # I used a `yarn pack`ed `.tar.gz`.
Honestly, that is all already covered in the README, you just need to figure out how to get those dependencies on Windows (but then, we don't provide instructions for that on Linux, either). |
|
The vs. |
|
Looking good. That really wasn't too bad.
|
|
Here are my setup steps for iOS (again, nothing that isn't in the README already):
mkdir ca-test
cd ca-test
npm init --yes
npm i cyanoacrylate # I used a `yarn pack`ed `.tar.gz`.
|
|
Actually, maybe we should mention that you need the iTunes drivers. |
We are pretty sure that CA won't work on Windows due to the IPC mechanism used:
https://github.com/tweaselORG/cyanoacrylate/blob/b59010c79fa4939307b81bc58db0f52147e285fc/README.md?plain=1#L14
But we haven't actually verified that. And maybe it does work under WSL at least…
The text was updated successfully, but these errors were encountered: