[framework] Running Framework2 and Framework3 for Windows on the same box

[Tomas L. Byrnes]

Probably the smartest solution would be to create a VMWare community
appliance of MSF. It would ease support issues too.
 
Metasploit is part of some of the appliances:
 
http://www.vmware.com/vmtn/appliances/directory/348
 
http://www.vmware.com/vmtn/appliances/directory/122
 
http://www.vmware.com/vmtn/appliances/directory/165
 
For those who don't know: VMWare player is free, and these pre-built
appliances let you get a custom environment up and running immediately.
The advantage is it's totally segmented memory space running its own OS.
Solves all those nasty Windows compatibility issues.
 
More @ www.vmware.com
 
And no, I don't work for VMWare/EMC at all. Just really like their
stuff.
 
 

________________________________

From: Bob Davies [mailto:tyggerbob at gmail.com] 
Sent: Wednesday, December 06, 2006 10:24 AM
To: framework at metasploit.com
Subject: Re: [framework] Running Framework2 and Framework3 for Windows
on the same box


Thanks, HD.
I appreciate the detailed response.
I'll get around it by setting up a couple small VM's one with MSF2 and
one with MSF3.  That should get me through.
Take care.
Bob


On 12/6/06, H D Moore <hdm at metasploit.com> wrote: 

	To clear up some confusion, this is how it works:
	
	* Cygwin creates a share memory page using a magic ID value. If
another
	copy of Cygwin tries to load (regardless of version), it dies
with an
	error. If you run more than one Cygwin application at the same
time, they 
	need to use the same copy of Cygwin and the same root
filesystem.
	
	* Metasploit 2 uses a Cygwin1.dll that reads the 'Msf200'
registry path to
	determine the file system location of the Cygwin root.
	
	* Metasploit 3 uses a Cygwin1.dll that reads the 'Msf300'
registry path
	determine the file system location of the Cygwin root.
	
	Copying one version of Cygwin1 from MSF3 to MSF2 won't work
since the
	filesystem path would be incorrect for MSF2 (it would actually
launch 
	MSF3 in most cases).
	
	Creating a single version of Cygwin for all Metasploit versions
would
	solve this, but I ran into incompatibilities between the version
of Perl
	used in 2.x and the newer Cygwin.
	
	Using a plain old unmodified Cygwin environment would work, but
then the
	installer would tromp all over an existing Cygwin installation
and it
	becomes difficult to install/uninstall like a normal
application.
	
	The solution is to only run a single Cygwin instance at the same
time. To
	run Metasploit 2, make sure that Metasploit 3's Cygwin is not
loaded. The
	same applies to using Metasploit 3 if you have 2 loaded. Any
other system 
	application that uses its own copy of Cygwin will also cause
problems, so
	you may need to start killing off other applications to get
either
	version to work correctly.
	
	So... Cygwin sucks. It was meant as a quick solution until we
resolved the 
	native Perl/Ruby compatibility issues. Perl never progressed to
the point
	where the Framework could really use the native version on
Windows, but
	we still have hope of moving Metasploit 3 to a native
interpreter in the 
	future.
	
	-HD
	
	
	On Wednesday 06 December 2006 07:45, Bob Davies wrote:
	> Anyone have any issues with this?  FW3 runs fine, but FW2
cacks
	> reporting a conflicting cygwin1.dll file.
	> Just checking: 
	> a) if this is doable at all, and if it is
	> b) if I'm the only one having this problem.
	


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://spool.metasploit.com/pipermail/framework/attachments/20061206/3c243372/attachment.htm