Jump to content

Clue to enabling USB in mach_kernel.prelink?


oz_paulb
 Share

6 posts in this topic

Recommended Posts

Hello -

 

I've just started messing with my AppleTV. I'm new to the Mac, so my questions/comments may sound like I'm a newbie. Sorry.

 

I've decompressed the "mach_kernel.prelink", and see what appear to be USB driver files. Something that looks promising are the strings "IsIOUSBDeviceAllowed" and "IsIOUSBInterfaceAllowed" referenced several times.

 

From what I understand, the USB port isn't enabled by default. Could this be a clue to enabling it?

 

Is there some sort of master 'database/registry' on the MAC where 'variables' such as "IsIOUSBDeviceAllowed" would be stored (and drivers could refer to the vars to make decisions)? If not, maybe the AppleTV EEPROM (which is partially dumped in the "dmesg" output) contains 'variables' that the drivers can refer to?

 

If anything, someone with Intel disassembly/reverse-engineering experience may be able to find the code that actually refers to these strings/'variables', and force the code to always treat them as 'TRUE'. (assuming that's what these strings are - boolean 'variables')

 

Just a thought - sorry if this is obvious.

 

Edit: Maybe these aren't "boolean" symbols (yes/no for all USB devices) - maybe they are function names (that get passed device IDs to see if the given device is 'allowed'). Maybe they are exported somewhere in one of the modules inside "mach_kernel.prelink", or somewhere outside. Same idea should be possible: stub-out these functions to always return 'true'.

 

- Paulb

Link to comment
Share on other sites

It may be worth looking at the ioreg output. I haven't seen a dump of an Apple TV but its quite possible it checks an entry in the io tree and based on how its set, locks out the USB.

 

BTW are you the same oz_paulb from the X-Box scene known for the large HD patch? :(

Link to comment
Share on other sites

It may be worth looking at the ioreg output. I haven't seen a dump of an Apple TV but its quite possible it checks an entry in the io tree and based on how its set, locks out the USB.

OK, thanks.

 

Some further searching has found this page where someone has had some success with a USB keyboard (after patching the "mach_kernel.prelink" file to allow his USB keyboard's device ID): Link

 

BTW are you the same oz_paulb from the X-Box scene known for the large HD patch? :)

Yes, that's me.

Link to comment
Share on other sites

That page you linked is very interesting.

 

My thought was that within the prelink kernel there was a USB module which was being loaded and therefore any USB module stored in /System/Library/Extensions would not load (module already loaded type error). This would prevent hackers from just using a USB extension from a normal Mac.

 

I did some experimenting with pulling the prelink kernel apart but stuck with the compression (I worked out it was LZSS but for some reason the decompressor I used didn't work). From what I have read, files extracted do not have filenames so it is very hard to work out what the files are.

 

From that link he mentions he searched the data area for the IR remote Vendor/Product ID and patched it to the keyboard. Unfortunately we don't know the exact extension name. Knowing that we could remove the module and just use what is stored in extensions. Would make experimenting far easier.

Link to comment
Share on other sites

From what I have read, files extracted do not have filenames so it is very hard to work out what the files are.

I'm not an apple OS X expert, but I think that at least some of the 'modules' have names embedded, so it could be possible to work out 'filenames'.

 

For example, I see names like "com.apple.iokit.IOUSBFamily", "com.apple.driver.AppleUSBHub", etc.

 

- Paulb

Link to comment
Share on other sites

I'm not an apple OS X expert, but I think that at least some of the 'modules' have names embedded, so it could be possible to work out 'filenames'.

 

For example, I see names like "com.apple.iokit.IOUSBFamily", "com.apple.driver.AppleUSBHub", etc.

 

- Paulb

 

If thats the case then it seems obvious why USB doesn't work properly.

 

Taking a look at the System/Library/Extensions I notice this:

 

/System/Library/Extensions/IOUSBFamily.kext. This has a PlugIn:IOUSBHIDDriverSafeBoot

 

On a real Mac there will also be another PlugIn: IOUSBHIDDriver.

 

Therefore the logical explanation is that mach_kernel.prelink has this IOUSBHIDDriver compiled into it with a whitelist for the IR remote.

 

Disable or remove this extension and then toss the real one in extensions should hopefully cause it to provide full keyboard support.

 

 

Just a quick idea I came up with.

 

Edit this file:

/System/Library/CoreServices/com.apple.Boot.plist

 

In the kernel flags section add -x. This activates safe mode which is what I think the extensions directory might be for, it ignores whats in the kernel and uses that. Or maybe it might use the safe USB HID? Worth experimenting with.

 

If that doesnt work try -x -f (-f forces reloading of extensions).

Link to comment
Share on other sites

 Share

×
×
  • Create New...