Why is 2.0.0 on the PSGallery but not on Github?

[cs-shadowbq]

The current release show 1.1.33 as latest

https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools/releases

The PS Gallery has 2.0 published with an alpha as well..

https://www.powershellgallery.com/packages/NtObjectManager/2.0.0

[tyranid]

I will release the code soon, it's in the middle of a significant refactor. However I needed to put up a version of 2.0 for the early release of my book which will use the module.

[cs-shadowbq]

2.0 change log ..had breaking changes.. (no surprise hence 2.0.. but a change log would of been nice)

WTF-WFP was downstream of this PSM

https://zeronetworks.com/blog/wtf-is-going-on-with-wfp/

Unable to find type [NtApiDotNet.Net.Firewall.FirewallLayerGuids].
At C:\Program Files\WindowsPowerShell\Modules\wtf-wfp\1.0.4\wtf-wfp.psm1:805 char:34
+ ... $layerslist = @([NtApiDotNet.Net.Firewall.FirewallLayerGuids]::FWPM_L ...
+                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (NtApiDotNet.Net...ewallLayerGuids:TypeName) [], RuntimeException
    + FullyQualifiedErrorId : TypeNotFound

Unable to find type [NtApiDotNet.Net.Firewall.FirewallConditionFlags].
At C:\Program Files\WindowsPowerShell\Modules\wtf-wfp\1.0.4\wtf-wfp.psm1:823 char:5
+     [NtApiDotNet.Net.Firewall.FirewallConditionFlags]$flags,
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (NtApiDotNet.Net...lConditionFlags:TypeName) [], RuntimeException
    + FullyQualifiedErrorId : TypeNotFound

[tyranid]

Yeah, well sorry about that, I at least should have put in a warning in the release notes. That said supporting anything outside of the exported cmdlets has never been my intention, the ability to use the NtApiDotNet library is just a sometimes useful byproduct and shouldn't be relied upon. As in, any script which worked before in v1 and only used the exported cmdlets should hopefully still work in v2, but obviously if you access internal classes I don't make any guarantees.

You could specify in your module that you rely on a specific version of the NtObjectManager module, not sure how well that works in practice.

Unfortunately the v1 branch is basically dead, anti-virus detections killed it. It required a substantial refactor to try and make the detections go away. Some things might not have been required such as changing the main module's name but I thought best to do it one go (this seems to be what has failed for you, going from NtApiDotNet to NtCoreLib). While I was at it a more substantial refactor of the structure is being undertaken which might change things even more.

[cs-shadowbq]

Interestingly, there are parts of this that might be extracted for more generalized access. The generalized access may be abused less. Specifically a smaller scope that could be combined to make the [sandbox-attacksurface-analysis-tools]. I say this because the full tool is very powerful, but Im focused on the pure WFP api portion.

[tyranid]

Certainly it might make sense to pull out what you specifically need into your own library to provide with the PowerShell code, although not sure how easy that would be. You could also ship a copy of NtApiDotNet.dll with the module. I think the main problem with AV is around code linking to the library not necessarily the library itself so it probably won't be detected by AV.