Jump to content

datguy_dev

Active Members
  • Content Count

    18
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by datguy_dev

  1. I should have mentioned I was running v1.3 at the time this happened. Yet, the problems I have began immediately after I changed the switch. Before that, it was fine. So I'm not entirely sure we have the exact same issues. I have wait 5 minutes, try to boot, and 70% or so of the tries it'll fail. Whereas if I wait 1 minute, it fails 100% of the time. However, there is like a 95% chance it'll boot if I remove the cover to inspect it, put it back together, then boot. But it crashes shortly after. Therefore I cannot recover nor change the firmware because my BB crashes after 15 seconds or so. Its truly bricked. Ran a continuity test on the switch. Seems to be working fine. Though it doesn't appear to be grounded directly to the USB negative. Odd. Oh well, peace out. I'm not going to buy another. May try the Rpi Zero route sometime down the road though.
  2. Do I really need to explain that the BB was plugged in after a period of time? To clarify that, there is a duration of time of when the BB is left unplugged - that when plugged back into a power source - that produces different boot sequences for the BB. Whether that be no power, a solid green led, or a slow blue led. For example, 1 minute between the BB being unplugged and plugged in, would likely produce no led; as in dead. Say 2-3 minutes of rest would more likely produce a solid green light, with it being plugged back in of course. Where 5+ minutes of rest might reach a slow blue led, with it being plugged back in of course. 1+1 Search for "bricked." There are numerous threads and thus this is "yet another" one of those threads. Those are your words, not mine. If someone can't put 1+1 together on the power discussion, I would not even attempt to try and explain that Python library, let alone take techincal troubleshooting advice from them.
  3. Greetings, I was in the middle of developing this Python library: https://github.com/datguy-dev/pythonbunny I was testing the "switch helper." I wanted to see what would happen if someone happened to change the switch position while the Bunny was running. Perhaps I could use the change of the switch for additional functionality mid-payload... Kind of risky, but with my research, I figured it simply indicates where and what resources to run at after booting. I thought it would be safe, but it crashed the Bunny when I did. Ever since I've been trying to get the BB working again. If I leave the BB unplugged for 5 minutes, it will sometimes boot to ARMing mode but crash shortly after. Sometimes in ARMing mode it will boot to a solid green led but not progress even waiting for ~10 minutes. The longer I wait with it unplugged, the better the odds of it booting. The led will not light in switch position 1 or 2 nor will it appear as a device. These other switch positions appear completely dead. One time, it appeared stable so I tried to run the recovery script in /usr/local/bunny/bin. It began the red/blue routine and within a minute or so it went a blue led. But after booting again, the firmware version was the same so I suspect that failed... Haven't gotten that far since. I have had no success with the unplugging recovery method given the inconsistent booting. Such as sometimes I get no power and a solid green led. Still, I tried to get at least 3 of the proper green led, just before blue, and it has yet to recover. Tried an 2A USB power adapter in the wall with the same results. One thing I found interesting is the BB with heatsinks, will not boot at all without the case. I'm not sure why that is. If I can't fix this BB, it'll suck because that library is going to be abandoned.
  4. That is true. But if you're good, no one should see it right? :D Personally, I'm in it for the tech and not the creds. I tinker around with Arduino and ARM boards as well. I guess you could call me a whitehat, as I just graduated not too long ago w/ certs and now work as a sys admin. Can't take such risks anymore. I did try out cucumber plaid. I didn't see a difference at first glance.
  5. Greetings, I was bored, so I cut a chunk off the top of the BashBunny and slapped a small heatsink on the CPU. The fit is snug, so I could use thermal paste (generic white). With storage, ethernet, and ssh, it idles around 50 C*? according to /sys/class/thermal/thermal_zone0/temp. Default governor. The heatsink is hot to the touch; not warm. I simulated a load looping "find /" and it got as hot as 55 C. I never had heat issues with the BashBunny. But it does look "cooler" so why not?
  6. It's not the LEDs. Its just I'm having all sorts of "saving loot" or writing issues that have been inconsistent and just wonky all around. I was hoping there was a definite answer to writing to the BashBunny. This shouldn't be a cryptic thing in the least. With my bashbunny, I found that it fails to write the first pass. But after being re inserted, it does work. I would really like to know the reasoning behind why I have to do that to save a simple text file.
  7. Greetings, Would anyone care to provide the most current means for "saving loot." Whether that be echo "${X}" > /root/udisk/etc or mv $file to /root/udisk. I'm sure both work, but I have had no luck saving anything run from a payload to the disk on the BashBunny. I just cannot figure it out even scraping through all the payloads posted on github. It's kind of crazy. I made a payload to test directories while using switch 1 or 2. Such as below, it's simple. Yet I'll get a green led saying that /see/more/butts is a directory! It makes no sense. Even if I change /root/udisk to /udisk it still lights green. I had a payload that used the echo write method for saving information to a file. But when I went to check the loot in arming mode, the payloads folder was gone! It just disappeared. :D I had to do a recovery and the first time, it failed. Second time worked a charm, but I wouldn't be surprised if my permissions or something is now even more messed up. It is working normally in every other context though. But I thought I'd ask as I don't want to brick the BB experimenting further. (! = not. -d = directory.) #!/bin/bash if [ ! -d "$(pwd)" ]; then LED R else LED G fi if [ ! -d "/root/udisk" ]; then LED R else LED G fi if [ ! -d "/see/more/butts" ]; then LED R else LED G fi
  8. Thanks for your reply. I just found your thread about this issue and it answered a lot of questions. ... That sucks for the time being huh? I remember watching hak5's bash bunny introduction video and Darren was combining attackmodes like it was nothing. [face palm]
  9. It has been wonky for me as well. I don't know what to make of it as of yet.
  10. No one else has had this issue? Maybe I have the wrong idea, are you supposed to only use a single attackmode at a given time?
  11. Found: " Three of five attack modes may be executed simultaneously." and that doesn't work because RNDIS _ETHERNET & ECM_ETHERNET.
  12. Greetings, I just received the BashBunny in the mail, so please bare with me. I was just trying to get started, when I ran into problems trying to share an internet connection w/ Windows 10. If I use the default payload on switch 2, ATTACKMODE RNDIS_ETHERNET STORAGE, or vise versa, it refuses to pop up as an Ethernet device in Windows. Just RNDIS_ETHERNET works, but isn't that kind of a problem when it comes to saving loot? On a side note: " Many combinations of attack modes are possible, however some are not. For example, ATTACKMODE HID STORAGE ECM_ETHERNET is valid while ATTACKMODE RNDIS_ETHERNET ECM_ETHERNET STORAGE SERIAL is not." - http://wiki.bashbunny.com/#!index.md How do I know what is a proper attackmode combination?
×
×
  • Create New...