Keycroc Multiple problems out of the box (wifi, keyboard, version)

[DonBigly]

So I just got the keycroc today and plugged it in; first thing that pops up on OSX is a warning that I have a device that's not a keyboard connected (this keyboard works fine without the croc) it asks me to continue or quit. I continue, and it wants me to identify the keyboard by pressing keys. The keys don't work. Ummm okay. So how the hell am I supposed to deploy this thing if its warning of a device connected inline?

Next, when I get into arming mode to configure the wifi, It won't connect. Not an open network, not a secured network, nothing.

Get into serial mode and try various ifconfig settings, wpa_supplicant.conf, wpa_cli and all that.... Nothing

Finally I check to make sure I've got the most recent firmware and version installed, and I somehow have version 1.3_513 when the highest available downloadable version is 1.3_510.

So what's going on here I wonder?

[DonBigly]

Alright, so an update on the wifi:

• does not connect to an open wifi
• does not connect to hidden networks

That's a huge bummer. There was no clear diagnosis/errors available here, just trial and error.

And the croc is somehow showing as "RNDIS/Ethernet Gadget" to my system usb, while the /tmp/mode within croc is showing as HID device (and not allowing usb keyboard passthrough)

RNDIS/Ethernet Gadget:

  Product ID:	0xff01
  Vendor ID:	0xf000
  Version:	3.33
  Serial Number:	ch000001
  Speed:	Up to 480 Mb/s
  Manufacturer:	Linux 3.4.39 with sunxi_usb_udc

There does not seem to be any "automatic cloning" of the connected USB device. Changing the ATTACKMODE always uses the same VID/PID etc as shown above.

Manually changing the ATTACKMODE HID VID_XX PID_XX SN_XXXXXX will have it "identify" manually as the device info I want to the system, but the croc still won't allow they keyboard to pass through or change to a green LED.

I CAN however issue QUACK commands remotely, that will input to the target system - I'm missing the main function of the KEYcroc. (I've also tried two different keyboards, one being microsoft and one being apple). I can't expect the target system to have anything else.

[dark_pyrro]

So, some things to troubleshoot as it seems. A couple of basic questions just to start moving the train...

Does the SSIDs used contain any special chars and/or spaces? If so, have you tried some simple SSID (if it's possible for you to set up a temporary AP just for testing purposes)? The Croc can be picky sometimes. I haven't had any real issues, but I've read that others have had issues for some reasons.

When you try to configure the WiFi settings manually and serial into the Croc, in what way did you do that? The Croc has a file that takes care of this normally. It's called "croc_framework" and is located in /usr/local/croc/bin

In the framework file there are some functions to look at, more specificly: "setup_wifi", "ENABLE_WIFI", "CONFIG_OPEN_WIFI", "CONFIG_PSK_WIFI", "START_WLAN_DHCP", "CLEAR_WIFI_CONFIG" and "ENABLE_INTERFACE". This is purely informational though so that you know what is affecting wireless on the Croc.

The framework functions writes to wpa_supplicant depending on what it sees in the config.txt file on the udisk and then brings up the wlan0 interface along with dhclient.

If activating DEBUG_MODE, you might be able to spot something in /root/loot/croc_framework_debug.log and it's of course possible to add logging of your own to the framework file if there's a need for that.

When it comes to keyboards, the Croc can be picky as well. But that's mainly if "combo" setups are used (like mouse and keyboard with one connector) or fancy gaming keyboards with extra functionality that makes the Croc choke (or, well, not work properly at least).

What green LED are you referring to? When the Croc has no keyboard attached it should be solid white, when attached it should go off (no light at all).

Any other Mac related stuff is out of my area of expertise, I'm Linux/Win only.

[DonBigly]

Wifi aside, (I can work around the limitations), how do you activate the DEBUG_MODE for the framework? I've been checking the logs in /var/log and can notice that they keyboard is properly identified when it's plugged in/unplugged from the croc (as well as listed under lsusb as bus device 005), yet it's still showing up on my target as the ethernet device.

I was able to get the keyboard to successfully "hotplug" and clone the vid/pid into /tmp/mode automatically (Showing HID VID_XXX PID_XXX) that matches... yet KEYBOARD command says "MISSING", with no keystrokes recorded, and still white LED (I thought the LED would turn green with keyboard, my mistake, it should be off).

OSX still reports as an RNDIS/Ethernet Gadget with pid/vid 0xff01/0xf000

Linux reports the device as HID/Keyboard with pid/vid 0xf001/0xf000

Both will show the proper vid/pid in /tmp/mode on the croc, but not on the target system.

The keyboards remains unresponsive. =,(

[dark_pyrro]

Line 10 (..ish) in croc_framework says "use set DEBUG ON on config.txt", but, reading the croclog function I guess DEBUG_MODE="true" is the way to go (and specifying it in the croc_framework file directly)

[DonBigly]

The croc_framework_debug.log indicates everything is working from that perspective (shows additional log lines that indicates proper cloning/attack mode enabled)

Startup - Detected attached device
Startup - Keyboard Detected
Startup - Waiting for keyboard...
Starting key parser...

croc_parser_debug.log is a different story (this repeats over and over)

[!] IPC STREAM
[!] Device is unavailable. Is there a keyboard plugged in?
[*] Checking Storage Space

I can't imagine I'd be 2 for 2 with keyboards that aren't compatible (given they do get identified initially).

Kinda frustrating. Not sure what else to do now.