A from-scratch handwritten HBC application
#1
This is my first HBC application I have made.

https://github.com/VegaASM/V-Elf-Disc-Drive-Lighter

I decided to learn a little bit about Elf files and their structure. This HBC app is made 100% via ASM, every byte of the file is accounted for. This wasn't tough to do per say, but I have never seen anyone make an HBC app in this fashion. Nothing is required other than the ability to compile the source to Raw byte code and using a Hex Editor to make the binary (.elf) file. You don't need devkit, libraries, linkers, c files, etc.

All this app does is light the disc drive up... forever. Til you turn off the Wii by holding the power button down. 

FAQ:
Why is there a gigantic padding of zero's?

HBC (in it's source code) has specific rules + checks on the virtual address entry point. The Wii likes to have this at 0x80004000, so that's the entry point I'm using. HBC allows you to use an address as low as 0x80003400.

Why is the Program Header's physical address value in it's virtual address form?

After viewing many other devkitPPC compiled elf files from other HBC apps, they all do that too. It doesn't matter as HBC does a logical OR with the value of 0x80000000 against the p_paddr value anyway.

Is there anyway to bypass the entry point rules?
I've tried for a bit, but I was unsuccessful. If I was able to bypass the entry point check, the elf file would only be 100 bytes in size.

---

Other notes:
It appears HBC doesn't do any checks for the p_vaddr value, but it's there because other devkitPPC compiled elf files all have it.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)