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

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?

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


Yes, that's me.

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.

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).