Jump to content
519 posts in this topic

Recommended Posts

Hi Slice

 

So are you saying a dmidecode dump from a system booted with Clover with SMBIOS v2.6 and newer would have the UUID in the byte order as the specification and not as my MacBook Pro?

Hmmm.... I have to follow Apple's rule to be sure to see UUID in System Profiler and in diskutility the same as written in ascii. But I don't know why we need to see SmUUID.

  • Like 1
Link to comment
Share on other sites

Hello man,

 

Did you also compare your 'Hardware UUID' from system_profiler with 'IOPlatformUUID' from ioreg?

Look the (officially) way they wrote & read that value? Is that looks identical for you?

Sorry, I choose 'IOPlatformUUID' as an example here because I dont have mac & cant found references how Apple display the (system-id) value in their way without any 3rd party :)

system_profiler SPHardwareDataType | awk '/UUID/ { print $3; }'
ioreg -rd1 -c IOPlatformExpertDevice | awk '/IOPlatformUUID/ { split($0, line, "\""); printf("%s\n", line[4]); }'

** My 'IOPlatformUUID' was auto generated by OS (because I didnt inject em / store fixed value with boot manager).

** I wont force you to update current dmidecode, please take it as reference :)

 
Yes. All other values checked and are correct. It's just the system-id which is incorrectly shown in cavaliercoder's dmidecode due to Apple not conforming to the SMBIOS spec.
 
ioreg system-id = DMI type 1 -> UUID
Your IOPlatformUUID is generated by the OS using the ioreg system-id.
 
That can be overridden by using one of:
Clover's SMBIOS/SMUUID, OZ SMBIOS/HardwareSignature, Chameleon's SMBIOS.plist/SMSystemUUID

Hmmm.... I have to follow Apple's rule to be sure to see UUID in System Profiler and in diskutility the same as written in ascii. But I don't know why we need to see SmUUID.

Diskuility? what's that to do with the output from dmidecode?

As far as I see here the values when booted using Clover are fine, but I don't have a SMBIOS version greater that 2.4 to check with to be sure, other than using Clover on my MacBook Pro.

  • Like 1
Link to comment
Share on other sites

ioreg system-id = DMI type 1 -> UUID

Your IOPlatformUUID is generated by the OS using the ioreg system-id.

 

Exactly.

 

In fact, the current v2.12b in DarwinDumper shows better explanation of some information

 

Well said, showing known Apple tables is a plus.

  • Like 3
Link to comment
Share on other sites

DarwinDumper has gone a while without any updates so I've pushed out v3.0.4.

 

Changes:

- Revised parsing of getcodecid result.
- Added Pike R. Alpha's' AppleIntelInfo.kext v2.9.
- Dump diskutil list unconditionally when running a disk scan.
- Include APFS and CoreStorage dumps when performing diskutil list.
- Added Pike R. Alpha's' lzvn tool for listing of prelinked kexts.
- Move kext dump out of section requiring elevated privileges.
- Limit kernel message log dump to 512KB.
- Limit disassembled ATI rom file to 1MB.
- Update Pike R. Alpha's' csrstat v1.8 for SIP with extended bits.
 
Edit: Oops forgot to add fix for case-sensitive file systems by Derek Zhu.
 
Previous versions should notify of the update, but otherwise here's a download link:
Edited by blackosx
  • Like 6
Link to comment
Share on other sites

  • 1 month later...
  • 2 months later...

Recent versions of macOS started to download firmware.scap files.

Do the darwindumper takes the fresh datum (acpi, smc, ...) if supplied by firmware.scap?

Real mac assumed.

Link to comment
Share on other sites

  • 4 weeks later...
Good evening everyone, like everyone else I was interested in the Hardware-Id "UUID "System Profiler" Utility I learned with the help of all that we could modify the UUID by modifying or creating the key" SMsystemid " in the "smbios.plist", but that the UUID injected by the key will never be the System Profiler's UUID Hardware-id, but that it will still be modified by UUID of key in "smbios.plist". At the boot there is application of a matrix or a hash, and I was able to find in the kernel the hash function SHA1 which is applied to the UUID of "system-id", a function of hash SHA1 which transforms this UUID in another UUID This transformed UUID is the one that appears in the System Profiler Utility and becomes the official UUID of your hardware (Imac, MacBook, MacPRO, Mac Mini) I found the answer to my question "Why?" is different from the hardware ID? "

below hardware-d uuid
ioreg -l -p IODeviceTree | grep \ "IOPlatformUUID \"

below "system-d" UUID
ioreg -l -p IODeviceTree | grep \ "system-id \"
it is with this one that we create the other (harware-id) after SHA1 hash
 
 
 
 
 
 
 
 
Link to comment
Share on other sites

I know this since Clover first release. The rule is follow

1. If we want determine UUID exactly same as in System Profiler then we have to set

                <key>CustomUUID</key>

           <string>511CE200-1000-4000-9999-010203040506</string>

and 

<key>InjectSystemID</key>

<false/>

 

2. If we want UUID same as with Chameleon then we took the digits from ioreg

IODeviceTree:/ef/platform=>system-id

use it as CustomUUID and set InjectSystemID=true

Link to comment
Share on other sites

For my part, I especially wanted to understand and find how a UUID we came to another UUID just by the boot and I found the answer in the kernel obviously.
Below is the SHA1 hash applied by the kernel to create the official UUID of Hardware-id
"
     SHA1_CTX context;

     const uuid_t space = {0x2A, 0x06, 0x19, 0x90, 0xD3, 0x8D, 0x44, 0x40, 0xA1, 0x39, 0xC4, 0x97, 0x70, 0x37, 0x65, 0xAC};
    
SHA1Init (& context);
     SHA1Update (& Context, space, sizeof (space));
     SHA1Update (& context, uuid, 16);
     SHA1Final (uuid, & context);
     uuid [6] = (uuid [6] & 0x0F) | 0x50;
     uuid [8] = (uuid [8] & 0x3F) | 0x80;

"
I prefer using Enoch to boot, and if I have to modify the UUID, I do it with smbios.plist, SMsystemid, with Clover it works very well too.
Edited by deek5
Link to comment
Share on other sites

  • 2 months later...
  • 6 months later...

hmmm.. thanks for the note.

 

I know AppleIntelInfo used to 'sometimes' cause a system freeze, especially on older Sandy Bridge CPU's but Pike's last update(s) fixed that. But as we know Pike's gone and no longer working on it so it's good to know that headkaze has picked it up. I wonder if the crashes are specific to 10.14 or just with specific CPUs?

 

I could change DarwinDumper to NOT run AppleIntelInfo when selecting the CPU dump?

Link to comment
Share on other sites

Yes, it is very dangerous. I catch the reboot on IvyBridge under 10.13.6.

I may propose that reading MSR requires CPU-dependency. We can't read all MSR from all CPU. But I am not sure in AppleIntelInfo details.

Link to comment
Share on other sites

  • 2 weeks later...

Hi @blackosx

I have i9-9980XE

If I run DarwinDumper getting panic when get CPU Information.

machdep.cpu.brand_string: Intel(R) Core(TM) i9-9980XE CPU @ 3.00GHz

  • Like 1
Link to comment
Share on other sites

On 1/18/2019 at 5:44 PM, Slice said:

Thanks Slice.

 

On 1/31/2019 at 9:36 PM, nmano said:

Hi @blackosx

I have i9-9980XE

If I run DarwinDumper getting panic when get CPU Information.

machdep.cpu.brand_string: Intel(R) Core(TM) i9-9980XE CPU @ 3.00GHz

 

Yeah. Slice mentioned the issue also.

When I get time I'll update DD to not include appleIntelInfo by default when running the CPU info dump.

  • Like 1
Link to comment
Share on other sites

14 minutes ago, blackosx said:

Thanks Slice.

 

 

Yeah. Slice mentioned the issue also.

When I get time I'll update DD to not include appleIntelInfo by default when running the CPU info dump.

Thanks @blackosx

Link to comment
Share on other sites

  • 4 months later...

Hi @blackosx thank you for your recent update of DarwinDumper, just to tell you that the URL as source for SMC_util3 is probably dead :( as ProjectOSX has been silent for long time, as far as I know.

http://www.projectosx.com/forum/index.php?s=&showtopic=2447&view=findpost&p=23230

Thank you.

Edited by MacKonsti
Link to comment
Share on other sites

  • 6 months later...

@blackosx

Sorry for intervention I want to present the DarwinDumper with follow changes

- exclude Pike R. Alpha's' AppleIntelInfo.kext v2.9. as it crashes on most CPU

- replace dmidecode by acidanthera version with more information

- replace gfxutil by joevt version https://github.com/joevt/gfxutil

- latest iasl version

- latest smcutil version

 

For users wanted to share their dumps I have to recommend:

- exclude BIOS dump as it very large

- exclude HTML report as it very large and contain no new information

- make dump private. You will not do this if you save the dump for own use

- archive as lzma. It is like 7z and create very compact archive. But there may be problems to unpack in Windows. More universal to archive as ZIP.

DarwinDumper-305.app.zip

  • Like 4
Link to comment
Share on other sites

Sorry, I forgot to exclude AppleIntelInfo

0xffffff91197fbec0 : 0xffffff80003ef715 
0xffffff91197fbf40 : 0xffffff80003ef2b5 
0xffffff91197fbfa0 : 0xffffff800035d0ce 
      Kernel Extensions in backtrace:
         com.pikeralpha.driver.AppleIntelInfo(2.9)[319606A5-8247-37F6-91F5-79DFF4ACA558]@0xffffff7f849ff000->0xffffff7f84a15fff

It is here

/DarwinDumper.app/Contents/Resources/public/drivers/AppleIntelInfo.kext

Move it to trash!

Link to comment
Share on other sites

  • 2 months later...
On 6/4/2013 at 5:28 PM, Andy Vandijck said:

 

Sources are included.

Enjoy ;)

RadeonPCI_AnV_Dong.zip

 

How to build it for new macOS?

(kernel) kxld[com.dong.driver.RadeonPCI]: The following symbols are unresolved for this kext:
(kernel) kxld[com.dong.driver.RadeonPCI]:     __ZN11IOPCIDevice20extendedConfigRead32Ey
(kernel) Can't load kext com.dong.driver.RadeonPCI - link failed.

Thanks!

Link to comment
Share on other sites

 Share

×
×
  • Create New...