Contribute
Register

HP Folio 13 Guide! UNIBEAST + parts of MultiBeast

Status
Not open for further replies.
I'm back. It didn't work. But now I see a line in system.log that seems to be related to the injector.
As far as I know, it seems to be trying to load a the kext for SL instead the one for ML, Mavericks.

Code: 
Kext id com.apple.driver.AirPort.Atheros9388 not found; removing personalities from kernel

I'm attaching system.log + IOReg.

Thanks!
 

Attachments

  • Kext_Injector_Used.ioreg
    1.2 MB · Views: 165
  • system.log.zip
    357.8 KB · Views: 118
jackito said:
I'm back. It didn't work. But now I see a line in system.log that seems to be related to the injector.
As far as I know, it seems to be trying to load a the kext for SL instead the one for ML, Mavericks.

Code: 
Kext id com.apple.driver.AirPort.Atheros9388 not found; removing personalities from kernel
Click to expand...

Normal/expected.

I'm attaching system.log + IOReg.

Thanks!
Click to expand...

What is the output of 'kextstat|grep -y atheros' just after booting?
 
Code: 
$ kextstat | grep -y atheros
   67    0 0xffffff7f813d8000 0x14a000   0x14a000   com.apple.driver.AirPort.Atheros40 (700.74.5) <66 47 11 7 5 4 3 1>

I guess the kext is loaded, even doe wifi is not working. :(
 
jackito said:
Code: 
$ kextstat | grep -y atheros
   67    0 0xffffff7f813d8000 0x14a000   0x14a000   com.apple.driver.AirPort.Atheros40 (700.74.5) <66 47 11 7 5 4 3 1>

I guess the kext is loaded, even doe wifi is not working. :(
Click to expand...

It is loaded to run its IOService::probe. (eg. injector and/or DSDT edit is working). But it is failing probe due to the code in the binary checking for known hardware. OS X is lazy about unloading kexts that fail probe/start, so it is still loaded for a while (this is in case the kext is needed shortly after -- avoids another load/unload cycle). Eventually, you'll see it disappear with a enough time passing.

To make a rebrand work as 0032, you're going to need to patch the binary, to convince the driver it is really an 002a. If you're experienced with x86 machine code/assembly, you can see that the answer lies in the _ath_hal_probe function.
 
RehabMan said:
It is loaded to run its IOService::probe. (eg. injector and/or DSDT edit is working). But it is failing probe due to the code in the binary checking for known hardware. OS X is lazy about unloading kexts that fail probe/start, so it is still loaded for a while (this is in case the kext is needed shortly after -- avoids another load/unload cycle). Eventually, you'll see it disappear with a enough time passing.

To make a rebrand work as 0032, you're going to need to patch the binary, to convince the driver it is really an 002a. If you're experienced with x86 machine code/assembly, you can see that the answer lies in the _ath_hal_probe function.
Click to expand...

Got it. Unfortunatelly that kind of hack is beyond my knowledge.

I will search a little bit more to know if it's possible to get the whitelist from the BIOS in order to confirm if 0032 is the only device id allowed for 168c vendor. Who knows, maybe the added a couple more that are not document. Long shot I know.
The BIOS whitelist is a big show stopper here. We were sooo close....

In any case, thank you very much for all your time, replies and help!
It's really appreciated!
 
jackito said:
Got it. Unfortunatelly that kind of hack is beyond my knowledge.

I will search a little bit more to know if it's possible to get the whitelist from the BIOS in order to confirm if 0032 is the only device id allowed for 168c vendor. Who knows, maybe the added a couple more that are not document. Long shot I know.
The BIOS whitelist is a big show stopper here. We were sooo close....

In any case, thank you very much for all your time, replies and help!
It's really appreciated!
Click to expand...

You could try this patch... I based this off 10.9.5 kext:
Code: 
cd /System/Library/Extensions/IO80211Family.kext/Contents/PlugIns/AirPortAtheros40.kext/Contents/MacOS
sudo cp AirPortAtheros40 AirPortAtheros40.orig
sudo perl -pi -e 's|\x83\xc1\xf9\x83\xf9\x29|\x83\xc1\xf1\x83\xf9\x29|g' AirPortAtheros40
# verify that it made a change
md5 AirPortAtheros40.orig
md5 AirPortAtheros40
# trigger a cache rebuild
sudo touch /System/Library/Extensions

Be aware it could cause your build to crash. The patch attempts to treat 0x32 as 0x2a by subtracting an extra 0x08. It does so only in the previously mentioned function _ath_hal_probe. There may be other dependencies in the code on the specific device-ids (in which case this wouldn't be expected to work... more investigation would be necessary).
 
RehabMan said:
You could try this patch... I based this off 10.9.5 kext:
Code: 
cd /System/Library/Extensions/IO80211Family.kext/Contents/PlugIns/AirPortAtheros40.kext/Contents/MacOS
sudo cp AirPortAtheros40 AirPortAtheros40.orig
sudo perl -pi -e 's|\x83\xc1\xf9\x83\xf9\x29|\x83\xc1\xf1\x83\xf9\x29|g' AirPortAtheros40
# verify that it made a change
md5 AirPortAtheros40.orig
md5 AirPortAtheros40
# trigger a cache rebuild
sudo touch /System/Library/Extensions

Be aware it could cause your build to crash. The patch attempts to treat 0x32 as 0x2a by subtracting an extra 0x08. It does so only in the previously mentioned function _ath_hal_probe. There may be other dependencies in the code on the specific device-ids (in which case this wouldn't be expected to work... more investigation would be necessary).
Click to expand...

First of all thank you very much for all this effort. You don't have to do this and I really appreciate it.

I patched it and the build didn't crash.
This is what I got in system.log after reboot.
Let me know if you need any other information and thanks again.

Code: 
Oct  5 22:55:39 Fernandos-MacBook-Pro.local com.apple.kextd[12]: Kext id com.apple.driver.AirPort.Atheros9388 not found; removing personalities from kernel.
Oct  5 22:55:39 Fernandos-MacBook-Pro.local com.apple.kextd[12]: String/URL conversion failure.
Oct  5 22:55:39 Fernandos-MacBook-Pro kernel[0]: ATHR: devid[0x0032] not supported.
Oct  5 22:55:39 Fernandos-MacBook-Pro kernel[0]: 40.209619: ath_dev_attach: unable to attach hardware; HAL status 1
Oct  5 22:55:39 Fernandos-MacBook-Pro kernel[0]: 40.209646: ath_attach[5428]: Device attach failed!, error[-6]
Oct  5 22:55:39 Fernandos-MacBook-Pro kernel[0]: 40.209665: ath_cwm_detach: error - acw NULL. Possible attach failure
Oct  5 22:55:39 Fernandos-MacBook-Pro kernel[0]: 40.209707: start[957]: __ath_attach failed!, error[-6]
 
jackito said:
First of all thank you very much for all this effort. You don't have to do this and I really appreciate it.

I patched it and the build didn't crash.
This is what I got in system.log after reboot.
Let me know if you need any other information and thanks again.

Code: 
Oct  5 22:55:39 Fernandos-MacBook-Pro.local com.apple.kextd[12]: Kext id com.apple.driver.AirPort.Atheros9388 not found; removing personalities from kernel.
Oct  5 22:55:39 Fernandos-MacBook-Pro.local com.apple.kextd[12]: String/URL conversion failure.
Oct  5 22:55:39 Fernandos-MacBook-Pro kernel[0]: ATHR: devid[0x0032] not supported.
Oct  5 22:55:39 Fernandos-MacBook-Pro kernel[0]: 40.209619: ath_dev_attach: unable to attach hardware; HAL status 1
Oct  5 22:55:39 Fernandos-MacBook-Pro kernel[0]: 40.209646: ath_attach[5428]: Device attach failed!, error[-6]
Oct  5 22:55:39 Fernandos-MacBook-Pro kernel[0]: 40.209665: ath_cwm_detach: error - acw NULL. Possible attach failure
Oct  5 22:55:39 Fernandos-MacBook-Pro kernel[0]: 40.209707: start[957]: __ath_attach failed!, error[-6]
Click to expand...

There is probably more binary patching to do (probably a bunch more checks against valid range of Atheros ids). For example this code:
Code: 
00000000000721e6	movl	%esp, %ebp
00000000000721e8	pushq	%r14
00000000000721ea	pushq	%rbx
00000000000721eb	subq	$0x20, %rsp
00000000000721ef	movl	%edi, %eax
00000000000721f1	movq	0x20(%rbp), %r14
00000000000721f5	cmpw	$0x30, %ax
00000000000721f9	ja	0x722a6
00000000000721ff	movq	0x18(%rbp), %rbx
0000000000072203	movq	0x10(%rbp), %r10
0000000000072207	movabsq	$0x7e9800000800, %rdi   ## imm = 0x7E9800000800
0000000000072211	btq	%rax, %rdi
0000000000072215	jae	0x72288
0000000000072217	movq	%r14, 0x10(%rsp)
000000000007221c	movq	%rbx, 0x8(%rsp)
0000000000072221	movq	%r10, (%rsp)
0000000000072225	movzwl	%ax, %edi
0000000000072228	callq	_ar5416Attach
000000000007222d	xorl	%ebx, %ebx
000000000007222f	testq	%rax, %rax
0000000000072232	je	0x722c6
0000000000072238	movw	0x808(%rax), %cx
000000000007223f	movw	%cx, 0x8(%rax)
0000000000072243	movw	0x80a(%rax), %cx
000000000007224a	movw	%cx, 0xa(%rax)
000000000007224e	movl	0x80c(%rax), %ecx
0000000000072254	movl	%ecx, 0x38(%rax)
0000000000072257	movw	0x810(%rax), %cx
000000000007225e	movw	%cx, 0x3c(%rax)
0000000000072262	movw	0x812(%rax), %cx
0000000000072269	movw	%cx, 0x3e(%rax)
000000000007226d	movw	0x814(%rax), %cx
0000000000072274	movw	%cx, 0x40(%rax)
0000000000072278	movw	0x816(%rax), %cx
000000000007227f	movw	%cx, 0x42(%rax)
0000000000072283	movq	%rax, %rbx
0000000000072286	jmp	0x722c6
0000000000072288	cmpq	$0x30, %rax
000000000007228c	jne	0x722a6
000000000007228e	movq	%r14, 0x10(%rsp)
0000000000072293	movq	%rbx, 0x8(%rsp)
0000000000072298	movq	%r10, (%rsp)
000000000007229c	movzwl	%ax, %edi
000000000007229f	callq	_ar9300Attach
00000000000722a4	jmp	0x7222d
00000000000722a6	xorl	%ebx, %ebx
00000000000722a8	leaq	0x81055(%rip), %rdx     ## literal pool for: "ATHR: devid[0x%04x] not supported.\n"
00000000000722af	xorl	%edi, %edi
00000000000722b1	movl	$0xffffffff, %esi       ## imm = 0xFFFFFFFF
00000000000722b6	movl	%eax, %ecx
00000000000722b8	xorb	%al, %al
00000000000722ba	callq	_HDPRINTF
00000000000722bf	movl	$0x1, (%r14)
00000000000722c6	movq	%rbx, %rax
00000000000722c9	addq	$0x20, %rsp
00000000000722cd	popq	%rbx
00000000000722ce	popq	%r14
00000000000722d0	popq	%rbp

You can see the compares against 0x30...

... but it got further...

You might try re-applying the DSDT patch.
 
After applying the DSDT patch again, nothing really changed.
Exactly the same lines in system.log that I posted before. :(
 
jackito said:
After applying the DSDT patch again, nothing really changed.
Exactly the same lines in system.log that I posted before. :(
Click to expand...

This patch is an attempt to force 0x2a within the code I mentioned above...

Code: 
sudo perl -pi -i 's|\x66\x83\xf8\x30\x0f\x87\xa7\x00\x00\x00|\x66\xb8\x2a\x00\x90\x90\x90\x90\x90\x90|g' AirPortAtheros40
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top