2 ms·
You're right hence the extensive reverse engineering. I think you can expose call graphs and assembly with SoftICE or some product like that and infer which win
by blackbeard 11y ago
You're right hence the extensive reverse engineering. I think you can expose call graphs and assembly with SoftICE or some product like that and infer which windows API calls are used so that's a starting point. However some of the things that talk are going to be heavily optimised binaries, code signed and difficult to poke inside.
- mahouse 11y agoI'm not sure of that, they could even be C# binaries, which are usually easy to disassemble and follow.
- blackbeard 11y agoPossible. I suspect anything interesting will be C++ however, possibly by design.
- balabaster 11y agoGenerally speaking you don't need to go to such lengths to intercept client/server communication from your own device. You can even have your wireless devices use your local WiFi, computer and Fiddler (which I think is roughly equivalent to Charles on Linux/iOS) as a proxy to intercept SSL and decrypt communication. You don't need to bust open the codebase itself to figure out what comms are occurring. You can stage your own MITM attack against yourself with a couple of home made SSL certificates and a router you have the ability to install your own software on.
- blackbeard 11y agoThat's true but then you still have to understand the data that is sent rather than where it is collected from. The of latter is much easier than the former from experience (I've had to reverse engineer a couple of protocols in my time)