Search the Community

Hello guys, I have been working on VulnHub/Root-me.org/Hackthebox.eu watching the hak5 show a lot on youtube lately one of the common things i have noticed on all the platforms is that people looking for a starting point to get into the security field to help everyone whose new to this field, you need a strong will a lot of persistence and above all "Try Harder" attitude to help the community further I made a blog where I will be posting CTF guides/Attack Methodology from metasploit to reverse engineering everything so please check out this blog and please tell me about your views! http://openexploit.blogspot.in/2017/10/ "Security is hard, Just dive in" - Jared Demott

Hello guys, I have been working on VulnHub/Root-me.org/Hackthebox.eu watching the hak5 show a lot on youtube lately one of the common things i have noticed on all the platforms is that people looking for a starting point to get into the security field to help everyone whose new to this field, you need a strong will a lot of persistence and above all "Try Harder" attitude to help the community further I made a blog where I will be posting CTF guides/Attack Methodology from metasploit to reverse engineering everything so please check out this blog and please tell me about your views! http://openexploit.blogspot.in/2017/10/ "Security is hard, Just dive in" - Jared Demott

Hello all! I was recently watching the video Access Internal Networks with Reverse VPN connections - Hak5 1921 and around 15:15 of the video @Darren Kitchen mentions: I was wondering what are some of those "ways" the LAN Turtle can discover the IP range of the network it's connected to and then make itself available for connection via VPN? Not doubtful just interested in learning the process! Thanks!

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 http://www.atmel.comDownload Atmel Studio (windows only & version 6.0) (Atmel Studio 6.1 is beta and breaks the code!!!) http://www.atmel.com.../atmel_studio6/Look for documentation on chip, and example projects (EVK1104 or UC3B1) AT32UC3B Complete Datasheet doc8360.pdf doc8445.pdf doc8446.pdf 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