|
|
Post by oleavr on Dec 4, 2021 2:58:26 GMT
With the machine hooked up to the local network, I finally got around to cross-compiling Frida for it. Here is what it looks like. This was done very quickly, and it's getting so late that I'm going to have to rush through the details real quick: - Uploaded binaries here. Extract this tarball's three files (frida-server, lib/frida-helper, lib/frida-agent.so) to the root of a thumb-drive. Mount it at /mnt (important), then run frida-server and tell it to listen on a network interface, e.g.: /mnt/frida-server -l 192.168.1.64 (by default it will only listen on the loopback interface).
- From another machine with frida-tools installed (pip install frida-tools), you can now connect to the running frida-server by passing -H 192.168.1.64
Some examples: - List running processes: frida-ps -H 192.168.1.64
- Attach Frida's REPL to the64 process: frida -H 192.168.1.64 the64
- Inject a script into the64: frida -H 192.168.1.64 the64 -l c64.js (Example script here. Note that the outer-loop offset is hard-coded for firmware v1.5.2 for now.)
Note: The frida-agent.so binary is quite large due to the V8 JS engine being included. Frida can be built without it to shave off a lot of footprint, but I opted to include it for the initial exploration, just in case I'd end up using it. (The default JS engine is QuickJS, but you can switch to V8 by passing --runtime=v8 to the CLI tools.) The example agent above is really primitive, but down the road I'd like to write a generic "bridge" to make instrumentation really easy. (Frida already has bridges such as frida-objc-bridge, frida-swift-bridge, frida-java-bridge, etc., and it would be awesome to write a frida-c64-bridge that exposes a lot of different functionality by building on VICE's internals.) |
|
|
|
Post by jj0 on Dec 4, 2021 9:28:57 GMT
Another cool development. Where do you see this going with the bridge idea? It reminded me a little bit of fusys' tc64monitor tool though Frida is more flexible. |
|
|
|
Post by oleavr on Dec 8, 2021 1:24:32 GMT
Another cool development. Where do you see this going with the bridge idea? It reminded me a little bit of fusys ' tc64monitor tool though Frida is more flexible. Thanks!  Yeah the in-process nature of Frida makes it easy to do really complex introspection, even calling functions inside the target and placing hooks at arbitrary points. The drawback is obviously that it's very easy to blow things up, which is a nice aspect of tc64monitor's outside-looking-in approach.
I'm still not sure exactly what kind of API the bridge should expose, but at least I'd like to have: - Peek/poke
- Memory snapshot, which internally would find the base address of VICE' 64 kiB buffer and do base.readByteArray(65536). This could then be used to implement Action Replay style UIs.
- C64ceptor.attach(address, { onEnter() { ... }), similar to Interceptor.attach(), i.e. an easy way to hook arbitrary functions.
- Execution trace. (Maybe drawing some inspiration from Frida's Stalker API.)
Would also be cool to write a different bridge that knows the RGL UI internals (libflashlight.so, OpenGL, etc.), and makes it easy to draw UI overlays.
But my gut feeling is that the best place to start is perhaps a graphical frontend that makes it easy to explore games while playing them. This could use radare for disassembly/graph view, and implementing the dynamic bits would be a way to drive the VICE bridge functionality forward. But anyway, just spitballing here -- for now I've run into a few Linux/ARM bugs in Frida that have kept me distracted.. but hoping to get back to the fun bits again soon.
What about you, what are you keen on building?
|
|
|
|
Post by jj0 on Dec 8, 2021 16:00:43 GMT
Another cool development. Where do you see this going with the bridge idea? It reminded me a little bit of fusys ' tc64monitor tool though Frida is more flexible. Thanks! Yeah the in-process nature of Frida makes it easy to do really complex introspection, even calling functions inside the target and placing hooks at arbitrary points. The drawback is obviously that it's very easy to blow things up, which is a nice aspect of tc64monitor's outside-looking-in approach.
I'm still not sure exactly what kind of API the bridge should expose, but at least I'd like to have: - Peek/poke
- Memory snapshot, which internally would find the base address of VICE' 64 kiB buffer and do base.readByteArray(65536). This could then be used to implement Action Replay style UIs.
- C64ceptor.attach(address, { onEnter() { ... }), similar to Interceptor.attach(), i.e. an easy way to hook arbitrary functions.
- Execution trace. (Maybe drawing some inspiration from Frida's Stalker API.)
Would also be cool to write a different bridge that knows the RGL UI internals (libflashlight.so, OpenGL, etc.), and makes it easy to draw UI overlays.
But my gut feeling is that the best place to start is perhaps a graphical frontend that makes it easy to explore games while playing them. This could use radare for disassembly/graph view, and implementing the dynamic bits would be a way to drive the VICE bridge functionality forward. But anyway, just spitballing here -- for now I've run into a few Linux/ARM bugs in Frida that have kept me distracted.. but hoping to get back to the fun bits again soon.
What about you, what are you keen on building?
Sounds nice. Almost like a debugging environment for developing games on the Maxi. Me, I'm working on allowing the Mini/Maxi to boot other OS's from USB if a suitable OS on USB is inserted at boot. Nearly finished. After that maybe trying to get my Maxi to recognise that it actually has 512MB. |
|
|
|
Post by oleavr on Dec 10, 2021 0:38:20 GMT
Sounds nice. Almost like a debugging environment for developing games on the Maxi. Glad to hear Yeah, that and peeking under the hood of old classics while playing them. Me, I'm working on allowing the Mini/Maxi to boot other OS's from USB if a suitable OS on USB is inserted at boot. Nearly finished. After that maybe trying to get my Maxi to recognise that it actually has 512MB. Wow, that's super-neat! Can definitely see myself using that to work on an experimental version of the original software. (Mainline kernel, bleeding edge userland, etc.) |
|
Yeah the in-process nature of Frida makes it easy to do really complex introspection, even calling functions inside the target and placing hooks at arbitrary points. The drawback is obviously that it's very easy to blow things up, which is a nice aspect of tc64monitor's outside-looking-in approach.
