Jump to content

Wabbe

Active Members
  • Posts

    8
  • Joined

  • Last visited

Recent Profile Visitors

481 profile views

Wabbe's Achievements

Newbie

Newbie (1/14)

  1. Hi, I recently did some extensive testing with different payloads on several machines and I stumbled on the fact that the RB does not stream it's string commands correctly when using a virtual machine on VMWare Workstation. It is obvious that this is a major drawback since virtual machines will allow for extensive / flexible testing of different scenario's and environments. The RB works perfectly on the physical hosts, but when the RB is connected to the VM, characters (from the string commands) are being omitted or altered. Succes rate of the RB is around 20%, which means that this behaviour occurs about 80% of the time. There is no real pattern as to which characters are omitted, or when this happens, it just looks as if some issues occur when streaming the command from the physical layer up to the virtual layer within the VM's. What did I test : - tested the RB's (two different devices) on the host machines (3 different computers with plenty of memory and available cores (so no oversubscription)) : success rate : 100% (did over 100 tests) - tested the RB's (same as above) on VM's (WIN7) running in VMWare Workstation of the hosts above : success rate 20%, 80% loss or alteration of characters (did more than 100 different tests). - Tested with different flash firmwares (classical and twinduck (version 2 and 2.1)) with comparable results. - Tested the virtual machines on VMWare 10, 11 and the latest version 12 (with all the same results) VMWare support : - tested the quirks documented on the VMWare support forum with th vid & pid, reset,refresh and setconfig options (with no result wich is not surprising because it does work 20% of the time) - tested the quirck documented on the VMWare support forum in order to allow usb HID detection (with no result which is also not surprising because this is not really the issue, but tested it anyway for completeness). Can anybody confirm this behaviour (omitting and/or altering characters from string commands) is indeed a problem with VMWare Workstation (or even player, did not have any chance to test this (running out of hardware ;-)) ? Can anybody tell me how to go further from here in order to get the issue analyzed/fixed (I don't have the means or knowledge to analyze the usb traffic and/or communication protocols used) ? I also wonder if this behaviour occurs when using ESXi hosts. Will the RB be able to stream it's commands to any virtual server that has the USB connectors assigned ? Implications might be big, but just guessing (and I'm not able to test this anyway) ... I do understand that the issued might be VMWare related, but since I have no other usb issues on any of the computers (and/or VMWare Workstation versions) chances are the issue is actualy RB related. If it quacks like a duck, looks like a duck and sounds like duck,it just might be a duck ;-) Any feedback welcome ! Kind regards, Wabbe
  2. Well, looks like we nailed it ;-) Test (10 separate tests done) within the virtual machines -> success rate ± 50% Test (20 separate tests done) on the host machines -> success rate 100% So clearly something happening with the translation from physical to virtual layer (don't like it because it want it to work on virtual machines for all kinds of testing purposes) ... Will investigate tomorrow (or the day after) if I can optimize the usb behaviour on the VMWare virtual machines ... As Always, all insights welcome ...
  3. Well, i have my doubts ... i'm seeing the same behaviour with two different rubber ducky's (would be an awfully big coincidence, and i don't really believe in coincidence ;-). I still have a third one laying around, will do some more tests tomorrow to see how that one behaves ... I still believe i'm missing something, just don't know what ... will keep you informed ... Maybe should start looking at the virtualisation layer of the targets (all running as vm's on different hardware). Maybe issue with the usb driver software (don't know, just guessing) ... As always, all insights welcome ...
  4. Hi Peyo, Thanx for your reply. It looks like it is somehow flash related since i'm getting different results ... but not the kind i was hoping for (situation is even worse ;-). Using the 2.1 version with a totally stripped down version of the payload (just invoking a basic powershell) fails 99% of the time. Characters are streamed inconsistently (different characters are ommited at different times) towards the operating system. I'm seeing the same behaviour with different ducky's on different target computers. Even with different flash versions (classical duck and twin duck). It doesn't really makes any sense, should be straightforward right (started to think in the direction of the language file, but in that case it should never work, and not 50% of the time) ... I'm missing something, just don't know what (maybe my common sense ;-). Any ideas are always welcome, maybe they will make me see the light ... Kind regards
  5. @LukasS : I do realize that i can alter the mechanism in order to get the drive letter. That is not the problem, in fact most everything i implement works just fine as long as the strings are streamed correctly (which is not the case). So the problem is not the commands itself, the problem is the way the keys are streamed to the operating system ... @Peyo : The values in the example are a result of me playing with them in order to see how they would affect the streaming. Unfortunatly it doesn't make a difference if I delay for a 100 or more (or not), the results remain the same. I was thinking the problem could lay with the flash software. Does anybody know where i can find the latest versions (is kind of confusing because there are lots of links to github. I'm using the hex files dated april 16 2013. Maybe I'm wrong with this but any help woud be greatly appreciated. Kind regard, Wabbe
  6. Hi, Having some problems using encoded payload (encoding done manually and on toolkit site) in conjunction with the twin duck flash. Half the time the string commands are not streamed correctly (characters missing at different positions). Below an example to illustrate : Encoded string command : STRING $driveletter = Get-WMIObject Win32_Volume | ? { $_.Label -eq 'Drive' } | select Name When I use the ducky, half the times everything is just fine. But the other half (and most of the time it happens on the command above (but also occasionaly with others) the command get streamed with characters missing. Some examples : $driveletter = Get-WMObject Win32_Volume | ? { $_.Label -eq 'Drive} | select Name $driveletter = Get-WMIbject Win32_olume | ? { $_.Label -eq 'Drive'} | select Name Anybody any ideas ? Kind Regards, Wabbe In attachment an example showing the actual run (and the coding side by side).
  7. ok, finaly figured this out. Took me a while since i've never used the Pineapple before (unboxed it yesterday, so wasn't clear how the hardware was configured) ... Current status : Wired client mode is working as described in the guides. Description of the problem i had : when using wired client mode with dhcp, the Pineapple received and applied the issued ip address from the dhcp server, routing table was updated correctly, however no inbound or outbound communication was possible over the eth0 nic. Why it took so long to figure out : i am a complete novice to Pineapple and was not aware of how the nic configurations were done on the box. Since the Pineapple received a correct dhcp address i mistakenly concluded that all was working fine on the network layer. So after a few hours of checking interface configurations and iptables settings i was forced to conclude that the issue had to be on the network layer (didn't like that at all ...). What was the problem : I was using tagged vlan's on the network switch (this means in fact that the port was configured as a trunk port and not an access port). This is a normal setup in my lab since i play around with lots of virtualised environments that use virtual switches and hence use vlan tagging to seggregate the traffic. So after changing the port to access mode all worked correctly. Maybe somebody can benefit from the answer provided.
  8. When trying the wired client mode with dhcp, I can see that my dhcp server issues an ip address. The pineapple does apply the issued address on the eth0 nic, and the correct default gateway is set in the routing table. Internet access is not working however, nor is the address reachable in any way. could this be an iptables issue ?
×
×
  • Create New...