Jump to content
  • Announcements

    • Allan

      Forum Rules   04/13/2018

      Hello folks! As some things are being fixed, we'll keep you updated. Per hour the Forum Rules don't have a dedicated "Tab", so here is the place that we have our Rules back. New Users Lounge > [READ] - InsanelyMac Forum Rules - The InsanelyMac Staff Team. 

26 posts in this topic

Recommended Posts

great compilation, many thanks :)

Share this post


Link to post
Share on other sites

Wew @manor thankyou for testing. The value inside <> should be base64 encoded data later in xml output. Although why did you have some strange port name on your ati card?

Share this post


Link to post
Share on other sites

Wew @manor thankyou for testing. The value inside <> should be base64 encoded data later in xml output. Although why did you have some strange port name on your ati card?

I was used nvidia card I dint change my DSDT.Thank you for note that.I will fix that.

 

How to run HDAVerbsAnalyzer

Valid args:

  yod-HDAVerbsAnalyzer.php <string> (1 line)

  yod-HDAVerbsAnalyzer.php <file>

manoranjans-Mac-Pro:~ manoranjan$ 

Share this post


Link to post
Share on other sites

Just like his father, put ConfigData (check source for example or something like this) as args / file contain that ConfigData

yod-HDAVerbsAnalyzer.php \
01171F99 01171C10 01171D01 01171E43 \
01471C20 01471D40 01471E01 01471F01 01470C02 \
01571C30 01571D10 01571E01 01571F01 \
01671C40 01671D60 01671E01 01671F01 \
01771C50 01771D20 01771E01 01771F01 \
01871C60 01871D98 01871EA1 01871F01 \
01971C70 01971D9C 01971EA1 01971F02 \
01A71C90 01A71D30 01A71E81 01A71F01 \
01B71CA0 01B71D4C 01B71E21 01B71F02 01B70C02 \
01E71CB0 01E71D61 01E71E45 01E71F01

Share this post


Link to post
Share on other sites

**Update: Able to parse: xml -> hex | hex -> xml

Reorder blocks below to change mode in script header

Master please test

// Dummy sample XML -> HEX
$settings->ifile_type = FILE_XML;
$settings->ofile_type = FILE_HEX;
$settings->ifile = dirname(__FILE__) . "/dump2.xml";
$settings->ofile = dirname(__FILE__) . "/dump2.hex";


// Dummy sample HEX -> XML
$settings->ifile_type = FILE_HEX;
$settings->ofile_type = FILE_XML;
$settings->ifile = dirname(__FILE__) . "/dump.hex";
$settings->ofile = dirname(__FILE__) . "/dump.xml";

Share this post


Link to post
Share on other sites

POC swapping ioreg serial (or maybe other sensitive datas, later upped to repos) by "X" before give it to stranger like you  :( 

#!/usr/bin/php
<?php
# SerialKiller
# @cecekpawon 04/29/2016 11:37 AM
# thrsh.net

$input = "input.ioreg";
$output = "output.ioreg";

$dir = dirname(__FILE__);
$input = $dir . "/{$input}";
$str = @file_get_contents($input);

/*
$a = array(
  "IOPlatformSerialNumber" => "(IOPlatformSerialNumber.*?string>+)([^<]+)",
  "serial-number" => "(serial\-number.*?data>+)([^<]+)",
  );
*/

function swap($str) {
  return str_repeat("X", strlen($str));
}

$rgx = "#(>IOPlatformSerialNumber<.*?string>+)([^<]+)#is";
if (preg_match($rgx, $str, $m)) {
  $serial = $m[2];
  $new_serial = swap($serial);
  $tmp = "$1" . $new_serial;
  $str = preg_replace($rgx, $tmp, $str);
}

$rgx = "#(>serial\-number<.*?data>+)(.*?)([a-z0-9\+\/\=]+)(.*?<\/data>+)#is";
if (preg_match($rgx, $str, $m)) {
  $tmp = bin2hex(base64_decode(trim($m[3])));
  $tmp = str_ireplace(bin2hex($serial), bin2hex($new_serial), $tmp);
  $tmp = base64_encode(hex2bin($tmp));
  $str = preg_replace($rgx, "$1" . "$2" . $tmp . "$4", $str);
}

@file_put_contents($dir . "/{$output}", $str);

Share this post


Link to post
Share on other sites

I found an an issue in yod-GfxUtil.php while looking at the device-properties from a MacBookPro 2015.

 

The issue occurs when there's an empty property:

ioreg -lw0 -p IODeviceTree -n efi -r -x > ~/ioregdevicetree.txt
grep 'device-properties" = <' ~/ioregdevicetree.txt | sed 's/.*<//;s/>.*//;' > ~/deviceproperties.hex
xxd -p -r ~/deviceproperties.hex ~/deviceproperties.bin
xxd ~/deviceproperties.bin ~/deviceproperties.txt
cd ~/Downloads/OSXOLVED-master/
./yod-GfxUtil.php -h
./yod-GfxUtil.php -i hex -o xml ~/deviceproperties.hex ~/deviceproperties.plist

Error: ReadBinary: empty val (length)!
 

 

I think you have to remove or modify this line:

error("ReadBinary: empty val (length)");
 

When you do that, the plist file is created, but there's an error if you try to open it in Xcode:

plutil ~/deviceproperties.plist
/Users/joevt/deviceproperties.plist: Encountered empty <data> on line 55

sed -n -E "55 p" ~/deviceproperties.plist
      <data/>
plutil and xcode don't like that empty <data/> tag. They will accept <data></data> though:

 

plutil ~/deviceproperties.plist
/Users/joevt/deviceproperties.plist: OK

There is an unrelated issue with verbose output where all the keys have a null character (which I've replaced with ¿ below as BBEdit.app would display them):

...
+-o PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) <size=69508, records=69>
|   {
|     "ATY,EFIVersion¿"=<30312e30302e373737>
|     "ATY,EFICompileDate¿"=<4d61722020352032303135>
|     "ATY,Rom#¿"=<3131332d4335363730452d373737>
|     "ATY,EFIVersionB¿"=<3131332d4335363741312d303036>
...
|     "ATY,RefCLK¿"=<8c0a0000>
|     "VRAM,totalMB¿"=<00080000>
|     "ATY,MemVendorID¿"=<0300>
|     "ATY,MemRevisionID¿"=<0000>
|     "ATY,PlatformInfo¿"=<>
...
The "ATY,PlatformInfo" property is an example of an empty property.

Share this post


Link to post
Share on other sites

Thanks for testing @joevt. Honestly I created this port while ago with poor valid datas/samples, and sadly I cannot found any dump for that model like yours (with AMD card) from internet to test. Would you drop here your bin/hex dump to take a look? Is original gfxutil give you correct values?

 

If no "-i" specified, we can use "-f" to auto grab from registry (file on repo currently broken with this arg).
Here my attempts to fix verbose output (with trim / echo printable str) and "-f" arg.
TODO: Maybe next we can force to allow empty values with valid "data" type / tag.

yod-GfxUtil.php -f -v -o xml deviceproperties.plist > log.txt

please compare

yod-GfxUtil.php.zip

Share this post


Link to post
Share on other sites

Thanks for testing @joevt. Honestly I created this port while ago with poor valid datas/samples, and sadly I cannot found any dump for that model like yours (with AMD card) from internet to test. Would you drop here your bin/hex dump to take a look? Is original gfxutil give you correct values?

 

If no "-i" specified, we can use "-f" to auto grab from registry (file on repo currently broken with this arg).

Here my attempts to fix verbose output (with trim / echo printable str) and "-f" arg.

TODO: Maybe next we can force to allow empty values with valid "data" type / tag.

yod-GfxUtil.php -f -v -o xml deviceproperties.plist > log.txt
please compare

 

Sorry I didn't catch your reply until now. I thought I would receive an e-mail notification but maybe I forgot to follow the thread.

 

It looks like the original gfxutil does not have an error with the verbose output or with the empty <data></data>. I've attached the version of gfxutil that I'm using. I forget where it came from.

 

The fix for the verbose output of the php script seems to work. I like the fix for the registry grab so it doesn't require an input file name. I've attached the results. I removed the line from the php script that causes an error message to display when an empty property is encountered. I also added default file types to match the functionality described by the help text.

 

To make the xml compatible with Xcode, and plutil, maybe you can output the xml to a string in the php script, then do a search for <data/> and replace with <data></data> before outputting the string to file?

 

I think the proper way to fix verbose output is to assume that a key's length includes a terminating null, and you should verify that the null is there (output an error if it isn't) and remove only the null from the key. This way you won't hide any other problems (there shouldn't be any other non-printable characters in the key).

joevt_GfxUtil.zip

Share this post


Link to post
Share on other sites

Hello,

I finally found an additional "LIBXML_NOEMPTYTAG" libxml constant here to avoid self closing tags like "<data/>". Also thanks for default in/out type if currently unset. New version 1.8 is up, please update :)

./yod-GfxUtil.php -u

Share this post


Link to post
Share on other sites

Hello,

 

I finally found an additional "LIBXML_NOEMPTYTAG" libxml constant here to avoid self closing tags like "<data/>". Also thanks for default in/out type if currently unset. New version 1.8 is up, please update :)

./yod-GfxUtil.php -u

 

Good find. I've done some testing and it works, except it has a problem with device-properties generated by Clover where one of the device paths has no properties. That's probably a problem in Clover, but I think GfxUtil should be able to handle that and give a warning. I've made some changes to fix that, plus more debugging, plus verification of the key string (length > 0, includes terminating null, length is even because 16 bit unicode characters).

 

I've attached the device-properties sample so you can see what I mean, and a copy of the results and updated script.

joevt_GfxUtil2.zip

Share this post


Link to post
Share on other sites

Yes, I can confirm that original gfxutil can handle device with empty property, and your workaround was running perfectly during my test with your supplied bin data. About the warning, I decide to add "-x" option for debugging purpose, is it ok? Originally Verbose ("-v") is just to print whole device tree, I just extend it to print xml result. While Print ("-p") is to print the final output into screen instead of file. Here my modified script base on yours to test.

./yod-GfxUtil.php -vsnxi bin devicepropertiesGigaMac.bin devicepropertiesGigaMac.plist > devicepropertiesGigaMac.txt

Share this post


Link to post
Share on other sites

Yes, I can confirm that original gfxutil can handle device with empty property, and your workaround was running perfectly during my test with your supplied bin data. About the warning, I decide to add "-x" option for debugging purpose, is it ok? Originally Verbose ("-v") is just to print whole device tree, I just extend it to print xml result. While Print ("-p") is to print the final output into screen instead of file. Here my modified script base on yours to test.

./yod-GfxUtil.php -vsnxi bin devicepropertiesGigaMac.bin devicepropertiesGigaMac.plist > devicepropertiesGigaMac.txt

 

Works good. You fixed some other bugs too. Only thing I would change is this (move debug out of the loop):

function readbytes($a, $s, $l) {
  $r = ""; $l += $s;
  for ($i=$s; $i < $l; $i++) {
    $r .= $a[$i];
  }
  debug("%07x: readbytes:%s\n", $s, $r);
  return $r;
}

Share this post


Link to post
Share on other sites

Hello lord,

Thanks for correction :P

And now, Im trying to bring back original "-f" switch from given name to retrieve its device path:

./test.php -f ethernet
DevicePath = PciRoot(0x0)/Pci(0x19,0x0)

./test.php -f display
DevicePath = PciRoot(0x0)/Pci(0x2,0x0)

./test.php -f hdef
DevicePath = PciRoot(0x0)/Pci(0x1b,0x0)

 

 

#!/usr/bin/php
<?php

/*
gfxutil: [command_option] [other_options] infile outfile
Command options are:
-f name   finds object devicepath with the given name from IODeviceTree plane

./gfxutil -f hdef
DevicePath = PciRoot(0x0)/Pci(0x1b,0x0)
*/

$is_Terminal = (bool) isset($_SERVER["TERM_PROGRAM"]);

//if ($is_Terminal) passthru("clear");

function dump($value) {
  die(var_dump($value));
}

function passVar($str) {
  ob_start();
  passthru($str);
  return trim(ob_get_clean());
}

function todevpath($str) {
  $values = explode("/", $str);

  $part = array();

  /*
    From docs:
      IOACPIPlane:/_SB/PCI0@0/HDEF@1b0000

      HDEF@xxxxyyyy - (add leading zeros)
      xxxx - pci device
      yyyy - pci function
  */


  foreach ($values as $value) {
    if (count($part)) {
      preg_match("/^(\w+)@(\w+)$/i", $value, $matches); // HDEF@1b0000
      if (count($matches) == 3) {
        # fill with leading zeroes: 1b0000 -> 001b,0000
        $value = str_pad($matches[2], 8, '0', STR_PAD_LEFT);

        if (!($device = ltrim(substr($value, 0, 4), '0'))) { # device
          $device = "0";
        }

        if (!($function = ltrim(substr($value, 4), '0'))) { # function
          $function = "0";
        }

        $part[] = "Pci(0x{$device},0x{$function})";
      }
    } else { // PCI0@0
      preg_match("/^PCI(\w+)@(\w+)$/i", $value, $matches);
      if (count($matches) == 3) {
        $part[] = "PciRoot({$matches[1]}x{$matches[2]})";
      }
    }
  }

  printf("DevicePath = %s\n", implode("/", $part));
}

function getdevpath($dom, $str) {
  $els = $dom->getElementsByTagName("key");

  foreach ($els as $el) {
    # Should have value (skip empty tag to next: <key/><#textnode/><value/>).
    if ($val = $el->nextSibling->nextSibling->nodeValue) {
      # Found matched key: 'acpi-path'.
      if ((strcasecmp($el->nodeValue, "acpi-path") == 0) && stristr($val, $str)) { # key: 'acpi-path'
        $ret = $val;
        break;
      }

      # Found matched key: 'name' /  'IOName'. Search for 'acpi-path' key from its parent.
      elseif (stristr($el->nodeValue, "name") && stristr($val, $str)) { # key: name / IOName
        $els2 = $el->parentNode->childNodes;

        foreach ($els2 as $el) {
          if (
            (strcasecmp(($key = $el->nodeName), "key") == 0) &&
            (strcasecmp(($val = $el->nodeValue), "acpi-path") == 0)
          ) {
            $ret = $el->nextSibling->nextSibling->nodeValue;
            break 2;
          }
        }
      }
    }
  }

  if ($ret) {
    $ret = todevpath($ret);
  }

  return $ret;
}

if (count($argv) !== 3) {
  ###: start: test name
  $s = "display";
  $s = "ethernet";
  $s = "hdef";
  ###: end: test name
} else {
  $s = $argv[2];
}

$bp = passVar("ioreg -a -d4 -p IODeviceTree -c IOPCIDevice");

//dump($bp);

$dom = new DOMDocument;
$dom->loadXML($bp);

$s = getdevpath($dom, $s);

echo $s, PHP_EOL;

 



If you have time, please check out :)

Share this post


Link to post
Share on other sites

And now, Im trying to bring back original "-f" switch from given name to retrieve its device path:

./test.php -f ethernet
DevicePath = PciRoot(0x0)/Pci(0x19,0x0)

./test.php -f display
DevicePath = PciRoot(0x0)/Pci(0x2,0x0)

./test.php -f hdef
DevicePath = PciRoot(0x0)/Pci(0x1b,0x0)
If you have time, please check out :)

 

I've attached my results (bottom of the BBEdit.app worksheet file) for 3 computers: MacBook Pro 2015, MacPro 2008, Hackintosh

Looks like HDEF is the only option that worked on all 3.

joevt_GfxUtil_F_test.zip

Share this post


Link to post
Share on other sites

Thank you for testing. For me, current script seem to working as expected. So user have to be more specific when giving a 'name' to search?

Yes, matched word 'hdef' exists in 'acpi-path' (IOACPIPlane:/_SB/PCI0@0/HDEF@1b0000), and 'display' in 'IOName'.
I made a small modification to parse base64 encoded 'name' like in your MacBook below, just in case:

 

 

 

<key>IOName</key>
<string>display</string>
<key>IOObjectClass</key>
<string>IGPU</string>
...
<key>acpi-path</key>
<string>IOACPIPlane:/_SB/PCI0@0/IGPU@20000</string>
...
<key>graphic-options</key>
<data>
DAAAAA==
</data>
<key>hda-gfx</key>
<data>
b25ib2FyZC0xAA==
</data>
<key>model</key>
<data>
SW50ZWwgSXJpcyBQcm8A
</data>
<key>name</key>
<data>
ZGlzcGxheQA=
</data>

 

 

function getdevpath($dom, $str) {
  $els = $dom->getElementsByTagName("key");

  foreach ($els as $el) {
    # Should have value (skip empty tag to next: <key/><#textnode/><value/>).
    if ($val = $el->nextSibling->nextSibling->nodeValue) {
      if (($decoded = base64_decode($val, true)) !== false) {
        $val = $decoded;
      }

Share this post


Link to post
Share on other sites

Thank you for testing. For me, current script seem to working as expected. So user have to be more specific when giving a 'name' to search?

Yes, matched word 'hdef' exists in 'acpi-path' (IOACPIPlane:/_SB/PCI0@0/HDEF@1b0000), and 'display' in 'IOName'.

I made a small modification to parse base64 encoded 'name' like in your MacBook below, just in case:

I've attached some changes.

1) Verify assumption that key element is followed by whitespace.

2) Ignore values for dict and array elements.

3) Only do base64_decode for data elements.

4) Don't stop at first matching device.

 

 

Additional changes you can make:

 

1)

Name might not be enough. For example, my GigaMac doesn't have a device with name or path containing the string "display". I think that you should consider doing a regular expression match on the hex bytes of class-code. The PCI specification lists the possible class codes. Create a regular expression for ethernet, display and hdef then search for that like you do for name.

 

2)

Consider returning multiple results. Create a dictionary of acpi paths and return that as a list of line feed delimited paths, in case a computer has more than one display or ethernet or hdef. Use a dictionary so you don't add the same acpi path more than once (like when a device matches by more than one of name, acpi path, class code).

joevt_test.php.zip

Share this post


Link to post
Share on other sites

Hello Joevt,

Sorry for slow response brother. Correct me if Im wrong, from my perspective, the original purpose for this "-f" switch is to help users who want to manually create device-properties by translating device path from given name (I believe user should manually check their own IOreg to get those name, and not automatically by class-code / something else). Heres a note from original releases page: * New switch [-f name] it finds object devicepath with give name from IODeviceTree plane. I think a valid name (to scrap) should be exists, so detecting all available devices by class-code is (great but) not necessary in this case.

Yes I agreed with multiple output, since some devices do exists with same name, ex: "-f pci-bridge".

What i want to make sure here, is current script give you a valid/correct path? From your previously (Macbook) device-properties data there are device (I believe its an AMD discrete card) with following path: PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0). But I cannot found this device on your last MacProIOReg.plist. Is "ioreg -a -d4 -p IODeviceTree -c IOPCIDevice" not enough to list all available devices? ** The marked red is exactly what I want to make sure how to get it with correct way.

Added also parsing to device path "pcidebug" (instead of "acpi-path", with other interesting "IORegistryEntryLocation" key). Which do you prefer? We must choose one in final code to prevent confusions.

Share this post


Link to post
Share on other sites

I think a valid name (to scrap) should be exists, so detecting all available devices by class-code is (great but) not necessary in this case.

 

What i want to make sure here, is current script give you a valid/correct path? From your previously (Macbook) device-properties data there are device (I believe its an AMD discrete card) with following path: PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0). But I cannot found this device on your last MacProIOReg.plist. Is "ioreg -a -d4 -p IODeviceTree -c IOPCIDevice" not enough to list all available devices? ** The marked red is exactly what I want to make sure how to get it with correct way.

Right, I think the problem is that you limited the device depth to 4. If you take that parameter (-d4) out of the ioreg call, then it can find all the devices (except for ethernet on the MacBook Pro, which is using Airport instead).

 

Added also parsing to device path "pcidebug" (instead of "acpi-path", with other interesting "IORegistryEntryLocation" key). Which do you prefer? We must choose one in final code to prevent confusions.

I don't think depending on something with the word debug in it is the best choice? If you look at the results in my worksheet, the acpi-path results have the extra /Pci(0x0,0x0) device path node which is missing from the pcidebug results for the display devices.

 

Yes I agreed with multiple output, since some devices do exists with same name, ex: "-f pci-bridge".

My MacPro and GigaMac have multiple ethernet ports, so it's useful to be able to output more than one result for a device. But the different options may return the same device-path more than once. This is why I suggested that you should implement a dictionary for the results where the device-path is the key. Then each device-path can have information describing the ways that give that result, or the number of times that result was achieved.

 

I've attached the updated ioreg results, the modified test.php, and the updated test.php results (in the BBEdit worksheet file).

 

In the results, there is an invisible null character at the end of the "name" properties. When you convert from base64, you should remove a single terminating null character if it exists.

Share this post


Link to post
Share on other sites


./yod-GfxUtil.php -f -v -o xml deviceproperties.plist

GFX conversion utility version: 0.75b. Copyright (c) 2007 McMatrix
This program comes with ABSOLUTELY NO WARRANTY. This is free software!
--------------------------------------------------------------------------
PHP gfxutil v1.8 : @cecekpawon | thrsh.net
==========================================================================

Error: ReadBinary: cannot read blockrecords!

 

hello!

what does it mean?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.

×