+++ /dev/null
-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). Rather hacked up.
-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
-patch/ - Most of the external patches were based on the C code in Luma3DS. Obviously, they share no actual code.
-src/i2c.* - I2C handling code from delebile's arm9loaderhax repo. I cleaned it up somewhat.
-src/start.s - Another inherited piece of code. I obtained this from Decrypt9's repo, but this is in use elsewhere.
+++ /dev/null
-Bytecode format
-===================
-
-Instructions are one byte and have a variable number of bytes afterwards.
-
-Note that this file describes the instruction set AS THE VM INTERPRETS IT,
-e.g. not as you'd write it for the assembler.
-
-Any integers of greater than one byte are not re-ordered to fit endianness.
-If you specify 0001 as a value, the vm will read this as:
-
- uint16_t val = *((uint16_t*){0x00, 0x01})
-
-Be aware of this.
-
-Unless otherwise noted, if an instruction doesn't succeed, it will abort.
-
-nop : 1 byte : Opcode 0x00
- Does nothing. Not actually treated as an instruction,
- rather just skipped over. This is mainly just for compatibility.
-
-rel <mode> : 2 bytes : Opcode 0x01
- Chooses firmware relativity.
-
- <mode> : The location and size to operate in.
- 0: NATIVE_FIRM (whole size)
- 1: AGB_FIRM (whole size)
- 2: TWL_FIRM (whole size)
-
- 3: Native Proc9 ExeFS
- 4: AGB Proc9 ExeFS
- 5: TWL Proc9 ExeFS
-
- 6: Native Section 0
- 7: Native Section 1
- 8: Native Section 2
- 9: Native Section 3
-
- 10: AGB Section 0
- 11: AGB Section 1
- 12: AGB Section 2
- 13: AGB Section 3
-
- 14: TWL Section 0
- 15: TWL Section 1
- 16: TWL Section 2
- 17: TWL Section 3
-
- 18: Loader title (see info)
-
-find <size> <pattern...> : 2 + size bytes : opcode 0x02
- Finds a pattern in memory. On success, operations
- will be performed relative to the beginning of the found pattern.
-
- <size> : 1 byte
- How many bytes the pattern is.
- <pattern> : <size> bytes
- data to find
-
-back <count> : 2 bytes : opcode 0x03
- Moves back <count> bytes from current position.
-
- <count> : 1 byte
- How many bytes to rewind.
-
-fwd <count> : 2 bytes : opcode 0x04
- Moves forward <count> bytes from current position.
-
- <count> : 1 byte
- How many bytes to rewind.
-
-set <size> <data...> : 2 + size bytes : opcode 0x05
- Copies the bytes in <data> to the current location pointed to,
- and increments the current location by <size> bytes copied.
-
- <size> : 1 byte
- How many bytes to copy.
- <data> : <size> bytes
- Data to copy.
-
-test <size> <data...> : 2 + size bytes : opcode 0x06
- Tests if the current location's data is equivalent to <data>.
- If equivalent, goes to the next instruction. If not, skips
- one operation.
-
- NO ABORT ON FAIL
-
- <size> : 1 byte
- Size of data to test against.
- <data> : <size> bytes
- Pattern to test.
-
-jmp <offset> : 3 bytes : opcode 0x07
- Jumps to offset instruction within the bytecode, and
- resumes execution from there.
-
- Note that the assembler should be passed the number of instrcution
- and will automatically calculate the offset needed.
-
- <offset> : 2 bytes
- Offset to jump to.
-
-rewind : 1 byte : opcode 0x08
- Resets the location to the beginning of the space we're working off.
-
-and <size> <data...> : 2 + <size> bytes : opcode 0x09
- Performs an AND operation bitwise using data as a mask.
-
- <size> : 1 byte
- Size of <data>.
-
- <data> : <size> bytes
- Data to bitwise and with relative data.
-
-title <count> <title> : 2 + <count> * 8 bytes : 0x0A
- Specifies that the following code is applicable only when being applied to
- a list of titles.
-
- This allows the creation of generic patches which can be used with multiple
- titles and share common parts.
-
- The default state is to apply code on any titleID matches within the header,
- so unless you have specialized needs you'll almost never need this.
-
- <count> : 1 byte
- How many titleIDs to read.
- <title> : 8 * <count> bytes
- List of titleIDs as u64.
-
-next : 1 byte : 0xFF
- Resets state to default, and changes the base of code to the next instruction.
- This opcode is not meant to be used directly - it's emitted when generating
- caches.
+++ /dev/null
-There's only *one* real hard rule: run `make reformat` before you commit.
-
-Format is a modified mozilla standard - four spaces, not two.
-
-Also, there's a few hard-enforced rules you need to obey if you want to submit code:
-
- 1) Avoid trigraphs at all costs. Only use them if it actually helps readability.
-
- 2) Any `#pragma` macros are banned. You're using linux and GCC, so stop using MSVCisms.
- There's another few quirks about #pragma once that mean I have to use guards instead.
- Use `__atrribute__` instead.
-
- 3) If by some odd chance you use inline assembly; use `__asm__`, not `asm`.
-
- 4) Do not remove `-Werror`. It's there for a reason. Your code should be squeaky clean;
- if not, find a way to make your code correct. This is mandatory.
+++ /dev/null
-Cloning / Compilation
---------------------------
-
-Okay, first thing's first. I can't support compiling on Windows. Use Linux. The repo abuses symbolic links, relies on certain software being present which isn't with devkitPro, and has host tools which are untested on Windows and require a native gcc (as in, mingw only.) Therefore, do NOT attempt to use windows to compile this. No, I will not port the build scripts to Windows. If you want to fix it without invasive changes, be my guest and make a PR. If I deem the maintenance cost too high, I'll tell you.
-
-It may or may not compile with an OSX based cross compiler. I dunno.
-
-You'll need the following to compile:
-
- * git
- * python2
- * gcc (as in, host gcc)
- * arm-none-eabi-gcc (as in, devkitarm OR baremetal gcc (the latter isn't well tested, but may work. Compiling devkitPro using https://github.com/devkitPro/buildscripts is highly recommended.)
- * bash (as /bin/bash)
-
-To clone: use `git clone --recursive`. Some parts of this CFW are submodules.
-
-To build: run `make`. Output is in `out`. Done. Optionally, parallel make works so pass `-jN` to speed up things.
-
-Not every revision is 100% guaranteed to build. I'll set up a CI eventually.
+++ /dev/null
-Feature graph
-===================
-
-+--------+-----------------+-----------------+------------------------------+-----------+---------------+-------------------+-------+
-|CFW |Firms? |Patch Method |Supplies Officially |3rd Party |Optimization[1]|Focus? |Notes |
-+--------+-----------------+-----------------+------------------------------+-----------+---------------+-------------------+-------+
-|CakesFW |Dec/Enc (SD) |Loadable Fixed |S EN T G Y P R |L B U I F |Speed/Read |Devs/Advanced Users| [2] |
-+--------+-----------------+-----------------+------------------------------+-----------+---------------+-------------------+-------+
-|Luma3DS |Enc(NAND) Dec(SD)|Builtin Dynamic |S E2 Y L B P U X R |N/A |Speed |"Noob-proof" | [3] |
-+--------+-----------------+-----------------+------------------------------+-----------+---------------+-------------------+-------+
-|ReiNAND |Meme(SD) |Builtin Dynamic |S E1 L P F Y R |N/A |Readability |Minimalist | [4] |
-+--------+-----------------+-----------------+------------------------------+-----------+---------------+-------------------+-------+
-|Corbenik|Dec/Enc(SD) |Loadable Bytecode|S P Y L B F U X | |Read/Speed |Advanced Devs | [5] |
-+--------+-----------------+-----------------+------------------------------+-----------+---------------+-------------------+-------+
-|NTR |Hook |ARM11 Binaries |X F |X |Closed Src? |Being Dead | [6] |
-+--------+-----------------+-----------------+------------------------------+-----------+---------------+-------------------+-------+
-
- * R: Reboot patch
- * S: Basic Signature Patch
- * T: TWL Signature Patch
- * G: AGB Signature Patch
- * P: FIRM protection
- * E: Emunand.
- * N - Can have many (unlimited)
- * X - Can have X emunands.
- * Y: Can boot sysnand from a9lh.
- * L: Loader replacement
- * B: Load svcBackdoor on 11.0
- * U: UNITINFO
- * I: GBA BIOS screen
- * F: Region free
- * X: Extras that are not general features listed above
-
-Misc features by CFW:
- * Cakes
- * mid-kid/lgy_cakes
- * TWL patches
- * AGB patches
- * 3ds_injector
- * You have multiple choices. Wolfvak's, mid-kid's, mine, etc...
- * Wolfvak/icing
- * UNITINFO
- * svcBackdoor (o3DS only)
- * Luma
- * Loader replacement. CPU speed/language emulation
- * ARM11 XN Clear (dev)
- * Exception vector hook (dev)
- * Corbenik
- * Arbitrary service injection to empty slots.
- * Loader replacement. Uses patch files.
- * Baked in: langemu (based on Luma)
- * Baked in: CPU speed change
- * ARM11 XN Clear
- * Alternate menu force (courtesy @Reisyukaku)
-
-[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
- easily debugged at the expense of speed? Would you use preprocessor macros to use different implementations?
-
- CakesFW is Speed/Read. It's hit and miss on documentation, but of the bunch, cakes is the best documented.
-
- Luma uses very fast code to do its thing. The source, however, lacks documentation, and some things done
- are not self-evident without analysis. The amount of pointer math rather than structs is astounding.
-
- ReiNAND is cruft-free and well documented. It doesn't do a lot, but what it does do, it does well.
- Unix philosphy in a nutshell. The only complaint is memekey.
-
- My focus will always be readability over speed, unless choosing speed and adding additional documentation
- suffices. As an aside; if you see a single trigraph in my code, please report it. Trigraphs are by design a bug.
-
-[2] CakesFW uses a patch format that has static offsets. They're loaded off SD and _in theory_ are impervious
- to updates. Memory patches in cakes are kind of a kludge, though.
-
- In practice, updating patches is a pain and better done by offset patches like Luma3DS/Rei.
-
- Either way, Cakes allows doing some things the other firmware authors would probably call idiotic; I call them
- smart since I get a choice. Cakes is lacking a few things from Luma3DS mainly because (in my opinion) the patch
- format is problematic and not really future proof or extensible.
-
-[3] "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. You will never brick with Luma, but by the same
- token, a number of options aren't exposed to prevent users shooting themselves in the foot.
-
- As I've been told by @TuxSH - "Noob-proof" != Just for noobs. I agree. I do find that "Noob-proof" as a goal
- tends to somewhat limit the people who truly understand what they're doing. This isn't a bad thing.
- Simply a design choice.
-
- My only real complaint about Luma is the sheer amount of pointer math instead of reading headers correctly,
- and the more-than-slightly evangelical mindset of some users.
-
-[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
- encrypting data differently makes it any less illegal to rehost I have no clue.
-
-[5] Yes, Corbenik currently lacks quite a few things from this graph. Quite. A. Few. This will change with time.
-
-[6] Okay, first - I could rant about how NTR was harming us long run for hours. I won't rant for hours, but I will
- 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 with some offset patches done by BootNTR - then takes over the debug service(?) and
- subsequently the arm11 kernel and spawns a thread in HOME 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 and layeredFS it's also apparent he's a
- shitty coder[8].
-
- He also quit development because people kept pestering him for source. I understand his rationale, but do you
- really want to use software by someone who will throw up his arms and say 'fuck you' at a moment's notice
- due to a few bad eggs?
-
- The point is; NTR is not your friend. It's unmaintained, and nobody but him can continue it due to
- the source code issue. Stop using it.
-
-[7] At least from what I can tell. See https://github.com/patois/NTRDisasm. This is an out of date version, as well.
- I have no idea how accurate I am here. I'd have to run NTR through a debugger.
-
-[8] Tell me that giant switch statement in BootNTR 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.
-
- And don't even get me started on layeredFS - again, python code that could be a dynamic patcher on console.
+++ /dev/null
-Old 3DS NATIVE_FIRM Versions:
- cetk: http://nus.cdn.c.shop.nintendowifi.net/ccs/download/0004013800000002/cetk
-
- 10.4: http://nus.cdn.c.shop.nintendowifi.net/ccs/download/0004013800000002/00000050
- 11.0: http://nus.cdn.c.shop.nintendowifi.net/ccs/download/0004013800000002/00000052
-
-New 3DS NATIVE_FIRM (The standard 3DS firmware - REQUIRED):
- cetk: http://nus.cdn.c.shop.nintendowifi.net/ccs/download/0004013820000002/cetk
-
- 10.4: http://nus.cdn.c.shop.nintendowifi.net/ccs/download/0004013820000002/0000001F
- 11.0: http://nus.cdn.c.shop.nintendowifi.net/ccs/download/0004013820000002/00000021
-
-Old 3DS TWL_FIRM (Firmware for DS/DSi games):
- cetk: http://nus.cdn.c.shop.nintendowifi.net/ccs/download/0004013800000102/cetk
-
- firm: http://nus.cdn.c.shop.nintendowifi.net/ccs/download/0004013800000102/00000016
-
-New 3DS TWL_FIRM (Firmware for DS/DSi games):
- cetk: http://nus.cdn.c.shop.nintendowifi.net/ccs/download/0004013820000102/cetk
-
- firm: http://nus.cdn.c.shop.nintendowifi.net/ccs/download/0004013820000102/00000000
-
-Old 3DS AGB_FIRM (Firmware for GBA games):
- cetk: http://nus.cdn.c.shop.nintendowifi.net/ccs/download/0004013800000202/cetk
-
- firm: http://nus.cdn.c.shop.nintendowifi.net/ccs/download/0004013800000202/0000000B
-
-New 3DS AGB_FIRM (Firmware for GBA games):
- cetk: http://nus.cdn.c.shop.nintendowifi.net/ccs/download/0004013820000202/cetk
-
- firm: http://nus.cdn.c.shop.nintendowifi.net/ccs/download/0004013820000202/00000000
-
-Note that while latest is usually greatest, if you MUST use 11.0 FIRMs, please enable
-both the loader replacement and service fix. Nintendo broke quite a bit, and it was
-quite literally a anti-hack update.
-
-I may implement a token based svcBackdoor since it can now be used to detect CFW's
-presence.
+++ /dev/null
-Feature graph
-----------------
-
-+--------+-----------------+-----------------+------------------------------+-----------+---------------+-------------------+-------+
-|CFW |Firms? |Patch Method |Supplies Officially |Available |Optimization[1]|Focus? |Notes |
-+--------+-----------------+-----------------+------------------------------+-----------+---------------+-------------------+-------+
-|CakesFW |Dec/Enc (SD) |Loadable, Fixed |Sig,Emu(M),Twl,Agb,Sys,Ptc |Mis,Bck,Mod|Speed/Read |Devs/Advanced Users| [2] |
-+--------+-----------------+-----------------+------------------------------+-----------+---------------+-------------------+-------+
-|Luma3DS |Enc(NAND) Dec(SD)|Builtin, Dynamic |Sig,Emu(2),Sys,Mod,Bck,Mis,Ptc|N/A |Giant Mess |"Noob-proof" | [3] |
-+--------+-----------------+-----------------+------------------------------+-----------+---------------+-------------------+-------+
-|ReiNAND |Meme(SD) |Builtin, Dynamic |Sig,Emu,Sys,Mod,Ptc |N/A |Readability |Minimalist | [4] |
-+--------+-----------------+-----------------+------------------------------+-----------+---------------+-------------------+-------+
-|Corbenik|Dec/Enc (SD) |Executable |Sig,Ptc,Bck,Mod,Sys |Mis |Read/Speed |Advanced Devs | [5] |
-+--------+-----------------+-----------------+------------------------------+-----------+---------------+-------------------+-------+
-|NTR |N/A |Executable |Mis |Mis |Douchebaggery |Shilling Closed Src| [6] |
-+--------+-----------------+-----------------+------------------------------+-----------+---------------+-------------------+-------+
-
- * Sig: Signature Patch.
- * Twl: TWL Signature Patch
- * Agb: AGB Signature Patch
- * Ptc: FIRM protection
- * Emu: Emunand.
- * (M) - Can have many (unlimited)
- * (X) - Can have X emunands.
- * Sys: Can boot sysnand from a9lh.
- * Mod: Loader replacement
- * Bck: Load svcBackdoor on 11.0
- * Mis: Other misc fixes and alterations including:
- * UNITINFO patch
- * GBA bios screen
-
-Misc features by CFW:
- * Cakes:
- * mid-kid/lgy_cakes
- * TWL patches
- * AGB patches
- * 3ds_injector
- * You have multiple choices. Wolfvak's, mid-kid's, mine, etc...
- * Wolfvak/icing
- * UNITINFO
- * svcBackdoor (incomplete)
- * Luma
- * Loader replacement. CPU speed/language emulation
-
-[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
- easily debugged at the expense of speed? Would you use preprocessor macros to use multiple?
-
- CakesFW is Speed/Read. Speed first, keep readability if possible whenever possible. Which is a good
- approach.
-
- No, I don't call Luma a complete mess lightly. Go look thorugh the code. You back? Good. Tell me,
- are the comments helpful and do you understand what the blatant pointer abuse in patches.c is
- actually ref'ing? No? I had to decode that. It's referencing the exefs's code section. Which was
- impossible to tell without ten minutes staring at it. Moving on now...
-
- ReiNAND is cruft-free and well documented. It doesn't do a lot, but what it does do, it does well.
- Unix philosphy in a nutshell. The only complaint is memekey.
-
- My focus will always be readability over speed, unless choosing speed and adding additional documentation
- suffices. As an aside; if you see a single trigraph in my code, please report it. Trigraphs are by design a bug.
-
-[2] CakesFW uses a patch format that has static offsets. They're dynamically loaded and in theory are impervious
- to updates. In practice, updating patches is a pain and better done by offset patches like Luma3DS/Rei.
-
- Either way, Cakes allows doing some things the other firmware authors would probably call idiotic; I call them
- smart since I get a choice. Cakes is lacking a few things from Luma3DS mainly because (in my opinion) the patch
- 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.
-
-[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
- encrypting data differently makes it any less illegal to rehost I have no clue.
-
-[5] Yes, Corbenik currently lacks quite a few things from this graph. On the upside; patches can be implemented
- externally. I currently have zero interest in implementing reboot; I never need it, having a n3ds. EmuNAND, as
- well is something I have little interest in (but will happen eventually.)
-
- As for other bits; Aside from fixing svcBackdoor, I can also inject arbitrary custom services. You're welcome.
-
-[6] Okay, first - I could rant about how NTR is harming us long run for hours. I won't rant for hours, but I will
- 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.
-
- 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
- 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
- NATIVE_FIRM even though there's literally no difference that should break NTR.
+++ /dev/null
-Things I won't implement (for a number of reasons)
-==========================
-
- * Memekey Support.
-
-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; there's problems that hamper it from being truly a good idea.
-
-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. Do it yourself. No support will be offered to gateway users. You're paying for a piracy tool. Not to mention, I only integrate code I'm capable of testing safely, so this won't ever be a part of corbenik.
-
- * 3dsx
-
-You might be able to use Brahma, but hell if I know. Either way, I'm not going to attempt to get stuff on menuhax since there's limits on version now. I recommend any menuhax users get a9lh.
-
-Not bugs
-=========
-
- * CETK decryption
-
-This has been removed from the FIRM decryptor, since it's unreliable on a9lh. I may re-add it someday.
+++ /dev/null
-The std/ directory is a self-contained, mostly conformant implementation of the C Standard Library for 3DS in ARM9 code.
-It supports a good chunk of standard functions and interfaces, but not everything.
+++ /dev/null
-Next
--------------
-
- * Optimize the code in svc. It's slow, because it checks the filesystem for 0xfe files that don't exist. It should list the dir instead.
-
-Shortterm
--------------
-
- * Make config file for corbenik plaintext. Nobody likes binary configs. They suck. Massively. Especially when you fuck up a setting and need to change it on something that isn't a 3ds.
- * In place firmware loading/patching.
- * Weird hack central - Developer 11.4 leaked. Allow injecting debug module? Ehehehehe. No clue what the point of this would be, but hey, it'd be FUCKING cool, man.
-
-Longterm
--------------
- * Attempt to create a replacement handler for Service 0x3D, AKA OutputDebugString(void const, int) to log to a file on SD.
- * Might be a pipe dream. It still would be cool to capture debug logs from games.
- * Pretty sure this goes over JTAG on PARTNER units and anything else >/dev/null.
- * Maybe replace svc 0xFF with something fancy.
- * Change some stdlib functions to more closely imitate their userland counterparts
- * EmuNAND. By this, I mean any non-physical NAND, not just gateway style.
- * I'd like to implement a loop-mount-like NAND. The NAND would be a file off the SD card rather than a region before partition 1 in this setup, and on the upside near unlimited NANDs could be accomodated without moving partitions. On the downside, any user stupid enough to move the NAND bin while the system is running would be in for severe consequences.
projects / corbenik / corbenik.git / commitdiff