From the paper you quote, additional Symbiotes would both complicate the code rewriting scenario, making disabling them theoretically more difficult; and the Symbiotes could be made to protect one another, making disabling them practically impossible.
The attacker would need to get a precise image of all their entry points and disable them all in one fell swoop, before any of the Symbiote's integrity routines can execute enough to identify the threat (remember, they're multitasked - the attacker possibly isn't, and might conceivably have available for a brief instant the whole CPU power).
To do this, though, the attacker would need to do what you propose - to slowly copy the image for analysis. In the proposed scenario, this is unfeasible, because the code performing the copy would be identified long before it could do anything dangerous. It needs to execute on the victim machine, and that machhine is Symbioted. Copying the image slowly just gives the Symbiote more time in which to notice the copying instructions, while copying fast is going to attract attention to the copying itself.
I'm not too clear on how two Symbiotes might protect one another though - it seems to me that this would require some way for the second Symbiote to become known (and trusted) to the first, which might hint to a possible attack vector. But this might be an oversight on my part: I haven't studied the paper in depth.
A possible way of circumventing security (especially if the Symbiote is not executing very fast) could also be offered by this:
The SEM injection process requires a handful of parameters specic to
the target firmware, including a list of randomly chosen control-flow
intercept points and locations of usable memory. All such parameters
are computed automatically by a simple single pass analysis of the
target binary
Ideally the attacker knows the target system and must be thought to have a copy of the Symbiote injector. Therefore, he can run himself the same single pass analysis remotely beforehand, and come up with a large, but finite list of intercept points together with their original content (which the attacker may garner from an original image of the victim OS). Large as it may be, it will be certainly much smaller than the whole victim OS image.
Therefore, as a first stage, he could engineer a "desymbioting" missile composed of an exploit together with the code to restore all those control points to normalcy. Such code would contain a long list of memory locations (easily compressible with a delta strategy) together with the content to poke therein.
If such code were to execute between a Symbiote check and the next, and if it did not trigger inside a Symbiote execution call (which would probably result in a crash), then all Symbiotes in the target system would be rendered inert. This probably poses an upper bound to what a Symbiote may do between two consecutive calls to its Manager - calls must be lean and fast, in order to detect the incoming attack before it has completely deployed.
Using actual numbers from the paper, around 75K functions are deemed to be useable by the Doppelganger symbiote. This is likely to require 75k addresses and 75k DWORDs (presumably) to be defused. 75k addresses in 35 Mb of space are about half a kilobyte apart on average. It is also likely that the hooked areas have a reduced variability - i.e., they are very similar preamble codes. In this case the attacker would need to transfer only about 75k address deltas - around 150 Kb - and maybe the same amount of data. Processing 300 Kb of information isn't going to need a very long time, and a 300 Kb attack package, while awkward, is not unreasonable.
Possibly, the Symbioting operation might also perform some polymorphic surgery on the host OS, to increase the data required by the attacker for a "blind restore". This would require the injector not to be OS agnostic, though. The Manager might choose a large branchless code section between two of its activation points, and replace it with another emergency activation mechanism. The first activation point would set it back to the original code, which would execute, and would be again replaced by the emergency code by the second activation call. If the attacker were to remove all activation points, the emergency code would never get swapped out, the next execution cycle would activate it, and the attack would be thwarted.
While the number of suitable code sections might be comparatively small, the attacker finds himself against a sort of Merkle puzzle - he does not know which code section has been booby-trapped, so he has to process all code sections; and they are large. This inflates the code size requirements for a successful attack, bringing it back towards the unfeasible value of "a copy of the original unSymbioted image".
