How'd you do it?
Looking on the source code have both scripts shows that it will only run on “client.platform =~ /win32|win64”
Checking the variable with IRB shell throws “windows”. Adding “windows” to both scripts solves the issue.
However, I am not sure that this is the right solution.
Kali Linux
version
Framework: 4.13.10-dev
Console : 4.13.10-dev
Kali Linux
It’s important to mention that searching for “client.platform =~ /win32|win64” on Metasploit repository returns 45 results although I’m not sure it is relevant for all.
Also, I am not sure that it only happens on 2012R2
Scripts are no longer supported and are deprecated in favor of post modules. As per my initial assessment in https://github.com/rapid7/metasploit-framework/issues/7789, the enum_vmware script don't have a corresponding post module at the moment. However you can use post/windows/gather/memory_grep instead of the process_dump script in order to dump and grep a pattern from a process memory.
Dang, right as I was about to comment, lol. Thanks, @void-in. Sorry, @ClearGateTeam. That is the correct fix, though. If you want to submit a patch, you're welcome to.
wvu@kharak:~/metasploit-framework/scripts/meterpreter:master$ git grep -E 'win(32|64)' | wc -l
76
wvu@kharak:~/metasploit-framework/scripts/meterpreter:master$
@wvu-r7 You and me have this tendency to pick and comment on an issue at the same time :)
I'm not that familiar with the inner works of Metasploit.
Is there a reason why the client.platform is windows instead of win32 or win64?
Yeah, one sec.
I think it was #7507, @ClearGateTeam. Scripts have been deprecated for literally years now, btw. If you heard about them from Metasploit Unleashed, the advice is a bit dated.
If you're not comfortable submitting a patch, I could fix this quickly, but then there'd be 74 other fixes to make, too... So do we fix these as we go or rm all of them? :P
I think scripts are still useful, but they've largely been outmoded by post modules. While we don't have complete feature parity between the two, we'd like that to happen before we move on scripts.
In my opinion as there are scripts that don't have a corresponding post module yet, it would be great if you can add windows to all of them, what do you think?
p.s - @void-in , I don't think memory_grep post module will assist me as I want to dump the entire memory of a process and not part of it.
@ClearGateTeam: Adding windows to all of them isn't as simple as a search and replace, though. Scripts will need to be refactored. 59 of them, to be exact. That's putting a lot of time into something that's already deprecated. I think we can fix these as we go. What do you think?
ok. didn't know that
@wvu-r7 For those scripts which have the exact functionality available in the post modules. we can literally rm-ed them and there won't be any functionality lost. I am working on the exact functionality parity you mentioned in https://github.com/rapid7/metasploit-framework/issues/7789 to make sure everything is documented when the time comes to get rid of these scripts.
@void-in: Great, thank you. Just trying to be sensitive to people's workflows. :)
@ClearGateTeam: No idea if this would work or not, but notice how it's not a simple search/replace:
wvu@kharak:~/metasploit-framework:master$ git diff
diff --git a/scripts/meterpreter/enum_vmware.rb b/scripts/meterpreter/enum_vmware.rb
index c19a8fb200..64b51eae2c 100644
--- a/scripts/meterpreter/enum_vmware.rb
+++ b/scripts/meterpreter/enum_vmware.rb
@@ -297,7 +297,7 @@ def enum_vmwarewrk
end
end
end
-if client.platform =~ /win32|win64/
+if client.platform == 'windows'
if check_vmsoft
vmware_products = check_prods()
if vmware_products.include?("VMware VirtualCenter")
diff --git a/scripts/meterpreter/process_memdump.rb b/scripts/meterpreter/process_memdump.rb
index 3d8c825364..42f7d46960 100644
--- a/scripts/meterpreter/process_memdump.rb
+++ b/scripts/meterpreter/process_memdump.rb
@@ -147,9 +147,9 @@ def get_mem_usage( pid )
# Note: As we get the raw structure back from railgun we need to account
# for SIZE_T variables being 32bit on x86 and 64bit on x64
mem = nil
- if( @client.platform =~ /win32/ )
+ if @client.arch == ARCH_X86
mem = pmc[12..15].unpack('V').first
- elsif( @client.platform =~ /win64/ )
+ elsif @client.arch == ARCH_X64
mem = pmc[16..23].unpack('Q').first
end
return (mem/1024)
@@ -165,7 +165,7 @@ def get_mem_usage( pid )
end
# Main
-if client.platform =~ /win32|win64/
+if client.platform == 'windows'
if resource
resource.each do |r|
next if r.strip.length < 1
wvu@kharak:~/metasploit-framework:master$
If that took me 5 minutes, and there are 74 other changes to make, then it would take me approximately 6 hours to fix all the scripts, assuming no breaks and consistent complexity, only for the scripts to be removed in the future. No thanks. :(
@wvu-r7 thank you for the explanation.
I just didn't understand yet what is the meaning of windows , can you explain ?
There are some false positives in there, and I rounded down on the time, but you get the point!
@ClearGateTeam: Did you read #7507, which I linked above?
@wvu-r7 not yet.
Well, in short, arch already contains the arch, such as ARCH_X86. No need to put it in platform like win32, so windows became the new thing. It's more consistent, it's more correct, and it allows for new features @OJ has been working on.
(That's my personal understanding. Please correct me if you had other reasons, @OJ. :)
Checking for client.platform == 'windows' isn't enough these days either :) Having the platform set to windows rather than win32, for example, was done for a few reasons. The main one being that arch was already in the client.arch, and so was rather redundant. However, the platform can be set to windows for php and python payloads as well. If you want to check for a native meterpreter on windows you need to make sure that the platform is windows and that the arch is either ARCH_X86 or ARCH_X64. An example of this is here: https://github.com/rapid7/metasploit-framework/blob/master/scripts/meterpreter/persistence.rb#L229
As far as updating all the scripts goes, that's not going to happen any time soon. If you want this particular script to be updated, feel free to modify it and submit a PR. However, as already alluded by others, these scripts are deprecated in favour of post modules. If there's no post module that does what you're looking to do, then... the same process applies :)
@OJ ok I understand
I'm closing this out. If you feel the need to update the two scripts, @ClearGateTeam, send a patch! It's pretty easy. :)
Most helpful comment
Checking for
client.platform == 'windows'isn't enough these days either :) Having the platform set towindowsrather thanwin32, for example, was done for a few reasons. The main one being that arch was already in theclient.arch, and so was rather redundant. However, the platform can be set towindowsforphpandpythonpayloads as well. If you want to check for a native meterpreter on windows you need to make sure that the platform iswindowsand that the arch is eitherARCH_X86orARCH_X64. An example of this is here: https://github.com/rapid7/metasploit-framework/blob/master/scripts/meterpreter/persistence.rb#L229As far as updating all the scripts goes, that's not going to happen any time soon. If you want this particular script to be updated, feel free to modify it and submit a PR. However, as already alluded by others, these scripts are deprecated in favour of post modules. If there's no post module that does what you're looking to do, then... the same process applies :)