About This Hack (2009-Nissan-Cube version migrated to SwiftUI)

[Slice]

Good!

[Alpha22]

About This Hack-glass 

 

 

[Max.1974]

About this Hack 👓  Glass  

 

 

 

[miliuco]

@Max.1974

 

I don't see the transparency, did you create the screenshot over dark wallpaper?

 

@kaoskinkae

 

I'm working on it, audio tab will be available only in Hackintoshes, not in real Macs, these have a different (and hard) way to get codec info, in this platform is not so important to get it.

 

Spoiler

 

[Max.1974]

2 hours ago, miliuco said:

@Max.1974

 

I don't see the transparency, did you create the screenshot over dark wallpaper?

 

@kaoskinkae

 

I'm working on it, audio tab will be available only in Hackintoshes, not in real Macs, these have a different (and hard) way to get codec info, in this platform is not so important to get it.

 

  Reveal hidden contents

 

 

 

Hi my friend, yes, my wallpaper was dark, so I printed another one.  

Thanks for this nice work !! 

 

 

 

 

 

Edited April 3 by Max.1974

[miliuco]

Added Audio tab with codec info. Only in Hackintosh, real Macs don't have the audio tab.

 

Spoiler

 

[kaoskinkae]

38 minutes ago, miliuco said:

Se agregó la pestaña de audio con información del códec. Solo en Hackintosh; las Macs originales no tienen esta pestaña.

 

  Revelar contenido oculto

 

good job

[jlrycm]

In my hackintosh the audio tab does not show any information. Is it possible that using VoodooHDA and eqmac causes the audio to be missing?

[miliuco]

@jlrycm

Maybe. I have to check this. Tell me, VoodooHDA loads AppleALC as the other method?

 

EDIT: I see AppleALC is not used. I guess that IOReg has a different paths. I'll try to fix this. 

Edited April 4 by miliuco

[kgp]

Thanks my friend for this awesome work. Just downloaded glass version 4.1.0 👍

Not that I would need it but just for completeness: I don't have any Audio button at all: OCLP + AppleALC + Realtek ALCS1220A 7.1

 

 

 

 

 

 

Edited April 4 by kgp

[Slice]

3 hours ago, miliuco said:

@jlrycm

Maybe. I have to check this. Tell me, VoodooHDA loads AppleALC as the other method?

 

EDIT: I see AppleALC is not used. I guess that IOReg has a different paths. I'll try to fix this. 

See how VoodooHDA is attached to Realtek ALC897 and AppleGFXHDA is attached to AMD RX570 HDMI Audio

iMac — Sergey.ioreg.7z

[Alpha22]

I set the layout ID to 1, but the app says 7, that’s not a problem

I don't know if it's a mistake

 

 

great app

Edited April 4 by Alpha22

[deeveedee]

@Alpha22 Is it possible that you have a layout-id defined in both DeviceProperties and boot-args?

[Alpha22]

27 minutes ago, deeveedee said:

@Alpha22 Is it possible that you have a layout-id defined in both DeviceProperties and boot-args?

only in DeviceProperties

[deeveedee]

@Alpha22 If you examine your IORegistry with IORegistryExplorer, do you see "layout-id = 7" in IORegistry?

 

EDIT: When I examine my IORegistry in Sequoia, I see the following:

 

 

 

 

I have layout-id = 11 in my DeviceProperties, but IORegistry shows layout-id = 7.  I don't think what you're observing is an "About This Hack" issue (unless "About This Hack" should be showing alc-layout-id instead of layout-id).

Edited April 4 by deeveedee

[robi62]

hi  I seem to have same problem too with audio???  

Could not see anything in in ioreg about the layout....

 

 

Edited April 4 by robi62

[miliuco]

Thank you all for your feedback.

Points to check:

• VoodooHDA: thanks @Slice for the ioreg, I'll compare it with AppleALC
• Layout id: is always right? 
• All 4.1.0 must have Audio tab, I'm afraid that I have uploaded a wrong version. 

 

[Alpha22]

11 hours ago, deeveedee said:

@Alpha22 If you examine your IORegistry with IORegistryExplorer, do you see "layout-id = 7" in IORegistry?

 

EDIT: When I examine my IORegistry in Sequoia, I see the following:

 

 

 

 

I have layout-id = 11 in my DeviceProperties, but IORegistry shows layout-id = 7.  I don't think what you're observing is an "About This Hack" issue (unless "About This Hack" should be showing alc-layout-id instead of layout-id).

Exactly, I wrote that thinking there was a mistake, but there’s no problem

 

what I see in IoReg:

[kgp]

Hi,

I noticed a reproducible issue when downloading and launching About This Hack 4.1.0 for the first time.

Before even allowing the app via Privacy & Security → Open Anyway, Avast Antivirus triggers the following alert:

“/usr/libexec/icloudwebd is trying to change or delete the file Photos.sqlite in your protected folder – we have blocked this action for you.”

 

 

 

Observations:

- This happens immediately after the first launch attempt

- The app has not yet been explicitly allowed (Gatekeeper still blocking it)

- The process involved (icloudwebd) is a legitimate Apple system service

- The file (Photos.sqlite) belongs to the Photos library

 

Possible explanation:
It looks like a false positive caused by Avast’s ransomware protection reacting to normal iCloud/Photos activity triggered indirectly during app initialization.

 

Additional note:
After this happens, some features inside About This Hack (e.g. Audio section/button) may not appear, possibly due to blocked system interactions.

 

Question:
Has anyone else observed this behavior?
Could this be related to how the app initializes system queries before being fully allowed by Gatekeeper?

 

Best regards
KGP

[jlrycm]

40 minutes ago, kgp said:

Hi,

I noticed a reproducible issue when downloading and launching About This Hack 4.1.0 for the first time.

Before even allowing the app via Privacy & Security → Open Anyway, Avast Antivirus triggers the following alert:

“/usr/libexec/icloudwebd is trying to change or delete the file Photos.sqlite in your protected folder – we have blocked this action for you.”

 

 

 

Observations:

- This happens immediately after the first launch attempt

- The app has not yet been explicitly allowed (Gatekeeper still blocking it)

- The process involved (icloudwebd) is a legitimate Apple system service

- The file (Photos.sqlite) belongs to the Photos library

 

Possible explanation:
It looks like a false positive caused by Avast’s ransomware protection reacting to normal iCloud/Photos activity triggered indirectly during app initialization.

 

Additional note:
After this happens, some features inside About This Hack (e.g. Audio section/button) may not appear, possibly due to blocked system interactions.

 

Question:
Has anyone else observed this behavior?
Could this be related to how the app initializes system queries before being fully allowed by Gatekeeper?

 

Best regards
KGP

I use Avast too but I have not noticed this behavior with About My Mac app.

[deeveedee]

This document explains that the appearance of alc-layout-id in IORegistry indicates that layout-id injection was successful.  AppleALC overrides the system's default layout-id (which remains unchanged in IORegistry).

 

@miliuco Based on this explanation of alc-layout-id, I think that "About This Hack" should be displaying alc-layout-id for hackintoshes that use AppleALC.

 

EDIT: When I use AppleALC on my hack (macOS Sequoia), Hackintool displays both ALC Layout ID and Layout ID

Spoiler

 

EDIT2: When I use VoodooHDA on my hack (macOS Tahoe), Hackintool does not display any layout IDs.

Spoiler

 

When I use VoodooHDA in macOS Tahoe, layout-ID in IORegistry is consistent with the layout-ID I specified in DeviceProperties

Edited April 5 by deeveedee

[miliuco]

@kgp

ATH has nothing to do with Photos.sqlite, I don't know what's the cause of this.

Maybe is a false positive and, after it, not all functionalities of ATH work. Not sure.

Anyway, the source code is available and there is no logic to access Photos.sqlite.

 

I'm checking VoodooHDA. IOReg is different, as expected, but since HDEF and VoodooHDA can be found, there is a way to get audio codec info.

In my system, I get this in Audio tab:

• Device ID: Intel Cannon Lake PCH cAVS (0x8086:0xA348)
• Layout ID: 7. (correct)

Thanks @deeveedee for the info, really i didn't know that alc-layout-id is the real layout used when AppleALC is enabled.

 

I have a question. I was thinking that AppleALC must be deactivated to use VoodooHDA. But I have noticed in my Hack that, with AppleALC disabled, there is no VoodooHDA device and, with AppleALC enabled, VoodooHDA works very well. Am I wrong about this?

 

Edited April 5 by miliuco
Typo

[deeveedee]

@miliuco On some hacks, VoodooHDA is preempted by AppleGFXHDA.  See explanation here.  AppleALC can be used as an "AppleGFXHDA blocker."  In this case, both AppleALC and VoodooHDA are loaded simultaneously.  This is only possible in macOS Tahoe, since Tahoe does not have AppleHDA.

Edited April 5 by deeveedee

[miliuco]

@deeveedee

Absolutely! I see my mind is failing.

This explains why I need AppleALC as a companion because I'm testing VoodooHDA in Tahoe. I saw you wrote about this months ago. Lack of attention on my part.

Question answered.

[jlrycm]

1 hour ago, deeveedee said:

@miliuco On some hacks, VoodooHDA is preempted by AppleGFXHDA.  See explanation here.  AppleALC can be used as an "AppleGFXHDA blocker."  In this case, both AppleALC and VoodooHDA are loaded simultaneously.  This is only possible in macOS Tahoe, since Tahoe does not have AppleHDA.

In my case I don’t have to block AppleGFXHDA like @deeveedee.