Disk Investigator has shown me that some of my passwords are showing
on my C: drive.

http://theabsolute.net/sware/dskinv.html

I think their being there might be related to my sometimes
copy/pasting passwords into a program. I might have missed clearing
them from the clipboard after usage. Just guessing on that one.

Is there a program which would allow me to erase/delete those
passwords?

Nomen,

You have not told us /where/ DI found those passwords.

A simple file ? Check who it belongs to and see if "something bad"(tm) will
happen if you would decide to delete it.

The pagefile ? THat would be a bit of a problem, as you should not try to
delete it on a running OS (could and normally does crash and damage the OS).

A disk sector not at all connected to anything (free to use by the FS
if-and-when it needs a new one) ? You could try to find an "unused sectors"
disk eraser.

Any other sector (part of the filesyste but not part of a file) ? Well,
that would be a bit of a problem ...

You've got a number of possibilities, all having their own solutions

> Is there a program which would allow me to erase/delete
> those passwords?

As you can tell by the above, its not that easy.

.... But I guess you could securily wipe the whole drive and re-install the
OS. :-)

Regards,
Rudy Wieser

On 5/10/2022 11:48 AM, Nomen Nescio wrote:
> Disk Investigator has shown me that some of my passwords are showing
> on my C: drive.
>
> http://theabsolute.net/sware/dskinv.html
>
> I think their being there might be related to my sometimes
> copy/pasting passwords into a program. I might have missed clearing
> them from the clipboard after usage. Just guessing on that one.
>
> Is there a program which would allow me to erase/delete those
> passwords?
>

The passwords would either be in a valid file, or
the passwords could be in "white space", the space
between files.

https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete

sdelete -z C: # 32 bit OS, clean white space on C:
sdelete64 -z C: # 64 bit OS, clean white space on C:
# If on some other partition, change the C:
# to the desired drive letter.

However, the minimum OS requirement is Vista on the current one.
Why exactly, I don't know.

On NTFS, small files are stored inside the $MFT itself.
Sdelete has some mechanism to clean in those crevasses.
The mechanism requires a second pass. The first pass,
is bulk white space cleaning (which cannot clean $MFT).
The second pass, cleans the small file storage area.
Like a dinner fork, there are "spaces between tines" and
that's what the second pass cleans. Small files, naturally,
are used to hold passwords.

https://www.trishtech.com/2010/02/permanently-delete-files-in-windows-xp/

# Vista or later
https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete

# 32-bit for WinXP
https://web.archive.org/web/20101207031537/http://download.sysinternals.com/Files/SDelete.zip

That's a time consuming process, so it would be nice to know
exactly where the passwords are (inside a real file, inside
white space where sdelete can get them).

Just blindly running the cleaner, might get them.

You could use nfi.exe from the roughly 2003 Microsoft package, which
relates LBAs to file names. And that could tell you whether
the file is inside a real file or not.

But your Disk Investigator should be telling you this.
There's not much point making a fuss, unless you tell
the customer where the item in question is. Forcing people
to manually do maths for this job, isn't what computers
are for.

If Disk Investigator is not finding it in a named file...
then Sdelete is what you want for a cleaning.

Paul

What is suggested app to look at "white Space" and see what is there ?

Paul wrote:
> On 5/10/2022 11:48 AM, Nomen Nescio wrote:
>> Disk Investigator has shown me that some of my passwords are showing
>> on my C: drive.
>>
>> http://theabsolute.net/sware/dskinv.html
>>
>> I think their being there might be related to my sometimes
>> copy/pasting passwords into a program.  I might have missed clearing
>> them from the clipboard after usage.  Just guessing on that one.
>>
>> Is there a program which would allow me to erase/delete those
>> passwords?
>>
>
> The passwords would either be in a valid file, or
> the passwords could be in "white space", the space
> between files.
>
> https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete
>
>    sdelete   -z C:              # 32 bit OS, clean white space on C:
>    sdelete64 -z C:              # 64 bit OS, clean white space on C:
>                                 # If on some other partition, change
> the C:
>                                 # to the desired drive letter.
>
> However, the minimum OS requirement is Vista on the current one.
> Why exactly, I don't know.
>
> On NTFS, small files are stored inside the $MFT itself.
> Sdelete has some mechanism to clean in those crevasses.
> The mechanism requires a second pass. The first pass,
> is bulk white space cleaning (which cannot clean $MFT).
> The second pass, cleans the small file storage area.
> Like a dinner fork, there are "spaces between tines" and
> that's what the second pass cleans. Small files, naturally,
> are used to hold passwords.
>
> https://www.trishtech.com/2010/02/permanently-delete-files-in-windows-xp/
>
>    # Vista or later
>    https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete
>
>    # 32-bit for WinXP
>
> https://web.archive.org/web/20101207031537/http://download.sysinternals.com/Files/SDelete.zip
>
>
> That's a time consuming process, so it would be nice to know
> exactly where the passwords are (inside a real file, inside
> white space where sdelete can get them).
>
> Just blindly running the cleaner, might get them.
>
> You could use nfi.exe from the roughly 2003 Microsoft package, which
> relates LBAs to file names. And that could tell you whether
> the file is inside a real file or not.
>
> But your Disk Investigator should be telling you this.
> There's not much point making a fuss, unless you tell
> the customer where the item in question is. Forcing people
> to manually do maths for this job, isn't what computers
> are for.
>
> If Disk Investigator is not finding it in a named file...
> then Sdelete is what you want for a cleaning.
>
>    Paul

On 5/10/2022 3:47 PM, SpacedOut wrote:
>
> What is suggested app to look at "white Space" and see what is there ?

I haven't seen good tools for this.

The software you're using, has spotted the passwords. That's good.

But identifying parts of the file system, as a function of LBA,
only the old Norton Disk Editor tool for NTFS, sorta did that for you.
The idea has not been popular in later designs by others.

I use HxD for tasks like this, but it does not have the
tools to "do a Norton" on the disk either. I've had to do
some of this manually, such as equating unreadable sectors
to certain files (or white space). When my WD Blue started
showing problems, two disk errors were inside files (bad),
two disk errors were in white space ("good"). But I had to
sit there with a calculator, to work out which things
were involved.

Maybe someone else here, will chime in with a tool for this.

While you could tar up all the files on a volume and then
search the tarfile for visible passwords, even that
isn't a sure thing, as it's very hard to get thorough/complete
anything on these systems. I have *no* tools that absolutely
list every file on a hard drive. Every tool I've got, gives
a slightly different list of files for the hard drive.

From a forensics point of view, the computers we use are
"craptastic". Everything you do on them, is hard work.

********

The easy way, is just run sdelete on it, and clean the
white space, then use your Disk Investigator and do a second scan.
Then if you get a hit, it's in a file.

Note that, sometimes, even the act of *typing the thing to search for*,
gets logged in a file! When I've done forensic tests for people
in the past (check how leaky something is), even the search
tool can pollute the drive. Only the people who work in forensics
on a full time basis, get the tiny details like this right. If
a hobbyist writes you a tool, they can screw up details like that.

Paul

In article <t5eb8v$nc3$1@dont-email.me>
Paul <nospam@needed.invalid> wrote:
>
> On 5/10/2022 11:48 AM, Nomen Nescio wrote:
> > Disk Investigator has shown me that some of my passwords are showing
> > on my C: drive.
> >
> > http://theabsolute.net/sware/dskinv.html
> >
> > I think their being there might be related to my sometimes
> > copy/pasting passwords into a program. I might have missed clearing
> > them from the clipboard after usage. Just guessing on that one.
> >
> > Is there a program which would allow me to erase/delete those
> > passwords?
> >
>
> The passwords would either be in a valid file, or
> the passwords could be in "white space", the space
> between files.

I left your entire post intact. Someone down the line might find it
helpful.

Be warned: I'm no tech. All I know is what I see in Disk Investigator.

> https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete
>
> sdelete -z C: # 32 bit OS, clean white space on C:
> sdelete64 -z C: # 64 bit OS, clean white space on C:
> # If on some other partition, change the C:
> # to the desired drive letter.
>
> However, the minimum OS requirement is Vista on the current one.
> Why exactly, I don't know.
>
> On NTFS, small files are stored inside the $MFT itself.
> Sdelete has some mechanism to clean in those crevasses.
> The mechanism requires a second pass. The first pass,
> is bulk white space cleaning (which cannot clean $MFT).
> The second pass, cleans the small file storage area.
> Like a dinner fork, there are "spaces between tines" and
> that's what the second pass cleans. Small files, naturally,
> are used to hold passwords.
>
> https://www.trishtech.com/2010/02/permanently-delete-files-in-windows-xp/
>
> # Vista or later
> https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete
>
> # 32-bit for WinXP
> https://web.archive.org/web/20101207031537/http://download.sysinternals.com/Files/SDelete.zip
>
> That's a time consuming process, so it would be nice to know
> exactly where the passwords are (inside a real file, inside
> white space where sdelete can get them).

I posted that info in my reply to R. Wieser.

> Just blindly running the cleaner, might get them.
>
> You could use nfi.exe from the roughly 2003 Microsoft package, which
> relates LBAs to file names. And that could tell you whether
> the file is inside a real file or not.
>

It was a pgp encrypted test file containing my passwords.

Somehow Win XP got the file when unencrypted.

> But your Disk Investigator should be telling you this.
> There's not much point making a fuss, unless you tell
> the customer where the item in question is. Forcing people
> to manually do maths for this job, isn't what computers
> are for.

Again, put that info in the Wieser reply.

> If Disk Investigator is not finding it in a named file...
> then Sdelete is what you want for a cleaning.
>
> Paul

You know what? Changing my passwords is simpler and surer - possibly
safer.

However, not knowing how XP did this means it wil lhappen again. How
did Windows capture the info?

Thanks for trying.

On 5/10/2022 7:58 PM, Nomen Nescio wrote:
> In article <t5eb8v$nc3$1@dont-email.me>
> Paul <nospam@needed.invalid> wrote:
>
> You know what? Changing my passwords is simpler and surer - possibly
> safer.
>
> However, not knowing how XP did this means it wil lhappen again. How
> did Windows capture the info?
>
> Thanks for trying.

Utilities use temporary files in %temp%, all the time.

When Windows "deletes" a file, all it has done, is
flipped a single byte in the %MFT table. It does not
remove the cluster contents. Utilities like Recuva,
can flip the byte back.

If you were to engineer a file system to "tromp" all
over every last bit of an deleted file, that would be
non-scalable and slow.

The closest equivalent to doing that, is Heidi Eraser.

https://en.wikipedia.org/wiki/Eraser_%28software%29

It must be installed in advance of any "secret" "crypto"
type stuff.

When a %temp% file shows up, and Windows "deletes" it,
Heidi can listen to the journal and take details.
It knows what clusters to stomp on.

If you "deleted" a 10GB file, then you'd have to wait
while Heidi does 10GB of writes to clean the disk areas.
This is like Sdelete cleaning white space, the difference
is, it's happening while you are working.

Having higher speed storage devices, may help hide
the performance issues Heidi might cause.

*******

But word of warning, computers leak. Despite your best
efforts, you might still find stuff. My favorite
peeve, is if I use Windows to search for password "12345678",
then the registry record of "what I searched for"
now has "12345678" in it :-) I think you can see
the unintended comedy, of "searching for a secret",
by having the "secret" now recorded in the Registry.
Try and erase that now (bulk erase the registry).

The way to search for something, is to boot a second
OS and do the searching from there. For example, Linux
LiveDVD OSes, store working files in RAM (TMPFS) rather
than on rotating media. If I use my Linux Mint stick
without persistence, then when the stick is unplugged
after a session, nothing of what I was doing is recorded
on it.

So there are ways to improve your technique, when
doing forensics.

I did a test on sdelete, and I *did* find all sorts
of bits of my test string on the drive later. This is
all part of the "fun", is learning where the leaks
come from, and trying to figure out a way to stop
them from happening.

My guess is, a policeman is only too glad when you're
using Windows. Your dirty fingerprints will be all over
the place, and he'll be wallowing in evidence. It's not
easy to make a drive "squeaky clean", short of bulk
erasing it and removing the OS in the process.

Paul