I am trying to identify the software which creates an unidentifiable login item in my macOS installation.
Web search does not reveal any usable clues.
Does anybody know which software this is from?
Model Identifier: Mac14,3
System Version: macOS 13.6.7 (22G720)
Does EtreCheck reveal anything about it?
I’m a developer and had something similar happen to my app.
“GuangJun Song” is the name of the app developer who code-signed the item. macOS Ventura (or maybe Sonoma?) changed its presentation of “login items” to include items which in earlier versions of macOS were not shown, and for an item added by a now-deprecated mechanism, it shows the name of the signer instead of the name of the application that made it a login item or in which the item is contained.
The launchctl list | grep -v apple command may give a clue; it will list all login items that are not from apple, and the third column of the list shows the item’s “label”, which may help identify it.
Note that, because this item says it “affects all users”, it is a “launch daemon”, not a “launch agent”. That means that it probably runs as root rather than as the user, which makes it especially powerful.
See also this Apple Community question/answer.
I don’t know the answer, but I did a search just for the name GuangJun Song and found this listing of patents: Guangjun Song Inventions, Patents and Patent Applications - Justia Patents Search
The name of the company in two of those listing BOE Technology, and one of their businesses is making display panels, including reportedly for Apple.
Do you perhaps have an external display that may have installed some sort of driver? Or if it is a MacBook model, perhaps it’s just required for the display on that Mac. (Though I’d think that Apple would sign a driver for their own hardware, even if it was from an external supplier.)
Nice, I learned something new!
And I see the first column is PID.
So if you see an entry there you can do ps -ef | grep <PIDnumber> which will get you the application it started.
Thanks for all your support, guys.
This is what I was able to reveal using the proposed terminal command JKBull suggested.
I ran the first command twice having the Background item in question deactivated and then activated.
As a difference this line was added in the output:
PID Status Label
73304 0 application.com.crowdcafe.windowmagnet.22984061.22984120
It corresponds to another line in the output as both contain “crowdcafe”:
PID Status Label
- 0 com.crowdcafe.magnetLauncher
I searched the Internet for “crowdcafe” and found out, that it indeed belongs to the app “Magnet”, a window management tool I am using frequently.
The terminal command using PID 73304
reveals
501 48242 1090 0 11:49AM ttys000 0:00.00 grep 73304
which I don’t know how to interpret as application.
I contacted the software developer to find out what this GuangJun Song is all about, but they did not answer.
I guess it is ok to allow this background item.
If the Application was still running, you would have got two lines. One with grep finding itself
501 48242 1090 0 11:49AM ttys000 0:00.00 grep 73304
and one with the App. No second line means that the App has quit.
Here is a example with Numbers.
ps -ef|grep 20198
502 20198 1 0 9:57AM ?? 0:10.10 /Applications/Numbers.app/Contents/MacOS/Numbers
502 22860 22728 0 5:32PM ttys000 0:00.00 grep 20198
I agree that it is probably OK to allow the login item.
But I want to try to clear up a possible misunderstanding of P. Boersting’s suggestion to try
ps -ef | grep <PIDnumber>.
Angle brackets (< and >) are sometimes used to indicate something that needs to be replaced with something else. What is between the brackets indicates what should be substituted.
So what P. Boersting meant is that <PIDnumber> should be replaced by the process ID number that was output by the launchctl list | grep -v apple command that I suggested.
So if the output of launchctl list | grep -v apple was
| PID | Status | Label |
|---|---|---|
| 73304 | 0 | application.com.crowdcafe.windowmagnet.22984061.22984120 |
Then the command that should be typed is
ps -ef | grep 73304
(substituting 73304 for <PIDnumber>).
But don’t substitute 73304 for <PIDnumber> now, because the 73304 may be out-of-date. You need to do the two commands one after the other, not separated by a lot of time, because the process ID number changes when a process quits and is restarted. Depending on the process, that could happen as often as many times per second.
As P. Boersting later noted, two lines will be output, one showing the grep command, the other showing the program you actually want.
The last part of the output (in his example, /Applications/Numbers.app/Contents/MacOS/Numbers) should show the path to the program that is running with the specified process ID number, followed by the arguments the program was started with, if any.
Note that launchctl list | grep -v apple may output several lines; each one after the header line would be for a program that will be launched at startup that is not written by Apple. (Technically, it would be a list of any program that doesn’t include “apple”, so it is possible that a program that includes “apple” in its name would not show up in the output. There can be hundreds of Apple programs and it would be painful to look through them all, which is why I included the | grep -v apple, which is what removes lines that include “apple”.)
Thanks for your input. 
I followed your advice and this time the terminal command
ps -ef | grep <PIDnumber>
returned
/Applications/Magnet.app/Contents/MacOS/Magnet
The “GuangJun Song” remains a mystery, but at least I know now that that Background entry in question belongs to a trustworthy program.
Have you tried using the codesign utility to display the signature details for an app?
codesign -dv --verbose=4 /path/to/application
Use that on executables pointed to in the plist files found in LaunchServices or LaunchDaemons and you should be able to find the culprit.
Not sure what you mean.
Where exactly do I find these Launch…things and which process points to them?
Sorry, have some knowledge deficits here.
You probably don’t need to; all you probably care about is “GuangJun Song”, and you’ve already found out that’s the name of the person who signed the “Magnet” app.
Technically, “GuangJun Song” is Apple’s “Developer ID” for the individual or organization that signed it, and it is conceivable but unlikely that you have a copy of Magnet that has been maliciously modified and then signed by “GuangJun Song”.
But this is more likely to be innocent and is a result of the Magnet app being developed and signed by an individual or organization with a Developer ID of GuangJun Song. The only way to check that would be to contact the “Magnet” folks directly and have them confirm that “GuangJun Song” is the Developer ID used to sign their app.
To answer your question, though, and to help anyone who stumbles on this topic in the future:
The “these Launch…things” that @Technogeezer is referring to are files that macOS uses that contain information about programs macOS should run when your computer starts up or when you log in. The files contain information about contain paths, which are a way to represent the location of something on a disk.
That said, codesign -dv --verbose=4 /path/to/file can be used to get information about the digital signature of anything that has been digitally signed. That includes most executable files and .apps.
(Similar to the <PIDNumber> notation, /path/to/file isn’t meant to be typed literally. It means you should substitute the path for an actual file or app for `/path/to/file.)
So you could get more information about the digital signature on Magnet with
codesign -dv --verbose=4 /Applications/Magnet.app/Contents/MacOS/Magnet
or more simply,
codesign -dv --verbose=4 /Applications/Magnet.app
(Technically, the first one produces information about the signature on the primarly executable file in the Magnet app, the second one about the signature on the app itself. In all likelihood, they are signed by the same individual or organization.)
There’s a lot of information presented in the output. For an application like Magnet, which is apparently signed by an individual, what’s relevant for @Alexander_Tetzlaff is the line starting with
Authority=Developer ID Application:
The rest of the line has the name of an individual or an organization that signed the file and, in parentheses, the “team” that the member belongs to. I would expect that the output for Magnet has a line that starts with
Authority=Developer ID Application: GuangJun Song
indicating that the application was signed by GuangJun Song.
Thanks for taking the time to educate me on this. I really appreciate it.
This is the output I received from Terminal:
codesign -dv --verbose=4 /Applications/Magnet.app/Contents/MacOS/Magnet
…
Authority=Apple Mac OS Application Signing
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Doing codesign -dv --verbose=4 /Applications/Magnet.app reveals the same.
No name of individual or organisation that signed the file is returned.
I wrote a long explanation of how I investigated this, which appears below, but here’s what I suggest:
Disable the “GuangJun Song” login item and see if Magnet still works. If it doesn’t work, then it is probably part of Magnet. If it still works, there is one more thing to try: with it still disabled, shut down your computer and then start it up again. If Magnet still works, then the “GuangJun Song” login item is not part of your current version of Magnet.
If Magnet doesn’t work with the "GuangJun Song’ item disabled, enable it and get on with your life!
If Magnet does work with the "GuangJun Song’ item disabled, leave it disabled and see if anything else on your computer starts misbehaving (or misbehaving more than usual : ) If you want to continue investigating, let me know.
Here’s the long explanation of how I came to that conclusion.
The last two lines in the output are as expected (they have to do with the chain of trust).
I checked all of the apps in my /Applications folder, and most of them were signed as expected, with Authority=Developer ID Application:…
Those that were signed with Authority=Apple Mac OS Application Signing included Apple apps (Developer, GarageBand, Keynote, Numbers, Pages, Xcode, iMovie). However, it also included others (Adblock Plus, Kindle, and Sequel Ace) which I believe were obtained from the Mac App Store. Since Magnet is obtained from the Mac App Store, I guess that’s why it doesn’t seem to be signed by a Authority=Developer ID Application….
Which raises the question of where the name “GuangJun Song” came from! Even higher verbosity levels in the codesign command don’t show anything that looks like names of persons. Maybe macOS stores it somewhere else, but other possibilities are:
I was very curious about all this so, I downloaded Magnet version 2.14.0 from the Mac App Store. When launched, it first asked me to allow it to use accessibility features of the Mac, which I allowed. (Thinking about that, I could imagine an older version of Magnet that, instead of using the accessibility features, used a “launch daemon” login item such as the one associated with “GuangJun Song”, so maybe you’re using a different, older version of Magnet, or maybe the “GuangJun Song” item is just a leftover from an older version of Magnet.)
My version of Magnet does have a login item (which I received a notification about), but when enabled, it is named “Magnet.app” and is in the “Open at login” list, unlike “GuangJun Song” item which is listed in your “Background items”. That means that the “Magnet.app” is launched when you log in, and is not a “launch daemon”. From this, either
To find out the version of Magnet that you have, click the Finder icon in the Dock to open a Finder window, then hold down either shift key and either command key while you press and release the “a” key (then release the shift and command keys). That will get you a Finder window with Applications. Scroll down to find the Magnet app, click it once to select it, then hold down the command key while you press and release the “I” key (then release the command key). That should open a small window that contains information about Magnet, which should include the version number.
Given that this mysterious start item is noted as impacting all users, the offending plist is likely to be in either /Library/LaunchAgents or /Library/LaunchDaemons.
Could you post a listing of the plist files that are in both those locations. Perhaps it isn’t related to Magnet at all, but some other application that needs a background task.
Here are the results:
2.14.0 is the version I have.
I have been using older versions in the past since Big Sur.
Disabling the login item does not seem to hamper the Magnet functionality.
Restarted, Magnet works fine with login item disabled.
Bingo! I think I’ve found the offender. And it isn’t Magnet.
I went down the list of files in the LaunchAgents and LaunchDaemons folder, trying to decipher the developer and possible software that would generate these launch agents.
The hit came on a plist entry for com.minicreo.PrivilegesHelper.plist. From there, I searched for “minicreo” and found the website minicreo.com for MiniCreo - where they have a number of macOS and iOS products. I downloaded the .dmg for their Omni Remover product for the Mac, and ran the codesign utility against the OmniRemover.app file in the mounted .dmg.
Here’s the result:
% codesign -dv --verbose=4 Omni Remover.app
… stuff deleted
Authority=Developer ID Application: GuangJun Song (55GJE27CWH)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Jun 2, 2024 at 12:04:52 AM
Info.plist entries=26
TeamIdentifier=55GJE27CWH
… stuff deleted
This appears to be the “smoking gun”. You have an app from MiniCreo (I don’t know which one it is for sure) installed and is most likely signed by GuangJun Song. I don’t think I’m going out on a limb here to think that it has a background item installed, and that it too is signed by GuangJun Song.
Criticism for both Apple for not giving you a good way to find this miscreant, and MiniCreo for not providing a more descripive developer ID for a commercially available product.
