DarwinDumper

[Maniac10]

Here's the dump for version 0.40: dump_203435.zip

 

I can try booting in UEFI mode but my BIOS is actually a hybrid, not full UEFI. Would you like it anyway?

[joe75]

http://www.mediafire.com/download/7ztq0lra14d27dw/dump_202635.zip

 

Ozmosis  

[blackosx]

@Maniac10 - Thanks for providing a dump with v0.40.

The script now correctly finds 12 tables from following your v1.0 RSDT. However you have helped find another bug where the script failed to look in the FACP for the FACS and DSDT address pointers.

I hope to have now fixed that and posted a revised v0.41 of the script to my original post for this.

Would it be possible to run another test please?

I can try booting in UEFI mode but my BIOS is actually a hybrid, not full UEFI. Would you like it anyway?

Thanks. But only if you wish to do so. No problem if you don't.

 

 

@joe75 - Thank you for testing also

This is the first example I've seen where no valid RSDP pointers have been found in the ACPI_NVS regions of memory.

Maybe the script needs to search other areas of memory?

[blackosx]

I've updated earlier post with v0.42 of the dumpACPIfromMem script.

The script itself has not changed but the pmem.kext driver has been replaced with a signed version from http://www.rekall-forensic.com

[joe75]

Im not sure why it doesn't find anything.. Maybe because tables are a little different on Z97?

[blackosx]

Actually.. looking at debug_resolve_rsdp_pointers.txt file from your supplied test I see you do actually have two valid XSDT tables.

My script grabbed the memory block 8 bytes early so therefore failed to read the signature. I'll look in to why...

 

EDIT: @joe75 - Can you try with version 0.43 when you get time please?

[Maniac10]

 

@Maniac10 - Thanks for providing a dump with v0.40.

The script now correctly finds 12 tables from following your v1.0 RSDT. However you have helped find another bug where the script failed to look in the FACP for the FACS and DSDT address pointers.

I hope to have now fixed that and posted a revised v0.41 of the script to my original post for this.

Would it be possible to run another test please?

 

Thanks. But only if you wish to do so. No problem if you don't.

 

Here's the dump with rev 0.42: dump_103600.zip

 

Tonight I'll upload a dump from UEFI.

[blackosx]

Thanks Maniac10. I'll take a look.

[Fabio1971]

Hello blackosx

 

Here you go

 

Fabio

dump_155849.zip

[blackosx]

Here's the dump with rev 0.42: dump_103600.zip

 

Tonight I'll upload a dump from UEFI.

Bingo! - That looks good from here. Thanks for your patience Maniac10

Can you confirm the AML_b0fa3040/DSDT-GBTUACPI.aml is your original BIOS table?

@.::Fabio::. - Thank you for your test too.

It looks good here, both patched and original tables.

That's a large DSDT!

Can you confirm which loader used to boot that system please?

[Andy Vandijck]

I've tested your dump script.

It successfully dumped both original and patched tables from memory.

It did however skip one SSDT table because of the size (> 1MB, why?)

I'm using Clover R2815 (my own custom blend) in UEFI mode.

Attached dump for your review

dump_162206.zip

[blackosx]

Thanks for your test Andy

The SSDT table skipped was

"CPU0IST ", 
0xDB859018, 
0x000009AA,

Which you can see should be only 2474 bytes in size.

 

However the address pointer points to invalid data.

7B57D253EA58C8BA

This should be the table signature and size which is clearly wrong.

I've seen this problem in a few dumps and seems quite common.

 

I have put that 1MB limit in place to prevent the script from trying to dump what would be, in this case, 3931687098 bytes.

 

 

EDIT: I've revised the script to now v0.44 to check for non-original SSDT Cpu-Pm tables, such as PM tables generated by Revogirl/Pike's  SSDT-PR gen script. This should prevent you seeing the incorrect, %D4_~-%E8%E2%8E%FF.aml and @%9Df.aml files

[Maniac10]

Bingo! - That looks good from here. Thanks for your patience Maniac10

Can you confirm the AML_b0fa3040/DSDT-GBTUACPI.aml is your original BIOS table?

 

I'll do a dump with Clover and compare them tonight (can't reboot for now).

 

This it the dump with v0.43: dump_124006.zip

[blackosx]

I'll do a dump with Clover and compare them tonight (can't reboot for now).

 

This it the dump with v0.43: dump_124006.zip

I see that v0.43 now finds one extra RSDP pointer..

ACPI v1.0 Checksum 00 is valid.
Pointer is valid and correctly resolves to an RSDT table.
Rev:00 | RSDT:b0c2a038 | Checksum:00 | Valid

Have you rebooted since last dump?

It's great to see some positive results coming in. As I'm seeing multiple RSDP pointers in these dumps I will have to figure out the best way to incorporate this in to DarwinDumper... For example, would it be best to just dump all pointers as this script currently does?

 

Has anybody experienced a freeze/crash from running the script?

 

Is anyone booting using Chameleon willing to test?

 

I haven't forgotten about your dump kynnder...

[Fabio1971]

@ blackosx

Can you confirm which loader used to boot that system please?

Clover 2795

 

Fabio

[Maniac10]

Have you rebooted since last dump?

 

Yes, and also these last two dumps were done from Mavericks and the other 2 from Yosemite.

[blackosx]

Clover 2795

Thanks for the confirmation .:Fabio:.

But was it CloverEFI or UEFI Clover?

Yes, and also these last two dumps were done from Mavericks and the other 2 from Yosemite.

Thanks for the confirmation.

Which loader was used for your 2 dumps?

 

EDIT: Oops.. Sorry I see you already told me; Clover EFI. 

Hi blackosx

I think you will be able to use this method to dump video/system roms as well.

Yeah.. Slice showed this with his kernel memory dumper

I'd been wanting to use it for a while but it was 32bit only. So since Andy posted pmem.kext it's got me interested again..

 

So the question is, can we get more video rom data from direct memory than we can get already with the existing tools in DarwinDumper?

[bs0d]

you maybe able to read them directly from the cards this would also permit reading cards that haven't posted.

 

since usually only 1 video bios can be active in the legacy region.

 

most of the boot loaders have code for retrieving the rom directly from cards, this should be possible with a kext,

[Fabio1971]

Thanks for the confirmation .:Fabio:.

But was it CloverEFI or UEFI Clover?

 

UEFI Clover

 

Fabio

[stehor]

dump from asrock z97extreme6 bios 1.30  https://www.dropbox.com/s/kly7yopeeq44q5f/FirmwareMemoryMap.txt

[joe75]

http://www.mediafire.com/download/vi7o95i6dz352r1/dump_205035.zip

 

0.44 got it

[Maniac10]

Ok, here are the dumps for both boot, legacy and "UEFI" (hybrid actually).

 

dump_220540_CloverEFI.zip

dump_225514_hybrid_CloverUEFI.zip

[blackosx]

Well on my Z77pro3, can't dump bios, must be protected.

Also doesn't dump whole VBios, like legacy/UEFI. i.e 66k NOT 132K

Okay. I'll take a look once I'm happy with the ACPI dumps.

you maybe able to read them directly from the cards this would also permit reading cards that haven't posted.

 

since usually only 1 video bios can be active in the legacy region.

 

most of the boot loaders have code for retrieving the rom directly from cards, this should be possible with a kext,

Thanks for the info bs0d.

UEFI Clover

Thanks for the confirmation .::Fabio::.

dump from asrock z97extreme6 bios 1.30  https://www.dropbox.com/s/kly7yopeeq44q5f/FirmwareMemoryMap.txt

Why have you posted a link to the FirmwareMemoryMay trace script?

If you wish to provide a test result then please supply the dump_<TIME> directory created after double-clicking the 'dumpACPIfromMem.command' script.

http://www.mediafire.com/download/vi7o95i6dz352r1/dump_205035.zip

 

0.44 got it

Great!.. Thanks for confirming joe75

I notice your system has an SSDT with table ID CpuSsdt with links to four further tables (well 3 as I'm willing to bet the first address pointer will be invalid). The script had only been checking for a table ID of CpuPm so this table of your was missed.

I've fixed that in v0.45 of the script.

Ok, here are the dumps for both boot, legacy and "UEFI" (hybrid actually).

 

dump_220540_CloverEFI.zip

dump_225514_hybrid_CloverUEFI.zip

Thanks Maniac10 - checking now.

 

EDIT:

AML_b0fa3040 from both dumps contains your original tables.

AML_00000000b0dcd000 and AML_00000000b0c28000 contain your patched tables. There are slight differences in the DSDT of those dumps but that may be down to bootloader configs.

 

v0.45 of the script will leave you with a cleaner dump folder as the invalid AML_00000000b0c2a120 and AML_b0c2a038 directories will no longer be present.

 

Thanks for testing.

@kynnder - I've been thinking about your dump and am thinking along the lines that Clover's on-the-fly DSDT fixes patch the tables directly in memory. So maybe that's why your dump shows only the clover auto patched one. I don't make use of Clover's auto DSDT patching so have nothing else for comparison - I will have to test it here to be certain. But otherwise, ACPI table dumps from the script when booting with Clover UEFI are working..

[joe75]

http://www.mediafire.com/download/82aum39igr9733r/dump_074404.zip

 

now we're talking!  looks like it got them all now. the SSDT-ami7hdm3 is the SSDT i inject with Oz and is from RampageDevs haswell pkg if you were wondering about the name

[blackosx]

Thanks for the report joe75.

It's great the script has detected all your tables, however as far as I can tell, it has not dumped your original bios DSDT.

The DSDT in the AML_00000000dcd87078 directory does not successfully decompile here using iASLme

Could not parse ACPI tables, AE_AML_NO_OPERAND

and MacIASL reports:

iASL returned:
ACPI Warning: Incorrect checksum in table [DSDT] - 0x41, should be 0xC8 (20100331/tbutils-351)]

I saw a similar issue trying to decompile a dumped DSDT from my hack when booted using Clover UEFI. The error was different, but I still couldn't open it.

 

EDIT: Now back on my hack and examining some of my tests I can surmise:

 

Dumping Original Tables:

Booting with Chameleon, Clover EFI, Clover UEFI and Ozmosis.

Memory region 00000000cabb1000 - 00000000cabb9fff provides RSDP pointer to XSDT at 00000000cabb1060

All tables are fine except DSDT which proves to be corrupt.

 

Booting with Chameleon, Clover EFI and Ozmosis. 

Memory region 00000000ca93f000 - 00000000cab91fff provides RSDP pointer to XSDT at 00000000cab84070

All tables are fine including DSDT.

 

Dumping Patched Tables:

Booting with Clover UEFI.

Memory region 00000000ca93f000 - 00000000cab91fff provides RSDP pointer to XSDT at 00000000cabc2000

All Tables are fine including DSDT

 

Booting with Chameleon, Clover EFI and Ozmosis

Memory region 00000000cab92000 to 00000000cabc3fff provides RSDP pointer to XSDT at 00000000cabc0070

All tables are fine including DSDT.

 

Conclusion:

I can’t get original DSDT using Clover UEFI.

 

EDIT: Some more thoughts on why the original DSDT may be corrupt when following XSDT at 00000000cabb1060...

 

I was thinking maybe the data inside the ACPI_recl region was being overwritten as ACPI_recl regions are reclaimable (meaning the OS can re-use this area once booted). And indeed I did find some DMI info in one supposed DSDT data dump.

 

The memory map in this instance was:

ACPI_NVS   00000000cabb1000 - 00000000cabb4fff   = 16,383 bytes
ACPI_recl  00000000cabb5000 - 00000000cabb7fff   = 12,287 bytes
ACPI_NVS   00000000cabb8000 - 00000000cabbefff   = 28,671 bytes
                                         Total   = 57,341 bytes

 

The DSDT (length of 47,866) was found at 00000000cabb1128, so that means 296 bytes in to first ACPI_NVS region and spanning across ACPI_recl region and in to next ACPI_NVS region taking it up to 00000000cabbcafa.

 

Thing is though, the DSDT corruption doesn’t really happen until after 0x6ED6 (28374 bytes) (which is the combined sum of ((16383-296)+12287). Meaning the corruption happens in the ACPI_NVS region which AFAIK is supposed to remain untouched by the OS.

 

So I'm not sure what to think ATM.