Jump to content

[Bugreport] OSX Single User Mode - doesn't recognize ducky


Recommended Posts

Hey, I need some help debugging my new ducky. I've made some simple 'hello world' ducky scripts without any issues. They run on mac, windows, linux etc without any problems. I tried the same simple script in OSX's single user mode with no luck. It appears as though OSX in single user mode does not recognize the ducky as a keyboard? I tried increasing the string delay of the script so that it would type much slower. No luck. I have also tried plugging in external USB keyboards (such as my dell keyboard). Those are all recognized in single user mode. I tried the ducky on desktop Macs and MacBook Pros. Also no difference. Here is a test script:

STRING_DELAY 50
DELAY 3000
STRING Hello World
ENTER

I'm really hoping that I am just making a small mistake. I've tried compiling my ducky script using 2.4, 3.0, and with the online tool. Again, any help would be appreciated! I have a real kickass script for quickly rooting Macs that I would like to share. Thanks!

Link to comment
Share on other sites

I thought single user mode only loads a small subset of drivers. Have you tried cloning the vid and pid of a keyboard that works. You need v2 firmware.

Encoder v2.4 is more stable at moment, v3 is experimental.

Link to comment
Share on other sites

If your a mac developer you can download the usb debugging kernel module. That might shed some light in single user mode?

I saw someone demo the mac pin attack on the net, but didn't record the link.

Your sure your on firmware v2 not stock?

Edited by midnitesnake
Link to comment
Share on other sites

I thought single user mode only loads a small subset of drivers. Have you tried cloning the vid and pid of a keyboard that works. You need v2 firmware.

Yes, single user mode is very limited. I do not believe that is the problem. I can plug any keyboard into any mac in single user mode, and they are all useable.

So I created a vidpid.bin at the root of the SD card. I was able to change the VID and PID properly. On OSX, you can run:

system_profiler SPUSBDataType

Will give:

HID Keyboard:

Product ID: 0xc312

Vendor ID: 0x046d (Logitech Inc.)

Version: 1.00

Speed: Up to 12 Mb/sec

Manufacturer: ATMEL AVR

Location ID: 0x06200000 / 4

Current Available (mA): 500

Current Required (mA): 100

This will give the VID and PID of all attached USB devices. I connected the working keyboard and copied the VID and PID over to the Ducky. Running the above command again, I was able to confirm that the Ducky had successfully cloned the VID and PID of the previously working keyboard. I also tried a handful of the VIDS and PIDS files available on google code. Still no luck.

I flashed the ducky with duck_v2.hex and also osx.hex. I compiled a hello world script on Duck encoder V2.4. Again, the script works just fine on any computer, but isn't recognized in single user mode.

I know this is possible because the ducky is a "keyboard", and keyboards work in single user mode. I know its possible!!! I appreciate the help btw

Link to comment
Share on other sites

Also here are two screenshots of some debugging using Apple's USB Prober app. The device labeled "HID Keyboard" is the ducky that is imitating the VID and PID of the true logitech keyboard. The device labeled "USB Multimedia Keyboard" is the logitech keyboard.

I noticed that towards the bottom there is a "Interface subclass". The ducky is 0 (false) and the logitech is 1 (Boot interface). I immediately correlate the words "single user mode" and "boot". I know nothing about USB devices, but could setting the value to 1 somehow make the ducky keyboard "visible" at startup in single user mode?

Is there anyway to hardcode these Device Descriptors?

post-43143-0-53611900-1366188656_thumb.p

post-43143-0-81420100-1366188657_thumb.p

Link to comment
Share on other sites

I think we're getting closer. It appears as though the "Device subclass" was changed to 1 instead of "Interface subclass". With the v2.1 hex, OSX doesn't recognize the ducky as a keyboard in regular or single user mode. Also, it appears as though the vidpin.bin is no longer read. The ducky appears to be an "Atmel Corporation" VIDPIN instead of the desired logitech VIDPIN. I attached a screenshot of the ducky with the new hex.

Thanks!

post-43143-0-87672800-1366223137_thumb.p

Link to comment
Share on other sites

Right, 3rd time lucky....

duck_v2.1.hex

Some of the variables are tricky, and require access to the heap - I havnt fully worked out all the memory bugs & spacings so am having to hack the code. Looks like previous attempts were changing the Device subclass instead of the intended interface subclass, hopefully this one has patched the right memory space.

Thanks again for your help and feedback.

Edited by midnitesnake
Link to comment
Share on other sites

Same results as the previous. I ran the command

tail -c 2097152 duck_v2.1.hex | grep 0000010300

:1082D00009022200010100A032090400000103008C

Those might represent the values:

Interface #0 - 0x00

Alternate Setting - 0x00

Number of Endpoints - 0x01

Interface Class - 0x03

Interface Subclass - 0x00

Changing it to 0000010301 may work? I'm having a hard time figuring out how to find and replace in hex though.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...