MSP-11147
Sometime travis-ci is showing leaked threads even when
'Msf::Framework#threads cleaner' is being used, so I'm adding the
`Thread#status` to the data printed about the Thread to see if the
sometimes leaked threads have an odd status. There's still a chance
that there will be a race-condition between when I call Thread.list and
I ask for each Thread's status that the VM could finish aborting a
Thread so that status I print isn't the same as the one that caused the
Thread to be returned in Thread.list.
The exploit works with the URLs fixed, installs the APK, but hangs at the Installing...
screen and never actually launches. We tried opening the APK in a setTimeout() intent
URI, but the previously launched intent seemed unresponsive. Andre had the bright
idea of re-opening the previously launched intent with invalid args, crashing it and
allow us to launch the payload.
So I was looking at issue #4162, and on my box I was seeing this
problem of the exploit failing to delete the payload in C:\Windows,
and the error was "Rex::Proto::SMB::Exceptions::NoReply The SMB
server did not reply to our request". I ended up removing the sleep(),
and that got it to function properly again. The box was a Win 7 SP1.
I also tested other Winodws boxes such as Win XP SP3, Windows Server
2008 SP2 and not having the sleep() doesn't seem to break anything.
So I don't even know why someone had to add the sleep() in the first
place.
MSP-11614
`Msf::TaskManager` was only used for `Msf::DBManager#sink`, which was
removed because it was unused, so `Msf::TaskManager` can also be
removed.
MSP-11614
`Msf::DBManager::Sink` contains code for a `sink` that is a meant to
serialize database events, but it's unneeded because all database events
go directly through ActiveRecord, which handles threading.
MSP-11605
The `framework` from 'Msf::Simple::Framework' shared context is not
guaranteed to make threads with `framework.threads` anymore, so the
cleaner shouldn't allows be present in 'Msf::Simple::Framework'.