Jump to content


Active Members
  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

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

emptyhen's Achievements


Newbie (1/14)

  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 keep some between re-boots). The SharkJack is having to do all that as well as ping each address as it is always starting from a fresh config - even it's own MAC address is randomised on each boot. If a device doesn't respond to the ARP request in a timely fashion, I don't think the ping will even get sent. Out of interest, if you ran the NMAP scan twice, do you get more results the second time? (Could try this from arming mode as a quick experiment?) Yeah, that's going to take a long time - especially if you have a few devices on the network. That's why I suggested a reduced list of just 5 ports. (HTTP, FTP, HTTPS, & 2xSMB related ports.) You could also add 22 for SSH? My Jack seems to cope with this on a network of ~30 devices a few times before it runs out of juice.
  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 '' 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 30s --max-retries 3"? This may also give you a little more detail at the same time! Hope that helps.
  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 really just a work around rather than a solution...
  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 && echo 0 > $SCAN_FILE') - it creates the empty file but never populates it with the '0'. For reference, I run the payload with 'ash /root/payload/payload.sh'
  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...