dark_pyrro
-
Posts
2,625 -
Joined
-
Last visited
-
Days Won
198
Posts posted by dark_pyrro
-
-
If xterm is available on the Ubuntu target, that is
-
You will probably increase your chances of getting an answer if posting in the Pineapple section of the forums
-
1
-
-
That is nothing related to your specific C2 setup. It's a (most likely) certificate glitch in the Hak5 infrastructure that supports C2. On every start, the C2 instance verifies the license against a kind of service that Hak5 has up and running. If the C2 server hasn't got internet access, or that something like certificates aren't behaving as expected, then the C2 server won't start.
-
It will contact the server at least during normal startup as well, so those that want to start an "untouched" C2 server will have problems as well. I seem to remember that it checks it periodically when running as well, but I might remember that wrong. As I said on Discord, it affects instances that has been installed years ago as well, so it's not directly related to upgrades specifically (I also tried with the 3.2.0 binary and it does the same thing, i.e. doesn't start since it can't verify the license against the Hak5 infrastructure).
-
I can't say that I totally agree that it's a different Atmel chip. They are both based on 32UC3B1.
What I agree to though is not to try to flash the 2nd gen Ducky with any alternative firmware. But, since this is posted in the forum section for the old Duck, and that the title of the post (and the post itself) clearly states "Classic Rubber Ducky", then I guess that's already a "non issue".
Try these links:
https://code.google.com/archive/p/ducky-flasher/
https://github.com/midnitesnake/usb-rubber-ducky
And... flashing anything else other than what's official/stock Hak5 is at your own risk...
-
You can submit it to the Hak5 GitHub repo, there are similar ones there already though in different categories.
You could also slim it down a bit since using the 2nd gen Ducky and get rid of some ENTER lines if using STRINGLN instead of STRING + ENTER.
Also possible to try the DETECT_READY extension instead of the initial DELAY to make payload execution faster (in many cases) and also not risk having a DELAY set that might be too short.
-
So, you're running a Mac on a .1 address. Not at all impossible, but doesn't sound likely if it's a regular/normal home /24 network.
-
Are you using the correct port along with the IP address?
-
As you can see here (and also on other places in the documentation)...
https://docs.hak5.org/shark-jack/getting-started/shark-jack-basics
...the documentation is about both the SJB and the SJC, and as you may already have discovered, the parts that are only for the SJC is commented in the texts.
I would advise to read the documentation, and all of it, and you will see what relates to the SJB (as well as the SJC).
11 minutes ago, npcdev said:but why totally rewrite the entire system
Not sure what this relates to, how do you know that is was totally rewritten?
12 minutes ago, npcdev said:It would have been nice to pay a little extra money and have it be wireless.
It is nice with a lot of things and the Santa wish list can be long. As I see it, it's all about use case and every use case/scenario has its tools. So, to be specific, why would it need to have wireless capabilities? (Actually, the MT7628DAN "SoC" in itself has WiFi capabilities, but it's not part of the Shark implementation).
-
4 hours ago, npcdev said:
After configuring my Windows laptop and installing Ubuntu to run the Sharkjack.sh file, it doesn't even work.
Be more specific about what's not working
4 hours ago, npcdev said:flashing version 1.2.0 from the SJC didn't resolve the issue either
Don't (or actually DON'T!!!) flash firmware variants that aren't supposed to be used with a specific product. The SJC firmware is for the SJC only.
4 hours ago, npcdev said:Googled and even used GPT to see if there was something I was missing, but nothing came out of it.
Why not just read the official documentation, then you would have gotten answers to some things that you seem to have issues with (however, still not fully clear what those issues are)
4 hours ago, npcdev said:I also get this weird message when trying to ssh into the shark on CMD after I updated the firmware.
See comment below on screenshot 2.
Regarding the screenshots specifically:
Screenshot 1; nothing strange here, it's what the "menu" looks like when executing that script, please be more specific about to which issue this is related
Screenshot 2; still nothing strange, you have probably (or; you have) been running ssh against that IP address (probably sessions against the Shark before and after the firmware update) and you need to remove that entry in known_hosts to be able to run a ssh session against that IP again, it's just standard ssh behavior, nothing Shark related specifically, just basic "ssh knowledge"
Screenshot 3; nothing strange here either when operating the battery based Shark, those commands are simply not available for the battery version (and some of those executed aren't even commands)
In detail...
HELP - not a SJB command
UPDATE_PAYLOADS - not a SJB command
from the official documentation
"The UPDATE_PAYLOADS command was introduced with firmware 1.2.0 on the Shark Jack Cable and requires an internet connection."
https://docs.hak5.org/shark-jack/managing-payloads/untitledLIST - not a SJB command
the official documentation has a typo here since it refers to the ACTIVATE command when making it clear that the LIST commands is for the SJC, but... anyway... it's not available on the SJB
https://docs.hak5.org/shark-jack/managing-payloads/the-list-commandLIST_PAYLOADS is just an alias for the LIST command, so the same goes here as for the LIST command
ACTIVATE and the alias ACTIVATE_PAYLOAD - not a SJB command
from the official documentation
"The ACTIVATE command was introduced with firmware 1.2.0 on the Shark Jack Cable"
https://docs.hak5.org/shark-jack/managing-payloads/the-activate-commandUPDATE_FIRMWARE - not a SJB command
from the official documentation
"Shark Jack Cable users may conveniently upgrade their device's firmware by running the UPDATE_FIRMWARE command"
(and then the word "Shark Jack Cable" is mentioned in almost every step in the instruction, so it's quite obvious it's not for the SJB)
https://docs.hak5.org/shark-jack/software-updates/over-the-air-upgradeThe commands above, and the fact that they are "SJC only, can also be read here
https://docs.hak5.org/shark-jack/getting-started/default-settings#shark-jack-helpers-and-commandsSo... all in all... I can't see anything being wrong with your battery based Shark, it's exactly as it should be and according to the official documentation (if there isn't any other issues that can be more specifically described in order to troubleshoot it).
-
Check the FCC documentation for the product
-
Sounds like a parallel discussion on Discord. In that case it was the USB cable.
-
29 minutes ago, MarkusM said:
ok, so from the principle it is a performance problem....
could be, but not really, it's by design that the Pineapple loops through available channels, the optimal way is to have one radio per channel (like the Coconut) but that is not the way the Pineapple is set up
30 minutes ago, MarkusM said:quite nicely done but not really usable
that really depends on the use case of the user, just because it might not fit your exact scenario, that doesn't make it not usable, for you most likely, but not for all
31 minutes ago, MarkusM said:why can I actually only enter one post per day here in the forum???
because the forum is abused from time to time and that has to be stopped in some way, the chosen method is to limit newly registered users until they have reached a certain amount of posts, if I remember it correctly it's 5 posts
-
The SOC mainly, but also networking devices used and amount of RAM (etc).
-
I guess you are the same one posting on Discord recently about the same thing and got some advise there. Perhaps not on the formatting part though. Try another card (preferably 2 GB or less), or try formatting it with something else than Windows native formatting tool.
-
Exfil to some online storage? Other than that (if using the Ducky as a storage device isn't an option), then I guess you're stuck with mentioned keystroke reflection. Exfiltrating a PPT(x) using keystroke reflection can be a time consuming process though (even if it's just an example).
-
There's no 100% guarantee that all the devices you see connected to a (for example) home router will show up. They have to be active to do that. The Pineapple also cycles through the WiFi channels and if a device connects to channels 6 when the Pineapple is scanning on channel 11, it won't show. Even worse on 5 GHz since there are more channels to cycle through.
-
Since it's not an officially supported way of accessing the Pineapple, it's not part of any customer documentation. I have used the mentioned/quoted pinout, and it has worked for me since a long time back. The 3.3V pin isn't really needed though since the Pineapple will be powered on.
-
Did you read the documentation? Use the button.
-
It depends on what you want to do, and how
I think using uci is far easier if the settings are a part of what's within the "uci scope"
To show not just the value, but the whole "uci path" as well, for a LED setting (using red LED as an example here):
uci show system.led_red.triggerTo show just the value itself:
uci get system.led_red.triggerSet a value for a LED color:
uci set system.led_red.trigger='default-on'
uci commit system
/etc/init.d/system restartAddressing green and blue is done in the same way:
uci set system.led_green.trigger='off'
uci set system.led_blue.trigger='off'Possible trigger settings should be:
default-on
off
heartbeat
netdev
with extended options for netdev specifically:
option mode 'tx rx'
option dev 'eth0'
option dev 'wlan0'
option dev 'wlan0-1'
option dev 'wlan0-2'
option dev 'wlan0-3'
option dev 'wlan1mon'
option dev 'wlan2'
option dev 'wlan3mon' -
you can use uci as well to "interact" with it (instead of just using grep)
-
OK, well... if you want to edit the settings that the web UI saves using CLI, then you can try to manipulate /etc/config/system
-
What LED binary? There's just a script file that controls the LED.
Just cat the files below and if it returns a 1, that LED state is activated
/sys/class/leds/red:system/brightness
/sys/class/leds/green:system/brightness
/sys/class/leds/blue:system/brightness
To turn off the LED, just execute LED OFF
-
2 minutes ago, v0id9 said:
get the current state
Not sure if I understand your use case, but can't you just check the LED related file(s) to get the current state (the ones you've already mentioned)?
Shift key in STRING seems to not be working correctly
in Bash Bunny
Posted
Can't agree really that it's part of the "out of the box experience" when it comes to Ubuntu 22.04. I checked on 3 of my 22.04 boxes and none had xterm available. (Not the default Kali rolling release VM I spun up either).