If you just paste that into a Terminal window, what is the output? Post it, please, including any error messages.

If the output isn't what you expect, please describe what you expected, and how you decided that the posted defaults command-line is what should work.

Also describe exactly what you're trying to do. If you're trying to read the environment.plist file, looking for a DYLD_INSERT_LIBRARIES entry, perhaps related to the Flashback trojan, then please say that's what you're trying to do. Because if that's what you're trying to do, your syntax is wrong. You should start by reading the man page for the defaults command. You might also read about PListBuddy (google it).

Upon further examination it appears it might just be easier to download someone else's script and distribute it or use some of their script to construct my own.

defaults writes to stderr, you need to direct it to stdout. It might also make sense to pipe it to: grep -E "( does not exist)$" or something before you assign it to a variable, also use meaningful names for variables.

Edit: I have not tested this on a machine that has this trojan, keep that in mind. It might actually be better to do it manually to be sure instead of taking the risk of a false positive or worse, a false negative.

It does write to stdout, when invoked correctly, on a plist value that exists, in a plist or domain that exists.

If invoked incorrectly, or on a plist file or domain that doesn't exist, or with a key that doesn't exist, the stdout stream contains no bytes.

It only writes error messages to stderr, like many other Unix/Posix commands. In this design, the fact that nothing is written to stdout is intended to mean "no such thing", usually coupled with a non-zero exit status (shell: $?).

For example, if the cat command is invoked to cat a file that doesn't exist, the stdout stream gets no bytes, the stderr stream gets an error message, and cat's exit status is not-success (i.e. non-zero).

It does write to stdout, when invoked correctly, on a plist value that exists, in a plist or domain that exists.

If invoked incorrectly, or on a plist file or domain that doesn't exist, or with a key that doesn't exist, the stdout stream contains no bytes.

It only writes error messages to stderr, like many other Unix/Posix commands.

Right, but in this case the idea is to catch the case where a plist does not exist so stderr needs to be redirected to assign it to the variable. The non existence of these plist files is the only case we know about. Likewise for the removal, a script can't be made by the information posted by Fsecure since the exact output is not known.

Right, but in this case the idea is to catch the case where a plist does not exist so stderr needs to be redirected to assign it to the variable. The non existence of these plist files is the only case we know about.

I'm not following your logic.

If you didn't redirect and grep the stderr stream, the value assigned to the variable is "" (empty string). How is that not a definitive indicator that there is either no such file, or no such key?

It's conceivable that the file does exist, and the key exists with a value of "" (empty string), and this would not be a uniquely detectable condition. I'm not seeing how it's harmful, though, since it means DYLD_INSERT_LIBRARIES is defined to be the empty string. How is that harmful?

If it were strictly necessary to detect "no such file or no such key", then checking the exit status of 'defaults' is simpler:

If defaults has any non-zero exit status (i.e. no such file or no such key), then example will be assigned the string "###" (any other distinctive string would suffice). It's not necessary to parse the stderr messages looking for a grep pattern. Using the exit status of defaults is sufficient in this case.

I also see that your example is still using the wrong syntax for defaults [1]. So it will behave as if the file and/or key doesn't exist, producing a false negative.

Quote:

Likewise for the removal, a script can't be made by the information posted by Fsecure since the exact output is not known.

It is entirely possible to script the "use the path retrieved from the plist" procedure using PListBuddy. It's also possible using defaults and awk. I'm not going to suggest it's trivial, or even simple (as such scripts go). It is, however, quite possible to get the value assigned to DYLD_INSERT_LIBRARIES and do something with that pathname.

I surmise that Fsecure simply isn't interested in producing a free solution, since they explicitly say that non-advanced users should contact their support.

There may even be a better choice of scripting language than bash. Perhaps python or perl.

Personally, I'm not going to spend a lot of time on it, because none of the Mac users I know personally have this infection, and the ones I talked to recently are well aware of how to avoid it.

If you didn't redirect and grep the stderr stream, the value assigned to the variable is "" (empty string). How is that not a definitive indicator that there is either no such file, or no such key?

It's conceivable that the file does exist, and the key exists with a value of "" (empty string), and this would not be a uniquely detectable condition. I'm not seeing how it's harmful, though, since it means DYLD_INSERT_LIBRARIES is defined to be the empty string. How is that harmful?

Calm down, I'm using an example that fits the code in post 1 and explicitly test the condition posted by Fsecure.

Quote:

Originally Posted by chown33

If it were strictly necessary to detect "no such file or no such key", then checking the exit status of 'defaults' is simpler:

If defaults has any non-zero exit status (i.e. no such file or no such key), then example will be assigned the string "###" (any other distinctive string would suffice). It's not necessary to parse the stderr messages looking for a grep pattern. Using the exit status of defaults is sufficient in this case.

Technically correct, and you could come up with 5 or more different ways of doing it, the point was to replicate what was known exactly.

Quote:

Originally Posted by chown33

I also see that your example is still using the wrong syntax for defaults [1]. So it will behave as if the file and/or key doesn't exist, producing a false negative.

Yeah that's correct I simply copy pasted it from the first post.

Quote:

Originally Posted by chown33

It is entirely possible to script the "use the path retrieved from the plist" procedure using PListBuddy. It's also possible using defaults and awk. I'm not going to suggest it's trivial, or even simple (as such scripts go). It is, however, quite possible to get the value assigned to DYLD_INSERT_LIBRARIES and do something with that pathname.

I surmise that Fsecure simply isn't interested in producing a free solution, since they explicitly say that non-advanced users should contact their support.

There may even be a better choice of scripting language than bash. Perhaps python or perl.

Personally, I'm not going to spend a lot of time on it, because none of the Mac users I know personally have this infection, and the ones I talked to recently are well aware of how to avoid it.

I wonder how many of the affected Macs are running an OS and Java version so old they can't be updated? Or on hardware so old they can't be updated?

Turning off Java in the browser should take care of that. I have had it turned off for several years without noticing any difference, I can probably count the instances on one hand where it had to be turned on explicitly for some reason.