Hacking install permanent homebrew launcher without nds game ?

[Pikachuk]

hi, i'd like to install the permanent homebrew launcher but i haven't any nds game, i've gba games and n64 games, i wonder if one of them or WUPinstaller would allow me to install the homebrew launcher
i haven't money atm to allow me to buy a nds game that's why i can't just buy a nds game like this

 

[nooby89]

You can't on the SysNAND right now without NDS game

 

[cheuble]

ATM, haxchi is the only permanent entrypoint we have. Either wait for a new exploit (and this may happen using contenthax) or get some money to buy the game (10€ isn't that much)
EDIT: 500th post

 

[C0mm4nd_]

contenthax is confirmed to work with N64 but it isn't exploited

 

[sj33]

The Homebrew Launcher Channel needs to executed after the exploit itself. You cannot use it as your main entrypoint.

 

[KevinX8]

contenthax is confirmed to work with N64 but it isn't exploited

Contenthax is system wide it applies to every title your thinking of haxchi, Smealum did find a vulnerability in n64 vc titles but since its not necessary ATM none has used it. Also Contenthax is just the fact we can modify any content or meta folder to an extent on any title without tripping sig checks since only select files are checked

Sent from my LG-D855 using Tapatalk

 

[C0mm4nd_]

Contenthax is system wide it applies to every title your thinking of haxchi, Smealum did find a vulnerability in n64 vc titles but since its not necessary ATM none has used it. Also Contenthax is just the fact we can modify any content or meta folder to an extent on any title without tripping sig checks since only select files are checked

Sent from my LG-D855 using Tapatalk

Spoiler

contenthax

Present in system versions: All

Publicly exploited: Yes

Discovered by: yellows8, smea (Early 2016); WulfyStylez (Early 2016)

The Wii U's data management system does not include provisions to validate the integrity of most title contents after installation. Any title contents using hash tables for verification (content type 0x0002 in tmd, using *.h3 files) are vulnerable. Generally, all contents are vulnerable apart from those in /code.

As such, any game or app's contents may be altered by attackers. In particular, attackers with IOSU code execution may use FSA commands to alter the content files in USB or MLC filesystems. Alternatively, an attacker with control over certain PPC usermode processes (such as home menu or system settings) may use commands such as MCP:CopyTitle to copy title contents over from SD to MLC or USB.

haxchi
Present in system versions: N/A

Publicly exploited: Yes

Discovered by: smea (Early 2016)

The Wii U Nintendo DS virtual console emulator is vulnerable to contenthax attacks. In particular, the rom parsing code lets an attacker perform fully controled arbitrary write operations, which very easily leads to ROP and code execution, because these titles are among the few that have JIT capabilities.

contenthax

Present in system versions: All

Publicly exploited: Yes

Discovered by: yellows8, smea (Early 2016); WulfyStylez (Early 2016)

The Wii U's data management system does not include provisions to validate the integrity of most title contents after installation. Any title contents using hash tables for verification (content type 0x0002 in tmd, using *.h3 files) are vulnerable. Generally, all contents are vulnerable apart from those in /code.

As such, any game or app's contents may be altered by attackers. In particular, attackers with IOSU code execution may use FSA commands to alter the content files in USB or MLC filesystems. Alternatively, an attacker with control over certain PPC usermode processes (such as home menu or system settings) may use commands such as MCP:CopyTitle to copy title contents over from SD to MLC or USB.

N64 VC contenthax
Present in system versions: N/A

Publicly exploited: No

Discovered by: yellows8 (Early 2016)

The Wii U N64 VC emulator title("VESSEL") has two known vulns which can be attacked via contenthax. These vulns were tested on hardware, but actual exploitation wasn't tested.

Note that this title can only write to codegen(JIT) via using OSCodegenCopy(), unlike other titles.

Currently this is the only known VC platform(N64) which is affected by any of these VESSEL vulns(not all platforms were checked for this).

The .ini loading occurs much earlier during title boot than the font loading. These vulns(or at least the .ini one) trigger while the system is still displaying the application spash-screen(from the title's meta/ directory).

• Stack buffer overflow when handling BMFont "pages". The entire block is copied to stack using just the size, without checking the size. The loaded data is not checked either, other than converting uppercase to lowercase('A'..'Z' to 'a'..'z'). This string is used with sprintf + PNG texture loading afterwards.
• Heap buffer overflow during .ini parsing with field-data string starting with '"'. The allocated heap buffer is 0x100-bytes, but the size is not checked when copying the value string into this buffer. During copying/etc this string content is not checked/modified, besides checking for the end of the string with '"'. For example: HAX = "LONGSTRINGHERE"

It's like Contenthax-> NDS contenthax (haxchi)
Contenthax-> N64 contenthax (vesselhax?)

 

[KevinX8]

Spoiler

contenthax

Present in system versions: All

Publicly exploited: Yes

Discovered by: yellows8, smea (Early 2016); WulfyStylez (Early 2016)

The Wii U's data management system does not include provisions to validate the integrity of most title contents after installation. Any title contents using hash tables for verification (content type 0x0002 in tmd, using *.h3 files) are vulnerable. Generally, all contents are vulnerable apart from those in /code.

As such, any game or app's contents may be altered by attackers. In particular, attackers with IOSU code execution may use FSA commands to alter the content files in USB or MLC filesystems. Alternatively, an attacker with control over certain PPC usermode processes (such as home menu or system settings) may use commands such as MCP:CopyTitle to copy title contents over from SD to MLC or USB.

haxchi
Present in system versions: N/A

Publicly exploited: Yes

Discovered by: smea (Early 2016)

The Wii U Nintendo DS virtual console emulator is vulnerable to contenthax attacks. In particular, the rom parsing code lets an attacker perform fully controled arbitrary write operations, which very easily leads to ROP and code execution, because these titles are among the few that have JIT capabilities.

contenthax

Present in system versions: All

Publicly exploited: Yes

Discovered by: yellows8, smea (Early 2016); WulfyStylez (Early 2016)

The Wii U's data management system does not include provisions to validate the integrity of most title contents after installation. Any title contents using hash tables for verification (content type 0x0002 in tmd, using *.h3 files) are vulnerable. Generally, all contents are vulnerable apart from those in /code.

As such, any game or app's contents may be altered by attackers. In particular, attackers with IOSU code execution may use FSA commands to alter the content files in USB or MLC filesystems. Alternatively, an attacker with control over certain PPC usermode processes (such as home menu or system settings) may use commands such as MCP:CopyTitle to copy title contents over from SD to MLC or USB.

N64 VC contenthax
Present in system versions: N/A

Publicly exploited: No

Discovered by: yellows8 (Early 2016)

The Wii U N64 VC emulator title("VESSEL") has two known vulns which can be attacked via contenthax. These vulns were tested on hardware, but actual exploitation wasn't tested.

Note that this title can only write to codegen(JIT) via using OSCodegenCopy(), unlike other titles.

Currently this is the only known VC platform(N64) which is affected by any of these VESSEL vulns(not all platforms were checked for this).

The .ini loading occurs much earlier during title boot than the font loading. These vulns(or at least the .ini one) trigger while the system is still displaying the application spash-screen(from the title's meta/ directory).

• Stack buffer overflow when handling BMFont "pages". The entire block is copied to stack using just the size, without checking the size. The loaded data is not checked either, other than converting uppercase to lowercase('A'..'Z' to 'a'..'z'). This string is used with sprintf + PNG texture loading afterwards.
• Heap buffer overflow during .ini parsing with field-data string starting with '"'. The allocated heap buffer is 0x100-bytes, but the size is not checked when copying the value string into this buffer. During copying/etc this string content is not checked/modified, besides checking for the end of the string with '"'. For example: HAX = "LONGSTRINGHERE"

It's like Contenthax-> NDS contenthax (haxchi)
Contenthax-> N64 contenthax (vesselhax?)

Thats literally what I said, N64 VC contenthax is just a poor name for the vuln, should be something like veshax since the ds VC emu is hachihachi and the n64 one is vessel. Contenthax is just the vuln that allows us to use the vuln in the n64 emu , contenthax can be used on any title heck someone could make NSMBUhax if they wanted its not even restricted to vc titles