Jump to content

emptyhen

Active Members
  • Content Count

    10
  • Joined

  • Last visited

About emptyhen

  • Rank
    Hackling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. A work around for this is to swap the order of the lines in the language file. The Q and QUACK scripts seem to take the last instance in the file and 'quack' out that key code. The files are in the languages folder on the udisk. Try using to attached file instead to see if it helps. Make sure to unplug and re-connect the KeyCroc to enable the changes. us.json
  2. You loot should be in the /root/loot folder. You can either browse to this in the SSH terminal or just look for the 'Loot' tab on the web interface, at the top ,(when in Arming mode) and that should show all the files in the loot folder. Does that help?
  3. Out of interest, is you Kali VM connected to the network in the same way as the SharkJack? Might be an interesting experiment to connect your Kali box/computer to the same physical port that you are testing the SharkJack and compare the results? Another thing that occurs to me is that the SharkJack is potentially having to do more on its first scan that the Kali box. The reason for this is that the Kali box will already know the MAC addresses for most or all the devices on the network (since it's probably been running for a while and all be constantly maintaining it's ARP table - and may
  4. Hi, How far have you got with this? Have you plugged it into your laptop (in arming mode yet?) It should just be a case of switching it into arming mode (middle position) and plugging it into your laptop either directly into an Ethernet port or into a USB Ethernet adaptor. Once connected, you can open a web browser and go to the address 'http://172.16.24.1' or alternatively connect to the SSH terminal using something like PuTTY (same IP address) That should get you up and running initially. Hope that helps
  5. I do get differing results on subsequent runs but I get that on Kali and on a tool on my Android phone but only differing by 3-5. I guess some devices don't respond to all pings or the frames are being dropped by the router? (Some are wireless and some are wired devices). I've found adding the "--host-timeout 30s --max-retries 3" does help a bit. I tried playing with the speed a bit but that generally makes things worse! You could try a more detailed scan if you want a more accurate list (although this is of course a bit more 'noisy'). Something like "-p 80,21,443,445,139 --host-timeout 3
  6. @cyrus104, just wanted to check you saw Foxtrot's reply about this on Discord? The changes you suggest are exactly what I'd done and it looks like it's been applied by Foxtrot for the next version of firmware to be released. Hope that helps.
  7. I think the touch is needed as it creates the file path too. ie. the /etc/shark/nmap/ (/etc/shark doesn't exist before the payload is run for the first time) It does appear to be down to the way the SharkJack executes the payload. It essentially runs 'bash -C /root/payload/payload.sh'. If I try that from the command line on the Shark, I get: 'payload/payload.sh: line 31: /etc/shark/nmap/scan-count: cannot overwrite existing file' Running it without the '-C' works fine, as described before. Interesting.... Either way, adding 'rm $SCAN_FILE' seems to fix the issue - even if it is
  8. The really strange thing is it seems to work fine if I run the script in Arming mode. (I comment out the NETMODE DHCP_CLIENT and the 'halt' lines so that it will run) This seems to work fine and the count increments as it should etc. (remember you need to wait a little before checking as the script runs itself in the background - 'run &' on the last line. I haven't dug into exactly how the Shark Jack runs the payload yet but it must be an issue linked to that. As I mentioned before, even the line that creates the file the first time doesn't work properly either ('touch $SCAN_FILE &
  9. Hello, I tried this on mine and was surprised to find I had the same issue. Having had a poke around I noticed the SCAN_FILE (/etc/shark/nmap/scan_count) was empty. I tried setting a value in it but that still didn't work. I ended up adding a line in the finish() routine, just before the 'echo $SCAN_M > $SCAN_FILE' that simply removes the file before saving the new value ('rm $SCAN_FILE'). This seems to have done the trick, but I'm not really sure why it didn't work before... Hope that helps Mark
  10. You can call just ATTACKMODE again with different parameters to achieve what you want. In your case you'd start with ATTACKMODE HID STORAGE then do what ever you need to do and then call ATTACKMODE HID to remove the storage aspect. Hope that helps.
×
×
  • Create New...