Suspect folder (hex characters in name) in /Library/Application Support

[JF Mezei]

Found a odd folder in /Library/Application Support.

each .dat file contains gibberish (no readable text).
Some files from 2020:
April 30,
May 18
August 25

But one from:
May 27 2021

Any chance these would be legit (fearing some license files for Adobe
products that are stored in non obviosu places) or are these nefarous
and should be deleted?

(I wish there were a feature like on VMS where you could set an alarm
whenever a file is accessed so I could know when and more importantly
which process opens to read or write such a file).


bike:Application Support $ ls -l 54F3DE4E-B7BA-4EBD-8B3B-385D272CC583/
total 200
-rwxrwxrwx 1 root admin 16 Apr 30 2020 0186a991.dat
-rwxrwxrwx@ 1 root admin 64 Aug 25 2020 0f5d21a3.dat
-rwxrwxrwx 1 root admin 64 Aug 25 2020 164610e2.dat
-rwxrwxrwx 1 root admin 16 Apr 30 2020 189d98d0.dat
-rwxrwxrwx 1 root admin 48 May 27 00:20 1f94300c.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 42630de3.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 61412074.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 694e5e20.dat
-rwxrwxrwx 1 root admin 2 Apr 30 2020 6f9aa846.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 70556f61.dat
-rwxrwxrwx 1 root admin 2 Apr 30 2020 76819907.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 785a1135.dat
-rwxrwxrwx 1 root admin 1264 Aug 25 2020 802dfb15.dat
-rwxrwxrwx 1 root admin 80 Aug 25 2020 8846e984.dat
-rwxrwxrwx 1 root admin 16 Apr 30 2020 8ef67327.dat
-rwxrwxrwx 1 root admin 0 Aug 25 2020 97ed4266.dat
-rwxrwxrwx 1 root admin 64 Aug 25 2020 9936ca54.dat
-rwxrwxrwx 1 root admin 64 May 18 2020 a5db20e4.dat
-rwxrwxrwx@ 1 root admin 1264 Aug 25 2020 ab00a8d6.dat
-rwxrwxrwx 1 root admin 2 Apr 30 2020 d2dc1072.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 dc079840.dat
-rwxrwxrwx 1 root admin 0 Aug 25 2020 e0ea72f0.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 e63e8496.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 ee31fac2.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 f72acb83.dat
-rwxrwxrwx 1 root admin 2 Apr 30 2020 f9f143b1.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 ff25b5d7.dat

[nospam]

In article <Gq8wI.740208$nn2.1...@fx48.iad>, JF Mezei

<jfmezei...@vaxination.ca> wrote:

>
> (I wish there were a feature like on VMS

then go use vms.

[Lewis]

In message <Gq8wI.740208$nn2.1...@fx48.iad> JF Mezei <jfmezei...@vaxination.ca> wrote:
> Found a odd folder in /Library/Application Support.

> each .dat file contains gibberish (no readable text).
> Some files from 2020:
> April 30,
> May 18
> August 25

> But one from:
> May 27 2021

> Any chance these would be legit (fearing some license files for Adobe
> products that are stored in non obviosu places) or are these nefarous
> and should be deleted?

> (I wish there were a feature like on VMS where you could set an alarm
> whenever a file is accessed so I could know when and more importantly
> which process opens to read or write such a file).

Adobe is a large malware root kit, and no one knows what it does, but it
spreads tentacles throughout your system. So sure, could be abobe.

> bike:Application Support $ ls -l 54F3DE4E-B7BA-4EBD-8B3B-385D272CC583/

there is nothing suspicious about that path, it's simply a hash value.
They are not common in Application Support, but you will find similar
pattern files troughout your library.

$ find ~/Library | egrep "[0-9A-F]{8}-[0-9A-F]{4}-" | wc -l
160820

Yes, that is 160 thousand files or folders with the pattern of 8 hex
digits, a dash, 4 hex digits, and another dash.

Chances are that if you delete or move the folder, it will be recreated
by whatever app you have that uses it.

--
All Hell hadn't been let loose. It was merely Detritus. But from a
few feet away you couldn't tell the difference.

[gtr]

Get info on some of these provides no useful info? I have come to love
Houdahspot for digging through my world.

I might look at "all files created" on Aug 25 to see if I could find a
correlation.

[Your Name]

On 2021-06-10 02:56:12 +0000, gtr said:
> On 2021-06-09 19:14:45 +0000, JF Mezei said:
>
>> Found a odd folder in /Library/Application Support.
>>
>> each .dat file contains gibberish (no readable text).
>> Some files from 2020:
>> April 30,
>> May 18
>> August 25
>>
>> But one from:
>> May 27 2021
>>
>> Any chance these would be legit (fearing some license files for Adobe
>> products that are stored in non obviosu places) or are these nefarous
>> and should be deleted?
>>
>> (I wish there were a feature like on VMS where you could set an alarm
>> whenever a file is accessed so I could know when and more importantly
>> which process opens to read or write such a file).

<snip>

There are apps like FSMonitor which will tell you when a file is created.

> Get info on some of these provides no useful info? I have come to love
> Houdahspot for digging through my world.
>
> I might look at "all files created" on Aug 25 to see if I could find a
> correlation.

There's a lot of strange named files and folders within the two Library
folders, especially deep inside various sub-folders. You'll never find
out what they belong to. You can thank MacOS X being based on Unix for
that (there were strangley named files and folders even in the
"Classic" MacOS System Folder, but nowhere near as many or so
widespread).

[JF Mezei]

Another puzzling one, a behaviour I have not seen before.
High Sierra. Home directory on APFS SSD.


On my desktop:

.MG-9A44E1BB-6071-4B4...91546D
(icon is that of a vanilla document).

I cannot move it in Finder.
I cannot Alt move it to another folder to copy it. (to see what is
inside, how big it is).

If I move an item that is just to the right of the file, the mystery
file then moves right to the space vacated when I moved the other file.

I cannot Get Info for it. (no error message, but nothing happens).

If I try to delete it:
"The Item .MG-9A44E1BB-6071-4B43-B82D-D2828F91546D can't be moved to
the Trash because it can't be deleted. (only button is OK)

If I open a finder window to "Desktop", the file isn't there (but then
again, I think Finder tends to hide any/all . files) imilarly, Time
Machine does not show the file.

In command line:
ls -a ~/Desktop does not show the file
ls -a ~/Desktop/.MG* does not show the file

I can't run disk first first air without logging off. I get a feeling
that there is an entry in the GUI file that contains desktop description
and file positions, but that entry doesn't poinr to a file.

or is there a way to hide a file from the unix side of things (eg:
invisible to ls ?

[Dr Eberhard Lisse]

helpful...


--
To email me replace 'nospam' with 'el'

[Dr Eberhard Lisse]

On 10/06/2021 08:11, JF Mezei wrote:
> Another puzzling one, a behaviour I have not seen before.
> High Sierra. Home directory on APFS SSD.

[...]

Unhelpful advice: Upgrade to Big Sur :-)-O

el

[Bernd Froehlich]

On 10. Jun 2021 at 08:11:46 CEST, "JF Mezei"

<jfmezei...@vaxination.ca> wrote:

> If I try to delete it:
> "The Item .MG-9A44E1BB-6071-4B43-B82D-D2828F91546D can't be moved to
> the Trash because it can't be deleted. (only button is OK)

Open Terminal

sudo rm "Drag that file in here"

that should get rid of it.

[Lewis]

That will work with files that can be deleted. It is unlikely to work
with a fle that reports it cannot be deleted. It is ossile that the uchg
flag has been set for the file. you can celar it with:

open terminal
sudo chflags -R nouchg <drag the file in to the Terminal>

then try to remove the file.


--
Help me, Obi-wan Kenobi. You're my only hope.

[JF Mezei]

On 2021-06-14 04:26, Bernd Froehlich wrote:

> Open Terminal
>
> sudo rm "Drag that file in here"
>
> that should get rid of it.

Thanks,. neat trink I hadn't thought of.

Alas, my mac crashed yesterday and the unmoveable "non existent" file
is gone from the desktop.

[JF Mezei]

On 2021-06-14 04:26, Bernd Froehlich wrote:

> sudo rm "Drag that file in here"

However, since the Unix view of the file system did not see the file, I
have to wonder if that command would simply return "file not found,
can't be deleted" kind of message.

Is there an "ls" incantation that would show any/all hidden files ?

[b...@ripco.com]

JF Mezei <jfmezei...@vaxination.ca> wrote:

> Is there an "ls" incantation that would show any/all hidden files ?

One way to see everything in a directory is to use the find command.

If you cd in Terminal to the directory with the stubbon file, run this:

find .

or if it's a large directory (many files)...

find . | more

I dunno about the mac, finder and all that but there used to be a way of
destroying a file via the inodes. The mac seems to support:

ls -i filename

which will return something like:

57835797 zzz

where that number is the inode the file starts at but they seem to have
changed/removed the rm -i command which used to be remove the files inode
and changed it to interactive.

The osx find seems to support both the -inum and -delete so something like
this:

find . -inum 57835797 -delete

could get rid of it.

Keep in mind that will blow the file out but with Finder and a gui, it
doesn't mean it'll disappear from the desktop.

Odds are when you rebooted it ran fsck, figured the problem out and fixed
things, that sort of is the point of it.

-bruce
b...@ripco.com

[JF Mezei]

On 2021-06-15 08:33, b...@ripco.com wrote:

> I dunno about the mac, finder and all that but there used to be a way of
> destroying a file via the inodes. The mac seems to support:
>
> ls -i filename
>
> which will return something like:
>
> 57835797 zzz

Would the above list files that sudo ls -a didn't show?


BTW, is APFS now suffiently documented to allow 3rd party apps to parse
the APFS file structure , undelete files etc. Such an app might have
been able to give hints on the existence (or lack thereof) of this file
which appeared in Finder on Desktop but nowhere else.

> find . -inum 57835797 -delete

Would it be correct to state that all the Unix utilities use the same
interface to the Apple file system that synthetizes Unix file
names/structure and so if ls doesn't know of a file, no other unix
command would? or are there commands that have lower level access to the
APFS file system?

[b...@ripco.com]

JF Mezei <jfmezei...@vaxination.ca> wrote:

> Would the above list files that sudo ls -a didn't show?

It's really a "more than one way to skin a cat" possibility.

The main difference would be the find command would show the contents of a
directory, if one is in the directory you are using find on, where ls is
just showing the directory name.

You also don't get any permission or ownership info with find.

So it (find) could show something that ls isn't. Or not.

> Would it be correct to state that all the Unix utilities use the same
> interface to the Apple file system that synthetizes Unix file
> names/structure and so if ls doesn't know of a file, no other unix
> command would? or are there commands that have lower level access to the
> APFS file system?

I don't know the answer to that but one thing I haven't seen mentioned is
that .DS_Store file. As far as I know, the osx finder reads from there to
show what things are. I guess it's a mini database of sorts. Somewhere osx
must scan drives, directories, files to create a fast way of seeing in the
finder and make updates as things change.

I'd guess from the original complaint that finder was showing something that
didn't exist within the file system. The .DS_Store file maybe had some
corruption.

Wonder if the .DS_Store file was simply deleted and let the osx rebuild it
wouldn't of fixed the problem also.

Just pointing out that Finder (the gui) is not the same as looking at the
file system through Terminal.

-bruce
b...@ripco.com

[Lewis]

In message <saavq7$58s$1...@remote6hme0.ripco.com> b...@ripco.com <b...@ripco.com> wrote:
> I don't know the answer to that but one thing I haven't seen mentioned is
> that .DS_Store file. As far as I know, the osx finder reads from there to
> show what things are. I guess it's a mini database of sorts.

No, the .DS_Store files contains metadata about the folder display
settings for the finder window. Things like position on screen, list
view, sort selection, dimensions, state of the sidebar, etc.

It has no other function.

> I'd guess from the original complaint that finder was showing something that
> didn't exist within the file system. The .DS_Store file maybe had some
> corruption.

It is impossible to guess with JF.

> Wonder if the .DS_Store file was simply deleted and let the osx rebuild it
> wouldn't of fixed the problem also.

Nope, it has nothing to do with files.

> Just pointing out that Finder (the gui) is not the same as looking at the
> file system through Terminal.

Of course not, but JF lacks some very basic understanding and is
constantly saying inane things about the filesystem that shows he is
quite clueless about how it works.

--
Reality is a curve. That's not the problem. The problem is that there
isn't as much as there should be. According to some of the more
mystical texts in the stacks of the library of Unseen University
- (...) - at least nine-tenths of all the original reality ever
created lies outside the multiverse, and since the multiverse by
definition includes absolutely everything that is anything, this
puts a bit of a strain on things. --Moving Pictures