Fix stringFromCFData

[SilverPlate3]

I am building a binary for OSX that reports the details of devices that are physically connected to the Mac.
I used your implementation of stringFromCFData in order to convert the "USB device signature" which is of type Data (bytes) into a string. However I saw that the output is a random unrelated string.
I created my own implementation and called both implementations one after the other in order to compare results:

Here are the results, screenshotted from my XCode debugging session:


On the left is an ioRegistryExplorer window showing the device "USB device signature", on the right are the results strings.
As you can see the current OSquery implementation is getting it wrong both times.

I even created a unit test locally in order to double check. This time I used a C-style byte array, as this is what "Data" really is.

As you can see the current implementation gets it wring again.

[zwass]

This doesn't seem quite right. I built this and did a test:

./osquery/osqueryi --line 'select * from kernel_info'
  version = 23.3.0
arguments = 00
     path = /626f6f745c53797374656d5c4c6962726172795c4b65726e656c436f6c6c656374696f6e735c426f6f744b65726e656c457874656e73696f6e732e6b6300
   device = 21A635EB-E18F-4DC4-B278-460058A54CD0

With osquery 5.11.0:

osqueryi --line 'select * from kernel_info'
  version = 23.3.0
arguments = %00
     path = /boot/System/Library/KernelCollections/BootKernelExtensions.kc
   device = 21A635EB-E18F-4DC4-B278-460058A54CD0

Notably, path seems to be corrupted with the changes.

[zwass]

I'm doing some testing and this seems to work well on initial testing:

std::string stringFromCFData(const CFDataRef& cf_data) {
  return std::string(reinterpret_cast<const char*>(CFDataGetBytePtr(cf_data)),
                     CFDataGetLength(cf_data));
}

Here's the output I get

./osquery/osqueryi --line 'select * from kernel_info'
  version = 23.3.0
arguments =
     path = /boot/System/Library/KernelCollections/BootKernelExtensions.kc
   device = 21A635EB-E18F-4DC4-B278-460058A54CD0

I'm going to work on a new PR that implements this and a unit test.

[zwass]

Ah, but now I notice that the issue seems to be that you are looking for a hex encoding of binary data, while osquery is looking for a UTF8 string?

[zwass]

Sorry for all the chatter. I've now looked at the osquery implementation and it seems to try to provide printable characters as their original and unprintable as hex encoded. Wondering what a good compromise is here.

[zwass]

It's not clear what the "right" behavior is, but I don't think we can proceed with these changes that turn the path column of kernel_info from human-readable to not.

[SilverPlate3]

@zwass Sorry, unable to reproduce.
I get:

osqueryi --line 'select * from kernel_info'
version = 23.3.0
arguments = 
path =
device =

Even when I run with sudo.
Any idea what I am missing?
MacOs Ventura 13.2.1

[zwass]

I'm on Sonoma 14.3 with an Intel processor. I don't know if the difference might be the OS version or perhaps you are on Apple Silicon?

[SilverPlate3]

@zwass Indeed I am on an apple silicon M1.
I will try to follow the code and understand why I don't get any output.
However I think I know what is the problem.
In more unit tests I did, if the input is a well formatted string already, the current implementation of stringFromCFData works fine, and my implementation breaks it.
However, if its a well formatted string already, we shouldn't use stringFromCFData but just convert it to a std::string.
stringFromCFData needs to handle hex in my opinion.
Ill try to prove it.