cleanup record_mic handler, use the right heap for freeing

[bcook-r7]

Problem

Currently, if you use the record_mic command and change the record duration, when the memory buffer is reallocated, garbage is passed as the heap pointer, causing a crash. This fixes the arguments and does a bit of code tidying at the same time. https://github.com/rapid7/metasploit-framework/pull/5460 has the minor framework fix for allowing longer durations than a few seconds.

Validation Steps

• [x] Using the metasploit-framework PR above, setup a meterpreter session and..
• [ ] Record 10 seconds via 'record_mic -d 10'
• [ ] Record 60 seconds via 'record_mic -d 60'
• [x] No crashes

[metasploit-public-bot]

Test PASSED. Refer to this link for build results (access rights to CI server needed): https://ci.metasploit.com//job/GPR-MeterpreterWin/200/ Test PASSED.

[OJ]

Finding the recording a little hit and miss:

msf exploit(handler) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > record_mic 10
[*] Starting...
[-] Error running command record_mic: Rex::TimeoutError Operation timed out.
meterpreter > record_mic -d 10
[*] Starting...
[*] Stopped
Audio saved to: /home/oj/code/metasploit-framework/HILiFTXb.wav
meterpreter > record_mic -d 10
[*] Starting...
[-] Error running command record_mic: Rex::TimeoutError Operation timed out.
meterpreter > record_mic -d 30
[*] Starting...
[-] Error running command record_mic: Rex::TimeoutError Operation timed out.

I'm using the Meterp PR, and from what I can tell that's behaving as it should. I'm wondering if the response duration should be increased even more, given that the resulting download will take some time as well?

[bcook-r7]

Yeah, should perhaps delay 2x the record duration then. I didn't realize timeout would occur even if the response was in flight.

[busterb]

This has hung out long enough, I'm going to close it and move to metasploit-payloads.