Contribute
Register

Alternative to IORegistryExplorer: IOJones

Status
Not open for further replies.
Joined
Dec 3, 2010
Messages
460
Motherboard
Gigabyte GA-H55M-S2V
CPU
Intel i3-530
Graphics
HIS HD 6570
Mac
  1. iMac
Mobile Phone
  1. Android
I've been annoyed by the lack of support Apple has provided for IORegistryExplorer since 3.0 came out, the biggest issue being asymmetric open/save (IORE can't open the files it saves). Beyond that, the binary plists it creates aren't human-readable because they're created using NSArchiver. There's no sorting, no easy copy-paste, the source was long ago made private so it can't be easily extended. It crashes in certain circumstances, and doesn't even have an icon.
Instead of reverse-engineering the NSArchiver method IORE uses, I decided instead to create my own implementation, geared toward simplicity. All IOObject fields are still presented in the same way, the custom property formatting painstakingly copied, and opening the plist in any plist editor should show an easily understood structure in case the recipient doesn't want to use or have access to the app.
There are a couple shortcomings at the moment, the biggest being the customized tree view Apple created which has parent-child node drawings and also can outline other locations of the same object in a given plane. A couple of methods are unimplemented right now (will be permanently gray), but the major ones should work. Please let me know if you experience any problems by posting or linking to a crash report or Console log entries. IOJones will eventually be available in source and binary at http://iojones.sourceforge.net.

Jis8FUJ.png

Download v1.1 #74 from ge.tt
 

Attachments

  • IOJones.zip
    2.6 MB · Views: 3,103
Since PJ has told me he's using IOJones to receive files from users, I have updated this posted version with my own working copy, #70. Includes at least preliminary implementation of all supported functions, some additions for filtering efficiency, formatting, and better traversal of the IO planes. The file format has changed slightly, but this version is backwards compatible with the old format. Please replace your files when possible.
 
Since PJ has told me he's using IOJones to receive files from users, I have updated this posted version with my own working copy, #70. Includes at least preliminary implementation of all supported functions, some additions for filtering efficiency, formatting, and better traversal of the IO planes. The file format has changed slightly, but this version is backwards compatible with the old format. Please replace your files when possible.

Any thoughts of allowing it to read actual ioreg files? I realize that not even IORegistryExplorer can read its own files (recent distributions), but...
 
I have a couple of flags in the code, but the issue is (as I've explained to PJ), that the intimate ties between NSArchiver/NSUnarchiver to the classes which implement their protocols is a real problem. The way the objects are differently defined (which could be determined using a class dump or just `otool`) is only part of the issue. How the archiving methods are (mis)implemented in IORE, and produce almost unreadable data is the larger problem; open an ioreg file in a binary-plist reader (like TextWrangler, Xcode...) to see why. IORE represents a more technically-correct implementation of an ioreg explorer, but at the expense of usability.
My iojones format is human-readable and could easily be read by other apps if developers wanted to use it, everything is simply laid out, but still complete. There are only 5 top-level objects: bundles, classes, objects, planes, and system. In fact, iojones files are frequently smaller than ioreg, sometimes half the size. I could make them even smaller, for instance by inverting the bundles dictionary, but that would increase the computation necessary to unarchive the data.

--edit
I suppose if someone fully documented it I would take a look, as i have other priorities right now.
 
Do you think it would be possible to make an anonymize feature on export / save? it could just redact the serial number and any other identifying info you are aware of in the file but keep the relevant data safe. Alternatively, perhaps just an option to export a specific branch instead of the entire ioreg tree.

Thanks,
g\
 
Part of the point of having it archive in a human-readable format is you can redact anything you like. Just open the file in a plist editor, or better yet in TextWrangler. Search for whatever you like and replace the sensitive values.
Keep in mind that even if I took out IOConsoleUsers and serial-number, there's no preventing other nodes from containing sensitive information, no method will ever be complete. Those worried about privacy need to examine the output file and make their own decisions; having a simple file format makes this possible.
 
Part of the point of having it archive in a human-readable format is you can redact anything you like. Just open the file in a plist editor, or better yet in TextWrangler. Search for whatever you like and replace the sensitive values.
Keep in mind that even if I took out IOConsoleUsers and serial-number, there's no preventing other nodes from containing sensitive information, no method will ever be complete. Those worried about privacy need to examine the output file and make their own decisions; having a simple file format makes this possible.

ok thanks that makes sense. i guess i was just thinking of something similar to the privatize function of darwin dumper that would redact the known user identifiable or unique values. But you're right, there seems like there would be potential for other sections to contain private info and the best way is to do a manual review.
g\
 
DPCIManager does automatically "privatize" information provided in the flashrom reporter because that information and its structure are well-known, it's easy to find the local disk mentions. Additionally, the entire text is provided to the user so they can review before they decide to submit it. The IORegistry is entirely different and I wouldnt want to make any promises that turned out to be false.
 
Fixed a bug where a saved file might not contain all bundles and classes, though the file format itself is still sound. Also fixed a bug where documents might not deallocate when closed. A top-level exception handler was also added.
Efficiency fixes for the class and bundles sets, and determination of service type.
The tree is now sorted at load, and retain counts should match, like IORegistryExplorer. General code cleanup for clarity.
 
Status
Not open for further replies.
Back
Top