Replies: 2 comments 1 reply
-
Hi, I did take a look at that tool you mentioned, wouldn't personally recommend it at all, people with absolutely no security or computer background will use it because it claims to "Fix" or "debloat" Windows, maybe to get 1 or 2 extra FPS in games, they make changes to their systems and when something goes wrong because they removed something that thought was useless because "Chris" said so, now is causing BSOD and then go complain in the online forums or social media that Windows has this problem without mentioning their own wrong doing etc. etc. I've seen that way too many times. SwiftOnSecurity has a nice tweet thread about this Anyway, I moved away from the monolithic design and now using a very modular design just like the WDACConfig module. The reason is that it was first a single script i made for myself but then i kept adding more and more stuff, turned it into a module but still kept the script style execution. In this latest update, there is no longer a script, everything is now interconnected as part of a module and resources are distributed properly with no code duplication. I began converting many of PowerShell codes to C#. The future of this repo is C# for sure and I will keep converting more PowerShell code in the future because C# code allows me to use the same code in PowerShell and as a C# application (like a compiled .exe) and it allows me to use Windows APIs and create high-performance code just like the ones in WDACConfig module. It's like write once and use it in multiple places. All these changes are transparent to the end-user though. There is no change in how the user starts or uses the Harden Windows Security module, so nothing extra has to be done on the user side, everything has been done under the hood to make the transition smooth and invisible. Currently waiting for .NET 9's stable release and after that the current Harden Windows Security's GUI will be overhauled with modern Windows 11 themes and the WDACConfig module will have a complete GUI for all of its features. The target for both of them is by the end of this year. I use CSV files and XML files for non-code resources to separate things, if there is a need then i can switch to JSON format but so far there hasn't been any needs for nested structures that JSON can offer. I use JSON in WDACConfig module though. I also have some surprise new feature for the next update 🙂 So please first check out the new codes and if there's still suggestions for improving them let me know! Thanks |
Beta Was this translation helpful? Give feedback.
-
I do agree with you that these debloat scripts cause more damage to the system than what is available OOBE or even using the built in tools to do something (ofcourse knowing exactly what you are doing). I dont use them myself as well and dont recommend anyoone as well. What I was trying to refer was the modular design and CI setup they had, to compile everything into a single file to run at the end and hoping some of that CI setup could be borrowed here. I do see that the code has been segregated a lot now. Now that .net is into the mix, I believe more CI things will also follow as well. I didnt really pay attention to the WDACConfig module since I dont have any use case for it right now. The hardening module was a little hard for me to follow. The past few PRs for it have really shifted some things. Anyway, thanks for the reply and providing a rough roadmap for things to come. 🙂 |
Beta Was this translation helpful? Give feedback.
-
Hi there,
By now, you must have heard about Chris's winutil utility for installing, tweaking, removing things in windows.
He recently posted a video and at the end of it he mentioned a brief overview of how the codebase is laid out and how it is built.
Now, winutil also has the ability to run without installing just like this hardening script. But, what I found interesting about winutil's codebase is the modularization of each function (including the GUI - more on this later) and easier configurability of functions (using json) and everything is then compiled into a single script by the CI.
Now I know the current code base of hardening module is really well laid out and code itself is written with best practices in mind. But as you are now diving into GUI for hardening and WDACConfig modules, it will increase the overall complexity of the code base. Winutil is using WPF as well (atleast from what I could make out from their code base), and this project is also going to use WPF as well. So maybe some things/ideas can be borrowed from them?
Maybe some of the automation ideas can be borrowed and integrated into this code base? Or making it easier to add/remove/edit existing hardening methods without much effort? Or atleast removing the additional copy-pasting of code into the hardening script (at the root of the code base) at the end every time some changes are made in the modules? 😜
Would love to hear your thoughts on this!
I have many other ideas on making this project better but they might be out of scope for this? Let me know if I should still post them.
Beta Was this translation helpful? Give feedback.
All reactions