no42
-
Posts
925 -
Joined
-
Last visited
-
Days Won
17
Posts posted by no42
-
-
This post may be of help.
Snake
-
Friday is comming.......
-
I have karma working on the wr703n, just have to play around with the interfaces and iptables, inorder for it to work correctly.
I started from a clean build. (Openwrt Attitude Adjustment). Installed karma (opkg install karma), then copied the hostapd_cli from the pineapple :)
Otherwise, karma definately works, just have an interface/routing problem with iptables.
UPDATE: Got it routing traffic through ICS through default Openwrt interface and iptables configuration. Karma can pick up clients. Works well, but doesnt work in Lobbying environments, as the DHCP is given by the ICS, rather than the Pineapple.
-
Thank you (Dnucna) for giving me the time by taking on the Encoder challenge.
Hopefully, this year we can increase language support.
-
Not annoying!
I really want to work on language support this year! The more questions the better, the better the understanding - i hope!
I'll help you with ru.properties, my time is limited at moment, but will do my best to help.
Does the cyrillic in ru.properties work correctly?
Is it latin character support you are after?
Just for clarification, thanks.
-
You really want to convince your employer to use the power of the cloud and elcomsoft software, a few processors and gpu's should yield a quicker result.
-
You need to edit ru.properties
Use encoder v2.2
Java -jar encoder.jar -l resources/ru.properties -i input.txt -o output.txt
-
Your network device is set to usbmon1, shouldn't it be eth0 or wlan0 depending on network/wifi network?
Do a "show options". You probably need "set interface eth0" or something similar.
-
For apple vid & pid. See http://code.google.com/p/ducky-decode/wiki/Keyboard_VID_PIDS
You can change vid & pid easily with version 2 firmware. Howto is on forum somewhere and ducky decode website, maybe Darren could demo this on next episode?
-
Speed is limited to the open source spi protocol, the connection interface to the sdcard. Sd has its own proprietary interface/protocol which is faster but costs $$$. This would affect licensing and cost of ducky. Trying to keep software as freeware & open source as much as possible.
I'm afraid you'll have to live with slow speed.
Corruption - never had problem, 1st sdcard was faulty , replacement still working fine.
Sdcard loading times, your right smaller the quicker. I get by with cheap 256/512mb.
- 1
-
-
%myd% is the variable storing the drive letter, just like %systemroot% is a variable for c:\windows\system32
so to call executable / jar files on the sdcard you need
%myd%/execute_me.exe or java -jar %myd%/my_jar_file_on_sdcard_root.jar
-
Twin Duck firmware:
- Mass Storage support
- HID injection
-
The ducky could call the jar file, this could be downloaded from internet, or loaded from mass storage drive.
Your just dependant on having:
- Java needs to be installed on the system
- Java needs to be fully configured; e.g. class path, executable path
-
Do you mean one that changes from USB Storage to HID Keyboard on a key press?
Otherwise, check out http://code.google.com/p/ducky-decode/downloads/detail?name=c_duck_v2_S001.hex&can=2&q= triggers are the *_LOCK keys.
CAPS,NUM,SCROLL LOCK all trigger the same payload; inject.bin.
-
you could use the twin duck firmware to load the image from the mass storage partition...
-
Q1: No see above.
Q2: The chip is a micro-controller, not an actual full-blown OS, its pre-programmed with a set of instructions triggered/executed by a series of interrupts.
-
Thanks for the info... I'll amend the flashing how-to guide, to include this package.
Thanks
Snake
-
I've been getting questions, on how I was successful at creating the community edition firmwares.
Background
After using usblyzer or busdog to record various dumps of USB traffic from devices like the Ducky, HID keyboards, and Mass Storage devices. I spent hours checking the USB protocol for how it interacts with computers. Learning that different OS's have speed tolerances, descriptor packets are formed in a specific way, learning about EP (Endpoints).
I had proved that the Ducky could cope with other languages or keyboards,by programming the Ducky for the UK keyboard-map (where I was currently working at the time), I then moved to Germany briefly, so started to write a DE-encoder with some help from the community. Hoping for more community support, I changed my focus to firmware rather than the encoder. I wanted Mass Storage Support, so left the encoder development for the research below in writing firmware.
Later, Dnucna came along with his Encoder improvements (He's a better Java programmer than me).
Firmware Development
Basically, it involved research, and a fair amount of time pouring over Atmel's data sheets, and project examples. Atmel's framework, contained a few bugs, so I was constantly getting stressed over strange errors. These were slowly getting fixed as I queried these errors with Atmel Tech Support, and progressively downloaded updated frameworks. I started on ASF-2.11 for initial HID, the latest composite only worked on ASF-3.1+ the code never really changed just the Atmel framework, and the lower base calls.
At first I was scared about bricking the Ducky, as I didn't want to overwrite the Ducky's bootloader! (How you can repeatedly flash the Ducky, I downloaded a lot of documentation and programmed a simple bootloader just incase I erased it. When I took the risk and plunged in and ref lashed, I though shit..... its bricked! But then it came to life :) looks like Jason had set some fuses protecting the bootloader, thus i did not have to worry about bricking the Duck. Now I could focus on programming and flashing firmware, debugging USB traffic concentrating on developments.
I could guess (from using google) that the hardware that the chip was based on the EVK1104 demo board. I could have bought one, but decided to go right ahead and attempt flashing the Ducky, using the EVK1104 sample projects I got a feel for the code and what calls were necessary.
HID - Multi OS support
First I concentrated on speeding up the Ducky - secret to multi OS support. I played around with various settings from Atmel's examples and had mixed results - too fast I would loose keys, too slow and the Ducky was unimpressive. also all HID codes needed a signal button-down and button-up.
When Jason and Darren released their Source, it confirmed my initial guesswork. And Jason's state-machine for managing key presses was impressive and fast (with low error rate), so decided to keep this part of the code - as DuckyScript and the Encoder were dependant on this relationship - any change could add complexity, and potentially break their good relationship.
MSC Support
I was working in an organisation, with data-leaks were a problem, the company employed device control software to limit USB access, and enforce the use of encrypted USBs. I though *BANG!* I could probably program the Ducky to bypass this software, and use the Ducky to move data.
After 2 months of more reading/trial and error I had a working prototype :) Or so I thought, the device was registering as a USB drive in device-manager, but windows mounted no drive. Chatting with Tech Support I had messed up the boards clock settings (imported from their example). Not knowing these actual values, a began bruteforcing the values/settings; this was a painful and long process. Then one day I returned to the Hak5 forum to see Darren released the HID source-code, reading the code it involved learning how Darren/Jason was using the clock, and I quickly realised my mistake.
Making the necessary changes - I had the first Ducky that supported Mass Storage.
After some more months, I then created the community website and dumped the firmware online. As the support for the Ducky appeared to have dwindled, and people were complaining about the use of a Duck (initial costs were $80), so I could least give people the option of using their Ducky's as flash-drives.
Around this time Darren enquired about composite devices. So I moved onto combining both the HID and the MSC firmwares.
Multi Payload Support
It was a long process and without any success at composite I took a step back. Rumors of data-exfiltration via keyboard LED lights was an interesting research project, but i decided to look at controlling payloads dependant on the keyboard LEDs. Many chats with Tech Support on endpoints and the ability for keyboards to sense key presses yeilded no results. In the end I stuck my head down and realised only the status of LED lights are read by the AVR library. So I tied different files (inject.bin, inject2.bin, etc) to the status of these lights; again no success. The trick was getting the Ducky to acknowledge the change in file, and execute the different commands.
Upon accidentally hitting the GPIO (reset button) I realised that it did actually work. Hence the naked-duck was born, as you needed access to the GPIO.
Later developments, enabled me to perform the reset in software, removing the need for the GPIO button as a reset.
Composite
Just before Xmas I updated the ASF framework to 3.1+. Suddenly the composite code sprung into life. The idea was to release the code at Xmas, I gave demos out to a few private test subjects and thus had some time to test this feature in the real world, and had a chance to resolve bugs. One clever person noticed the code change in the SVN (hinting at composite support); so I decided to come clean and release the test-code early.
My plan then changed to reveal the improvements in the New Year.... this is when I released the Firmware 2 Enhancements.
Future Improvements
To this day I am still playing around, hopefully I can work out some nice features and introduce these into future projects/releases.
Summary of Steps
Goto Atmel website
Download Atmel Studio (windows only & version 6.0) (Atmel Studio 6.1 is beta and breaks the code!!!)
Look for documentation on chip, and example projects (EVK1104 or UC3B1)
Example code:
- http://asf.atmel.com...tml/index.html
- http://asf.atmel.com...ard__group.html
- http://asf.atmel.com...msc__group.html
- http://asf.atmel.com...msc__group.html
Prepare to have lots of chats with Atmels Technical Support when things go wrong????
Also worth joining Avrfreaks.net (they do some limited 32bit stuff, but mainly 8bit support for lower spec avrs).
So if you want to repeat what I've done, have a crack at writing your own code, or potentially improve the firmware / features of the Duck. You now know at least how I did it!
~~Snake
-
Hmm, I've used that OS with the Ducky no problems ???
-
What's the version of your os?
-
Yes, until these guys get wise!
Symantec, Sophos, and lumension (old versions)can be bypassed!
Lumension just released new version, that dictates what users are allowed USB. If you user isn't allowed USB, ducky will be blocked.
Windows 7+ GPO settings can also block the duck.
Other versions and products, block by vid&pid hence version2 firmware makes it easier for you to change these values without re flashing.
Go forth, and quack the system, my ducklings!
-
Oops.
That still looks like the demo code from before Xmas. Still works though ;) (hid instructions are in the file marked ui.c) just need to combine it with the HID_duck source :P .
Put your dev hat on B) , and frankenstein the code together.
I'm currently away from my machine with all the Ducky code, Ill post the updated source as soon as possible..... How does 2/1/2013 (1st Feb) sound for a countdown... 9 days to go!
-
Probably worth contacting nek6994 to see how far he has got.
Otherwise, follow the instructions in that blog post to create an es.properties.
First one gets the Kudos! (But I do want to promote working as a Team!)
[Question] Ducky as a plain old USB drive
in Classic USB Rubber Ducky
Posted
Tricky, I dont have the facilities to practically test the speed today. But in theory:
The SPI uses a 12 MHz clock (from conf_sd_mmc.conf) <- this is the limiting factor (as USB should support a maximum of 12Mbps)
People from AVRfreaks claim 340 KBytes/sec for writing a 100 MB file.
Hope this helps.
Snake