Project:Help wanted

Many secrets still remain to be uncovered. If you have experience with reverse engineering or if you are looking for a fun project to start with RE (or both!), please help us investigate the following mysteries.

Formats

The following tasks require reversing file formats. It is strongly recommended to also examine the executable to gain more reliable knowledge about formats and figure out how they are used by Nintendo exactly.

XLink database

To make the development process more efficient, Nintendo introduced a system called SoundLink (aka SLink) (and its counterpart for effects: EffectLink) during development. Both systems were at some point unified and are now handled by a single xlink2 library which handles both the SLink and ELink systems.

Two files are used to map effect/sound names to the actual resources. In Breath of the Wild, they are called ELink2DB.belnk and SLink2DB.bslnk.

The format has not seen a lot of research as of September 2018, despite the executable being full of debug strings that include field names and the fact that other recent Nintendo games such as Splatoon 2 ship the library with debugging symbols.

Event timelines

bfevtm files (binary event timelines) are extremely similar to bfevfl files (binary event flowcharts), but have a few significant differences that make them incompatible with the evfl library as of September 2018.

Because timelines are exclusively used by the event manager — unlike flowcharts which are also used by smaller subsystems like TipsMgr — for demos, it has proven difficult to find the code that reads timelines.

If you are willing to take up this task, please ping leoetlino for the Switch 1.5.0 IDC.

Havok packfiles and structures

Nintendo uses Havok binary packfiles for all Havok resources. Thus, it is difficult to manipulate physics files.

leoetlino discovered that fortunately the Havok library relies on reflection data to load resources. This makes it possible to parse the binaries and reconstruct a human readable representation with every single field name and even enum definitions. Reflection information has been dumped for the Switch version.

The following tasks remain to be done:

• Dump reflection data for the Wii U version. Data offsets are different since the Switch uses a different compiler, is a 64 bit little-endian platform unlike the Wii U (32-bit big endian machine).
• Write a library to manipulate binary packfiles: getting, modifying, adding and removing Havok objects from a packfile (and perhaps converting them to XML too?)
• Figure out how the compression for hkpBvCompressedMeshShapes works. Nintendo uses compressed mesh shapes for all static compound collision files.

Game logic

The following tasks require reversing the executable to have reliable information on how the mechanics work.

amiibo drops

• How scaling (weapon upgrades) works for amiibo weapons.

  amiibo weapons don't entirely follow the regular weapon scaling and bonus rules.

• What determines the drop table list that gets used?

  amiibo DropTables generally contain 8 tables: Normal, SmallHit, BigHit({Normal,Parasail,Remain}), and GreatHit({Normal,Parasail,Remain}). Parasail tables are presumably selected after the player receives the paraglider, and Remain after Link completes a divine beast; however this is pretty much only speculation. It is also currently unknown what determines which xxxxxHit table gets used.

One-Hit kill protection

It is well known that Link cannot die in one-hit under specific cases. What are the exact conditions for this protection to apply? Interestingly, it appears this mechanic is gone in Master Mode.

NoDeathDamageBase (in Link's bgparamlist) might be related.

Executable analysis

Everything you see in Breath of the Wild is implemented in the executable. Some aspects can be modified by editing assets; other things are hardcoded, meaning it's impossible to change how the game works by merely editing content files.

Analysing the executable is the only way to understand how things are implemented internally and how the game actually works. Eventually, after enough information has been collected, it becomes possible to directly edit the game core. With a more complete understanding, more in-depth modifications can be done by hooking into functions and injecting custom code.

This is similar to the process of creating cheat codes, but different in that this relies on static analysis more and requires understanding how all the different subsystems interact.

Because of the sheer size of the executable, it is infeasible for this long-term project to be completed by a single person. If you are willing to help, please ping leoetlino for the Switch 1.5.0 IDC.  

Debug leftovers

The following tasks require reversing the executable and possibly patching it to re-enable functionality.

Demo mode

Setting the ROM type to demo ROM types (found in the executable) make the game crash. What is locked behind them?

Stage select screen

The release version has a stage select screen left (see Executable for more details). It should be possible to get it to work.

Actor debug utilities

In a similar fashion, Nintendo has also left an entire ActorDebug subsystem in all release versions, which can print information to the screen and interact with many different actor system components and things like map units.