Update docs, misc shit in place to attempt overlays

diff --git a/doc/attribution.md b/doc/attribution.md
index 6079cee19dea7732f37700ccf9cfddb8412ff7e5..a75273f558c0767e3ce954b914242f71d7bf2a14 100644 (file)
--- a/doc/attribution.md
+++ b/doc/attribution.md
@@ -1,7 +1,8 @@
 While most everything in this repo is original, some parts are derived from existing software, and I make the best effort to document what is derivative in the interest of giving proper credits:
 
-src/firm      - Firmware decryptor originally from CakesFW (http://github.com/mid-kid/CakesForeveryWan)
-src/fatfs     - FatFS - http://elm-chan.org/fsw/ff/00index_e.html . This version originates from Decrypt9's repo.
-src/std       - Work was originally based on memfuncs.c and memory.c from Cakes and ReiNand, but contains near none of the original code now.
-src/patcher.c - Contains some bits from Luma3DS, but they've been adjusted for the cakes structures (src/firm) rather than crazy-ass pointer math.
-
+src/firm        - Firmware decryptor originally from CakesFW (http://github.com/mid-kid/CakesForeveryWan)
+src/fatfs       - FatFS - http://elm-chan.org/fsw/ff/00index_e.html . This version originates from Decrypt9's repo. The sdmmc code is from Normantt.
+src/std         - Work was originally based on memfuncs.c and memory.c from Cakes and ReiNand,
+                  but contains near none of the original code now. Not really fair to say it's derived from it, but it WAS before a near 100% rewrite.
+external/loader - Originally based on Luma3DS' injector, which is in turn based on Yifan Lu's injector. Injector now has a very long history. ;P
+vco/            - Most of the external patches are based on patcher code from Luma3DS. Obviously some changes were made.

diff --git a/doc/features.md b/doc/features.md
index 1871f97e2f7e3c5e36ee57d9e88ad63f6472b15a..512c336541af1cf9016b2890d20474dd26efdbab 100644 (file)
--- a/doc/features.md
+++ b/doc/features.md
@@ -10,7 +10,7 @@ Feature graph
 +--------+-----------------+-----------------+------------------------------+-----------+---------------+-------------------+-------+
 |ReiNAND |Meme(SD)         |Builtin, Dynamic |Sig,Emu,Sys,Mod,Ptc           |N/A        |Readability    |Minimalist         | [4]   |
 +--------+-----------------+-----------------+------------------------------+-----------+---------------+-------------------+-------+
-|Corbenik|Dec/Enc (SD)     |Builtin, Dynamic |Sig,Ptc,Sys,Svc               |N/A        |Read/Speed     |Advanced Devs      | [5]   |
+|Corbenik|Dec/Enc (SD)     |Builtin, Dynamic |Sig,Ptc,Sys,Mod,Bck,Mis       |N/A        |Read/Speed     |Advanced Devs      | [5]   |
 +--------+-----------------+-----------------+------------------------------+-----------+---------------+-------------------+-------+
 |NTR     |N/A              |Executable       |Mis                           |Mis        |Douchebaggery  |Shilling Closed Src| [6]   |
 +--------+-----------------+-----------------+------------------------------+-----------+---------------+-------------------+-------+
@@ -28,6 +28,7 @@ Feature graph
  * Mis: Other misc fixes and alterations including:
    * UNITINFO patch
    * GBA bios screen
+   * Region-free
 
 Misc features by CFW:
  * Cakes:
@@ -44,6 +45,11 @@ Misc features by CFW:
  * Corbenik
    * Arbitrary service injection to empty slots.
      Similar results can be achieved in cakes, but with much pain.
+     I've yet to find a use for this, but it's certainly neat.
+   * Arbitrary sysmodule injection.
+   * Loader replacement - loosely based on Luma3ds' with some significant
+     alterations.
+     * Again, shit will be moved someday soon to externals.
 
 [1] I'm not just referring to speed; I'm referring to purpose-based optimization. For example;
     do you want something well documented? Would you choose a slower algorithm that can be more
@@ -71,10 +77,18 @@ Misc features by CFW:
     format is incapable of accomodating some changes in a sane manner that doesn't require excessive RE or on console
     one off offset checks.
 
-[3] Luma is a weird beast - "Noob-proof" as github states very perfectly describes it for better or worse. Want to load
-    encrypted SD FIRM? Nope. Load SD firm with SysNAND? Nope. And many options aren't exposed to the user, period. Oh,
-    I suppose there's no legitimate reason to disable firmprot anyways, either. Detection of Emunand #2 tends to be
-    faulty. I have four.
+[3] Luma is a weird beast - "Noob-proof" as github states very perfectly describes it for better or worse. It can do
+    a lot, has a very good focus on what it wants to do and probably works good enough for 90% of users. It handles
+    the vast majority of use cases well and sanely.
+
+    Some internal bits aren't exposed as configurable because turning them off is bad for the inexperienced. This is both
+    good and bad. On the upside, less brick complaints. On the downside, it loses some power for hacker-ish people who
+    know what they're doing and have odd requirements.
+
+    As I've been told by @TuxSH - "Noob-proof" != Just for noobs. I find that "Noob-proof" as a goal tends to somewhat
+    limit the people who truly understand what they're doing, however, in any software - not just Luma.
+
+    My only real complaint about Luma is the sheer amount of pointer math instead of reading headers correctly.
 
 [4] Reisyukaku has fallen behind a bit; his firmware is still in use and rather slim. He does, however, do some fancy
     ass magic to load a re-encrypted copy (?) of the nintendo firmware using a key refered to as the 'memekey'. How
@@ -86,15 +100,18 @@ Misc features by CFW:
     explain some of the rationale here:
 
     NTR is a secondary CFW; it's designed to be used with a primary one. It consists of a proprietary blob, ntr.bin
-    which loads into memory and takes over the debug service and subsequently the arm11 kernel.
+    which loads into memory with some offset patches done by BootNTR - then takes over the debug service and
+    subsequently the arm11 kernel and threading to keep itself resident[7].
 
     Normally, the functionality would be useful, but when you consider he's using techniques he hasn't bothered to doc
-    on 3dbrew, you should by now know his goal is lock-in. From BootNTR it's apparent he's a shitty coder[7]. He
+    on 3dbrew, you should by now know his goal is lock-in. From BootNTR it's apparent he's a shitty coder[8]. He
     won't document it, because someone else will create a better optimized version. Hm...that sounds a lot like a
     certain Japanese company who developed a cons- oh wait.
 
     The point is; NTR is not your friend. Stop using it.
 
-[7] Tell me that giant switch statement couldn't be implemented as a dynamic patcher on the 3DS itself, considering
-    all of the python offset extractor could be rewritten in C. Dare you. He also can't be bothered to port to 10.4
+[7] At least from what I can tell. See https://github.com/patois/NTRDisasm. This is an out of date version, as well.
+
+[8] Tell me that giant switch statement couldn't be implemented as a dynamic patcher on the 3DS itself, considering
+    all of the python offset extractor code could be rewritten in C. Dare you. He also can't be bothered to port to 10.4
     NATIVE_FIRM even though there's literally no difference that should break NTR.

diff --git a/doc/nonos.md b/doc/nonos.md
index 4b0ec254abb3e0f24f2c1581146e47bbb84ab457..524e584eb7de973f55c24156b6fbdde923049e2a 100644 (file)
--- a/doc/nonos.md
+++ b/doc/nonos.md
@@ -3,23 +3,21 @@ Things I won't implement
 
  * Memekey Support.
 
-This is a ReiNAND only thing; get over it.
+This is a ReiNAND only thing; get over it. Use ReiNAND if you want memekey, or use memekey instead of the normal firmkey.
 
  * Loading firmware from sysnand.
 
-IMHO, this is a bad idea for many reasons. It sounds great in theory; it isn't in any way a good idea.
+IMHO, this is a bad idea for many reasons. It sounds great in theory; there's problems that hamper it from being truly a good idea.
 
-This is for people who know what they're doing first and foremost, so if getting a firmware is too hard, you're not the intended audience. Please use another CFW like Luma3DS.
-
-I don't see this as a feature unless it's opt-in rather than opt-out or mandatory. If you're concerned about SD clutter; it's one folder, and everything IN THAT FOLDER IS IN FOLDERS. This is practically windows levels of organization, I don't think I can get more tidy.
+I don't see this as a feature unless it's opt-in rather than opt-out or mandatory. If you're concerned about SD clutter; it's one folder, and everything IN THAT FOLDER IS IN FOLDERS. This is practically unix levels of organization, I don't think I can get more tidy.
 
  * Gateway launcher dat
 
-Screw off. Need I explain why? Do it yourself. It's never getting merged to master; it's against the very goal of CFW - to eliminate the need for flashcarts.
+Screw off. Need I explain why? Do it yourself. No support will be offered to gateway users. You're paying for a piracy tool. Seriously, why?
 
  * 3dsx
 
-Get a9lh. Seriously. You might be able to use Brahma, but hell if I know. a9lh is the only supported method of running this.
+Get a9lh. Seriously. You might be able to use Brahma, but hell if I know. a9lh is the only supported method of running this, and no 3dsx launcher will be provided.
 
 Not bugs
 =========
@@ -28,5 +26,5 @@ Not bugs
 
 No, I can't fix this on a9lh. Here's how to do it; boot another CFW, go into system settings, then boot corbenik. You'll get the keys you need. This works with Cakes as well. After this, you'll never need a key again.
 
-Another thing to know is only NATIVE_FIRM is required to boot, so you can boot Corbenik without AGB and TWL suceeding, reboot from settings and they'll decrypt.
+Another thing to know is only NATIVE_FIRM is required to boot, so you can boot Corbenik without AGB and TWL suceeding, reboot from settings and they'll decrypt if the CETK is there.
 

diff --git a/external/loader/source/patcher.c b/external/loader/source/patcher.c
index e8db47c6b90b61337699eba805d65322f8f92691..efe681b91dd87685fae3974d508dc9f98fae2c23 100644 (file)
--- a/external/loader/source/patcher.c
+++ b/external/loader/source/patcher.c
@@ -506,6 +506,10 @@ void language_emu(u64 progId, u8 *code, u32 size) {
        }
 }
 
+void overlay_patch(u64 progId, u8 *code, u32 size) {
+       // TODO - Prt
+}
+
 void patchCode(u64 progId, u8 *code, u32 size) {
        load_config();
 
@@ -562,6 +566,12 @@ void patchCode(u64 progId, u8 *code, u32 size) {
                        ro_sigpatch(progId, code, size);
                        break;
                }
+               case 0x00040000000B8B00LL: // Smash 4
+        case 0x00040000000EE000LL:
+        case 0x00040000000EDF00LL:
+               {
+                       saltysd_patch(progId, code, size);
+               }
         default:
                {
                        language_emu(progId, code, size);

diff --git a/source/menu.c b/source/menu.c
index f89374383a8ba8e37fd6de3ea715c421188a6de8..21efc0d7c47a951a3ac211248ccf7c882e67c381 100644 (file)
--- a/source/menu.c
+++ b/source/menu.c
@@ -33,6 +33,7 @@ static struct options_s options[] = {
 
        { 14, "No dependency tracking", boolean_val, 0, 0 },
        { 15, "Allow unsafe options", boolean_val, 0, 0 },
+
        { -1, "", 0, 0, 0},
 };