"prefetch abort (svcbreak) processor ARM9" after CTRTransfer

PizzaYandere37 Jun 8, 2019.

  1. PizzaYandere37
    OP

    PizzaYandere37 Member

    Newcomer
    1
    Jan 21, 2017
    France
    Edit: TOTALLY FIXED IT, GO DOWN TO SEE THE FIX IF YOU HAVE SAME ISSUE

    Hi guys

    So I had a bricked O3DS XL and I just found how to make it work again, so I can launch payloads with luma3DS like GodMode9 and Decrypt9WIP, I first tried a CTRTransfer on GodMode9 but when I go to the script "ctrtransfer_ticket_copy" and try to launch it, it tells me "Could not find ticket backup. Something has gone wrong with your CTRTransfer". I still tried to launch my 3DS but it gave me this error "processor: arm9; exception type: prefetch abort (svcbreak)". I did another CTRTransfer with Decrypt9WIP and launched "ctrtransfer_ticket_copy" again on GodMode9, same error. I tried to re-launch another CTRTransfer with Decrypt9WIP but without launching the "ctrtransfer_ticket_copy" script on GodMode9, still the same error.

    Informations that might be useful:

    Like I said, I have a bricked O3DS XL (that I sorta unbricked)
    The console is European and was between version 11.2.0-35E and version 11.4.0-37E
    The CTRNand I try to transfer comes from this guide: https://3ds.hacks.guide/ctrtransfer.html (Old 3DS or 2DS - 11.5.0 - EUR - CTRTransfer)
    I have a 2gb microSD in it's adapter
    I have another O3DS (the original one, not an XL) which has Frogminer CFW (firmware version: 11.9.0-42E) and it has a 32gb microSD in it's adapter

    Joined my most recent crash with the thread

    thank you in advance for your answers and sorry for my bad english
     

    Attached Files:

    Last edited by PizzaYandere37, Jun 9, 2019
    Zefero and NoNAND like this.
  2. Shadow#1

    Shadow#1 Wii & 3DS Softmod Expert

    Member
    12
    Nov 21, 2005
    United States
    Use a full sized SD Card not a mad in an SD Adapter
     
  3. PizzaYandere37
    OP

    PizzaYandere37 Member

    Newcomer
    1
    Jan 21, 2017
    France
    Well I can't, I have no SD card reader and the only one that I have is unplugged of my pc
     
  4. PizzaYandere37
    OP

    PizzaYandere37 Member

    Newcomer
    1
    Jan 21, 2017
    France
    Okay, found the problem and fixed it:

    This was the movable.sed that was corrupted, I dumped the one from my working O3DS and injected it in my O3DSXL, got it working

    to do that:
    In Decrypt9WIP (with your working console), go to SysNAND options, go to System File Dump and chose "dump movable.sed". Now find your movable.sed on the SD of your working console then paste it in the folder "files9" of the SD card of your bricked console. Launch Decrypt9WIP on your bricked console, go to SysNAND options aswell but this time chose System File Inject and go to "Inject movable.sed". Reboot your console and it's fixed

    WARNING: You'll lose any online service access like the eShop, so if you didn't had HBL but you still got you D9W payload, try to inject HBL or FBI in HEALTH & SAFETY APP (I recommend Injecting FBI and install every CIAs like HBL CIA, FBI CIA, Luma3DS Update CIA, ect...)
     
    Last edited by PizzaYandere37, Jun 19, 2019
  5. TurdPooCharger

    TurdPooCharger Meh.

    Member
    12
    Jan 1, 2018
    United States
    The use of Decrypt9WIP's CTRTransfer is destructive (ie, loss of HWCAL0.DAt, HWCAL1.DAt, erased user profile's data folder, several console unique *.db files).
    If the built-in GodMode9's CTRTransfer doesn't resolve your issue, try CTRTransfer (Type D9).

    :!: There is one CTRNAND softbrick that neither GodMode9 and Type D9 varieties will fix. Dubbed "gamecoin" brick, this requires manual debugging.


    @PizzaYandere37, if you want to restore your * o3DSXL's console unique files including its own movable.sed,
    1. GodMode9 → [S:] SYSNAND VIRTUAL/essential.exefsMount as EXEFS image.
    2. While in the drive [G:] EXEFS GAME IMAGE, hold (L)-shoulder button and press (RIGHT) d-pad to highlight the eight (8) files in yellow.
    3. Press (A) → Copy to 0:/gm9/out.
    4. Go to [0:] SDCARD ()/gm9/out and rename these files as such:
      • frndseedLocalFriendCodeSeed_B
      • hwcal0 HWCAL0.DAt
      • hwcal1 HWCAL1.DAt
      • movable movable.sed
      • secinfo SecureInfo_A -or- SecureInfo_B
    5. Manually replace these files located at [1:] SYSNAND CTRNAND,
      • 1:/private/movable.sed
      • 1:/ro/sys/HWCAL0.DAt
      • 1:/ro/sys/HWCAL1.DAt
      • 1:/rw/sys/SecureInfo_A | 1:/rw/sys/SecureInfo_B | (you only need one)
      • 1:/rw/sys/LocalFriendCodeSeed_B
    6. At the 1:/private directory, press (A) on movable.sedCalculate CMAC → etc, to fix the CMAC.
      • For broad CMAC corrections, go to [root], hover white on [1:] SYSNAND CTRNAND, hold (R)-shoulder and press (A) → Fix CMACs for drive.
     
    Last edited by TurdPooCharger, Jun 9, 2019
  6. PizzaYandere37
    OP

    PizzaYandere37 Member

    Newcomer
    1
    Jan 21, 2017
    France
    It bricked it again dude... sorry but your thing is not a fix and I already found a fix (to unbrick console)
     
  7. TurdPooCharger

    TurdPooCharger Meh.

    Member
    12
    Jan 1, 2018
    United States
    Your idea of borrowing the o3DS movable.sed and using it on the o3DSXL is not recommended because Nintendo will notice you performed an unauthorized System Transfer and will ban both your systems from online services.

    Check your movable.sed file.
    1. GodMode9 → [S:] SYSNAND VIRTUAL/essential.exefs → Mount as EXEFS image.
    2. G:/movable Show in hexeditor.
    3. Hold (R)-shoulder and press (Y) to change the hex view.
    Does your movable.sed resembles this format? You want to see if the magic header "SEED" is in place.

    Due to privacy concerns, do not post a picture of yours.

    [​IMG]

    [​IMG]
     
  8. PizzaYandere37
    OP

    PizzaYandere37 Member

    Newcomer
    1
    Jan 21, 2017
    France
    Got these 4 files you asked me to rename deleted for no reason, and I can't boot my 3ds even with another CTRTransfer

    Edit: luckily got them back
     
    Last edited by PizzaYandere37, Jun 9, 2019
  9. TurdPooCharger

    TurdPooCharger Meh.

    Member
    12
    Jan 1, 2018
    United States
    When you unbricked your o3DSXL, did you first used Decrypt9WIP CTRTransfer and followed by using GodMode9 second?

    Do you recalled GodMode9 asking you to backup the essential.exefs?

    If you used Decrypt9WIP CTRTransfer before GodMode9, you may have inadvertently/permanently erased those o3DSXL's original NAND files as GodMode9 would have backed up dummy copies found in the CTRTransfer donor image.

    What do those files look like in essential.exefs?
    Do any of them look like bunch of zeros (00 00 00)?
    Do you still have access to GodMode9?

    • Good copies of the HWCAL0.DAt and HWCAL1.DAt are supposed to have "CCAL" as the header magic.
    • The SecureInfo_A or _B should have your o3DSXL's serial number (XX########).
    • LocalFriendCodeSeed_B should match the copy found in SecureInfo_A|B movable.sed as seen in the diagram.
    Try clearing the RAM with the battery trick if your o3DSXL automatically boots with an ARM9 or ARM11 error.
     
    Last edited by TurdPooCharger, Jun 9, 2019
  10. PizzaYandere37
    OP

    PizzaYandere37 Member

    Newcomer
    1
    Jan 21, 2017
    France
    I still have access to GodMode9, just updated it else I couldn't use the CTRTransfer script you gave me lol

    — Posts automatically merged - Please don't double post! —

    When I unbricked it, I used Decrypt9WIP for CTRTRansfer and movable.sed inject
     
  11. TurdPooCharger

    TurdPooCharger Meh.

    Member
    12
    Jan 1, 2018
    United States
    Okay, whatever you do, don't uninstall the custom firmware!

    You mentioned "CTRTransfer Ticket Copy", which is from the GM9Megascript. I'm reviewing the script code to figure out where the mishap happened when using that and Decrypt9WIP.

    By the way, the preferred way of doing built-in GodMode9 CTRTransfer was to go to the file 11.5.0-38E_ctrtransfer_o3DS.bin → press (A) → CTRNAND options... Transfer image to CTRNAND.
    Alas at this point, doing this won't matter now.

    Before you go any further with editing the NAND and doing any more CTRTransfer,
    1. Take the 32 GB SD card and copy everything over to a computer.
      • The 2 GB card is too small for the tasks ahead.
    2. Reformat the card in FAT32 + 32 KB cluster size with Windows File Explorer or guiformat.
    3. Full Write + Verify the empty card with H2testw. Unless you've recently done this before, do not skip this step.
    4. If the card passes, delete the *.h2w test files.
      • :!: You must replace the hardware failed card and go back to step 1 if an error was reported.
      • A bad or fake SD card will further brick your o3DSXL when doing CTRTransfer and will fail to properly backup files.
    5. Download this CFW starter kit to build a test setup. Hold off from using your main setup for the time being.
    6. When prompted by Luma3DS v9.1 configuration, use these settings.
      • Luma config settings
    7. Backup your current SysNAND *.bin image for safety. This is to prevent further unnecessary edits or mistakes.
    When these above steps are completed, we can continue discussion on repairing the 3DS firmware. Are you familiar with knowing how to use a hex editor, like HxD?


    ****

    Edit - So, I have bad news on why the "CTRTransfer Ticket Copy" didn't work for you.

    When you first used GodMode9 CTRTransfer, how it works is that it renamed the file ticket.dbticket.bak.
    However, because you used Decrypt9WIP CTRTransfer next, that file was overwritten/erased because that program doesn't back up that file.

    For any real purchases and game updates you downloaded from Nintendo eShop, all your personal/paid legit tickets are deleted. However, this might not be an issue since Nintendo should have a server record of your purchases (you would have go to the eShop and redownload titles).

    If you pirated games/DLCs/updates, fake tickets can be restored with faketik.
     
    Last edited by TurdPooCharger, Jun 9, 2019
  12. PizzaYandere37
    OP

    PizzaYandere37 Member

    Newcomer
    1
    Jan 21, 2017
    France
    all done, now what ?
     
  13. TurdPooCharger

    TurdPooCharger Meh.

    Member
    12
    Jan 1, 2018
    United States
    Sorry, I was out of town on family visit for the day. My adorable nephew was to be gifted an awesomely hacked o2DS, but the in-laws decided we should wait until Christmas. He's not quite old enough yet to play video games, but he'll nonetheless soon learn to fear turtle shells. Buwhaha! ^_^

    Anyway, look at the various files copied from the essential.exefs using a hex editor or hex viewer. Your o3DSXL should be using its own copies especially for the movable.sed, SecureInfo_A (or _B), and LocalFriendCodeSeed_B.

    For those three (3), sharing or using the wrong ones can lead to certain types of bans *. Remember not to publicly post images of yours on these forum.
    * For the LocalFriendCodeSeed_B, you should try to keep the original version. Borrowing another's LFCS_B can unban that system from online game play.

    As for HWCAL0.DAt and HWCAL1.DAt, using the Decrypt9WIP CTRTransfer erases the real ones and replaces dummy versions borrowed from the donor CTRNAND image. Not having them will affect image qualities: frame rate, 3D focus, color, lighting, etc.

    Essential Files Diagram.

    ***

    Verify the o3DSXL's files all look like they should in hex viewer, and they're located in the correct directories,

    [1:] SYSNAND CTRNAND/
    private/
    movable.sed
    ro/
    sys/
    HWCAL0.DAt
    HWCAL1.DAt
    rw/
    sys/
    LocalFriendCodeSeed_B
    SecureInfo_A
    | SecureInfo_B | (Unless region changing, there should only be one.)



    Once you have all those in place,
    • While hovering on (highlighting white) [1:] SYSNAND CTRNAND, hold (R)-shoulder and press (A) → Fix CMACs for drive<A> yes → button combo → <A> yes → button combo → <A> to continue → <A> yes.

    Fix CMACs for drive.

    If the o3DSXL still crashes, you'll need to test for softbrick caused by a "gamecoin"-type bug. Do this by temporarily renaming the folder,
    • [1:] SYSNAND CTRNAND/data[1:] SYSNAND CTRNAND/data_

    If this bug is in the real data_ folder, the o3DSXL should successfully boot and try to create a new user profile on the dummy data like this.

    gamecoin brick test.
     
    Last edited by TurdPooCharger, Jun 11, 2019
  14. PizzaYandere37
    OP

    PizzaYandere37 Member

    Newcomer
    1
    Jan 21, 2017
    France
    movable.sed: unique, no problem
    SecureInfo_A: unique, no problem
    LocalFriendCodeSeed_B:unique but full of 00
    HWCAL0: not unique, same on both consoles, is it a problem ?
    HWCAL1: not unique, same on both consoles, is it a problem ?
    o3DS XL still crashes after renaming data folder in SYSNAND CTRNAND
     
  15. TurdPooCharger

    TurdPooCharger Meh.

    Member
    12
    Jan 1, 2018
    United States
    Not borrowed from the o3DS, right?

    On the o3DS,
    • GodMode9 → 1:/private/movable.sedShow in Hexeditor
    Cross compare the movable.sed files between o3DSXL and o3DS. Make sure the outlined LFCS_B sections are different between the two.

    Does this one has the o3DSXL's serial number, and is the 0x100 region code correct? Is your o3DSXL natively EUR?

    This is bad. That means the o3DSXL's original LFCS_B wasn't properly backed up in its essential.exefs. This can be fixed depending if the o3DSXL's movable.sed is intact.

    If your o3DSXL's movable.sed is different than the one in the o3DS, you can recreate the LFCS_B with HxD hexeditor. Copy the block 0x008-117 (hex length of 0x110) and save it as new file. Refer to the diagram in posts #7 & #13.

    The HWCAL0.DAt and HWCAL1.DAt look similiar to another one.

    To check if they're exactly the same,
    • Press (A) on HWCAL0.DAtCalculate SHA-256.
    • Do the same thing for HWCAL1.DAt.
    Write down the hash values for both HWCAL0 and HWCAL1. Compare the hashes you get against the o3DS versions.

    If you copied, renamed, and pasted these files from the essential.exefs over to the 1:/ro/sys, they should be the correct ones.


    Edit - Can you clarify that the o3DSXL's HWCAL0.DAt and HWCAL1.DAt aren't all zeros (00) at their tops? Do they have the "CCAL" magic header?


    Okay, that means you don't have "gamecoin" brick.

    Did you already try the Fix CMACs for drive?
     
    Last edited by TurdPooCharger, Jun 11, 2019
  16. PizzaYandere37
    OP

    PizzaYandere37 Member

    Newcomer
    1
    Jan 21, 2017
    France
    Both movable.sed are different
    There is not serial number in the SecureInfo_A but the o3DS XL is natively european as I checked the serial number on the back
    For the LocalFriendCodeSeed_B, I must admit I didn't really understood what you told
    HWCAL0.DAt and HWCAL1.DAt files SHA-256 calculations on both consoles are different, which is good (?)
    HWCAL0.DAt and HWCAL1.DAt files don't have only 00 at their top from line 00000000 to line 00000028 (which, in the common of mortals, are line 1 to line 6)
     
  17. TurdPooCharger

    TurdPooCharger Meh.

    Member
    12
    Jan 1, 2018
    United States
    Good. It needs to be this way. :yay:

    Look closer in the diagram's red box & line. The example SecureInfo_A has the Serial Number SEH11397059.

    The o3DSXL's serial number from the back cover plate should equal the one in the SecureInfo_A.

    See the diagram's yellow box & line. The [ 35 6C 31 F2 65 ...... 1A DD 02 00 00 00 ] from the LocalFriendCodeSeed_B is also found inside the movable.sed.

    The o3DSXL's LFCS_B is not supposed to be blank or filled with all zeros [ 00 00 00 ... 00 00 00 ]. You can recreate the LFCS_B by copying it from movable.sed with desktop computer hex editor (see HxD program).

    Yes, this is good. This means you restored the o3DSXL's good copies of the HWCAL0 and HWCAL1.

    ***

    In the [1:] SYSNAND CTRNAND,
    1. Delete the dummy data folder.
    2. Rename the real data_ folder back to data folder.

    ***

    This error is commonly caused by mismatching CMACs for the files found in the data & dbs folders, and the movable.sed. Another possible cause is corruption in one of those files.

    I'm really confused on why your o3DSXL is still bricked if you used my script's CTRTransfer (Type D9). :(

    Would you be interested in having your NAND images troubleshooted on my nephew's o2DS?

    To learn about this method, read this thread (posts #14-16):
    Our discussion would have to continue by private message (PM)... :mellow:
    Not to surprise you with REAL cost and inconvenience, you'll have to "airship" your o3DSXL to my place with prepaid return label.


     
    Last edited by TurdPooCharger, Jun 11, 2019
  18. PizzaYandere37
    OP

    PizzaYandere37 Member

    Newcomer
    1
    Jan 21, 2017
    France
    I'm sorry but I'm not sending my o3DSXL anywhere, It's not I don't trust you but it's just that I do not like the idea
     
  19. TurdPooCharger

    TurdPooCharger Meh.

    Member
    12
    Jan 1, 2018
    United States
    I know English is not your main language but read deeper.

    Edit - Nevermind. I believe you understood the actual cost of "air shipping". I have nothing left to offer.

    For further assistance with debugging the firmware,
     
    Last edited by TurdPooCharger, Jun 12, 2019
  20. PizzaYandere37
    OP

    PizzaYandere37 Member

    Newcomer
    1
    Jan 21, 2017
    France
    are you sure you have nothing left ? I mean, if there is this much good thing in my 3ds files, it should be ok, no?
     
Quick Reply
Draft saved Draft deleted
Loading...