takeshixx
commented
8 years ago This could be a potential problem because if the exploit fails then it will not only fail for one team but for many. Having a single exploit instance for every team has the advantage that in case there are errors for some teams you can thread each instance individually. You can kill them, or exclude them without much trouble.
Having an exploit that exploits multiple teams at once would introduce a lot of complexity on the exploit part. However, the framework is meant to reduce this complexity by handling all of the "difficult" and repetitive tasks. It is highly recommended to keep the exploits as simple as possible in order to reduce debugging overhead.
We could implement multi host exploits easily without changing much of the core functionality for the (rare) cases where this would be necessary. But we should not encourage anyone to use it in their exploits.
If an exploit is IO heavy it might be more efficient to use something like asyncio in Python instead of starting 200 processes. So the idea is to add a config for exploits telling whether or not it can run on multiple hosts simultaniously. So the exploitservice provides an IP range instead of one IP and in return the exploit prints multiple flags.