I need to find out the path of the diskutil in Cocoa app. In terminal, if I type 'which diskutil', it gives me: '/usr/sbin/diskutil/'. Will it always be this path? If not, how can I programmatically find out the path as I need to use it with NSTask
Thanks
Try /usr/sbin/diskutil. If not found, get a list of the paths in $PATH:
[[[NSProcessInfo processInfo] environment] objectForKey:#"PATH"]
and look up the command diskutil on each of them using the NSFileManager. If the user has access, your application will find it.
An unusual case would be that the command is not on the default system location and the user messed with his PATH. Then you could hardcode a look up in certain locations (/opt/local/bin, /usr/local/bin, ...) or ask the user where it is.
You can have the env command do the work for you. Simply say “env diskutil blah blah blah”, and env will look for diskutil in the directories of the user's PATH and, if it finds it, run it with the remaining arguments.
For NSTask, this means you'll want to set your task's launch path to /usr/bin/env, and its arguments array to the command (diskutil) and its arguments; for example, [NSArray arrayWithObjects:#"diskutil", #"list", #"-plist", nil].
When you run such a task, it will run env, and that will exec diskutil in turn, so you will be indirectly running whatever diskutil the env program finds without having to find diskutil yourself.
You may want to use PRHTask, a replacement for NSTask that I wrote that automates this and some other things. With PRHTask, you can create the diskutil task in one line: [PRHTask taskWithProgramName:#"diskutil" arguments:#"list", #"-plist", nil]. (You'll still have to run it, of course; there are some other nice features you may want to turn on before you do, detailed on the wiki page.)
Related
i have an app that can show many popups in various scenarios, and i would like to verify their text using XCUITest. but would like to be able to do that with no effort for multiple text configurations. for multiple languages for instance.
Is there a way to pass arguments through the .xctestrun file or through the "xcodebuild test-without-building" command? some way to pass the dictionary, or a file that i can parse at the beginning of the XCTestCase to know the correct text values to predict? preferably without the need to rebuild the project.
Found the answer.
The test host (and your XCTestCases) can view its arguments same as the test target, using NSProcessInfo.processInfo.environment and NSProcessInfo.processInfo.arguments.
Using the scheme for "Test" in XCode, you can add arguments and environment variables that the test host itself can read. The test host can read these by using the process info as mentioned above.
Another way to do this would be by editing the xctestrun file for your test. In it, you can add the key CommandLineArguments as an array of strings for the process info arguments, or add EnvironmentVariables as a dictionary from key to string value.
An easy way to go about adding the arguments/variables to the xctestrun file manually would be to first add them to the Test scheme in XCode, see the changes to the xctestrun file, and modify them accordingly.
other xctestrun variables are described in https://www.manpagez.com/man/5/xcodebuild.xctestrun/
Is there a way to invoke bazel help such that it outputs a machine readable format. I would like to parse all the flags that are available in Bazel and make them automatically available in ibazel so that I don't have to manually sync them every time a new bazel release comes out with different flags.
There used to be a --helpxml argument that printed things out as XML, but it seems the command line argument parser has changed and you can no longer use that. I presume there is still some way to get this, since the docs are being generated with up to date command line info. Unfortunately the "edit this page" button on the docs site 404s and I can't figure out its origin.
The docs for the flags are generated via this genrule, which essentially runs bazel help everything-as-html, the source of which is here.
There are a few other options listed in that case statement, one of which being flags-as-proto which emits the flags as a base64 encoded version of the BazelFlagsProto.
Potentially ibazel could read this in, load in the proto and pull out the data from there.
This doesn't seem like a situation that is unique to me, but I haven't been able to find an answer anywhere.
I am attempting to build Jmeter scripts that can be executed both in the GUI and command line. The command line is going to need values to pass into the test cases, but the same test cases need to be executed via the GUI as well. I initially had separate scripts for GUI and command line, but it seemed redundant to have the same test cases duplicated with just a couple parameters changed.
For example, the GUI test case has the Web Server name set to:
<!-- ${ENV} set in User Defined Variables -->
<stringProp name="HTTPSampler.domain">${ENV}</stringProp>
The command line test case uses the following for parameters:
<!-- Define via command line w/ -JCMDDEV -->
<stringProp name="HTTPSampler.domain">${__P(CMDENV)}</stringProp>
Both work for their served purpose, but I want to combine the tests to be easier maintained and to have the ability to run them via GUI or command line.
I got passed one hurdle, which was combining the GUI Variables to be used as well as Properties for the command line by setting the User Defined Variable ${ENV} as the following:
Name Value
----- --------
ENV ${__P(ENV,dev.address.com)}
I am now able to run the same test case via GUI and command line (defining a new environment with -JENV)
I'm not sure if I'm overthinking this, but I want to be able to add a variable to the property default in order to avoid typos, etc while handing it off to others. I tried a few variations that didn't seem to work:
Name Value
----- --------
ENV ${__P(ENV,${__V(DEV)})}
DEV dev.address.com
This gave me the following Request:
POST http://DEV/servlet
Instead of:
POST http://dev.address.com/servlet
I also tried using:
${__P(ENV,${DEV})}
${__property(ENV,,${__V(DEV)})}
${__property(ENV,,${DEV})}
I was looking into Jmeter nested variables, but it didn't provide any working solutions.
So to my main question, am I able to use variables as the property defaults. If so, how would I achieve that?
I found a way around this. It's not exactly how I wanted it, but it could work for right now.
I really wanted to keep everything in one place where people had to make edits, but I was able to get the User Defined Variables to work by adding the ${__P(ENV,${DEV})} to the HTTP Request Defaults Web Server Name instead of pre-defining it as a variable.
Now there are two Config Elements that potentially need to be edited with GUI execution, but I think it should work out better in the long run.
Yes, seems the author is right - looks like nested variable can't be evaluated in JMeter from the same variables scope.
I've created a different "User Defined Variables" set, added there "defaultValue" - and after that this option works:
${__P(myProperty, ${defaultValue})}
I am going to check loading and memory path of process to find malicious processes. for example if csrss.exe is executed from other path than Windows\System32 would be considered malicious. But the result of Volatility for common process such as csrss.exe is as follows:
loading path : \??\C:\WINDOWS\system32\csrss.exe
mapped path : \WINDOWS\system32\csrss.exe
or for smss.exe I have
loading path : \SystemRoot\System32\smss.exe
mapped path : \WINDOWS\system32\smss.exe
So are these two paths equal in these two examples or not ? I.e. is \??\C:\WINDOWS == \WINDOWS
or \SystemRoot\System32 == \WINDOWS\system32
No, a ??\C:\... without the leading \ is not valid, to the best of my knowledge. Perhaps some libraries will accept this as input, however, and convert it appropriately. Or perhaps you missed some bits from the paths you copied and pasted?
Either way we'll stick to the (NT flavored) Windows behavior.
However, \??\C:\... definitely is. You can find a comprehensive discussion here and the official documentation here. Some of the aspects we need to know are also explained here.
Some implementation details
Quoting from the Google Project Zero page above:
There are 7 types of path that the Win32 API distinguishes between,
and potentially does different things with. NTDLL has a function,
RtlDetermineDosPathNameType_U, which, given a Unicode string will
return you the path type. We’ll go through each one of these types in
the next section. The following prototype can be used to call this
function:
enum RTL_PATH_TYPE {
RtlPathTypeUnknown,
RtlPathTypeUncAbsolute,
RtlPathTypeDriveAbsolute,
RtlPathTypeDriveRelative,
RtlPathTypeRooted,
RtlPathTypeRelative,
RtlPathTypeLocalDevice,
RtlPathTypeRootLocalDevice
};
RTL_PATH_TYPE NTAPI RtlDetermineDosPathNameType_U(_In_ PCWSTR Path);
To follow along, download WinObj from Sysinternals/Microsoft and start it elevated (right-click + "Run as Administrator").
Potentially valid paths you may see
You have a number of path representations (as discussed in-depth in the linked articles). Let's consider the path C:\Windows\System32\csrss.exe you gave:
Win32 path: C:\Windows\System32\csrss.exe (\Windows\System32\csrss.exe would be a variation that depends on the current directory at the time the path is processed, if it is somewhere on C: they should be identical)
NT native path:
\??\C:\Windows\System32\csrss.exe
\GLOBAL??\C:\Windows\System32\csrss.exe
\SystemRoot\System32\csrss.exe
Local device path: \\.\C:\Windows\System32\csrss.exe
Root local device path: \\?\C:\Windows\System32\csrss.exe
DOS paths: this is relevant for all paths whose individual path segments are longer than the classic 8.3 DOS path name segments. If configured, a 8.3 DOS name will be generated (usually something in the form of C:\LongPathName -> C:\LONGPA~1) ... this may be important for forensic purposes (you quote volatility), but is mostly legacy behavior.
UNC paths also exist and in fact a local device path (\\.\...) looks like a UNC path with server name . which could even be a thing, considering . is the current directory further down in paths, so why not the current machine up top? Either way, go read the articles if you want to know about those in more detail.
Starting at the top, drilling down
C:\Windows\System32\csrss.exe when passed to an API like CreateFile will be converted to \??\C:\Windows\System32\csrss.exe which the object manager then takes in for processing.
If a relative path was given, there will be additionally processing to convert to a full path, basically.
\\.\C:\Windows\System32\csrss.exe when passed to an API like CreateFile will be "converted" to \??\C:\Windows\System32\csrss.exe after some processing. Just like without the \\.\ prefix some additional processing happens before this path is passed down to the object manager.
\\?\C:\Windows\System32\csrss.exe when passed to an API like CreateFile will be "converted" to \??\C:\Windows\System32\csrss.exe. No further processing happens at the Win32 level. This is basically an escape route straight to the object manager (and in the Fun facts section I'll share a related fun fact).
The object manager view
Receiving a path like \??\C:\Windows\System32\csrss.exe the object manager attempts to find \?? first.
\?? used to be an actual item, these days it is a "view" of \GLOBAL?? overlaid with your session-specific DosDevices.
An example of session-specific DosDevices would be mapped network shares.
For a drive letter F: mapped to \\fileserver\Share
Under the hood you will have a session-specific DosDevices object directory like \Sessions\0\DosDevices\00000000-00261e8a which would contain a symbolic link named F:, pointing to \Device\LanmanRedirector\;F:0000000000261e8a\fileserver\Share ... or similar.
So in essence when looking up names in \?? the object manager will look in your session specific DosDevices, followed by \GLOBAL?? (or was it the other way around? 🤔)
Another example would be VeraCrypt mounted volumes. For example your drive letter T: may map to \Device\VeraCryptVolumeT
Having figured out that C: is \GLOBAL??\C: in our case, the object manager checks what C: is. On my Windows 10 it figures out that this is a symbolic link pointing to \Device\HarddiskVolume3.
Having found the device (and implicitly the driver associated with it) the object manager now will pass the remainder of the path (\Windows\System32\csrss.exe) to the device \Device\HarddiskVolume3, whose driver will hopefully do the right thing, create a file object and so on ...
And now that you know this you can follow along on your system for arbitrary paths.
What about \SystemRoot?
Well, on modern Windows versions the behavior differs a little from how it used to be, but \SystemRoot is a symbolic link resolving to the Windows directory on all NT-based Windows versions I am aware of. The Win32 subsystem parrots this in the %SystemRoot% environment variable (albeit in Win32 path notation).
On my Windows 10 \SystemRoot is a symbolic link to \Device\BootDevice\windows and so the path to a driver (which is the typical use case in the registry) can be expressed much more easily for early boot drivers (less processing needed by the object manager).
As a side note: on my system - as you'd expect - \Device\BootDevice maps to \Device\HarddiskVolume3.
Fun facts
The DosDevices object directory cited in the Google Project Zero article is no longer a thing. These days it's a symbolic link to \?? (not \GLOBAL??).
The subst command line utility allows you to create symbolic links inside your session-specific DosDevices object directory to map some directory path to a drive letter (under the hood uses DefineDosDevice()).
Files are unnamed objects, that is they have no name that could be directly processed by the NT object manager. Instead the remainder of a file name - after reparsing etc - will be passed to the driver responsible for the device object representing the file system volume (i.e. partition). That driver then takes care of making sense of the name.
\REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem (while this doesn't name a file, it is a perfectly valid native path to what you would see as HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
That escape routes named \??\ and \\?\
I mentioned before that the prefix \??\ is an escape route. Consider a file/folder path with a trailing dot, something you will not be able to create or access ordinarily from the Win32 subsystem. Similarly the reserved DOS device names (e.g. NUL, COM1 etc.) cannot be created or manipulated ordinarily.
Little experiment ...
start cmd.exe (Win+R)
go to your desktop folder: cd /d "%USERPROFILE%\Desktop"
Now create a new file test.txt. (note the trailing dot): echo . > \??\%CD%\test.txt. (the %CD% refers to the current directory)
Use Windows Explorer to navigate to your desktop folder. Try to open the file test.txt. by double-clicking. Pick Notepad when it asks you what program to use to open it.
You should see:
... please note the path (without trailing dot).
Now try to delete the file from Windows Explorer. It won't work.
NB: Some alternative file managers like Far or Speed Commander won't have trouble with this!
Now switch back to the command line window and use del /f \\?\%CD%\test.txt.
Did you notice something? I sneakily changed from \??\ to \\?\ because apparently the implementation of del doesn't like the former.
Depending on the implementation of your specific program it can vary whether \??\ or \\?\ is successful.
Another experiment would be to create reserved names like NUL or COM1 or tinker with WSL2's per-directory case-sensitivity.
Note
Win32 may sound outdated, but the Win32 subsystem and the respective "Windows personality" implemented through csrss.exe and its subsystem DLLs (kernel32.dll and friends) was called just that. Besides, if you're picky it may bother you particularly to find out that all the native 64-bit binaries on a modern x64 Windows reside in %SystemRoot%\System32 (<- yes, that's a 32 right there 😁). Enjoy!
Further reading
In addition to the articles from the top, I can recommend these books:
Obviously the Windows Internals book series.
Windows System Programming by Pavel Yosifovich also has some details
I need to launch 'TextMate' from an App, and I used the following code.
[NSTask launchedTaskWithLaunchPath:#"/Applications/TextMate.app" arguments:[NSArray arrayWithObjects:#"hello.txt", nil]];
But, I got the following error return.
*** NSTask: Task create for path '/Applications/TextMate.app' failed: 22, "Invalid argument". Terminating temporary process.
What's wrong with my code? I just tried to run "TextMate hello.txt".
ADDED
I could make it run as follows.
[NSTask launchedTaskWithLaunchPath:#"/Applications/TextMate.app/Contents/MacOS/TextMate" arguments:[NSArray arrayWithObjects:#"hello.txt", nil]];
And I asked another question to see how many other ways available.
In this case, the invalid parameter is the application's name.
If you check the documentation for NSTask you'll see that the method you're using is basically a wrapper for the low-level exec() system call. This means you need to provide the name of an actual executable or binary file for it to be able to create the process. In your case, you're giving it a directory (use a terminal to confirm that most app bundles in /Applications are directories). That's why it barfs.
You could look inside TextMate's bundle directory to find the actual executable (should be somewhere in /Applications/TextMate.app/Contents/MacOS). You could then modify your code to call the actual executable.
However, it would seem that the correct, Cocoa-ish way to do it is by using NSWorkspace, you might look into its openFile:withApplication: method, which seems to do what you need, and in this case you DO specify the application bundle directory as a parameter, the way you were originally doing it.
Official documentation is here.
By the way, I can't fully take credit for it; see this StackOverflow answer to learn more about this topic.
You're trying to launch a directory, not a binary.
With the onset of sandboxing this does not work anymore and fails with "forbidden-sandbox-reinit" if you try to launch yourself.