View Issue Details

Category
SSPBT:本体(SSP)
SeverityfeatureReproducibilityN/A 
Status closed 
Summary0000354: Modify or add a new uninstall mode to allow ghost to do something after it has been uninstalled
DescriptionHere's the thing, I've written a new saori to allow my ghost to trigger Blue Screen Of Death harmlessly, and I've designed this feature to be used for touching sensitive parts at low intimacy, and for certain special uninstallation gigs
But, you know, ghost can't do anything after \![vanishbymyself]
And if you trigger Blue Screen Of Death before uninstalling ghost it just stops everything , as a result ghost is not uninstalled

I was wondering if it would be possible to devise an uninstall mode that just moves ghost to another temp folder and keeps ghost running until ghost quits on its own?
TagsNo tags attached.
Attach Tags

Activities

ponapalt

2021-11-13 19:24

administrator   ~0000916

Last edited: 2021-11-13 19:31

What you're looking for is the same behavior of malware.
There was a ghost who had done something similar bad thing before, and had gotten into serious trouble.
Even if it's a joke, I won't help you do such a thing, and if you do, I will do my best to resist.

I'll say it again in a different way : **NEVER DO THAT. I'VE WARNED YOU.**

guest

2021-11-14 02:37

reporter   ~0000917

Just to clarify, I just want to make my ghost show a bit more flashy: the ghost will uninstall itself when the user meets certain conditions, and the user cannot run the ghost again on this computer by reinstalling it: it will just uninstall itself and trigger a harmless blue screen, and the user can just restart the computer and continue using his computer normally, without any loss to the user

If I wanted to do what malware does, I wouldn't come in and try to standardize the process, but release the watcher to system or something

guest

2021-11-14 03:29

reporter   ~0000918

Not the reporter.
Triggering a blue screen and forcing a restart means that the user may lose unsaved work, potentially very important work or something that has not been saved for hours. That is not harmless.
No ghost should have this behavior; it makes ghosts as a whole untrustworthy, and undermines the efforts of other developers to share their ghosts with a wider audience.

guest

2021-11-14 09:29

reporter   ~0000919

Many editors have an auto-save feature, and the user loses at most ten minutes of work progress if they are working on something else while installing back into a ghost that has been uninstalled several times

I have always considered a slightly disruptive interaction to be a type of interaction, and I have mentioned the possible consequences of this ghost in my disclaimer

Anyway, if it doesn't work I'll finish the uninstall by releasing a watcher to the system, which will leave a few dozen kilobytes of uninstall residue, that's all.

guest

2021-11-14 09:55

reporter   ~0000920

Hey man, while I can probably understand where you're coming from, why do you have to insist on uninstalling ghost first and then triggering the blue screen?
I mean, if you just trigger the blue screen every time the ghost starts, the user will uninstall the ghost themselves

ponapalt

2021-11-14 10:09

administrator   ~0000921

Last edited: 2021-11-14 10:24

If you want to block ghost reinstall, you can implement function checking OnFirstBoot reference0 > 0, which is uninstallation count, then just execute \\![vanishbymyself] to remove. It's proven, stable, and safe method. Although it does not prevent the installation process itself, it has a similar effect.

I think it's very bad idea, not only triggering BSoD, but also hide something in somewhere after uninstallation. These are both malware-like behavior.
This principle is not a technical limitation, because win32 unmanaged DLL can run anything anywhere, but it is based on the minimum necessary trust between users and developers.

That's why I used fierce language using all-caps.
I don't want to see another trouble involving anti-malware software companies, as happened before in Ukagaka community.

guest

2021-11-14 11:00

reporter   ~0000922

for: #c920
Some users may have set ssp as a boot-up program, which can cause blue screen triggering when the computer boot.
Some users may not know how to delete the ghost manually and this ghost may be used by ssp as the default startup ghost
I just want to do a proper gig, not wreak havoc

for: #c921
I'm still looking for a way to get ghost to uninstall itself before triggering BSoD, what I'm missing is not how to determine that ghost has been reinstalled, XD
Leaving some things behind may be unavoidable, but I'll try to leave everything as it is

guest

2021-11-14 14:23

reporter   ~0000923

To uninstall your ghost by itself:
1. Get the disk letter of the folder where ghost is located
2. Move to the $RECYCLE.BIN folder
3. anything else
4. \-

Dons't need for any watcher, I think

guest

2021-11-14 16:09

reporter   ~0000924

for: #c920

1. cannot be moved to the $RECYCLE.BIN folder or its subdirectories by the move command, access will be denied
2. You cannot move a folder containing a dll in use to the recycle bin via the SHFileOperation function, access will be denied.

In summary: watcher is still needed

guest

2021-11-14 18:15

reporter   ~0000925

I've looked through some of the documentation and so far I can't find any way to do it without the so-called "watcher" and let the ghost continue to do something after it has been deleted.
My suggestion:
1. it is best to abandon the blue screen.
2. consider corrupting shiori instead of deleting ghost: this will not harm the others, but will also serve the purpose of making ghost unusable.
3. when you have ghost and ssp on the same drive, you might consider moving the files to ssp/temp/ssptmp, which will be emptied every time ssp exits.

guest

2021-11-15 01:43

reporter   ~0000929

Thanks guys, I probably know what to do
thx again

ponapalt

2021-11-21 05:05

administrator   ~0000943

close

Issue History

Date Modified Username Field Change
2021-11-13 12:25 guest New Issue
2021-11-13 19:24 ponapalt Assigned To => ponapalt
2021-11-13 19:24 ponapalt Status new => closed
2021-11-13 19:24 ponapalt Resolution open => not fixable
2021-11-13 19:24 ponapalt Note Added: 0000916
2021-11-13 19:31 ponapalt Note Edited: 0000916
2021-11-14 02:37 guest Status closed => feedback
2021-11-14 02:37 guest Resolution not fixable => reopened
2021-11-14 02:37 guest Note Added: 0000917
2021-11-14 03:29 guest Note Added: 0000918
2021-11-14 03:29 guest Status feedback => assigned
2021-11-14 09:29 guest Note Added: 0000919
2021-11-14 09:55 guest Note Added: 0000920
2021-11-14 10:09 ponapalt Note Added: 0000921
2021-11-14 10:10 ponapalt Note Edited: 0000921
2021-11-14 10:11 ponapalt Note Edited: 0000921
2021-11-14 10:12 ponapalt Note Edited: 0000921
2021-11-14 10:14 ponapalt Note Edited: 0000921
2021-11-14 10:17 ponapalt Note Edited: 0000921
2021-11-14 10:22 ponapalt Note Edited: 0000921
2021-11-14 10:24 ponapalt Note Edited: 0000921
2021-11-14 11:00 guest Note Added: 0000922
2021-11-14 14:23 guest Note Added: 0000923
2021-11-14 16:09 guest Note Added: 0000924
2021-11-14 18:15 guest Note Added: 0000925
2021-11-15 01:43 guest Note Added: 0000929
2021-11-21 05:05 ponapalt Status assigned => closed
2021-11-21 05:05 ponapalt Note Added: 0000943