Jump to content

dark_pyrro

Dedicated Members
  • Posts

    2,618
  • Joined

  • Last visited

  • Days Won

    198

Posts posted by dark_pyrro

  1. I guess you are about to use it in some other scenario than trying to crack an Android lock screen PIN. It has been years since this was patched (well, if you have a really old Android device with an old OS that hasn't been updated, then it might work).

    Not really sure what script you are looking for since there are examples available in the posts/threads/videos that are mentioned. Recreate the "one liner" that Darren shows in the video below, it should take care of it in terms of generating the Ducky Script code. But, as said, not sure how it would be helpful since it won't brute force any modern device.

    https://www.youtube.com/watch?v=yoYiEkk5TyI

    Even if you can't afford a second computer, you can still run Linux without the need of involving Cygwin. Just install something that allows you to install virtual machines on your already existing computer, like VirtualBox. Then install some Linux based OS as a VM and use Linux as a "full OS". You can probably use Docker as well, but I seldom do that myself.

  2. As said previously in the thread, post Bunny related things in the Bunny section of the forums. And, when you do, provide as much information as possible about your specific scenario to take most guess work out of it all when trying to help to troubleshoot. What Bunny generation are you using? Mk1 or Mk2 or both? What OS is the computer using that you are trying to run bunnyupdater on? What firmware is your Bunny currently on? Any specific error messages or the same that has been posted before? etc...

  3. Well, the flash storage check is implemented in v2.x and that's why you have issues. There's no way around it since your Pineapple most likely has some kind of faulty storage if you can't get 2.x installed without storage issues. The only way is that the check is removed from the firmware, not implemented (and my guess is that it won't be removed). I advised you to contact Hak5 support in the other thread where you mentioned the same kind of issue a while ago and I'd suggest you to still do the same.

  4. You mean that you have the captive portal somewhere outside the Pineapple? Never seen that before using the Evil Portal module specifically. I guess you have to make changes in the extent that it's rather pointless to use the current Evil Portal module as a base for it. Try creating a new module from scratch instead or just simply start digging into the code of the Evil Portal module and make the changes needed. But, as said, my guess is that you have to tear down a perfectly well built "house" to the ground to create a new one. So, better to start off from scratch in that case.

  5. Just to be sure, previously it seems as if you have the new Rubber Ducky. Using the java encoder isn't possible in that case (well, perhaps if you stick to DuckyScript 1.0 features only). If you, however, actually have the classic Ducky, then use version 2.6.4 instead. In any case, the Java based encorders are more difficult to find since they aren't supposed to be used anymore. It's either payload studio or the JSEncoder (that makes it possible to use a language file).

  6. If you get a static public IPv4 address with the DigitalOcean droplet (you should, I at least got one when I did a test a while ago setting up a C2 server on DigitalOcean), I'd suggest using that IP address in "clear text" when starting the C2 server as a service and not mess around with variables. To get the variable populated, the use of .bash_profile is probably not the way to go since that won't be "executed" until login of the user. To make it work at boot and "system wide", I would most likely use /etc/profile (however, I would avoid using a variable, as said).

    If you haven't already, then use the docs that describes setting up a service for C2 (it looks like you have though judging from the paths used in your previous post).

    https://docs.hak5.org/cloud-c2/guides/enabling-cloud-c-as-a-service-on-boot-and-exfiltration

  7. If doing it that way, I would separate it all to not get faulty inputs to the start of the C2 server.

    First of all, I would start the C2 server with any of the IP addresses and skip the command that is included. Just to make sure that the C2 server starts as intended.

    If I would use that way of getting hold of the IP address, I would most likely separate it all and put it in a bash script and first put the IP address into a variable, then use that variable when starting the C2 server, something like:

    #!/bin/bash
    
    IP_ADDR=$(ifconfig eth0 | grep 'inet ' | awk '{print $2}')
    LISTEN=$(ifconfig eth0 | grep 'inet ' | awk '{print $2}')
    
    /path/to/c2/binary/c2-3.2.0_amd64_linux -hostname $IP_ADDR -listenip $LISTEN

    (Not sure I would use the listenip parameter though if there is no real reason to, I know I'm not for my C2 server).

  8. Can you resolve the hostname of the server on the Croc?

    Also check the cc-client error log on the Croc. I think it's in /tmp (if I remember it correctly).

     

    And, as said, that eth0 entry in the device.config file looks odd. Are you using that as a parameter in some way when starting the C2 server?

    In addition to the above, you could also execute cc-client and look for errors, or run C2CONNECT (don't remember if it's on the Croc, but pretty sure it's there, I don't have the Croc around at the moment so I can't check).

  9. I guess this is the same question/scenario/use case that you have already been posting in other sections of the forums. It's probably a "yes" and "no". You could most likely produce alerts if "someone" passes by ("someone" meaning any non specific individual). But, if you want to pinpoint a specific (identified) person, then it's most likely not possible if modern devices are used. This is because both Android and Apple based devices randomize MAC addresses exactly because of the fact that they shouldn't be possible to be tracked/geotracked.

  10. This doesn't look normal for sure. I have been on the 2.0.0 beta/RC for a while now, but 1.1.1 wasn't giving me such issues at all. I've noticed some users that seems to have experienced issues recently with their newly delivered Pineapples. No real evidence that there might be some big flaw in production lately, but it might be. I have no full insight in the architecture and design, but USB perhaps seems to be a part of the equation. And when saying USB, I mean hub related since this ties a lot of things together that you seem to have problems with. Did you have issues when setting the Pineapple up as well? As a first step I would probably do a firmware recovery, but I realize your situation being a Mac user. Since it's being tagged as an "unsupported" client platform when it comes to connecting to the Pineapple using the USB-C/Ethernet interface, I wouldn't add that layer of complexity when troubleshooting the issue. Not running it using a VM either. If it is possible to get hold of a Windows or Linux box, that would be the best way for sure. In any case, I would most likely submit a support ticket to Hak5 to get an official view and response on this.

  11. I don't know about all the other guys, but I would suggest posting Mark VII questions in the Mark VII section of the forums. The chances increase a bit to get an answer.

    The Pineapple is using the Mediatek MT7601U chipset and that chipset supports monitor mode and packet injection
    https://docs.hak5.org/wifi-pineapple/wifi-basics/radios-and-chipsets
    https://deviwiki.com/wiki/Mt7601u

    For 5 GHz you need an external USB adapter, but if you buy the Tactical "bundle" from the shop you will get what you need. Quoting the shop text: "Tactical edition includes everything in basic, plus 2.4 & 5 GHz support with MK7AC adapter, Hak5 carry case, limited edition skins and Hak5 keychain."

    Also note that it will not work as a wireless adapter if you connect it to a computer. The Pineapple is a device of its own. Kali Linux is fine, but still, the Pineapple won't work as a wireless adapter to Kali. You can connect to it using WiFi or USB-C Ethernet though.

    If you need a wireless USB adapter (2.4 and 5 GHz) to connect directly to a computer, then I would recommend something based on the Mediatek MT7612U chipset. Like, for example, the Hak5 MK7AC adapter (you don't need to use it exclusively on the Mark VII but with a computer as well, not at the same time of course). Other alternatives are the ALFA AWUS036ACM or EDUP EP-AC1605 V1. This scenario is however unrelated to the Pineapple itself.

×
×
  • Create New...