Well, I've had the slot0x05KeyY.bin file on the device the entire time. So it can't be case 1. And Decrypt9 used the file to build a working aeskeydb.bin, so it can't be case 2 either. Actually, I've just confirmed my USA N3DS XL does the same. It's just that I had already created aeskeydb.bin before updating from v0.20 so I hadn't noticed. I delete it and it had the same issue. Rebuilt aeskeydb.bin and it and it went away again. The functionality of aeskeydb.bin does not seem to matter whether I leave it in the Decrypt9 folder or move it to the root (well, technically, copy it to the root and delete it from Decrypt9, since there is no "move" function yet). CTRNAND is indeed not an option when it gives this error, as you would expect. With the aeskeydb.bin in place, the first 16 bytes on that .bin file are E9 00 00 43 54 52 20 20 20 20 20 00 02 40 01 00 on the EUR and USA devices (I'm using "SYSNAND VIRTUAL" and the hex viewer to get that, if that matters -- makes little sense copying 1 GB of data to get 16 bytes after all).



Now, I used the files from the data_input.zip provided by the A9LH tutorial. Is it possible that part of the problem is that I should have dumped my own firm0, firm1, and secret sector files? I was under the impression that they must be all the same if a distributed copy can work in the first place, but I can extract them from EmuNAND (being it's a copy of my pre-A9LH SysNAND) and reinstall A9LH if it matters.

Click to expand...