More actions
No edit summary |
No edit summary |
||
| Line 17: | Line 17: | ||
==How it works== | ==How it works== | ||
Bluebomb exploits a bug in the Bluetooth system that sets a lower bound to the Bluetooth channels that can be used, but no upper bound. On the computer, BlueBomb connects to the Wii, then uploads the stage 0 code in the attribute response, and it uploads some data in the format of a Bluetooth channel configuration in the service response. The channel configuration is normally part of a doubly linked list, but in this fake configuration the next pointer points to the beginning of the stage 0 code, while the previous pointer points near the function that handles packets being received. The computer then takes the out-of-bounds channel id of the fake configuration that was uploaded, and tells the Wii that that id is invalid, which makes the Wii "remove" it from the linked list it thinks it is in. This means changing the previous pointer of what appears to be next to be the next on the fake configuration, and the next pointer of what appears to be the previous to be the next of the fake configuration. Changing the "next" pointer of the previous changes part of the code in the packet receiving function to instead jump to the stage 0 code. Meanwhile, the previous of the next changes a byte in the stage 0 code that is intentionally jumped over to avoid corruption in that code. | Bluebomb exploits a bug in the Bluetooth system that sets a lower bound to the Bluetooth channels that can be used, but no upper bound. On the computer, BlueBomb connects to the Wii, then uploads the stage 0 code in the attribute response, and it uploads some data in the format of a Bluetooth channel configuration in the service response. The channel configuration is normally part of a doubly linked list, but in this fake configuration the next pointer points to the beginning of the stage 0 code, while the previous pointer points near the function that handles packets being received. | ||
The computer then takes the out-of-bounds channel id of the fake configuration that was uploaded, and tells the Wii that that id is invalid, which makes the Wii "remove" it from the linked list it thinks it is in. This means changing the previous pointer of what appears to be next to be the next on the fake configuration, and the next pointer of what appears to be the previous to be the next of the fake configuration. Changing the "next" pointer of the previous changes part of the code in the packet receiving function to instead jump to the stage 0 code. Meanwhile, the previous of the next changes a byte in the stage 0 code that is intentionally jumped over to avoid corruption in that code. | |||
Once the stage 0 code launches, it starts by making sure the packet handler function returns normally after the first part of stage 0 is finished. It then jumps over the byte that gets replaced by the exploit because of the changing of the linked list, and copies itself to an unused portion of memory where other Bluetooth connections won't interfere. After this, it changes the value changed earlier to instead point to a location in the copy of stage 0. The computer now uploads the stage 1 code in chunks, which gets stored in some more unused memory, and when the downloading finishes, it launches stage 1. This is done because the attribute response is limited in space, and there is not enough space for stage 1 to happen in 1000 bytes. | Once the stage 0 code launches, it starts by making sure the packet handler function returns normally after the first part of stage 0 is finished. It then jumps over the byte that gets replaced by the exploit because of the changing of the linked list, and copies itself to an unused portion of memory where other Bluetooth connections won't interfere. After this, it changes the value changed earlier to instead point to a location in the copy of stage 0. The computer now uploads the stage 1 code in chunks, which gets stored in some more unused memory, and when the downloading finishes, it launches stage 1. This is done because the attribute response is limited in space, and there is not enough space for stage 1 to happen in 1000 bytes. | ||
Latest revision as of 02:53, 26 March 2023
| BlueBomb | |
|---|---|
 | |
| General | |
| Author | Fullmetal5 |
| Type | Exploits |
| Version | 1.5 |
| License | GPL-3.0 |
| Last Updated | 2020/02/29 |
| Links | |
| Download | |
| Website | |
| Source | |
BlueBomb is a known exploit that targets Broadcom's Bluetooth stack, which is utilized in the Nintendo Wii gaming console. It takes advantage of the Wii's Bluetooth and injects unsigned code into the system via Bluetooth.
You will need a Linux computer to do this. A detailed guide is available on WiiBrew.
How it works
Bluebomb exploits a bug in the Bluetooth system that sets a lower bound to the Bluetooth channels that can be used, but no upper bound. On the computer, BlueBomb connects to the Wii, then uploads the stage 0 code in the attribute response, and it uploads some data in the format of a Bluetooth channel configuration in the service response. The channel configuration is normally part of a doubly linked list, but in this fake configuration the next pointer points to the beginning of the stage 0 code, while the previous pointer points near the function that handles packets being received.
The computer then takes the out-of-bounds channel id of the fake configuration that was uploaded, and tells the Wii that that id is invalid, which makes the Wii "remove" it from the linked list it thinks it is in. This means changing the previous pointer of what appears to be next to be the next on the fake configuration, and the next pointer of what appears to be the previous to be the next of the fake configuration. Changing the "next" pointer of the previous changes part of the code in the packet receiving function to instead jump to the stage 0 code. Meanwhile, the previous of the next changes a byte in the stage 0 code that is intentionally jumped over to avoid corruption in that code.
Once the stage 0 code launches, it starts by making sure the packet handler function returns normally after the first part of stage 0 is finished. It then jumps over the byte that gets replaced by the exploit because of the changing of the linked list, and copies itself to an unused portion of memory where other Bluetooth connections won't interfere. After this, it changes the value changed earlier to instead point to a location in the copy of stage 0. The computer now uploads the stage 1 code in chunks, which gets stored in some more unused memory, and when the downloading finishes, it launches stage 1. This is done because the attribute response is limited in space, and there is not enough space for stage 1 to happen in 1000 bytes.
Finally, stage 1 opens the USB and reads the file system for a boot.elf or boot.dol file, usually the HackMii Installer, which is loaded into memory and run.
Media
How to Homebrew the Wii Mini! (BlueBomb Tutorial) (Michael MJD)
Known issues
Changelog
v1.5
- Remove BlueZ dependency and refactor.
v1.0
- Initial Release.
External Links
- WiiBrew - https://wiibrew.org/wiki/Bluebomb
- GitHub - https://github.com/Fullmetal5/bluebomb