Toggle sidebar

open-dbi - Nintendo Switch Homebrew

  • Thread starter Thread starter mrbeige
  • Start date Start date
  • Views Views 281
  • Replies Replies 6
  • Likes Likes 3
Frankly put, lol.
I'm sure ducky will have fun checking out this AI slop code.
Anyway, just learn to recognize some Russian words visually and you'll be fine using normal DBI.
 
  • Like
Reactions: XenoFredo
Hey, first of all: thanks for sharing this.

I just cloned and built the current repo on Windows with devkitPro. I had to install switch-libzstd, but after that the project built cleanly and produced open-dbi.nro without issues. The NRO also loads fine in Eden, so the basic build/homebrew side seems to be working.

I understand this is still very experimental and more of a clean-room reconstruction / test harness than a full DBI replacement at this stage, but it is still really interesting work. The modular layout is pretty easy to follow, especially the separate DBI0, PFS0, installer, NCA/NCZ and NCM backend parts.

Before I test this on real hardware, I wanted to ask which parts you have personally confirmed on an actual Switch so far:

  • read-only USB transfer
  • NCA/CNMT decrypt test
  • NSP install from SD
  • USB install through dbibackend
  • NCZ/NSZ reconstruction
  • tickets / rights-ID content
  • cleanup behavior if an install fails halfway
I noticed a few parts are marked as unverified or still look like they need more real-world validation, especially around NCA/CNMT extraction, ticket handling and the real NCM/ES/NS install path. That is not meant as criticism, just trying to understand what is known-good before I start testing on hardware.

Also, if you really burned through your last AI tokens putting this together: respect, because even getting a buildable Switch NRO with this much structure is already a decent amount of work. I might try to do some testing and small fixes locally as well, especially around bounds checks, install failure cleanup and safer validation before touching real storage.

Thanks again for releasing it. Looking forward to seeing how far this can go.
 
Last edited by Evilengine,
Ethelbert said:
Frankly put, lol.
I'm sure ducky will have fun checking out this AI slop code.
Anyway, just learn to recognize some Russian words visually and you'll be fine using normal DBI.
Click to expand...
I prefer my slop open source

Evilengine said:
Hey, first of all: thanks for sharing this.

I just cloned and built the current repo on Windows with devkitPro. I had to install switch-libzstd, but after that the project built cleanly and produced open-dbi.nro without issues. The NRO also loads fine in Eden, so the basic build/homebrew side seems to be working.

I understand this is still very experimental and more of a clean-room reconstruction / test harness than a full DBI replacement at this stage, but it is still really interesting work. The modular layout is pretty easy to follow, especially the separate DBI0, PFS0, installer, NCA/NCZ and NCM backend parts.

Before I test this on real hardware, I wanted to ask which parts you have personally confirmed on an actual Switch so far:

  • read-only USB transfer
  • NCA/CNMT decrypt test
  • NSP install from SD
  • USB install through dbibackend
  • NCZ/NSZ reconstruction
  • tickets / rights-ID content
  • cleanup behavior if an install fails halfway
I noticed a few parts are marked as unverified or still look like they need more real-world validation, especially around NCA/CNMT extraction, ticket handling and the real NCM/ES/NS install path. That is not meant as criticism, just trying to understand what is known-good before I start testing on hardware.

Also, if you really burned through your last AI tokens putting this together: respect, because even getting a buildable Switch NRO with this much structure is already a decent amount of work. I might try to do some testing and small fixes locally as well, especially around bounds checks, install failure cleanup and safer validation before touching real storage.

Thanks again for releasing it. Looking forward to seeing how far this can go.
Click to expand...
I tested this on my switch so far :
  • read-only USB transfer
  • NCA/CNMT decrypt test
  • NSP install from SD
  • USB install through dbibackend
I'm actually burning my work's leftover weekly token during the weekend. :evil: I really just feel like dbi should be open source.

lordelan said:
Why didn't you put out a release tag with the compiled NRO though? :)
Click to expand...
Cause I'm dumb. Will try to do it tonight :grog:
 
  • Like
Reactions: Evilengine
mrbeige said:
I prefer my slop open source


I tested this on my switch so far :
  • read-only USB transfer
  • NCA/CNMT decrypt test
  • NSP install from SD
  • USB install through dbibackend
I'm actually burning my work's leftover weekly token during the weekend. :evil: I really just feel like dbi should be open source.


Cause I'm dumb. Will try to do it tonight :grog:
Click to expand...

I am sure you are aware of most of this.
Since you posted your results, I hope this answer may help to work on this.

That is honestly a pretty good start already, especially if you have personally tested:

  • read-only USB transfer
  • NCA/CNMT decrypt test
  • NSP install from SD
  • USB install through dbibackend
If those four paths are already working on real hardware, then I think the next big accelerator would not be adding more features immediately, but making the project extremely easy to test and debug for other people.

My suggestion would be to define one clear short-term goal:

“Make the install core boringly reliable.”

By that I mean:

  1. Add structured SD logging
    Something like sdmc:/switch/open-dbi/logs/open-dbi_latest.log, with every phase logged:
    • build commit/version
    • selected operation
    • NSP/NSZ/XCI type detection
    • PFS0 entries
    • CNMT extraction result
    • keygen / rights-id present yes/no
    • ticket/cert present yes/no
    • every libnx Result code as hex
    • install phase: open storage, create placeholder, write, register, import ticket, set meta, commit
    • exact failure phase
    • No keys, no private data, no ticket dumps, just enough diagnostics for testers.
  2. Add a dry-run install mode
    Before writing anything to NCM, let the app parse the file, extract CNMT, detect contents, tickets, keygen, rights-id, NCZ/NSZ sections, and print/log the planned install. This would let people test many files safely without risking a broken partial install.
  3. Create a small public test matrix
    For example:
    • small NSP base game
    • update NSP
    • DLC NSP
    • rights-id content
    • no-rights-id content
    • NSZ/NCZ
    • large file
    • USB install
    • intentionally broken NSP
    • missing prod.keys
    • missing ticket/cert
    • Then testers can report in a uniform way instead of just saying “works” or “doesn’t work”.
  4. Add report bundle generation
    A menu option like “Create debug report” could write:
    • latest log
    • build version
    • operation result
    • detected file structure
    • redacted error summary
    • Then people can upload that report without accidentally leaking keys or personal data.
  5. Keep feature work behind milestones
    Maybe:
    • Milestone 1: reliable NSP install from SD
    • Milestone 2: reliable USB install
    • Milestone 3: NSZ/NCZ correctness
    • Milestone 4: cleanup/rollback on failed installs
    • Milestone 5: UI/quality-of-life
    • Milestone 6: XCI/XCZ or other formats
I think this would help the project grow much faster, because people could actually help you validate the hard parts instead of everyone testing random things in random ways.

Also, since this is AI-assisted work, a very practical trick might be to make the codebase “AI-review friendly”: small modules, clear phase names, test logs, and one issue per failure mode. That way you or others can feed a log + exact source file into an AI and get much better fixes than by asking it to reason about the whole project at once.

Really appreciate you opening this. DBI being closed source has always made it harder for people to learn from or improve the ecosystem, so even an experimental clean-room implementation is valuable.
 
  • Like
Reactions: mrbeige

Site & Scene News

Go to forum More news

Popular threads in this forum

Dusk for switch (TLoZ Twilight Princess port)

Homebrew  Full List of N64 Recompilation Switch ports

Homebrew  New Homebrew "Foil Server"?

Hacking  WiFi chip failing and can't boot. is it possible to enable Airplane Mode by editing system save files directly?

Homebrew Tutorial Translation Project  CS2SX — Write Nintendo Switch Homebrew in C#

Homebrew  Sonic Unleashed Recompiled (Homebrew Port)

Homebrew Homebrew game Project  So... Dan didn't want to reveal his Vulkan, so I made mine.

Is it fixable