ROM Hack [Release] ExInjector - Inject original exheaders into repacked roms

[piratesephiroth]

from what i understand, the only reason we need to inject the exheader is because, when specifying the exheader in makerom initially, makerom messes it up and does not do it properly?
if so, why don't people just improve makerom to handle exheaders properly, instead of making a separate tool?

Only Nintendo can sign the access control stuff in the exheader. Makerom has built-in templates taken from roms and sdk apps's exheaders with signed setups for most sdk versions but of course they don't cover all the situations, plus you have to specify them with a command line switch..
Of course this hacky thing is mostly relevant for developer-signed roms. You can avoid it altogether by writing your own exheader and creating an unsigned rom, then installing it from a CIA, being able to use all services you want.

 

[d0k3]

At the risk of asking a noobish question: From what I understand this won't help N3DS / SKY3DS users, right? (because we can't use that CFW and games processed by this still won't run from SKY3DS)

 

[cearp]

.

Only Nintendo can sign the access control stuff in the exheader. Makerom has built-in templates taken from roms and sdk apps's exheaders with signed setups for most sdk versions but of course they don't cover all the situations, plus you have to specify them with a command line switch..
Of course this hacky thing is mostly relevant for developer-signed roms. You can avoid it altogether by writing your own exheader and creating an unsigned rom, then installing it from a CIA, being able to use all services you want.

so the access control stuff that makerom signs (?) is NOT signed properly (if so, i can understand that) - and does not run using gw, because they do not patch that check out...?
so we have to inject legit access control stuff?

i thought the stuff we specify in the rsf goes 'into' the exheader in the final creation...

At the risk of asking a noobish question: From what I understand this won't help N3DS / SKY3DS users, right? (because we can't use that CFW and games processed by this still won't run from SKY3DS)

this has nothing to do with n3ds or old3ds don't worry.
it is just a tool to help build roms etc

 

[d0k3]

this has nothing to do with n3ds or old3ds don't worry.
it is just a tool to help build roms etc

I should have asked differently: Repacked roms can't be run via SKY3DS, because they are not encrypted, right? And there's also no other way of running repacked roms on a N3DS other than via GW?

 

[hippy dave]

Right (well, because they're not signed), and right.

 

[liomajor]

I should have asked differently: Repacked roms can't be run via SKY3DS, because they are not encrypted, right? And there's also no other way of running repacked roms on a N3DS other than via GW?

We can only use a non supported crypt for rebuild .3ds that is not supported without gateway.

 

[piratesephiroth]

.
so the access control stuff that makerom signs (?) is NOT signed properly (if so, i can understand that) - and does not run using gw, because they do not patch that check out...?
so we have to inject legit access control stuff?

i thought the stuff we specify in the rsf goes 'into' the exheader in the final creation...

Yeah but there's an additional access control list, used as a limitation to the original one. This section is also signed and makerom can't sign it. When you build a rom using developer encryption, it will use access control lists from the built in templates.
Only if you use test mode encryption it will write the lists, because I presume the signatures aren't checked anyway.

I should have asked differently: Repacked roms can't be run via SKY3DS, because they are not encrypted, right? And there's also no other way of running repacked roms on a N3DS other than via GW?

There are 3 encryption types:
Retail - Used by commercial roms and impossible for us to replicate. Sky3DS can only run these.
Developer - Used by Developers' devices. The repacked roms we run from Gateway's red cart's use this encryption.
Test Mode - No encryption. All signature checks are ignored. Currently we can only run these when we install them from CIAs.

 

[pakrett]

Is someone know how I can build a cia from a system titles (.app), I have a way but I don't know how to build a working rsf...

 

[piratesephiroth]

Is someone know how I can build a cia from a system titles (.app), I have a way but I don't know how to build a working rsf...

Can't you download and build it with 3DNUS?

 

[pakrett]

Can't you download and build it with 3DNUS?

3DNUS is dead man ^^

 

[piratesephiroth]

3DNUS is dead man ^^

Only for certain files. 90% of them still work.

 

[pakrett]

Only for certain files. 90% of them still work.

There is only the lastest nver title no ? I need to build a full 2.X update pack !

 

[piratesephiroth]

There is only the lastest nver title no ? I need to build a full 2.X update pack !

You need it? 2.x? Wut.

 

[pakrett]

You need it? 2.x? Wut.

To dump the otp registers. I need to downgrade to this version.

--------------------- MERGED ---------------------------

So is it possible to build a rsf for a system title ?

--------------------- MERGED ---------------------------

BTW exInjector seems not working with system titles, that's why I asked that.
But maybe I not using it like it must ?

 

[Apache Thunder]

System Titles use "System Fixed Key" keyslot. That and they have to have certain flags set (For example all system apps that I'm aware of do not have the "run from SD" enabled in exheader). On 7+ system firmware (I don't know exactly when this was introduced) System apps must be encrypted using that keyslot. Unencrypted apps or encrypted apps using wrong keyslot will not show up on Home Menu and will not boot even if you force boot them from FBI.

So using ExInjector on system apps isn't the reason why they don't work. I think it's because you are attempting to use them with zero key encryption or unencrypted and that's why they stop working. If rxTools or similar CFW had a "CTR Encrypter" feature, modifying system apps would be easier. Currently you have to use xorpads from the original system app to reencrypt them properly. Then rebuild the CXI container manually in a hexeditor while fixing the hashes. It's a huge pain in the a** and I wish there was a CTR Encryptor in Decrypt9/rxTools. It would get around this issue.

 

[Shadowtrance]

System Titles use "System Fixed Key" keyslot. That and they have to have certain flags set (For example all system apps that I'm aware of do not have the "run from SD" enabled in exheader). On 7+ system firmware (I don't know exactly when this was introduced) System apps must be encrypted using that keyslot. Unencrypted apps or encrypted apps using wrong keyslot will not show up on Home Menu and will not boot even if you force boot them from FBI.

So using ExInjector on system apps isn't the reason why they don't work. I think it's because you are attempting to use them with zero key encryption or unencrypted and that's why they stop working. If rxTools or similar CFW had a "CTR Encrypter" feature, modifying system apps would be easier. Currently you have to use xorpads from the original system app to reencrypt them properly. Then rebuild the CXI container manually in a hexeditor while fixing the hashes. It's a huge pain in the a** and I wish there was a CTR Encryptor in Decrypt9/rxTools. It would get around this issue.

Put a suggestion to dok3 in the Decrypt9 thread (see sig), it could happen. (no idea how hard it would be)... don't look at me though. d0k3 is the code monkey haha

 

[pakrett]

System Titles use "System Fixed Key" keyslot. That and they have to have certain flags set (For example all system apps that I'm aware of do not have the "run from SD" enabled in exheader). On 7+ system firmware (I don't know exactly when this was introduced) System apps must be encrypted using that keyslot. Unencrypted apps or encrypted apps using wrong keyslot will not show up on Home Menu and will not boot even if you force boot them from FBI.

So using ExInjector on system apps isn't the reason why they don't work. I think it's because you are attempting to use them with zero key encryption or unencrypted and that's why they stop working. If rxTools or similar CFW had a "CTR Encrypter" feature, modifying system apps would be easier. Currently you have to use xorpads from the original system app to reencrypt them properly. Then rebuild the CXI container manually in a hexeditor while fixing the hashes. It's a huge pain in the a** and I wish there was a CTR Encryptor in Decrypt9/rxTools. It would get around this issue.

Thank you, so I'm blocked ^^ I think I can do that for some titles but for 127 XD

Put a suggestion to dok3 in the Decrypt9 thread (see sig), it could happen. (no idea how hard it would be)... don't look at me though. d0k3 is the code monkey haha

Ok I'll do that !

 

[piratesephiroth]

To dump the otp registers. I need to downgrade to this version.

--------------------- MERGED ---------------------------

So is it possible to build a rsf for a system title ?

--------------------- MERGED ---------------------------

BTW exInjector seems not working with system titles, that's why I asked that.
But maybe I not using it like it must ?

Did you try that python rsf generator? I was making one but got lazy.

 

[pakrett]

@Apache Thunder, just to be sure, this problem appears even if the .app is already encrypted ? (hasn't been decrypted ?)

--------------------- MERGED ---------------------------

Did you try that python rsf generator? I was making one but got lazy.

Ok but if it is useless, like @Apache Thunder said, why ? ^^

 

[Apache Thunder]

You can use an RSF...But what's the point? One could use this:

3DSBuilderNoCrypt.rar

This was modified to build CCI roms without encryption. You can extract the CXI from it and build a CIA that works in CFW. Provided what you built was setup to run from SD. (exheader has to be modified accordingly).

You could use this in combination with a future CTR Encrypter for Decrypt9/rxTools to build system apps. (You would just then extract the CXI from the CCI, use CTR Encrypter to encrypt the CXI, then build a CIA from that CXI)

Unlike the rsf method you have to modify the exheader manually if you are converting something originally meant to run as a CCI (3DS rom) to a SD app, etc. Assuming you are building a system app. (like you are modifying an existing app like System Settings or something), you don't really have to modify the exheader at all. But again, you have to find a way of re-encrypting it as it won't run unencrypted as a system app (and zero keys won't work either).

EDIT: By the way, that NoCrypt version of 3DSBuilder is basically what I use to convert a 3DS rom to a CIA (as this method produces a CIA that will work in CFW and Gateway mode. Original version used Zero Key encryption which can only be used with Gateway mode). No messing with RSF files or those batch tools that try to do it for you. I just have to a certain offset in the exheader to 03 hex value (as this sets the "run from SD" flag) build a CCI from it, then extract the CXI using 3DS Explorer or ctrtool then build a CIA. Then it's pretty much good to go.

There's an additional offset I can adjust in the exheader if I want to change the "major" version string. (the minor and micro numbers can be set using makerom/make_cia). The "version" number you see in DevMenu when you go to install this. This is important for example if you are building a game patch for use online as certain version string range is needed to fool servers into thinking you have latest patch when going online (games that don't really use online features or never had a patch don't really need to worry about this). For games like Pokemon X/Y or ORAS for example.

You can find the offsets for stuff like this in the exheader by visiting 3DBrew.