Get-NtSystemInformation now returns SystemCodeIntegrityInformation -
i.e. user-mode code integrity settings. This required reverse
engineering a dll that is only present on Windows 8 ARM devices.
See https://github.com/mattifestation/PowerSploit/pull/6#issuecomment-19289063
1) I like this feedback a lot and took it.
2) I tried going thread only but it got messed up with very large scans. Eventually,
I didn't think it was worth the amount of effort to make it reliable with only threads
3) Tried to do this
4) Did this
5) I like the idea in general and I took this one place (top-ports), but not for the two
examples you gave. The reasoning is, I want people to be able to specify various options
and arrays aren't that flexible. For example, I want people to specify a port list like
"80,90,8080-8090". Similar with CIDR, since that's one option, but they could also be
specifying hostnames e.g. "google.com,192.168.1.1/24,10.0.0.1"
Another awesome addition from Joe Bialek. Invoke-ReflectivePEInjection
is a vast improvement over Invoke-ReflectiveDllInjection. It adds the
following features:
* Now supports loading exe files in memory
* Supports reflective dll injection into a remote process
* Additional sample Visual Studio solutions
Get-NtSystemInformation is a wrapper function for
NtQuerySystemInformation. It is a swiss-army knife tool for obtaining
internal OS information. It can currently be used to query the
following: global flags, handles, objects, kernel pool allocations, and
loaded kernel modules
ConvertTo-String converts the bytes of a file to a string that has a
1-to-1 mapping back to the file's original bytes. ConvertTo-String is
useful for performing binary regular expressions.
Updated code to use [System.IO.FileStream] class with a buffer (64kb
default) to greatly increase performance, especially when handling large
files.
Updated $EndBytes validation logic to change it to a valid value rather
than throw an error.
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.