Yet another 'bricked' Bunny thread

[datguy_dev]

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. 

[Dave-ee Jones]

Is PythonBunny just some kind of library to interact with the Bunny outside of a 'payload.txt' or console? Why? Seems so silly..

It probably won't boot properly with the case because of the switch, it's probably holding it in the position, or it's trying to detect a part of the case and it can't see it (using the switch or LED).

Anyway, you have to remember, many people have said multiple times don't try changing the switch while a payload is running. Saying "yet another bricked Bunny.." kinda sounds like your blaming Hak5 for what you've done.

Anyway, I'm assuming you've tried recovering it with the normal eject-3-times-to-save-Bunny?

4 hours ago, datguy_dev said:

If I leave the BB unplugged for 5 minutes, it will sometimes boot to ARMing mode but crash shortly after

Whut. Are you saying that your Bunny randomly turns on when it's just sitting on the desk??

[quentin_lamamy]

7 hours ago, Dave-ee Jones said:

Whut. Are you saying that your Bunny randomly turns on when it's just sitting on the desk??

Vade Retro Satana

[datguy_dev]

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.

[Opticon]

@datguy_dev Well guess what? Mine did the same thing. It was just as you wrote; "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." So, I'll tell you when this started becoming an issue, not to mention I lost the ability to use payloads in switch position 2. I was advised to update to firmware 1.3, as new features had been made available. I was running the out-of-box- 1.0 without incident. After writing and researching, I changed to a firmware that I hadn't used, as recovery mode would not work- contrary to what is in writing. Firmware 1.2 resolved it. Every single time I use it, it operates the same, with no random lights at boot or disconnection from my system, and I can leave it plugged in for hours. So contrary to any advice given on the board, I will not use 1.3 as it caused a myriad of problems including everything you wrote and more! 

-Cheers

[datguy_dev]

1 hour ago, Opticon said:

@datguy_dev Well guess what? Mine did the same thing. It was just as you wrote; "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." So, I'll tell you when this started becoming an issue, not to mention I lost the ability to use payloads in switch position 2. I was advised to update to firmware 1.3, as new features had been made available. I was running the out-of-box- 1.0 without incident. After writing and researching, I changed to a firmware that I hadn't used, as recovery mode would not work- contrary to what is in writing. Firmware 1.2 resolved it. Every single time I use it, it operates the same, with no random lights at boot or disconnection from my system, and I can leave it plugged in for hours. So contrary to any advice given on the board, I will not use 1.3 as it caused a myriad of problems including everything you wrote and more! 

-Cheers

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. 

Edited September 14, 2017 by datguy_dev

[quentin_lamamy]

On 14/09/2017 at 8:42 PM, datguy_dev said:

Oh well, peace out. I'm not going to buy another. May try the Rpi Zero route sometime down the road though. 

I'm not sure you will succeed doing the same thing easily with a RPI 0 without resulting to a big ugly not cased pcb with lot of cable.

Quote

Search for "bricked." There are numerous threads and thus this is "yet another" one of those threads. Those are your words, not mine. 

With all the respect i must use when answering to a bb user :

BB is not a toy, it's a pentest tool which require some technical awareness. If you don't have skill i'm quite sure it will be useless for you. And even if you want to try to play with it, please always RTFM, avoid having dumb and inappropriate use of your bb (playing with switch when plugged in is a inappropriate use on my mind)

Edited September 15, 2017 by quentin.lamamy

[Dave-ee Jones]

4 hours ago, datguy_dev said:

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. 

Did you try Opticon's method of fixing?

I don't know why F1.3 is bricking some Bunny's, mine's fine and all my payloads and switches work when on F1.3, had no problems with it whatsoever. My suggestion is to see how Opticon's method goes, if it doesn't work it doesn't work. Talk to Hak5 Support and they will most likely replace it for you, however I can't be sure as you said you've opened your Bunny at least once. Bit of a waste of $100 USD just to try the Bunny and then have a rude attitude and give up on it just like that.

RPi Zero might be a better solution for you though, it sounds like.

[Opticon]

Hello again @datguy_dev !

As @Dave-ee Jones suggested, you may be able to resolve it using my method. However, I am not daft nor ignorant, as you wrote;

23 hours ago, datguy_dev said:

Therefore I cannot recover nor change the firmware because my BB crashes after 15 seconds or so

I'm truly sorry for your situation, as I have exhausted all options. Put in a word to Hak5 and see about an exchange.