Jump to content
RealModScene
pelago

Examining a NAND image to determine retail/glitched, and other options

Recommended Posts

Hello. I'm new here.

I have had my Trinity modded with a CR4 XL and DemoN (dual NAND) and am just starting to investigate it.

Is it possible, given a NAND image (either one I dump myself using the DemoN USB interface, or provided to me from the installer) to determine whether the image is for retail or for glitched, and if for glitched, what options were used to build it?

  • Like 1

Share this post


Link to post
Share on other sites

Hello. I'm new here.

I have had my Trinity modded with a CR4 XL and DemoN (dual NAND) and am just starting to investigate it.

Is it possible, given a NAND image (either one I dump myself using the DemoN USB interface, or provided to me from the installer) to determine whether the image is for retail or for glitched, and if for glitched, what options were used to build it?

yes.. just load it into jrunner or xebuild.. of course you will need the CPU key for each nand..

as far as the options used when building it.. not really.. afaik.. maybe Swizzy would.. lolz

but glitched images are 2BL (A/B)9188, 4BL 9452

retail are 9231 across the board.. there might be other differences.. as these are trinity values.. phats have a different CB..

there used to be more info floating around.. but not these days..

simplest way would be just load it up in xebuild/jrunner and create a glitched/retail nand and compare the differences

  • Like 1

Share this post


Link to post
Share on other sites

The SMC is always patched for Glitched, that's the easiest way to check if it's glitch or retail, however... retail images can also contain a patched SMC (it still works fine)

As for the other settings, no there isn't a way you can tell which ones were used... if you use the built in updater in xeBuild/Dashlaunch it does know what additional patches where used, but other then that, there's nothing...

  • Like 2

Share this post


Link to post
Share on other sites

Thanks for the replies. I do have the CPU key and did load NANDs into J-Runner and XeBuild GUI, but I was not knowledgable and confused at what I was looking at.

For example, in J-Runner, in the top-right XeBuild section, it would have Glitch2 selected whether I loaded a retail NAND or a glitched NAND, rather than saying Retail for one and Glitch2 for the other. I'm guessing that section isn't saying what the NAND currently is, but what NAND you want to build. Similarly, XeBuild GUI had Freeboot (RGH 1.x) selected when loading both types of NAND, rather than one having Retail selected, but again, I guess that is asking what type of image I want to build.

Now I know more of what to look for, I see in J-Runner that my retail NAND says:

2BL(CB_A): 9231
2BL(CB_: 9231
4BL(CD):   9231
5BL(CE):   1888
6BL(CF) Patch 0: 17349    6BL(CF) Patch 1: 17150
7BL(CG) Patch 0: 17349    7BL(CG) Patch 1: 17150

whereas my glitched NAND says:

2BL(CB_A): 9188
2BL(CB_: 9188
4BL(CD):   9452
5BL(CE):   1888
6BL(CF) Patch 0: 17150    6BL(CF) Patch 1: 0
7BL(CG) Patch 0: 17150    7BL(CG) Patch 1: 

which matches what felida was saying (and also shows that I could upgrade to 17349 on the glitched NAND I guess).

I also now see, on the right-hand side of XeBuild GUI, under Motherboard information, that it says SMC Type: Retail or Glitch, which I guess is what Swizzy was saying above.

After some more prodding in XeBuild GUI, Tools, Image version check menu, I see that gives the same sort of info as J-Runner, which is great.

So, identifying Retail versus Glitched is easy enough, but there's still the problem of how to find out what specific glitch options were picked. I'm intrigued that the built-in updater knows what patches were used, as that would suggest there was a way by analysing the file. But does the updater really "know" what patches were used, or does it just work in such a way that it doesn't actually matter what patches were used, e.g. just updates different parts of the NAND unaffected by the patches?

 

Share this post


Link to post
Share on other sites

Thanks for the replies. I do have the CPU key and did load NANDs into J-Runner and XeBuild GUI, but I was not knowledgable and confused at what I was looking at.

For example, in J-Runner, in the top-right XeBuild section, it would have Glitch2 selected whether I loaded a retail NAND or a glitched NAND, rather than saying Retail for one and Glitch2 for the other. I'm guessing that section isn't saying what the NAND currently is, but what NAND you want to build. Similarly, XeBuild GUI had Freeboot (RGH 1.x) selected when loading both types of NAND, rather than one having Retail selected, but again, I guess that is asking what type of image I want to build.

Now I know more of what to look for, I see in J-Runner that my retail NAND says:

2BL(CB_A): 9231
2BL(CB_B): 9231
4BL(CD):   9231
5BL(CE):   1888
6BL(CF) Patch 0: 17349    6BL(CF) Patch 1: 17150
7BL(CG) Patch 0: 17349    7BL(CG) Patch 1: 17150
whereas my glitched NAND says:

2BL(CB_A): 9188
2BL(CB_B): 9188
4BL(CD):   9452
5BL(CE):   1888
6BL(CF) Patch 0: 17150    6BL(CF) Patch 1: 0
7BL(CG) Patch 0: 17150    7BL(CG) Patch 1: 
which matches what felida was saying (and also shows that I could upgrade to 17349 on the glitched NAND I guess).

I also now see, on the right-hand side of XeBuild GUI, under Motherboard information, that it says SMC Type: Retail or Glitch, which I guess is what Swizzy was saying above.

After some more prodding in XeBuild GUI, Tools, Image version check menu, I see that gives the same sort of info as J-Runner, which is great.

So, identifying Retail versus Glitched is easy enough, but there's still the problem of how to find out what specific glitch options were picked. I'm intrigued that the built-in updater knows what patches were used, as that would suggest there was a way by analysing the file. But does the updater really "know" what patches were used, or does it just work in such a way that it doesn't actually matter what patches were used, e.g. just updates different parts of the NAND unaffected by the patches?

It reads the patches which have been applied to know which ones were used, the info for that is stored in the idx file of each patches folder...

  • Like 1

Share this post


Link to post
Share on other sites

It reads the patches which have been applied to know which ones were used, the info for that is stored in the idx file of each patches folder...

Thanks. So does that mean that a program such as XeBuild GUI or something else could be made that would read the patches too, without having to use the update server?

Share this post


Link to post
Share on other sites

Thanks. So does that mean that a program such as XeBuild GUI or something else could be made that would read the patches too, without having to use the update server?

Yes, if one knows what to look for ;) i could probably speak with the team to get all the information needed to write such a tool... but... haven't got the time to work on it right now...

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...