Jump to content

Scriptmonkey_

Active Members
  • Content Count

    17
  • Joined

  • Last visited

  • Days Won

    2

About Scriptmonkey_

  • Rank
    Hak5 Fan

Recent Profile Visitors

278 profile views
  1. This works beautifully btw. I've been using this for exactly what you suggest @Jenny_b against hosts with a removable storage exclusion applied. I've nicknamed it "the Exfiltrator", basically configured a DHCP server, nfs server, SMB, ftp and a simple php webpage offering upload and download, with the DHCP server, it's an awesome little beastie for that and some other things ;)
  2. Not had any issues here, but I'm primarily accessing it from an Ubuntu 18.04 base. I have ssh'd to it using Windows 10 and had no issues but I'm off on leave now for the holidays so no access to it at the moment but will double check when I can. Just to eliminate the obvious, it isn't just taking a while to regenerate its keys is it? It happens on connection so it could just be taking a while maybe?
  3. Honestly the only thing I can offer is "Try Harder" to coin a phrase. It took me a few attempts to get the reset function to trigger but it worked for me. If there are LEDS flashing patterns that aren't related to network activity, then I'd say there is clearly something running and its down to you to figure it out. I figured out the above, you may need to do some other incantation. There are other rescue modes advertised on the openwrt docs, perhaps you booted into one of those. Here LMGTFY: https://openwrt.org/docs/guide-user/troubleshooting/failsafe_and_factory_reset Your descript
  4. netdiscover, arp-scan, nmap -sn (or for that matter: https://nmap.org/book/man-host-discovery.html Also perhaps you should review some of the lovely free educational material published by Hak5... in particular this one may be of use: From the manual itself: I would recommend reading more of the manual: https://docs.hak5.org/hc/en-us/categories/360000982574-Packet-Squirrel The default IP, credentials and operation of the device is explained in full there. As for DNSSPOOF, that's a tool built by someone else. Read it's manual too. What are you tr
  5. Have used these a few times both for gear they sold anyway (think I bought my rdv2 from them) and hak5 gear recently when I grabbed a shark jack. Nice to have a reliable european distributor of hak5 gear! Welcome to the forums.
  6. Thanks, I was using a pin and it just kept missing it or slipping off 🙂 Wrote up the recovery guide into another thread but yeah, looks like firmware upgrade is basically scp firmware file to /root/ boot cycle it into arming mode and wait for LEDs to stop doing the hokey cokey.
  7. So anyone who's seen the other firmware post has probably seen my adventures in trying to figure out the firmware upgrade process as the suggested tool in the post just doesn't exist, is available on github if you need it, but the links in the download center appeared to be broken earlier. I ended up bricking my shark to some degree - Turns out though as it's based on openwrt it has the inbuilt recovery features. So these are the steps I took to restore its functionality - you can follow, but it is by no means the official help, nor is it without massive risk. I was willing to chalk
  8. Well... snifflebiscuits. I believe I've done did broke it. Lost network connectivity as the file was transferring (not sure why, it was there, I wasn't touching it, just SCP stopped transferring the file and said connection reset by peer). Next boot, I can only assume it tried to take to the partial file that I'd uploaded and appears to have flashed that. All switch modes are unresponsive. I don't suppose there is a "Users Be Stupid, Factory Reset" magical on-off-switch-button combination in order to restore the firmware? Edit2: I've actually managed to recover this myse
  9. I concur. The shark jack gets incredibly hot when charging. Still seems to work however, but I would definitely listen to the advice of DO NOT LEAVE IT CHARGING. Also working on it, I think there is a thermal cutoff being reached or something. I plugged it into a network port and had the USB-C connected from a reliable power bank as I was doing some dev on it and despite it continuing to flash the green LED the entire device became unresponsive. It was again, incredibly hot, like trying to hold a cup of coffee without a handle.
  10. Can confirm I'm getting the same issue. Edit: Don't think I need to do it manually. Reviewing the binaries on the host I found /usr/bin/shark_framework which has some interesting lines in. Looks like if you copy the firmware file to /root/, have the switch in arming mode... it'll autodetect and apply the firmware. #!/bin/bash SWITCH_POSITION=$(/usr/bin/SWITCH) MODE="OFF" UPGRADE_FILE=$(ls /root/upgrade-*.bin 2>/dev/null | tail -n1) LOG="logger -t Shark [*]" LOG_ERR="logger -t Shark -p 3 [!]" function upgrade_leds() { /usr/bin/LED OFF while true do
  11. I have a few ideas in mind for it, beyond just "quick!!!! make the SOC go red!" Hoping to get one progressed today and will submit it to the github payloads when it's ready for sharing. Also, for a device that can quickly check if there is a sterile area in the visitor areas of buildings when on an Phys SE job, this tool is pretty damn discrete. Certainly more so than "hey can I just er do some work! thannnnkkkss!" and whipping out a laptop with an ethernet cable.
  12. Phew thank goodness for the manual install, I rarely use my pineapple but when I do I invariably always end up factory resetting it due to forgotten passwords thanks Darren for providing the infusions for manual installation. I'm wondering if simply upgrading the openssl libraries on the underlying operating system should be enough to get this working again with firmware v2.4. not played too much with openwrt, but curious.
×
×
  • Create New...