Corrupted Cartridge Fixer Release

[Ternias]

@skawo I think I must have confused the buttons and ran the verify which errored.
I have been running the 100times version for ~5 times now and still crash after like 30 seconds in game.
I think some chunks might be problematic but I have no idea how many and if this is fixable.
Is there something like a log to evaluate the results after it finishes the restore action to check if it's worth continuing?
Or can I expect the game to be unrestorable if it still shows this behaviour after about 10 restore-runs?

The only reason I still have some hope is because it wouldn't boot at all before starting the first restore and I am able to open the game now and walk around for a little bit.

Hope you can shed some light on this, thanks a lot!!

 

[skawo]

If you hold Y when starting the process, it will save a log to gm9/out.
Try running the process twice and see if the amount of bad blocks decreases.

 

[madao3ds]

So I did try to fix corruption like 2-3 times now took like 24 hours and had to skip sometimes cuz it would get stuck. The game now boots but I get this error after loading save. I don’t care about previous owner save. If I have to do new game I can.(edit, I did and nothing changes I still get the error. When I try to verify I always get error)

 

[skawo]

Well, you can't just skip blocks if you want the game to work, sadly. As long as the hash is changing, it's doing something, and you may as well just let it run for a bit. If the thing truly gets stuck, then it'll skip it on its own.

 

[madao3ds]

Well, you can't just skip blocks if you want the game to work, sadly. As long as the hash is changing, it's doing something, and you may as well just let it run for a bit. If the thing truly gets stuck, then it'll skip it on its own.

I had one stuck (but the has was changing really slow like 3 per second and was there for like 5 hours) Okay now I will leave it as long as it takes then. The idea is to leave it be and maybe even have to do it multiple times on fix until verify runs with no problems ?

 

[skawo]

Sadly, yes. There's really not much to this, it just tries to bruteforce the fix, and there's a point where it either works, stops making any difference, or you give up :v

 

[Ternias]

Thanks for the tip!
I found 1475 unfixables in the first run, then 1465 and then 1365 so I'll just keep running it and see if something happens.

Thanks for your support!

 

[comokepa]

@skawoI am trying to fix a cartridge and the tool has been running for 12 hours with only 2% of the progress bar full. “Current” and “Expected” hashes keep changing so, as per the readme, I assume it is still doing its thing.

After a while, refresh count stops and hashes stay still. Redoing with button Y pressed produces the same result but no log is created at /gm9/out (even though an alert claiming it would be does appear before the process starts). Is that normal?

 

[skawo]

The log is only saved at the end of the process, unfortunately.
I'm... not exactly sure why what you describe could happen, aside from some kind of hard read error maybe...

 

[mikenigro]

should i just surrender ?

 

[skawo]

Oh, that's the exefs. I see the refresh count is really high, so I guess there might be some read issue as it's the first thing it really tries to read from the cart.

 

[mikenigro]

Oh, that's the exefs. I see the refresh count is really high, so I guess there might be some read issue as it's the first thing it really tries to read from the cart.

Should I leave it running as long as I can or ?

 

[skawo]

If the hash truly isn't moving, then I guess it might be a lost cause.

 

[mikenigro]

If the hash truly isn't moving, then I guess it might be a lost cause.

it does move every like, 4 or 5 seconds

 

[marioxbox]

if the current hash is changing but not the expected (it got to the exefs after the extension) after about 30+ hrs is it most likely dead?

 

[skawo]

it does move every like, 4 or 5 seconds

Well, in theory it is doing its thing then (EXEFS is a large file, so it takes a while to read back), but obviously if it's taking very long, then it might be a lost cause anyway.

if the current hash is changing but not the expected (it got to the exefs after the extension) after about 30+ hrs is it most likely dead?

Same here.

 

[marioxbox]

Is there a way to "force quit" safely or is the only option to either wait it out or (preferably not) hard power it off

 

[skawo]

You can just hold B IIRC

 

[comokepa]

The log is only saved at the end of the process, unfortunately.
I'm... not exactly sure why what you describe could happen, aside from some kind of hard read error maybe...

I tried reflowing the chip like in Voultar’s video, but no luck either. One doubt I have is whether the game data chip is actually being read or if I’m just seeing garbage data. The 3ds Home menu does not detect it being inserted, or no thumbnail is displayed at least. Your GodMode9 too shows no thumbnail when entering it. It does list files inside [C:] GAMECART, though:

• 0004000000132800_v00-priv.bin 80 Byte
• 0004000000132800_v00.3ds 1 GB
• 0004000000132800_v00.sav 512.0 kB
• 0004000000132800_v00.trim.3ds 554.2 MB
• 0004000000132800_v00.txt 245 Bye

Viewing 0004000000132800_v00.3ds in the hex editor does show garbled data, and viewing 0004000000132800_v00.txt in the Textviewer displays what I suppose is correct game info:

Title ID: 0004000000132800
Product Code: CTR-P-AYNP
Revision: 0
Cart ID: 9081FAAE
Plaform: O3DS
Save Type: SPI
Save chip ID: C22213
Padding byte: FF

The Title ID matches the game (Mario & Luigi - Paper Jam Bros. (EUR)).

 

[skawo]

No thumbnail etc would imply the even the banner itself is corrupted. If the reflow didn't work, then I guess the cart's a lost cause - just too heavily corrupted