Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG]: Error Running Script #351

Closed
giogio33 opened this issue Apr 27, 2024 · 3 comments
Closed

[BUG]: Error Running Script #351

giogio33 opened this issue Apr 27, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@giogio33
Copy link

giogio33 commented Apr 27, 2024

I disabled all antivirus and protection. Ran also as Administrator. I also tried in safe mode with networking. 80GB free on the disk.
This image was cleaned with Tweaking.com. Seems to run perfectly. It has been just upgraded from Win10-20H2 to Win10 22H2.
The only issue this image seems to have is that I have a windows security update failing after all upgrades and chose not to longer upgrade. Microsoft.

Description

I get Error Running Script, Fully Control on AppData\Roaming\privacy.sexy\runs and I tested it

OS

Win 10 Pro 22H2 (OS Build 19045.4355)

This image on 22H2 did not give me error prior upgrade to 22H2 from 20H2
I restored it to an image I had of the 20H2 prior running Privacy sexy, so it was clean

Reproduction steps

I also tried to only select Clear recently Opened application list and if gives error. This image on 22H2 did not give me error prior upgrade to 22H2

Scripts

If applicable, please attach the generated privacy.sexy file instead of copy pasting which becomes too long.
privacy-script.log

2024-04-27 14_20_16-privacy sexy - Maximize Your Privacy and Security

Additional information

main.log

@giogio33 giogio33 added the bug Something isn't working label Apr 27, 2024
@undergroundwires
Copy link
Owner

Hi @giogio33, thank you for all the context.

The logs show that:

  1. Privacy.sexy is creating the script file, it's reading it back to trigger an antivirus to see if antivirus will delete it.
  2. Privacy.sexy verifies that security scan was made possible and its not deleted.
  3. It attempts to run the file, but can no longer find the file.

Some questions to understand whats going on:

  1. Can you see any file at AppData\Roaming\privacy.sexy\runs? Which files do you see?
  2. Do you run any other antivirus / security software other than Windows Defender?
  3. Are you running Performance Mode docs 1, docs 2 on Defender?
  4. Can you try running after turning of Real-Time protection?

@giogio33
Copy link
Author

Thank you for your reply.

In the AppData\Roaming\privacy.sexy\runs I see all generated scripts batch files.

Performance Mode I read is for Windows11 and I have Win10-22H2. Is that correct then I don't have it?

I turned off Emsi-Antivirus Software and in windows security I get the following (screenshot) without rebooting and still privacysexy won't run. I may tray something deeper but I cannot for a couple of weeks. I'll get back to you with it.
2024-04-28 14_44_09-Windows Security

@undergroundwires
Copy link
Owner

Thank you for all of the information. It helped to eliminate other factors and I found out the problem.

privacy.sexy runs this files using powershell.

It sends the script path in double quotes as argument to powershell using double quotes to handle whitespaces in paths.

However for some reason, PowerShell strips away double quotes when it parses arguments, and fails when you have whitespace in script path (your user name in that case). See StackOverflow thread on this.

I set up a user with whitespace in its name and I can reproduce the issue.
I see that this can be resolved using double quotes + single quotes, double double quotes, using " instead of double quotes etc etc.

I will solve this in next patch. Thank you again for the guidance and bug report.

undergroundwires added a commit that referenced this issue May 7, 2024
This commit addresses the issue where scripts fail to execute on Windows
environments with usernames containing spaces. The problem stemmed from
PowerShell and cmd shell's handling of spaces in quoted arguments.

The solution involves encoding PowerShell commands before execution,
which mitigates the quoting issues previously causing script failures.
This approach is now integrated into the execution flow, ensuring that
commands are correctly handled irrespective of user names or other
variables that may include spaces.

Changes:

- Implement encoding for PowerShell commands to handle spaces in usernames
  and other similar scenarios.
- Update script documentation URLs to reflect changes in directory
  structure.

Fixes #351
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants