Something about adjustment of minimum system requirement I want to adjust the minimum system requirement of NSudo for avoiding the insecure library loading by using the SetDllDirectory and SetDefaultDllDirectories APIs. So the new minimum system requirement is: Windows 8 or later, Windows Server 2012 or later. If you want to use NSudo in Windows Vista and Windows 7, Windows Server 2008 and Windows Server 2008 R2, the KB2533623 should be installed first. I want to know the public opinion about the minimum system requirement before I change it. Kenji Mouri
Sorry for the noob question - how do you remove the entire FOLDER using nsudo? You must have permission. PPM - no option on the folder. Only on files. Take Ownership does not work.
hi there, mouri_Naruto, a few things, 1, I love your name! reminds me of that lil fella in that manga naruto 2, i'm so happy that you mentioned accessibility, i use nvda a free screen reader, could i test the application please with nvda? please note, nsudo or how ever it's spelled, is very accessible with nvda dism++ on the other hand, the menus are accessible with nvda but progress of opperations are not displayed. another question if you don't mind, is trusted installer and system the only god level accounts in windows? thank you so much for nsudo you are the best
Thank you very much. You can use NSudo even via Windows Narrator. (I know most people need the NVDA because lots of applications can't be operated via Windows Narrator. So they need to install NVDA.) I don't think it's an enjoyable experience for users if they can't use projects via Windows Narrator. So you can obviously use NSudo via NVDA. DISM++ don't support the accessibility because of the UI framework. But I will try my best to solve that. The highest level of access token is the process token of smss.exe. You can get it via NSudo Launcher's "System" user. Mouri_Naruto (Kenji Mouri)
I've been downloading and using NSudo for a few years without any problems; but with the latest version (8.0) I've started seeing browsers and anti-virus software blocking the current download and/or reporting threats in the files. I first noticed this when downloading 8.0 from MajorGeeks last week. But I also see the issue when downloading NSudo directly from GitHub. Both Chrome and Firefox on two different systems (Win10 and Win8.1) are blocking the download by default now. When I override the blocking to download it anyway, I can submit the NSudo zip file to VirusTotal, and find that they report 20 engines detecting threats in the zip file -- nearly half some kind of Trojan. Note that the previous NSudo version (6.2.1812.31) had no such issues. It's only the latest version (8.0) that indicates infections, at least based on VirusTotal. Digging into the NSudo zip file shows three files in the download that are triggering these threat alerts. The most concerning of the three is the Win32 version of NSudoDM.dll, for which VirusTotal lists threats detected by 20 different engines, including BitDefender, McAfee, and TrendMicro among others. And 7 of those 20 threats are listed as Trojans of some sort. The other two files that generate threat reports in VirusTotal are the Win32 versions of NSudoLC.exe and NSudoLG.exe. However, for those two files the threats are detected by only 3 or 4 of the engines, none of which include the major AV vendors listed above. What's changed between version 6.2.1812.31 and version 8.0 for the Win32 architecture that would cause so many different anti-virus products to indicate threats in the 8.0 software?
I don't know why the anti-virus indicate the x86 binaries of NSudo 8.0. (I have report to the Windows Defender and remove it to the threat list.) NSudoDM.dll is the implementation of NSudo Devil Mode, a library for helping developers to operate system files and registry keys under the normal Administrator privilege. Kenji Mouri
I will buy the DigiCert EV Code Signing Certificates for NSudo binaries if everything is OK. (There are lots of things to do.) I hope it can reduce the situation which your said. @Tom-R Also, I hope that can make more people see my sincerity and get more support form others. K.M.
@Thomas Dubreuil Your installer works great but I had an issue when trying to execute it from the folder C:\Téléchargements\NSudo_Launcher_Installer_AIO because of the accentuated letters; similarly a findstr command fails when executing from a folder when the name contains Asian characters. Therefore i brought 2 modifications : Code: Cosmetic change at line 21 for the fun ...: change C:\Users\%USERNAME%\AppData\Local\Temp to %temp% Replace line 56 pushd "%Tmp_Folder%" by pushd "%Tmp_Folder%" & copy /y "%~f0" "%~n0" >nul Replace line 237 (to add house cleaning) <nul set /p dummyName=Press any key to exit...%show_cursor% by call :Clean_Tmp_Folder & <nul set /p dummyName=Press any key to exit...%show_cursor% Replace line 293 set "fsrc=%~f0" by set "fsrc=%~n0" This could be improved, but it works.
@rpo Thanks Thats totally right :Clean_Tmp_Folder should be called in :Install_Success instead :Uninstall_Support For %temp% I tend to use %username% because I'm always thinking people could mess with their system variables, I am curious what is the consensus about this? (what is considered safest/most bulletproof : %temp%, %userprofile% etc? ) I will add your corrections Main thing I wanted to improve are responsivness of the "vista style" folder selector (the basic/usual folder selector is very bad imho) it was long investigation and task, some C ported to ps, and in the script it is decoded and ran as a .ps1 On my system this choice is faster than echo the .ps1 or than batch/ps chimera (+ the fact I can not obtain good compression with hybrid bat/ps due to the # character in encoded binaries) Still the explorer window takes a second or 2 to launch, while crappy folder selector load in an instant...I chose cosmetic And last thing maybe add few extensions, and double check the registry codes, one I tested wasn't elevating correctly ( might be .ps1) Anyway thanks for the tips, appreciated.
In fact, I was just wondering why you use %TEMP% at line 20 but C:\Users\%USERNAME%\AppData\Local\Temp at line 21. BTW, when the Rebuild failed, imho, it would be better to exit the script (with a pause command),and not only the Rebuild function.