My original plan was to start a thread in __init__() and stop the thread
when __del__() was called. Since the running thread (object) contains a
reference to the BatchingTelemetryMessenger object that launched it, the
destructor will not be called until the thread is stopped. This
resulted in adding a stop() method (fadd978) followed by adding a
start() method (1d066c8e).
By using an inner class to run the thread, we enable the class to be
used as originally intended, reducing the burden on the user of this
class. The thread is now started on construction and stopped on
destruction. The user can remain blissfully unaware that anything
resembling threading is going in, and can use the
BatchingTelemetryMessenger just like any other ITelemetryMessenger.
My original plan was to start a thread in __init__() and stop the thread
when __del__() was called. Since the running thread (object) contains a
reference to the BatchingTelemetryMessenger object that launched it, the
destructor will not be called until the thread is stopped. Therefore, a
stop() was added to allow the BatchingTelemetryMessenger to be stopped.
Since it has an explicit stop, it should also have an explicit start,
rather than starting the thread in the constructor.
We don't want the ransomware payload to encrypt all files and then send
telemetry to the island. This could lead to a long period of time where
the user has no insight into what the monkey is doing on a node. We also
don't want to flood the island with telemetries. By using the
BatchingTelemetryMessenger, ransomware encryption telemetries are
batched together and periodically sent to the island.
The term "wrapper" is sometimes used as synonym for the decorator
pattern, whereas this class is a textbook adapter. Use the term
"adapter" instead of "wrapper" and rename "TelemetryMessengerWrapper" to
"LegacyTelemetryMessengerAdapter", as this class servers as an adapter
between the new ITelemetryMessenger interface and the (soon to be) legacy way of
sending telemetry.
IBatchableTelem adds two methods to the ITelem interface. These methods allow
a telemetry object to mange batches of telemetry entries, rather than
just one.
The telemetry classes have too many responsibilities. At the moment, one
such responsibility is to send themselves to the island. As our plugin
interfaces develop, the need may arise to send telemetry using different
mechanisms. To isolate the RansomwarePayload from these changes, the
ITelemetryMessenger interface is introduced in this commit. It provides
a send_telemetry() method that handles the specific details of how
telemetry is sent to the Island.
At the present time, the TelemetryMessengerWrapper class is introduced
to handle sending telemetry. It simply wraps the existing send() method
on the telemetry class.
Mike Salvatore
Shreya