java starts throwing shit when nmap finished

[GoogleCodeExporter]

java starts throwing shit when nmap finished

[GoogleCodeExporter]

Look at question 4 from the FAQ (it's new, after you wrote this ticket):

http://www.fastandeasyhacking.com/faq

Follow those steps and provide the information requested to me. Basically 
Metasploit is crashing. I suspect it's an environment issue. Maybe it's an MSF 
issue, I don't know. :) The FAQ item will tell you what to do to get a 
Metasploit crash dump to me. Similar to what this guy did: 
http://code.google.com/p/armitage/issues/detail?id=13

Original comment by [email protected] on 15 Dec 2010 at 1:30

[GoogleCodeExporter]

I've created a jar file with some debug code. It's at: 
http://armitage.googlecode.com/svn/trunk/release/armitage-unix/armitage.jar

Execute Armitage with java -jar armitage.jar -d. Do your normal stuff, it'll 
create a debug.log file in the current directory. Go ahead and email that to 
[email protected]. Try to reproduce the crash. If you could do it 
twice and send me two debug.log files, that would be all the better. 

The debug.log file will contain some info about your system 
(System.getProperties().toString() in Java) and a log of the entire 
conversation between Armitage and MSFRPCD.

Original comment by [email protected] on 16 Dec 2010 at 11:52

[GoogleCodeExporter]

I think I've reproduced and fixed this error (hard to believe after all of our 
back and forth). Here's what happened:
When MSFRPCD is under load (e.g., during a db_autopwn or some combination of 
heavy crunching), Armitage may timeout during a read operation. When this 
happens, the next read from Armitage will read what the timed-out read was 
supposed to get. This will cause Armitage to get all screwed up as it will be 
receiving data it doesn't expect when calling into Metasploit. I modified the 
code so that Armitage doesn't timeout on reads. I've also updated the -d 
command-line flag to log Java stack traces to debug.log too. You can grab the 
fix out of subversion (it's checked in now) or download the updated jar 
tomorrow.

Oh PS, I highly recommend using PostgreSQL over MySQL if possible. PostgreSQL 
seems to have better throughput with requests than MySQL. I don't know where 
the bottleneck is, but PostgreSQL is a clear winner over MySQL when it comes to 
Metasploit.

Original comment by [email protected] on 22 Dec 2010 at 2:42

• Changed state: Fixed