Jump to content

bsdthread_register error on MacOS


BadActor

Recommended Posts

Posted

I just received my BashBunny MkII and cannot get it to work from my Mac. When plugged in using Arming mode, I wasn't able to modify payloads. I deleted the existing payload and drug a saved payload.txt into the BashBunny in order to get it on the device. After safely ejecting and setting to Switch 1 with the saved payload, Iget "Input/Output error" when attempting to execute. I updated to the latest firmware but noticed that I cannot update using BunnyUpdater.app. I've tried the chmod +x on locations both within BashBunny itself and in Downloads from here

 

I get the following output: 

/Users/BadActor/Downloads/BunnyUpdater.app/Contents/MacOS/bbupdater ; exit;
fatal error: runtime: bsdthread_register error

runtime stack:
runtime.throw(0x14234dc, 0x21)
	/usr/local/go/src/runtime/panic.go:605 +0x95 fp=0x7ff7bfeffa30 sp=0x7ff7bfeffa10 pc=0x1029635
runtime.goenvs()
	/usr/local/go/src/runtime/os_darwin.go:108 +0x83 fp=0x7ff7bfeffa60 sp=0x7ff7bfeffa30 pc=0x1026ed3
runtime.schedinit()
	/usr/local/go/src/runtime/proc.go:492 +0xa1 fp=0x7ff7bfeffaa0 sp=0x7ff7bfeffa60 pc=0x102c011
runtime.rt0_go(0x7ff7bfeffad8, 0x1, 0x7ff7bfeffad8, 0x0, 0x1000000, 0x1, 0x7ff7bfeffc30, 0x0, 0x7ff7bfeffc73, 0x7ff7bfeffcac, ...)
	/usr/local/go/src/runtime/asm_amd64.s:175 +0x1eb fp=0x7ff7bfeffaa8 sp=0x7ff7bfeffaa0 pc=0x105375b

Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

[Process completed]

In my many minutes of Googling, it seems this could be related to an older version of Go having been used to compile the BunnyUpdater. Is this valid? I've also tried adding BUNNYPATH. 

 

What's interesting is I was able to successfully launch commands through an OMG Cable. I am new to the device and very well could be doing something incorrectly. Thanks for the support!

Posted

What version of MacOS are you using? You are starting the uppdater app from the flash storage of the Bunny, right? The example result above seems to have been executed from the Downloads location on the Mac (/Users/BadActor/Downloads/BunnyUpdater.app), which should not be the way to do it.

Posted
8 hours ago, dark_pyrro said:

What version of MacOS are you using? You are starting the uppdater app from the flash storage of the Bunny, right? The example result above seems to have been executed from the Downloads location on the Mac (/Users/BadActor/Downloads/BunnyUpdater.app), which should not be the way to do it.

I've tried the updater from both BashBunny and Downloads on the Mac. OS version is 12.2/Monterey. 

I've tried to restore to factory by unplugging after the green LED goes off 3 times as well and the files remain on the BashBunny. I deleted the updater, moved the zip folder to the BB, unzipped, and launched and still get the bsdthread_register error message. I then connected to the BB via Serial and ran udisk reformat, downloaded the updater and put it onto the device, extracted and executed the updater after approving the security warning, and get the same bsdthread_register error message. Is there a way to manually update the device? At this point with the Input/Output error and the bsdthread_register error I'm not able to execute payloads outside of LED lights. 

Posted

What files are you referring to when mentioning that files remain on the Bunny after a factory reset? If you mean those on the udisk/flash storage, they will be left untouched during a reset.

What version is your Mk2 on now? It might already be on the latest version. Check the version.txt file in /root

In any way, something's not correct with that updater judging by your experience. And, as you say, probably incompatible with that version of the OS. I'm no Mac guy and haven't had one for eons of time so I can't try to reproduce/recreate what you are experiencing.

Posted

The updater and previously set payloads. It seemed that it did not reset at all. 

Firmware version is 1.7. I was primarily hoping to use the updater to grab all of the payloads/tools, but then realized I have other issues when trying to interact with payloads on the device. 

I'm going to find a Windows VM and try it there. I had the same issue on my Kali box.

Posted

That is strange, on Kali it shouldn't be a problem. I'm very sure of that since I use Linux based distros all the time.
Are you using: BUNNYPATH=<path-to-Bunny-udisk> ./bunnyupdater

The Mk2 should only have two versions of firmware (both 1.7, just differing on the "release level"). The one that is available on the downloads "site" and the one that seems to come out of the box from factory. Some of the Mk2's have problems resetting firmware. It seems as if it resets, but the process is so quick that things aren't changed at all really. It is because of the fact that the factory reset file on the Bunny is missing for a specific/restricted batch of Bunnies.

Posted

Doing the firmware update now. Will download the Linux updater and attach the BB to my Kali box to attempt there again and report. For the BUNNYPATH, do I need to set that everytime or is there a place to set it in the updater itself (might be a dumb question)?

Thanks so much for your help! 

Posted
52 minutes ago, BadActor said:

Firmware version is 1.7. I was primarily hoping to use the updater to grab all of the payloads/tools, but then realized I have other issues when trying to interact with payloads on the device. 

Fimware is 1.7_332. 

Posted

Regarding the BUNNYPATH, yes, it needs to be specified every time as far as I know (if you don't set it in your OS environment variables/path). Also remember that you need to run the updater several times since it only does one thing at a time. So, if the firmware isn't up to date, it takes care of that only in the first "cycle". Then you need to run it ones again to update payloads.

Posted

Oh, and I lied about not having a Mac. I just remembered now that I actually have a Power Mac G4 somewhere in one of the storage rooms. It's been a while since that was high end stuff though.

Posted

Oldie and a goodie. So I'm sure this is something simple and I'm missing it, but either way this is frustrating as I can't make the bunnyupdater executable through R-Click Permissions or sudo chmod. 

Image of me failing miserably 👇

https://ibb.co/HXWMzkc

Posted

I think that the Linux one needs to be updated or I'm doing wrong?

Posted
8 hours ago, BadActor said:

can't make the bunnyupdater executable through R-Click Permissions or sudo chmod

Is it mounted with the noexec flag?

Run

mount -v

and check if there is a "noexec" for the line in the output that represents the mounted Bunny udisk/flash storage

It needs to be mounted without that flag in that case

Posted
9 hours ago, Jtyle6 said:

I think that the Linux one needs to be updated or I'm doing wrong?

I updated, there were several updates to be installed. Unfortunately that and a reboot did not fix the issue. 

 

8 hours ago, dark_pyrro said:

Is it mounted with the noexec flag?

Run

mount -v

and check if there is a "noexec" for the line in the output that represents the mounted Bunny udisk/flash storage

It needs to be mounted without that flag in that case

There wasn't anything saying the device was noexec. I tried messing with umount/mount and no luck being able to change the permission to make it executable. I also haven't used mount before so there could be some Layer 8 issue occurring. 

 

I did get a Win11 VM last night and it worked perfectly there. I at least feel better about the deviec not being borked 🙂

mount.png

noexec.png

Posted

OK, I have to admit I got a bit tricked by your OS change. Didn't pay attention there. For Windows and Mac, the bunnyupdater executable is supposed to be copied to the flash storage of the Bunny (the udisk). However, this is not the case when it comes to Linux based distros. In that case you should not copy the bunnyupdater to the Bunny flash storage but keep it on the storage device (hard drive or ssd) of the PC that the Bunny is attached to. Hence the need to use the BUNNYPATH. So, download the bunnyupdater zip to the local storage of the PC (for example /home/kali/Downloads ). Unpack it (well, you have already done all of this). Then let the bunnyupdater executable stay in the Downloads directory of the PC, do not copy it to the Bunny. Do the chmod +x as well. Then execute the command string. You might need to adjust it though since it seems as if your Bunny has been mounted to a somewhat alternative location (BashBunny1).

The "original" command string

BUNNYPATH=/media/kali/BashBunny ./bunnyupdater

should perhaps in your case be

BUNNYPATH=/media/kali/BashBunny1 ./bunnyupdater

Posted

I want to clarify because the pages on how to execute don't load the images anymore. I totally didn't take the time to read what was going on. So as usual, layer 8 issue. Thanks again! 

Posted

Yes, the image showing how it's done is gone (if that was what you were referring to) from the older docs site. Not sure why it's not on the newer help site. Or... there's no need for an image really. Writing it in plain text is good enough.

  • 4 months later...

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...