You're right; this approach wouldn't work with an "opaque peer", as most machines on the Internet would count as.
However, assuming the above sci-fi scenario—a cooperative peer that wants to communicate, but shares no common signalling standards with you—you could assume that everyone is doing broadcasts on loop of their daemon binaries to let their peers analyze them.
This would require some bootstrap logic on each side, to find what signalling methods their peer is using to broadcast the bootstrap. This could be made an approachable problem if everyone assumes everyone else will use "lowest-common denominator" signalling technologies for their bootstrap transmissions (e.g. binary over AM radio.)
You'd also have to figure out the ISA of the recovered binaries, in order to begin to fuzz them. This isn't impossible to do automatically either; it basically requires an "inverted" fuzz process—fuzzing up a VM with various decoding strategies and opcode definitions, and then seeing what it does when fed the provided binary, attempting to find something that produces a "normal" program execution (maybe according to a neural network trained on what memory-states of running programs usually look like.)
---
To jump back out of the sci-fi context, though—if you assume an "opaque peer" that nevertheless has its source code published online somewhere (e.g. as FOSS on GitHub), then you can do something like this:
1. set up a web spider that downloads source code from the internet, compiles it, and then fuzzes the resulting binaries (presumably all in a sandbox) to create mappings between project URLs and fingerprints of behavior under fuzzing.
2. when trying to communicate with an arbitrary server, first fuzz it a bit to try to fingerprint the response using the index.
3. Take the results as a fingerprint; feed them to the index service; get a source URL; clone the relevant project.
4. Fuzz-analyze the source code of the project along with the responses of the live peer, comparing the two as you go to try to get your local "mental model" of the peer as aligned as possible with how it's really behaving. (E.g., use the live peer's responses to generate the config file for your local copy of the project.)
5. With a behavior-matched local copy, generate an IDL client as above. (Which can, of course, be a very easy process if it turns out the server obeys some previously-discovered protocol.)
However, assuming the above sci-fi scenario—a cooperative peer that wants to communicate, but shares no common signalling standards with you—you could assume that everyone is doing broadcasts on loop of their daemon binaries to let their peers analyze them.
This would require some bootstrap logic on each side, to find what signalling methods their peer is using to broadcast the bootstrap. This could be made an approachable problem if everyone assumes everyone else will use "lowest-common denominator" signalling technologies for their bootstrap transmissions (e.g. binary over AM radio.)
You'd also have to figure out the ISA of the recovered binaries, in order to begin to fuzz them. This isn't impossible to do automatically either; it basically requires an "inverted" fuzz process—fuzzing up a VM with various decoding strategies and opcode definitions, and then seeing what it does when fed the provided binary, attempting to find something that produces a "normal" program execution (maybe according to a neural network trained on what memory-states of running programs usually look like.)
---
To jump back out of the sci-fi context, though—if you assume an "opaque peer" that nevertheless has its source code published online somewhere (e.g. as FOSS on GitHub), then you can do something like this:
1. set up a web spider that downloads source code from the internet, compiles it, and then fuzzes the resulting binaries (presumably all in a sandbox) to create mappings between project URLs and fingerprints of behavior under fuzzing.
2. when trying to communicate with an arbitrary server, first fuzz it a bit to try to fingerprint the response using the index.
3. Take the results as a fingerprint; feed them to the index service; get a source URL; clone the relevant project.
4. Fuzz-analyze the source code of the project along with the responses of the live peer, comparing the two as you go to try to get your local "mental model" of the peer as aligned as possible with how it's really behaving. (E.g., use the live peer's responses to generate the config file for your local copy of the project.)
5. With a behavior-matched local copy, generate an IDL client as above. (Which can, of course, be a very easy process if it turns out the server obeys some previously-discovered protocol.)