Cannot download offline copy of Payload Studio Pro

[Antithetikos]

I started a new topic because Darren pinned my initial question so I didn't want to add any clutter to it.

I do not get the option to download a local copy of Payload Studio Community or Pro (Yes, I have a license). I'm using Windows (10 and 11) and have tried Chrome and Firefox in both normal and private/incognito mode. 

Is anyone else seeing the option in the address bar? If so, I'll chalk it up to some compatibility issue with my setups. 

Just in case someone is curious, sometimes I am creating payloads in an environment where the hak5.org domain is blocked (depending on who is in charge at the moment). This is why I need the offline option.

[Darren Kitchen]

For Chrome, click the Menu > More tools > Save page as...

For Firefox, click the Menu > Save page as...

For Edge, click Menu > More tools > Save page as (or go to firefox.com or chrome.com to get a real browser 😜)

[Antithetikos]

Thank you very much.

Saving it locally with Firefox worked, however both the Chrome and Edge saves did not. Long story short, save it with Firefox and you can use that save in all three browsers.

When saving it downloaded all of the dependent files but it looks like both Chrome and Edge modify the .js files. It appends a ".download" extension to each .js file and it appears to modify the references in the main .htm file with the correct new file names. However, each of the js.download files are only 9k in size. The .js files in the Firefox save vary in size.

Just for fun, I tried replacing the .js.download files from the Chrome save with appropriately renamed .js files from the Firefox save, but it did not work. 

Now, how do I get Payload Studio to run in Internet Explorer 11? Just kidding...

   

[Darren Kitchen]

Good tip re: Firefox download. Something may have changed since I tested the Chrome download in private beta.

[DidYouSayLinux]

Glad this was brought up. Without a mode to run payloads the RD's are just worthless bricks.  I dont need an IDE forced on me by hak5. 

I will try local only studio ability to generate my own byte code capability, but if it doesnt work on my linux laptop, the two new rubber ducky would be useless bricks to me.  

I would rather have the specs so I can generate the bytecode with python from files I write with vi. All fine if you want an IDE, just dont force it as mandatory or requires any browser or portal -- 

But I would prefer a mode where simple file called payload.ini or the like that would allow the RD to run std payloads and bypass this self serving sidebar to a once really cool device. I read the intro to the book and it describe the beginning of a departure from value and one of the worst UX decisions ever.

How ironic it would be to throw away the very benefits Darren used as a sysadmin to combine bash and duckyscript only to abandon the loyal group to force a .bin file to be created or else no .bin file present renders a RD device to be a cheap usb device. Rather than a fallback behavior to look for a payload file.

That is what I read Darren's 2nd ed book. Hopefully hak5 isnt going down the Java bytecode rabbit hole and losing its vision.  

I'd much prefer to hear back I completely misread the book and I never have to use an online tool (yes I have the full license) or portal to create .bin files. 

If not, this departure from standards (that hak5 defined) has zero value if it requires a browser to be involved in anyway.  It just shows a lack of imagination.

 

[Darren Kitchen]

Quote

I will try local only studio ability to generate my own byte code capability, but if it doesnt work on my linux laptop, the two new rubber ducky would be useless bricks to me.  

The compiler, which is a component of Payload Studio, will work in your browser offline on Linux for both Pro & Community editions.

Quote

I would rather have the specs so I can generate the bytecode with python from files I write with vi. All fine if you want an IDE, just dont force it as mandatory or requires any browser or portal -- 

You're welcome to write payloads in any text editor — vi, nano, etc — and use the compiler component of Payload Studio to generate the inject.bin

Quote

But I would prefer a mode where simple file called payload.ini or the like that would allow the RD to run std payloads and bypass this self serving sidebar to a once really cool device. I read the intro to the book and it describe the beginning of a departure from value and one of the worst UX decisions ever.

The original USB Rubber Ducky required that payloads, written in any pain text editor, needed to be encoded using a java-based command line tool. That was 2010, and a lot has changed since then. We found over time that folks were a lot more comfortable with a web based encoder, hence the jsencoder.html that was introduced in 2018. Most systems do not include/run java nowadays, and running a jar from the command line is an unnecessary hassle for most.

Quote

How ironic it would be to throw away the very benefits Darren used as a sysadmin to combine bash and duckyscript only to abandon the loyal group to force a .bin file to be created or else no .bin file present renders a RD device to be a cheap usb device. Rather than a fallback behavior to look for a payload file.

I see where I may have given the misconception in the book that we abandoned bash+duckyscript. We did not — however that product is the Bash Bunny, a full Linux-box-on-USB-stick that processes payloads written directly in Bash with the addition of some device-specific DuckyScript helpers. The USB Rubber Ducky on the other hand has always required a .bin file, and has never run Bash. So I can see how the impression that we've changed course could have been had, and I assure you that is not the case. If you're looking for a multi-vector attack tool that runs payloads with the power of Linux and Bash with DuckyScript — you want the Bash Bunny. If you're looking for an easy to use keystroke injection tool with advanced capabilities, you've got the USB Rubber Ducky — which has always required DuckyScript to be compiled to inject.bin

Quote

That is what I read Darren's 2nd ed book. Hopefully hak5 isnt going down the Java bytecode rabbit hole and losing its vision.  

As stated previously, we've departed from the old requirement of running a Java "duckencoder.jar" file to compile payloads and now have a much more flexible web-based compiler, all in JavaScript, which can be run locally that happens to also include fancy IDE functions. You're welcome to use vi and only use the javascript compiler to generate the inject.bin, which has always been necessary with the USB Rubber Ducky.