WIP {2168-0002} libdedbae & dbcli: C library and CLI tool for manipulating Nintendo Switch file formats

Discussion in 'Switch - Emulation, Homebrew & Software Projects' started by roothorick, Oct 3, 2018.

  1. roothorick
    OP

    roothorick Advanced Member

    Newcomer
    4
    Jan 30, 2008
    United States
    Find the repository here: https://gitlab.com/roothorick/dedbae

    Sort of the same release as the XCI to NSP converter, but this is more the developer-focused portion so I thought it deserved a separate thread.

    libdedbae is a minimal C library for hands-on manipulation of Switch files. It includes structs for CNMT (incomplete; it doesn't handle the extradata added by patches), HFS0, NCA, PFS0, RomFS, and XCI. It can also parse HFS0, PFS0, and RomFS and generate a list of file names and offsets for easy extraction. There's also a host of NCA-related functions, including correctly injecting/appending PFS0 and RomFS volumes to an NCA. All crypto and hashes are handled by the library, so all you need to worry about is what you want to make or change.

    dbcli is an experimental tool based on libdedbae with a random smattering of commands for manipulating Switch files. While hactool is focused on inspection, dbcli is focused on manipulation. Peek vs. poke, if you will, although dbcli also has some read commands that were written primarily as manual tests for libdedbae and/or because I couldn't find needed functionality in hactool. There isn't really anything for end users here; it is primarily intended for manually changing/assembling files as part of research and testing.

    Let me know if there's any additional features or field customizations you'd like. This is very easy to expand on.

    Usage:

    dbcli-usage.

    Caveats:

    • The git repo has submodules. Make sure you specify --recursive when cloning.
    • Testing on MinGW has been limited outside of facilities needed by xci2nsp. Expect bugs. If something acts odd, try it in Linux.
    • The library assumes little endian. Handling BE systems would greatly complicate the code and I really wanted to keep things simple. I'm not sure why you'd care about BE anyway, as x86 is LE and most ARM systems (including the Switch) are also LE.
    • GCC extensions are in use. Clang specifically is known to choke on a few things, and MSVC is a lost cause. Since GCC is FOSS and supports everything but the kitchen sink as build targets, I don't really see the need for supporting other compilers.
     

    Attached Files:

Loading...