pelago 7 Posted July 4, 2015 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? 1 Quote Share this post Link to post Share on other sites
felida 1653 Posted July 4, 2015 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 1 Quote Share this post Link to post Share on other sites
Swizzy 2085 Posted July 5, 2015 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... 2 Quote Share this post Link to post Share on other sites
pelago 7 Posted July 12, 2015 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? Â Quote Share this post Link to post Share on other sites
Swizzy 2085 Posted July 12, 2015 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? 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... 1 Quote Share this post Link to post Share on other sites
pelago 7 Posted July 12, 2015 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? Quote Share this post Link to post Share on other sites
Swizzy 2085 Posted July 12, 2015 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... 1 Quote Share this post Link to post Share on other sites