pelago

Thanks. In that case I will do: Completely separate storage (including profile storage) between the two NANDs Pre-banned KV in glitched NAND (taken from http://www.realmodscene.com/index.php?/topic/3202-jtagrgh-how-to-build-a-new-nand-when-you-lost-everything/) noSShdd patch in glitched NAND liveblock in dashlaunch Different MAC address in glitched NAND (Maybe an equivalent to liveblock on router, just for the IP or MAC associated with the glitched NAND) Family settings to block Live in glitched NAND (not sure if that will stop Live Arcade and Indie games from starting up, does anyone know?)

Thank you very much for your work on XeBuild GUI, Swizzy! Rather than start a new thread, I'll report the little bug I noticed, which is only cosmetic. You've got the text "MAC Adress" when it should be "MAC Address".

Thanks for all replies. Interesting about how liveblock works, and how it might fail if the console has cached the DNS lookup already. Although I would have thought that switching NANDs (which requires a reboot) would have cleared any such cache, so I'm still not entirely clear why it should fail. Maybe a good extra protection would be to use your Internet router to block the relevant DNS addresses, rather than (or in addition to) liveblock in dashlaunch. If you gave your console different manual IP addresses in the different NANDs, you could set your router to only block the Xbox Live servers on the IP the console has while in the glitched NAND. Would that be more effective, or would it still suffer from the problem where the console somehow has already resolved the IP address? Any thoughts about how important it is to have a different MAC address, reset code, or DVD keys in the two NANDs?

Thanks. It would be good to see XeBuild open source too, but I understand you don't speak for Team xeBuild. I am a great believer in open source driving things forward (many eyes, etc.), and I don't think it would diminish Team xeBuild's input into the work. In the absence of XeBuild GUI yet being on github, what is your preferred issue reporting method. Email, as mentioned in the readme in the rar, or posts on this forum, or something else?

Thanks. That's good to know. What about the rest of it? Am I thinking on the right lines? Does Microsoft flag you for having an unofficial HDD installed while in retail? Is it better to edit a KV manually or use a pre-banned one? Is it a good idea to change MAC address in SMC in glitched? Anything else I should do?

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?

Swizzy: Thanks for making XeBuild GUI open source. I realise the source is supplied in a rar with the binary, but have you considered using github or similar to host it, and using their issue tracker and fork/pull-request system etc.? Am I right in saying that XeBuild itself is not open source?

Hi. I have just had my console modded with CR4 XL and a DemoN. I have a clean retail NAND which I'd like to use on Xbox Live, and a glitched NAND for homebrew etc. I want to have Internet access on the glitched NAND, for downloading title updates from Unity etc., but I won't ever intentionally try to take the glitched NAND on Live, as I'm not interested in stealth services or modded lobbies etc. I'm researching how to keep the retail NAND Live-safe. My console will be used by multiple people, some of which won't be clued up to all the reasons for keeping the glitched NAND off Live. I understand that there are multiple things that I can and should do. I will list them below and although it might look like a tutorial, I don't consider it to have that status, and I invite comment from anyone to say whether or not I'm on the right lines. Imagine every paragraph starts "Am I right in saying..." There are also some questions specifically asked below: 1, Separate profiles The least one should do is to have separate profiles for retail and glitched, as some homebrew apps may create achievements which you shouldn't have in retail, or make other changes to your profile which shouldn't be seen in retail. Of course, non-clued up people may choose the wrong profile, or use one from a USB stick from their own console or something, so this is not sufficient on its own. 2, Separate storage Even better, have completely separate storage for retail and glitched, removing the "wrong" storage when changing modes. This should greatly reduce the risk of picking the wrong profile, and also eliminates the possibility of Microsoft spotting files and folders on the storage that shouldn't be there, like homebrew. This doesn't stop all the risk of USB memory units shared between both NANDs. 3, Enhancements to separate storage If you flash your glitched NAND with the nosshdd (No Security Sector HDD) XeBuild option, your glitched NAND won't read official Microsoft HDDs. Use an unofficial HDD instead while using the glitched NAND. This means that, if you forget to change storage and leave your Microsoft HDD inside while in glitched NAND, the glitched NAND won't be able to read it and so won't accidentally make changes to it. Similarly, if you forget to remove the unofficial HDD while in retail NAND, the retail NAND won't be able to read it and report anomolies to Microsoft. Again, this doesn't stop risks from USB memory units. Question about this: Does Microsoft flag you for having an unofficial HDD installed while in retail? Bonus points for using relays to change storage automatically based on current mode. 4, Liveblock The glitched NAND should have liveblock enabled in dashlaunch. This should stop the glitched NAND from contacting Live servers, although it doesn't always work 100%. Question about this: Am I right in saying this doesn't always work 100%? Does anyone know why it sometimes doesn't work? 5, Family settings Use family settings in the glitched NAND to stop connections to Live. 6, Separate KVs (keyvaults) This is the biggy, and should be the last defence against getting your retail NAND Live-banned if any of the above things fail. You should have a different KV in glitched and retail NAND, the KV storing things such as a console ID and serial number. Ideally, the KV in the glitched NAND should be someone's KV that has already been Live-banned. This way, if for some reason your glitched NAND ever gets on Live, only the glitched NAND KV will be banned (or be banned already), your retail NAND should still be fine. Questions about this: Is it better to just edit the KV manually, i.e. changing the console ID and serial number to something random, or specifically using a real KV from an already banned NAND (after changing the DVD key back to match your one)? Is it really sufficient to change the KV, or can Microsoft pick up other things that make them know that the two NANDs are from the same console and ban the retail NAND anyway? The obvious things to me that don't change if you change KVs are the CPU key, DVD key, and also things in SMC such as the MAC address or reset code. Clearly one cannot change the CPU key, and it may the case that retail code that Microsoft can run cannot determine the CPU key anyway. One also cannot change the DVD key, unless you want to go into the trouble of having different DVD drives between the two NANDs. You could have a different MAC address in the glitched NAND, editing it in J-Runner or XeBuild GUI. The reset code also may be editable - does anyone know? Is this a risk and should one change those things that one can, and is there anything else in the NAND one should change to keep safe? What about Wi-Fi SSIDs? Two NANDs connecting to the same Wi-Fi SSID in itself doesn't mean it's the same console (as it could be two consoles in the same household), but it may be additional evidence for Microsoft. Do Microsoft ever do IP address bans? I have a fixed WAN IP so this might be a worry, as even if they don't ban the console itself, an IP ban would be just as effective. Thanks in advance for anyone's input.

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?

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?