Opening this and then searching for "\.db$" reveals all of the processes that are (probably) using SQLite, which is fun for finding things you can poke around in.
I'd been poking through them with plain old `sqlite3` and then deserializing all the plist data with something like `pbpaste | xxd -r -p > foo.plist` for examination, but had no idea datasette existed and https://datasette.io/plugins/datasette-bplist#user-content-t... seems like the ticket for browsing these.
For others: all the Caches.db files are the per-process HTTP cache that NSURLRequest/NSURLSession keeps, so if you peek at it you can see (partially) a history of network requests that process has made. Most of them seem to pull feature flag configuration from https://bag.itunes.apple.com/bag.xml, but others do more interesting things.
Didn't know that, had to look into it immediately! Looks like a lot of the stuff in the Notes sqlite file is encrypted, though. Will need to look into this some more, would be nice to make a nice little exporter.
Last I checked it was not encrypted (unless you explicitly asked it to encrypt a note). Just gzipped protobuf data. I wrote an extractor about six years ago, maybe it'll help:
It seems to still work for text. It looks like it doesn't dump tables anymore, so that bit may have changed (it was pretty convoluted). I think the extraction of drawing information doesn't work anymore, but they provide a fallback PNG file.
I wanted it to be self-contained, so it has a little hand-rolled protobuf decoder and might be a little code-golfy.
Sometimes you can pull the phone ones out of backups. You used to be able to mount an application's full directory tree, but Apple killed that API years ago.
Ah, yes, nothing like running an unaudited application as root for security! Especially love the part where the developer signs with a 1024-bit DSA key and then uses ssh as root to deploy to a public webserver the sparkle updates:
I haven't reviewed obj-c code in over a decade, but I do know anything running with root authorization needs to be scrutinized carefully. And seeing blocks of code copy-pasted from stackoverflow, references to a 10 year old operating system, use of SIGKILL instead of the proper SIGTERM, for example, does not exactly inspire the necessary confidence.
Sloth author here. To clarify, Sloth does not run with or require root privileges. However, it allows you to (optionally) run lsof itself with root privileges via Apple's Authorization framework. The application is Developer ID signed, but not notarized by Apple (which is a PITA). I guess it's "unaudited", but the source code is right there for anyone to view, analyze and build from scratch.
Also, I'd be curious to know what "blocks of code copy-pasted from stackoverflow" you found. As far as I know, I wrote all of Sloth myself, starting 19 years ago. As for references to "Mac OS X" in code comments, that seems rather pedantic given that this is very old code and Apple keeps changing the name of their operating system: Mac OS X -> OS X -> macOS.
That being said, thank you for identifying the appcast deployment script, which shouldn't have been in version control to begin with.
Love this, reminds me of the BeOS process controller that permitted killing individual threads IIRC. useful when you need to unfreeze an app without losing your work in that app!
The built-in Activity Monitor in macOS also has the ability to show open descriptors for a process. Double-click a process and go into the "Open Files and Ports" tab.
Burp Suite does not create a [dot]app folder, so every time I want to start it I have to open the Terminal and run "java -jar /path/to/burpsuite.jar", which is not a big problem but I very much prefer to press Cmd+Space, quickly type "burp" and then press the Return key to start the Platypus wrapper.
I have both community and professional editions installed (trial expired), and would always open via spotlight or the dock shortcut... not sure what's going on with the parent comment's application.
Very cool. One of the things I would love to be able to do is to track all file reads and writes that traverse a network connection. You can kind of do this using a combination of fs_usage/iftop/lsof in the moment but it's rough. Can Sloth or something like little snitch do it?
Sometimes I'll see my network spike via menumeters but I have no idea what caused it. Was it Google drive syncing something? Something else? What files were accessed?
This is one of those no-brainer features that really should ship by default with any machine.
As it happens, there are GUIs that kinda do this, though not intentionally. Charles Proxy comes close, though the interface was a bit rough the last time I used it (2016).
I believe you're correct according to the linked Github repo:
> Sloth is essentially a friendly, exploratory graphical user interface built on top of the lsof command line tool. The output of lsof is parsed and shown in a sortable, searchable outline view with all sorts of convenient additional functionality.
There should be more GUI's for the command line tools, imho. Imagine if we could get a parsable json from the cmd line tools that allows for a standard UI to be built ..
There's a cli/python utility called jc, which can parse some cmd line tool outputs (including lsof) and convert them to JSON (can also convert many file formats to JSON..)
I wish there was a way to see which files were being actively written to sorted by amount of data written. Various times I've seen my disk space rapidly dwindling with no way of know what file was responsible..
If you'd rather spend some of your time than your money on this, you can use the built-in fs_usage terminal command and filter its output (e.g. with grep). Works even with SIP enabled, but will then obviously only return information that SIP doesn't cover.
More info:
man fs_usage
Example showing pathname-only events but otherwise unfiltered:
On Linux, this can be done using BPF (Berkley Packet Filter). In fact there is a tool in BCC[0] called filetop, which lists reads/writes by process and file[1].
Happened to me this morning, something filled up my drive in minutes. I used dust[1] to look for large files while it was happening but knowing what was doing it would've been a big help.
This is the beauty of a non-walled-garden, general-purpose computer. I really hope that Apple keeps macOS this way, and doesn't try to close it off like iOS. There are many worrisome trends...
I guess that I'm not the target audience for this - I like grep as UI on top of lsof, maybe in combination with less, and I've always found it fast and easy to use.
For people that are the target audience of this, I'm curious - what do you like about putting the information into a gui and using a mouse instead of a keyboard?
>what do you like about putting the information into a gui and using a mouse instead of a keyboard?
I don't have to remember anything to use it, I just click self-explaining buttons and the thing works. The search function is also very nice, and navigating an outline view with the arrow keys, quickly collapsing subtrees as needed, is a very useful tool. Also, drag and drop.
For guis in general, I like how the actions available to me are much easier to learn, and therefore use. The information conveyed through the layout often provides context for related actions.
In my experience, CLIs are great for efficiency, if I am doing a task so often that it becomes rote behavior and learning the tool is no longer helpful, or if I want to automate it. I find my real world need for either of these to be relatively slim, but I am not surprised that it is common for others.
What do you like about having to remember and execute a series of precise and arcane text commands instead of seeing everying comfortably and accessibly presented to you in a graphical form?
It's ok to like different things - there is no need to attack a different approach. If you find the visual layout comfortable and accessible then thank you for answering the question.
Process Monitor ("an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity") may be the closer parallel:
great little app. I had to approve it specifically in System Preferences > Security & Privacy > General because it's not signed, but that's a minor detail.
There's a fine line between glorified and shoulder-standing.
This project gives full credit to the giant it stands upon.
README.md:
> Sloth is essentially a friendly, exploratory graphical user interface built on top of the lsof command line tool. The output of lsof is parsed and shown in a sortable, searchable outline view with all sorts of convenient additional functionality.
The logo looks competently drawn and is better at bigger scales where the details are clearer, but from a distance it caused me a visceral rejection reaction.
Some constructive advice to the author, if they're lurking: "Good" logos economize on details to maximize impression and versatility. Use fewer and simpler shapes to communicate better. Or maybe let an AI tool have at it?
Another note to the author if they see this. I don’t find the logo offensive like the sibling commenters. I love the creative process and wasted days making logos which other people found unpalatable. People have visceral responses to logos for better or worse, which is why logos have become so boring over time - it’s just safer. But I do not hate the sloth
Not sure if it still works, but on macOS previously you could Command-I (Info) on two files, click the icon in one info window (highlighting it), and copy-paste on the other.
Agreed. The style looks nice and idea clear. But the details make this look unsettling, like early versions of AI generated human faces, resulting in creepy output
One things I envy about the macOS users is how obstinate they are to better macOS for free to Apple. While Linux users with the time tend to just be satisfied with the CLI tools and ignore GUI. At best, you would have a curses app to this.
That’s a rather backhanded compliment, but yes, when you use slick tools on a daily basis there’s a halo effect. Mac developers have, for decades now, taken pride in writing native applications that run well and look clean.
I suspect this also has to do with the presence of a native first-party GUI toolkit and app framework that deeply integrates with the rest of the system.
There are plenty of developers who also take pride in developing native applications on Linux that run well and look good, but from what little I know about GUI app dev, it's harder to do that in a way that runs well and looks good on the wide range of Linux-based systems that exist out there.
That’s an excellent point, Linux is definitely hampered, but Windows doesn’t seem to have benefited much from having a first-party toolkit and framework.
Windows doesn't have a first-party toolkit and framework. They have a multitude of them, with a new one every few years—each one bringing conflicting philosophies and design patterns.
The fragmentation is almost as bad as on Linux: an admin tool that looks at home alongside Microsoft Management Console will never fit in with the Windows 10 or Windows 11 Settings applications.
Exactly the problem that Android has compared to iOS. There isn't a "wide range of iOS-based systems" that are different enough that you invent your own way of doing things.
Allows for greater control over your own expression, while having to support many possible platforms.
> Sloth is essentially a friendly, exploratory graphical user interface built on top of the lsof command line tool. The output of lsof is parsed and shown in a sortable, searchable outline view with all sorts of convenient additional functionality.
Try "\.sqlite" too.
This is fun: