[Introducing the WiFi Pineapple NANO]

The NANO was developed with a focus on performance and usability with integration with existing wireless pentest workflows. The platform we've chosen, keeping with the Atheros, is due not only with our familiarity with the chipset for development but because of it's strengths on the networking side of things. It's a router chip built to handle the sorts of network loads we're accustom to putting it under and for that we're very happy with the performance. And this radio in particular is tuned so well, I think you're really going to notice the RF performance. We've learned a lot since the MK5 and applied that knowledge not only to the NANO but it's the same reason we're working on a 5G capable device using similar technology.

Integration wise we've already come out with an Android app that simplifies connection and setup to the extreme. Seriously it's dead simple -- check the box and everything just works. We're also working with Nethunter developers to get the NANO integrating well with that platform, which should be pretty epic! Similarly a new connector for Linux is being built similar to wp5.sh but taking it to the next level.

The new software is more than just the streamlined Web Interface (which looks awesome, BTW). It's about compartmentalizing functions and making it easy to administer so that down the line applications can communicate and control the NANO through it's API. For example, the entire web interface and additional applications could be run on a completely separate device.

Building on our strengths while integrating with the strengths of existing devices is one of the focuses with the NANO. Whether that's a tablet running nethunter, an unrooted Android, a Pi running Kali. We're never going to compete on price with the Zero - and that's ok. Eventually we'd like to have a sexy turnkey out-of-the-box ARM solution and for a while we've been developing what we call the "WiFi Pineapple Core" -- an ARM counterpart to the NANO. Essentially when plugged into the device it would act as the next node up on the network doing heavy lifting and even seamlessly controlling the device through the API.

It's all very possible since the hardware was designed with a single USB plug for both power and network connectivity. That said, in our experience talking with ODMs on ARM we've found it extremely expensive and time consuming, at least at our scale. That's not to say we're not keen on the Core - but we think focusing on working with what's out there now before rolling our own is the better bet. Once we have more of the software done I'd love to see our own distro or tighter connector tools for these platforms. The above photo is only a proof of concept -- but it works.

Is the usb module for the pineapple nano in the pic (with an ethernet port) going to be available?

[pineaple nano and iphone]

OK thanks @Sebkinne it is possible to manage the pineaple from a iphone device? i see there is a connector app for android... is there a connection app for iphone?

[pineaple nano and iphone]

It is possible to tether an internet connection from an iphone to the pineaple nano?

[Lan turtle without Cloud VPN access server]

It is possible to have the turtle working without a cloud VM with VPN access server?

Instead I want to run my own VPN accesses server from the Internet (from home) and do all the cool things in this video:

sorry if this is a dumb question

[Help with reverse shell payload (base 64 enconding problem)]

Hello Guys

I need help with the a payload to get a reverse shell using the ruber ducky:

I tried to use the powerducky script to get a reverse shell and no luck... I figured it out it was because my victim was an X64 and not a 386 ... So i went ahead and modified my powershell shell script to detect if my victim is X64... now when I run manually my malicious powershell script on my victim and i have a htpps listener in my attacking machine it works perfectly ... now the challenge i have is encoding my powershell script in base 64 so I can ultimately use in my inject.bin....

This is what I used to encode my powershell script:

$Content = Get-Content -Path <path to my file> -Encoding Byte

$Base64 = [system.Convert]::ToBase64String($Content)

$Base64 | Out-File <path to encoded file>

Also tried iconv in Linux:

$Content = Get-Content -Path <path to my file> -Encoding Byte

Encode="`cat $Content | iconv --to-code UTF-16LE | base64 -w 0`"

and then dumping the value of variable encode...

Whenever I tried to execute my payload in my victim (after loading the inject.bin in the ducky) the ducky starts to delivers the base 64 payload... however powershell truncates the payload while processing the base 64 string .. thus not getting a reverse shell....

After trying to run manually the powershell script... powershell -Enc <base64 string> i got the message in my victim that the string is not a valid base 64 string....

Anyone can point me on the command I need to run to convert my powershell script into a valid base 64 string so powershell can execute it?

PS the reverse shell (reflective and web delivered) in powerducky have the same problem... whenever the inject.bin runs in the victim... the base 64 string is truncated in the victim and no reverse shell is sent to the attacking machine...

Thanks

[Power Ducky ToolKit]

Hello b00stfr3ak

Powerducky is a great tool however the latest version checked in github has some issues...

It seems there was some syntax issue in the main menu.. and the payload to add a user to the admin group fails, since the localadmin word is misspelled.

For the reverse shell attack I am able to make it work from the rubber ducky, the payload is injected and i got a message in my attacking machine (sending stage to victim xx bytes) but it hangs there.... I tried to use the meterpreter X64 (since my victim machine uses an x64 architecture) but powershell just dies in the victim machine. It seems the payload needs to be specific for a x64 victim and your payload in github is specific for 32 bits.. do you have a reverse shell payload for x64? thank you....