Adding Invoke-ReflectiveDllInjection. PowerSploit now has reflective DLL
loading capabilities!!! Thanks to Joe Bialek @JosephBialek for writing
this awesome code!
Get-MethodAddress was not working correctly in 32-bit PowerShell because
it was returning a [UInt64] value when it should have been a [UInt32].
This fix will detect if PowerShell is running as 32 or 64-bit and define
its return type accordingly.
After parsing a PE header with Get-PEHeader, you now have the option of
downloading the original executable from Microsoft's symbol server for
reference/comparision.
* I unfortunately needed to change the names of Inject-Shellcode and
Inject-Dll to Invoke-Shellcode and Invoke-DllInjection in order to
confirm to proper verb naming.
* All scripts used to prepare and/or modify payload scripts were added
to the ScriptModification module.
* Added Remove-Comments - Strips comments and extra whitespace from a
script.
* Encrypt-Script was named to Out-EncryptedScript in order to conform to
proper PowerShell verbs.
* Now that PETools and ReverseEngineering are both full-fledged modules
with proper manifests, the manifests will take care of loading the
appropriate ps1xml files.
* Added Usage.txt to ReverseEngineering module.
* I renamed RE_Tools to ReverseEngineering and made it a module.
* Slight consistency modifications were made to documentation.
* This is one step in the process of modularizing all of PowerSploit.
* Renamed Prepare-Payload to Out-EncodedCommand in order to conform to a
standard cmdlet verb.
* Fixed bug in PowerShell v2
* Defaults to full base-64 encoding unless it exceeds the cmd.exe
character limit. Otherwise, it will default to partial base-64 encoding
in an effort to save space. Thanks @Carlos_Perez for the idea!
* User will be prompted if the cmd.exe character limit is exceeded.
* Command-line output uses truncated arguments in order to save space.
Thanks @obscuresec!
* Some payloads were not decoding properly after being uncompressed.
This was due to a bug in how `Get-Content -Encoding ASCII` was
interpreting input. When reading a script from a file, Prepare-payload
no longer makes any assumptions about the script's encoding.
* Prepare-Payload will display a warning if the cmd.exe or base64 string
length maximums are exceeded.
Marshals data from an unmanaged block of memory in an arbitrary process
to a newly allocated managed object of the specified type. In other
words, it will parse and return a structure at a known memory address in
any process.
* The script now silently continues if the ps1xml file is not present.
* Removed compiler parameter code. This was a remnant of the first
version of Get-KernelModuleInfo when it compiled code.
* Improved the heuristics for determining when the last kernel module is
encountered.
Prepare-Payload compresses, Base-64 encodes, and generates command-line
output for a PowerShell payload script. This script was inspired by and
an improvement upon createcmd.ps1
(https://www.trustedsec.com/files/PowerShell_PoC.zip)
Updated Inject-Shellcode. If running a 32-bit Metasploit payload from
64-bit PowerShell, it will prompt the user to execute the payload from
32-bit PowerShell. This fix was in response to Chris Gate's feature
request:
http://carnal0wnage.attackresearch.com/2012/05/powershell-shellcode-metasploit-x64.html
Note, there are some side effects:
1) It takes about one minute to initialize and execute the payload in
the 32-bit process. This is because the execution essentially emulates
copying and pasting its contents into the child process.
2) You will see some output artifacts of the script running in the child
PowerShell process.
I couldn't think of a good way to rectify these problems without
dropping the contents of the script to disk, which would not be
desireable.
Matt Graeber