[enhancement] Call back C&C(And Open Discussion)

[exploitagency]

[enhancement] Call back C&C(And Open Discussion)

[ChandraOrbit]

I am waiting for a GSM support upgrade, the price issue is not a problem because at least there is a modernization to follow the needs of the current era of mobile gadged everything.

Like this Adafruit Feather 32u4 FONA but with a compact and minimalist form

[ChandraOrbit]

there is an information on Ryan Ackroyd's tweeter with his eye-catching video demonstrating here, because he has already implemented it, it's just that the workings, schemes and source codes are not mentioned. Maybe in time to come you can make it happen. thanks.

[whid-injector]

I was already making prototypes with such kind of GSM modules, even before the inception of WHID.
The main blocker, is that the board would then not fit a USB case.
At this point, just use a OrangePi IoT 2G with P4wnP1.

[whid-injector]

@mame82 will be happy if u will port his P4wnP1 to OrangePi IoT 2G 😉

[ChandraOrbit]

@whid-injector, I happen to have one unused OrangePi IoT 2G.

I would be very grateful to you and how happy I am if you are willing to provide a guide guide or a little hint to install OrangePi IoT 2G with P4wnP1.
I've searched on Google but did not find the clue, and a few days ago I've asked @mame82 HERE but the answer is "No port for OrangePi atm"

thanks.

[whid-injector]

1. Re-read my intial message about it. I suggested you to port it to OrangePi, NOT to ask someone else! 😒
2. Your are polluting this thread with out of topic crap! 😤
3. Here we are not a help desk.
   4)Did you first tried to install Armbian on Orangepi IoT and tried to install P4wnP1 and see where is failing?😤

People has a job, family and hobbies. I am not here to do stuff for you!

I am really pissed when I see these kind of messages.😤😤😤

[exploitagency]

I will look into it if someone wants to donate the hardware and 2G service that works in the US. But why not try to create something original with broader network support? 2G options in the US are being phased out. I would prefer to create something original. It is a low priority on my list of projects but maybe I will get around to it.

[whid-injector]

From my side, I am going to port P4wnP1 straight to my POTAEbox board once I will bring it to production.
However OrangePi IoT 2G is already a nice bord to play with P4wnP1.
As for MobNets, only US killed 2G IIRC.
Countries like India or China will take other 10 years (at least) before shutting it down. Reason why OrangePi used a 2G modem. (cheap and still used in most of countries)

[exploitagency]

Well I wish you luck. I have a lot of other small unrelated projects I am working on though. So me porting something is not on my to do list, but I have built a simple cellular proof of concept before just never bothered to get a 2G sim to test it. I have never looked into that Pi project though, theres a ton of attack vectors when you bring a Pi into the equation, I just looked up the P4wnP1 project and there are even more attack vectors than they utilize. The Pi Zero W is pretty amazing hardware though for its size, but I rarely pull it out. But my PoC used much simpler 8 bit hardware but that is a neat project, I think your port should be fairly straight forward. I will check it out when your done.

[whid-injector]

P4wnp1 is indeed a nice framework. Unfortunately both RPi and OrangePi are too bulky.
That's why WHID + ESPloit is still the best covert solution for remote HID attacks, that can fit an innocent USB case.
P.s. Corey, as soon as I have few prototypes of POTAEbox I am going to send you one, sure you will enjoy it for your cool projects 🙂

https://www.dropbox.com/s/2v6y6wvd1wb5fck/File%2008-10-2017%2C%2012%2022%2013.png?dl=0

[exploitagency]

Thank you, I am sure I will find it useful.

[ChandraOrbit]

@whid-injector. Sorry if what I say does not please you. Maybe I was wrong in shipping. I only connect from the previous message. So I think there is little clue to me. Suppose I was a blind man, if there was a little lightening it would be wise.

Thanks and sorry before and last.

[exploitagency]

You will do fine @ChandraOrbit his point was we are not here to spoon feed anyone. But while we are on the topic of spoon feeding I have tried my best to NoobProof most of my projects so there is hope of replicating them or it would defeat the purpose of sharing them in the first place.

And while we are so far off topic @whid-injector have you tried this out yet?

https://exploitagency.github.io/Duckuino/index.html

It should help many users who are the copy paste type to convert ducky scripts into something to run on the stock firmware. I don't think many people are aware it exists yet.

Basically no one is ever going to be at the same skill level and will excel in different areas. A lot of the community using this device can not contribute to hardware or software development but if we make it easy enough for them to create usable payloads that same person can create something very creative to help the project gain popularity. With the price, ease of use, and the featureset I feel like we have a winner here. We just need the community now and to gain a little traction.

[whid-injector]

Sadly I haven't time yet to test that feature. But is indeed a cool thing to have for newbies! 🤘🙂
Actually as unsatisfied Hak5 customer, I prefer to have nothing to do with them. Even compatibility with their Ducky scripts. 😁

[exploitagency]

Well everyone is entitled to their own opinion. I like the Hak5 crew just fine, I have even had projects featured on their web show before. I actually chose to create my own payload scripting language out of respect to them and their product so I would have something more original. Plus ESPloit's scripting language is in my opinion a lot more extensive, you can type out strings that include carriage returns, mouse emulation, etc... I figured referencing ASCII codes for button presses would be trivial for the end user but Ducky Script uses plain text for these instead, it is a toss up there. Though apparently an option for Ducky Script conversion was needed to support the conversion of the massive amounts of existing payloads available for the Rubber Ducky. Some users are actually migrating our way that have already wrote payloads for the Rubber Ducky. And some users just want to search for and copy/paste a payload and it work. Even if we don't use certain tools, some things just have to exist for those specific scenarios so our project can be a success.

[mame82]

@exploitagency

I've done an converter for DigiSpark (AVR based), too
https://github.com/mame82/duck2spark/

I even done a reimplementetion of duckencoder:
https://github.com/mame82/duckencoder.py

The former uncovered how bad the original encoder was written.

Finally I incorporated it into P4wnP1...
https://github.com/mame82/P4wnP1
... only to make it easy for folks to get started.

Anyway, DuckyScript is a mess. Hard to send raw keys, even harder to send non ASCII chars.
Building functions or branching is impossible, but needed for P4wnP1. The only instruction to ease up handling repetitive tasks is REPEAT which only takes the last line into account. Even worse the, if you repeat an output 10 times, it is written to the compiled script 10 times. This increases output size dramatically (instead of using the Microcontroller capabilities to loop through code). Same is true for the DELAY function which gets encoded to the unused HID keycode of 0x00, with a single modifier byte representing the delay ... so you end up with a maximum delay of 255ms per 2 bytes of output. A 5000ms delay consumes 40 bytes in final output !

At least I added the ability to accept raw HID keycodes + modifiers to DuckEncoder, but the 8 month old PR was never reviewed
https://github.com/hak5darren/USB-Rubber-Ducky/pull/54

Hak5 moved over to DuckToolkit on BashBunny, which is more robust but doesn't introduce missing features.

So as soon as I have the time to do it, I'll drop DuckyScript support and introduce something more usable.
This is especially needed to combine everything with MouseScript for P4wnP1.

I wouldn't advice anyone who starts a new HID keyboard project to use DuckyScript. It isn't flexible, but restricted and not robust.

[mame82]

One more addition:
A boot protocol capable HID keyboard desriptor accepts 8 modifier bits and 6 keyboard bytes. A RubberDucky only sends 1 modifier byte and 1 keycode byte per HID input report. This restriction is represented in DuckyScript and makes it impossible to send multiple keycodes with the same modifier in a single report. This is of course a corner case, but playing multiple notes at the same time with a keyboard driven software synthesizer is impossible with DuckyScript ;-)

[ChandraOrbit]

I've tried using https://exploitagency.github.io/Duckuino/index.html
For ordinary users it's a very helpful thing. Although the end result we have to change / adjust delay.
But I prefer writing myself because the Esploit script is more concise and broad.

additional beyond my opinion above
Some cases in my tests are using several machines with different OS,

1. Esploit has decreased speed in the payload delivery when the target computer is long enough to be used. And will be very responsive when the new Target computer is turned on.
2. Also if Esploit is long enough attached to the target then the payload shipping speed will be slightly reduced. Most likely the heat changes on the Esploit device.
3. There are conditions if Esploit join target network and target network in high traffic condition (eg Public Hotspot / Cafe) then payload delivery will experience some time delay. In one load with larger files> 1500bytes will happen some delay time, this is very uncomfortable in my opinion.

So in making one payload, I have to do some tests with the above conditions.
So making a ready-made payload takes a long time (this is a constraint in my opinion)

Thanks

[exploitagency]

Focus more on text based commands in the payload and depend less on making your payload download an app, this is a keystroke injection attack after all. I feel like your third response is referring to using the FTP server to download files to the victim PC, also if you must depend on some app to do your dirty work as I told you previously download it to the target using a HTTP transfer not FTP, you can find the link of any uploaded file from the exfiltrated files page even if you intentionally uploaded it via FTP and it didnt come from a victim pc. I assume its likely an EXE file lets say test.exe the download link would be http://192.168.1.1/test.exe . You get the idea. I have not done a side by side speed comparison but I assume HTTP to be faster and more reliable. Don't even turn on FTP if you can help it. Use the HTTP exfiltration methods as well. You have got to be creative with payloads and optimize them as you said before. Also turn off any mode you are not using in the settings as part of said optimization. I am glad you like my scripting language better. Thanks for your feedback.

[ChandraOrbit]

Yes, For now Esploit will be maximized if more focus on text based command in payload because seen in terms of hardware minimalist.

I did some tests because I was a teacher aide, so I had to be able to summarize the questions from my students with all their strengths and limitations.

For Point 1 and 2 can be your consideration. It was the result of my experiments several times with OS and Machine with different specifications.
Maybe others will find different results.

[exploitagency]

I hope it was a great lesson! I wish I had such a device being demonstrated by my teacher while I was in school. Keep up the good work. I am sure it was a lot of fun for your students.