search

whid-injector / WHID

WiFi HID Injector - An USB Rubberducky / BadUSB On Steroids.
MIT License
1.67k stars 244 forks source link

Payloads are not uploading #8

Closed SymbianSyMoh closed 7 years ago

SymbianSyMoh commented 7 years ago

Hi, I successfully flashed my WHID device after i've got my package, after successful flash and connect to the AP i can't upload payloads through the normal upload process (through all browsers) and when i go to "List Payloads" nothing there.

BTW did "Format File System" and waited 90 seconds and nothing happened too!

Any help?

SymbianSyMoh commented 7 years ago

Also how to get the firmware which in this video: https://www.youtube.com/watch?v=PGa_ByyQw8Q

The current black WHID one is boring and don't have all those functionalities like the one in the mentioned video!

whid-injector commented 7 years ago

1) which OS did u use? 2) ArduinoVesrion? 3) did u use a USB 3.0 port? (sometimes they may create issues with arduino boards. try a usb 2.0 or a usb hub) 4) WHID Software is basic. Wifi Ducky is more user friendly GUI 5) in the wikis there are all explanations and also videos on how to install wifi ducky. 6) Remember to use esptool to erase the flash eeprom

Overall, the process is for people that knows what is doing and knows how to use Arduino 😉

Sad that, if you brick it u can unbrick with a magnet. (read wiki)

So far only with one laptop I had issues with the USB 3.0 controller.

P.S. About the inability to see the files uploaded... did u carefully used the flashing settings showed in video? correct baudrate? etc? A minimu misconfiguration on Arduino IDE and you can easily upload an unstable fw.

SymbianSyMoh commented 7 years ago
whid-injector commented 7 years ago

Here the Tutorial I created a while ago with my MBA 2015 (and worked perfectly with its USB ports). https://youtu.be/AwICe2P6D0A

Here some tips that might help: 1) Reduce BAUDRATE from 57200bps to 9600bps in both Wifi Ducky sketches. (9600bps for the serial between atmega32u4 and ESP is more than enough). 2) When you flash with ESPTool or Flasher.exe, use a bit lower baudrates (e.g. 115000 instead of 115200) 3) Upload the ESP Programmer sketch and then erase its flash with: python esptool.py -p WHID-PORT erase_flash

If above will not work... there is a 99,9% of probability the cause is your computer (i.e. USB controller, drivers, etc.) or something got fucked-up on the Arduino IDE!

whid-injector commented 7 years ago

I also forgot to mention one known bug that is already in the wiki... https://github.com/whid-injector/WHID/wiki/WHID-Sotware---Uploading-Scripts

There is a 21 character limit to the file name including the DOT and EXTENSION. If your file does not show up in the payload list after uploading it then this will likely be the reason why.

AnthonyLaiuppa commented 7 years ago

On a similar note, I am experiencing this same issue. I followed the video exactly and saw no error messages.

Which OS did u use? macOS

ArduinoVesrion? 1.8.3

Did u use a USB 3.0 port? (sometimes they may create issues with arduino boards. try a usb 2.0 or a usb hub) I used a USB 2.0 Port

I used your esptool and the following to flash it

python esptool.py --port=/dev/cu.usbmodem1411 -b 115000 write_flash 0x00000 ../WHID/sketches/WHID_and_Cactus_micro_rev2_sketches/ESP_Sketch/ESP_Sketch.ino.generic.bin

Im going to try the wifiducky and see how that goes

SymbianSyMoh commented 7 years ago

I'm still struggling and can't properly upload the payloads to the board.

@whid-injector Why not pre-flashing the WHIDs, make sure that it's working properly and ship it as a ready-to-use device?

SymbianSyMoh commented 7 years ago

@AnthonyLaiuppa Did you managed to get your WHID working properly?

Krisscool commented 7 years ago

Hey, had the same issue. Resolved by renaming payload files using basic chars. (try to remove brackets, parentheses, and so on).

All is working perfectly fine now.

SymbianSyMoh commented 7 years ago

Can you please give me an example of this "basic char" i tried everything and the payload is not showing up, the example i tried was "payload.txt"

Krisscool commented 7 years ago

Must be something else then : i just removed some brackets char in my case to get something like "payload.txt" just like you did. Sorry that didn't help.

Do you have any HTTP proxy on hand (burp style) so that you can check that your post request (payload upload) send the file as expected ?

SymbianSyMoh commented 7 years ago

@Krisscool , I will consider that for sure and give my feedback, Thanks!

dkfx commented 7 years ago

I had/have the same issue. I tried the wifi ducky version (https://github.com/spacehuhn/wifi_ducky) and I noticed that space meter indicated that it had 0kb of 0kb free. I think the issue is that the SPIFFS filesystem is not being formatted correctly but that is just a hunch. I don't really have a good way to troubleshoot. I tried a lot of troubleshooting and got one board to work correctly but I have not been able to replicate it on another board. I am also using OSX.

grugs commented 7 years ago

Try this before you export the compiled binary Go to Tools then choose Flash Size and select 4M (3M SPIFFS) Then flash the unit with the new binary.

Report back too as I am curious if it solves the issue.

whid-injector commented 7 years ago

Try also to erase completely the ESP memory by forcing also the flash mode to DIO: python esptool.py -p WHID-PORT erase_flash --flash_mode dio

dkfx commented 7 years ago

I have confirmed that I have the flash size set to 4M (3M SPIFFS) in the IDE before I complied the binary.

I also tried the "python esptool.py -p WHID-PORT erase_flash --flash_mode dio" command but I got this output:

python esptool.py -p /dev/cu.usbmodem1421 erase_flash --flash_mode dio
usage: esptool [-h] [--port PORT] [--baud BAUD]
               {load_ram,dump_mem,read_mem,write_mem,write_flash,run,image_info,make_image,elf2image,read_mac,flash_id,read_flash,erase_flash}
               ...
esptool: error: unrecognized arguments: --flash_mode dio

I would also like to note that I could not get the ESP module to work with the uploaded firmware without forcing the "--flash_mode dio" flag when I flash it. I would never see the SSID so I assume the firmware was not running on the device.

whid-injector commented 7 years ago

Please try the latest version of esptool from the official repo: https://github.com/espressif/esptool Before erasing the ESP flash (i.e. by running esptool), you need to upload the ESP_Programmer.ino sketch, otherwise you are unable to communicate with the ESP.

dkfx commented 7 years ago

I tried to pull a new version but I am current. I cloned it again and I still get the same output:

python esptool.py -p /dev/cu.usbmodem1421 erase_flash --flash_mode dio
usage: esptool [-h] [--chip {auto,esp8266,esp32}] [--port PORT] [--baud BAUD]
               [--before {default_reset,no_reset}]
               [--after {hard_reset,soft_reset,no_reset}] [--no-stub]
               {load_ram,dump_mem,read_mem,write_mem,write_flash,run,image_info,make_image,elf2image,read_mac,chip_id,flash_id,read_flash_status,write_flash_status,read_flash,verify_flash,erase_flash,erase_region,version}
               ...
esptool: error: unrecognized arguments: --flash_mode dio

I have the ESP sketch uploaded but I don't think we are getting that far.

whid-injector commented 7 years ago

Said that I have never had this issue, thus I have never tried forcing -fm dio ... I believe this option works only for write_flash command. Therefore, you could try to upload an empty .bin file of 4M size and forcing the --flash_mode dio. At the end... erase_flash is just resetting the flash to all zeroes (IIRC) What I suggest then is to reset Cactus WHID and try with another computer. I usually use Windows, so with OSX might be that is the type of Macbook...

dkfx commented 7 years ago

I have actually had a lot of trouble getting the two newest boards to work. I have messed with this on three laptops (MacOS (my main machine), Debian, and Windows 7) and I keep running into the same issues. I suspect something is off with the boards since I didn't have near this much trouble with the first board I received. I will try and do the 4M empty bin file and see if that helps.

grugs commented 7 years ago

Did you try the format SPIFFS option in the firmware? Something about micro controllers is that they do one thing at a time so it just looks idle while you are formatting the file system BUT you can click on that back to index link or whatever it says and when your browser actually goes back to the main menu you know that the chip is done formatting the SPIFFS. The code looks correct to format the file system. You should do this then check the SPIFFS free space.

This is the post that makes me believe the issue is related to SPIFFS/Flashing

I had/have the same issue. I tried the wifi ducky version (https://github.com/spacehuhn/wifi_ducky) and I noticed that space meter indicated that it had 0kb of 0kb free. I think the issue is that the SPIFFS filesystem is not being formatted correctly but that is just a hunch. I don't really have a good way to troubleshoot. I tried a lot of troubleshooting and got one board to work correctly but I have not been able to replicate it on another board. I am also using OSX.

Are you flashing to this start address? 0x00000

Try writing that blank.bin file included with the tool chains to 0x00000 and perhaps even 0x40000. Unsure of its file size.

dkfx commented 7 years ago

I have tried the format option in both the WHID and the wifi_ducky firmware. I just tried it again and I can go right back to the index as fast as I can click it on the WHID firmware. There is no hang or lag in the page loading at all. I suspect its hitting an error quickly and returning false to the SPIFFS.format() function. I even tried writing a little sketch that just formats the SPIFFS and then blinks the LED but I could not get that to work.

I have tried flashing from 0x0 and 0x00000. Not sure if the distinction matters. I also used the windows tool to flash 4 1Mb empty bin files onto the chip. The only issue I saw was at the end of the very last file I got a "Set ESP8266 Address timeout" error. I suspect the chips watchdog reset it but that is unsubstantiated.

grugs commented 7 years ago

What version of the ESP8266 library are you using located in boards manager?

May be SDK issue.

Also try esptool.py write_flash --flash_size 32m RESTOFSETTINGSHERE

dkfx commented 7 years ago

I tried to update the firmware with the current one but I never get it to connect. https://github.com/espressif/esptool

This is the one I had been using that "works." https://github.com/whid-injector/esptool

I am sure the non-connecting is a symptom. I have fiddle with it but I can't get it to connect. The other one connects fine.

grugs commented 7 years ago

Did you try methods I posted? Do you have the latest ESP8266 board manager in the Arduino IDE?

Also try manually specifying flash size 32megabit which is 4M(8bits in byte) when using esptool, I feel the error is happening here... esptool.py write_flash --flash_size 32m RESTOFSETTINGSHERE

Your not supposed to use the official esptool. April Brother has a custom version

https://github.com/AprilBrother/esptool

Or for Windows user according to their cactus wiki: https://github.com/nodemcu/nodemcu-flasher

dkfx commented 7 years ago

I wiped the board with 4 1Mb files. That is what gave me the "Set ESP8266 Address timeout" error.

I have 2.3.0 for the ESP tools in ESP8266 in the Arduino boards manager.

I am going to try with the espressif version of the tool on another laptop and see if that makes any difference.

grugs commented 7 years ago

No, you should use the custom version by April Brother... i think the problem is your not specifying the flash size when using esptool and flashing add the arg -fs 32m and i think it will work.

grugs commented 7 years ago

From esptool.py:

) parser_write_flash.add_argument('--flash_size', '-fs', help='SPI Flash size in Mbit', choices=['4m', '2m', '8m', '16m', '32m', '16m-c1', '32m-c1', '32m-c2'], default='4m')

4megabits thats half a megabyte so 512kb

See esptool defaults to 512kb unit. The tool included in this repo defaults to 4m

dkfx commented 7 years ago

@grugs - You got it!

That did it. I used the older esp programming tool (https://github.com/whid-injector/esptool) and used this command:

python esptool.py --port=/dev/tty.usbmodem1421 -b 115000 write_flash 0x00000 duck.bin --flash_mode dio --flash_size 32m

I can now upload files without issue. I am still not sure why the newer tool does not connect but this works fine. Thank you!