Hacking Could future updates ever potentially be blocked (or damage) A9LH systems?

[apoptygma]

I understand that A9LH is initialized prior to the operating system being loaded and hence any updates are performed in the modified environment, however I can imagine that if Nintendo wanted to search storage and/or memory for elements of the exploit and simply prevent the system updating or introduce elements in their update that clobber required A9LH resources they could do so fairly easily. This would of course be circumvented with updated modules for CFW or A9LH but there's nothing I understand about A9LH which makes it 'future proof' (without constant updates from the authors) should Nintendo wish to engage in a game of cat and mouse with hackers.

 

[sweis12]

They could mess with hackers. It would not be hard to tell. (SD files, the fact is uses the 8.1 firm, unofficial title IDs, out of region games, ect..)
Will they? Probably not.

 

[apoptygma]

My understanding is obviously somewhat crude but I wonder if there's any method they could employ to actually damage the A9LH installation itself. I would think that the system update process has permission to write to the same location on the NAND as the initial payload right? So couldn't they just 'reserve' that with dummy data and essentially brick all A9LH systems which are updated (essentially forcing A9LH users to execute, manually a customized update instead of just being able to use the standard OTA process)

 

[Deleted member 386348]

My understanding is obviously somewhat crude but I wonder if there's any method they could employ to actually damage the A9LH installation itself. I would think that the system update process has permission to write to the same location on the NAND as the initial payload right? So couldn't they just 'reserve' that with dummy data and essentially brick all A9LH systems which are updated (essentially forcing A9LH users to execute, manually a customized update instead of just being able to use the standard OTA process)

You can restore a brick with A9LH, and Nintendo isn't going to brick a chunk of users.

 

[apoptygma]

You can restore a brick with A9LH, and Nintendo isn't going to brick a chunk of users.

I understand you can restore a bricked OS but you can't restore anything if the A9LH payload itself is overwritten correct?

 

[Deleted member 386348]

I understand you can restore a bricked OS but you can't restore anything if the A9LH payload itself is overwritten correct?

The payload (arm9loaderhax.bin) can be replaced. I assume you meant A9LH itself. Luma3DS and some other CFWs block this.

 

[yifan_lu]

You highly underestimate the skills of hackers if you think Nintendo can slip by a cfw uninstaller.

 

[vb_encryption_vb]

Think you put this in the wrong thread?

 

[hundshamer]

Think you put this in the wrong thread?

Yes. Please remove the quote. It was meant for a private conversation.

EDIT: Thank you.

 

[apoptygma]

You highly underestimate the skills of hackers if you think Nintendo can slip by a cfw uninstaller.

I meant more, that there's nothing inherently protected about the storage and memory used by any given CFW or system modifications. It sounds as though there's some level of self-preservation in (as the example provided earlier) Luma3DS - in that it prevents arm9loaderhax.bin being overwritten, this however is the binary which A9LH itself calls, likewise it would call Decrypt9 or any other binary if instructed to do so. I was referring to the underlying NAND inject that calls these binaries, that allocation , is it protected by A9LH itself? If so then it would theoretically be possible for Nintendo to perform checks against the ability to overwrite it and if it (the OTA update) were not able to do so, abort. I'm not saying they can ever stop a user running A9LH from updating system files out of band through some other means, I'm just asking if they could deliberately break OTA for A9LH users and if that could (deliberately or otherwise) destroy the hack itself.

 

[The Catboy]

The payload (arm9loaderhax.bin) can be replaced. I assume you meant A9LH itself. Luma3DS and some other CFWs block this.

They could replace your arm9loaderhax.bin, but legally can not create an execute file without asking your permission first. And of course, the second they were to do that, word would spread and people would just delete the file from their SD card.
The only way Nintendo could remove it, would be for them physically go to your house and remove it by force. Otherwise, they can't do shit.
BTW, the update to 11 proved that Nintendo has been cornered. Their best bet now is just move on.

 

[IzeC0ld]

Probaly not. I would'nt think of nintendo getting access to your storage online unless you were on a ftp server

 

[The Real Jdbye]

The payload (arm9loaderhax.bin) can be replaced. I assume you meant A9LH itself. Luma3DS and some other CFWs block this.

They could theoretically overwrite the stage2 payload, I don't think Luma blocks that.

 

[phalk]

If they do introduce a brick code they would probably end up messing up and bricking legitimate users while A9LH users can just restore a backup because of the early boot control of the system.

So, in theory, yes, they can, but due to the nature of A9LH it can easily be reversed because of the FIRM protection CFW imposes early at boot. There's nothing Nintendo can do with this, really.

 

[apoptygma]

They could replace your arm9loaderhax.bin, but legally can not create an execute file without asking your permission first. And of course, the second they were to do that, word would spread and people would just delete the file from their SD card.
The only way Nintendo could remove it, would be for them physically go to your house and remove it by force. Otherwise, they can't do shit.
BTW, the update to 11 proved that Nintendo has been cornered. Their best bet now is just move on.

Perhaps I'm further exasperating my lack of understanding on this matter but you're talking about replacing arm9loaderhax.bin, I'm talking about replacing the code which calls that binary, the code which installing A9LH inserts into the NAND memory. Also legality has nothing to do with this at all. All the files on the system are created and executed by Nintendo and they require no 'law' to do so.

 

[The Catboy]

Perhaps I'm further exasperating my lack of understanding on this matter but you're talking about replacing arm9loaderhax.bin, I'm talking about replacing the code which calls that binary, the code which installing A9LH inserts into the NAND memory. Also legality has nothing to do with this at all. All the files on the system are created and executed by Nintendo and they require no 'law' to do so.

That would require them to modify files that they can't gain access to without accessing your hardware. They can't update the FIRM0/1 because it's being protected and the only way around that would be either new hardware or they go to your house and remove it.

 

[apoptygma]

That would require them to modify files that they can't gain access to without accessing your hardware. They can't update the FIRM0/1 because it's being protected and the only way around that would be either new hardware or they go to your house and remove it.

I think what I'm trying to address is that A9LH works by modifying the NAND 0x96 sector, could Nintendo not correct that data in an OTA update? As I said I'm not fully aware of how this works and I'm sure someone with less understanding than yifanlu would be able to explain. I'm not clear why you say FIRM0/1 can't written, isn't that what A9LH rewrites?

 

[EmperorOfCanada]

I think what I'm trying to address is that A9LH works by modifying the NAND 0x96 sector, could Nintendo not correct that data in an OTA update? As I said I'm not fully aware of how this works and I'm sure someone with less understanding than yifanlu would be able to explain. I'm not clear why you say FIRM0/1 can't written, isn't that what A9LH rewrites?

If **I** understand correctly, a9lh boots very early in the boot process and loads LUMA, which protects itself by putting the a9lh area as readonly?

 

[The Catboy]

I think what I'm trying to address is that A9LH works by modifying the NAND 0x96 sector, could Nintendo not correct that data in an OTA update? As I said I'm not fully aware of how this works and I'm sure someone with less understanding than yifanlu would be able to explain. I'm not clear why you say FIRM0/1 can't written, isn't that what A9LH rewrites?

Technically, if you were running a CFW without those protections turned on, it would remove A9LH. But with current CFW set ups, they protect the A9LH from bring removed through updates.
A9LH does rewrite the FIRM0/1, which means if it's not protected an update could remove your current install.

 

[apoptygma]

If **I** understand correctly, a9lh boots very early in the boot process and loads LUMA, which protects itself by putting the a9lh area as readonly?

I think you might have answered my question here actually - so depending on the CFW, it's likely that the CFW will protect the A9LH install. That makes lots of sense. So in theory if Nintendo attempted to remove the modifications the read-only lock in place would halt the upgrade.

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

Technically, if you were running a CFW without those protections turned on, it would remove A9LH. But with current CFW set ups, they protect the A9LH from bring removed through updates.
A9LH does rewrite the FIRM0/1, which means if it's not protected an update could remove your current install.

An update running without the protections in place on the CFW - thanks for the good answer.