juanii

Compare the red background wiring picture from your link with this one which screams FAKE everywhere. They didn't even put a black stroke around the big white "2". The photoshop in the V1.2S printed on the board is also very clumsy.

Does not surprise me, there's lots of knock offs, clones or whatever you want to call them around here. While googling for that picture, I noticed some boards with the v1.2 legend and the TX logo printed on the chip but some of them are clearly (and badly) photoshopped and others more carefully photoshopped, but fake anyway. The lack of documentation is also a strong sign that it's not genuine (there's no mention of the v1.2 in Team Xecuter web).

Yep. If what you mean by that is turning on the console while pressing the DVD eject button, I've tried. We also tried it yesterday. I'll send it over. I loaded it in xeBuild GUI but since it's a Corona 4G (which is not fully supported by the software) there are several checks that do not work. J-Runner loads it normally and I can see the KV and NAND info. AutoGG also loads it and displays all the information, with the previous remark about the "FakeKey". Yes, specifically it has DGX 1.2S printed on it, with the Team Xecuter logo, smaller than your picture's and to the left of the DGX legend. I didn't take a picture of it before dropping the console at the tech guy's, but it's very very similar to the one you posted and it has the metal pins for programming. Here's a picture I found on the internet and it's as I remember it so probably it's exactly the same.

Oh I get it, the point was the SMC was not a regular one. Before reading the article I thought it was just a regular NAND. Anyway, the glitch led blinking pattern doesn't look like the S-RGH I found in youtube. Mine is more like RGH2: a single blink, lasting a second or maybe a little less, every 5 seconds or so.

I'll read it, thanks. And I'm not sure if it's the same as what you're suggesting, but the guy already rebuilt a NAND from scratch using my CPUKey and a donor NAND. Are you talking about the same? Yes of course. I'd have to get in touch with the shop where I bought the console. I expressed my doubts about them keeping my original NAND, but the guy told me he always keeps backups in case a client wants to revert the RGH. He works for several shops that sell RGHd consoles but unfortunately not for the one where I bought mine. Anyway if it's common practice, maybe there's a chance…

I extracted the CPUKey myself before updating. To be completely sure I got it from XeLLReloaded, from the text file Simple NAND Flasher 1.4 saves in the disk and probably another method I can't recall now (Dashlaunch maybe). To be precise, AutoGG automatically extracted the CPUKey from the image and labeled the CPUKey field as "FakeKey" and painted it red. I could check it myself in my computer by downloading the latest AutoGG and feeding it my backup image. But as I mentioned before, I'm still not sure what it means, couldn't find it in the manual or forum posts talking about the "FakeKey". I know my console was booting on virtual eFuses (I think that's what the glitch2m does if I correctly read the xeBuild docs) but I don't know if it implies the CPUKey is faked. Anyway what I know is that the console was working fine using that backup NAND image. As for the DVDKey, I don't remember how (probably using XeLL) but I backed it up long time ago. None taken. Yes obviously creating a NAND from scratch it will necessarily match. But the mystery remains: why the 'original' NAND is reported as having a FakeKey and why flashing the re-created NAND doesn't fix the console. He did. He flashed XeLLReloaded and also the blaKCat version that comes with AutoGG. As always, the glitch board pulses a green light every 5 seconds or so, but the console won't boot. He's going to continue today, maybe he'll call me again and I'll be able to be there while he works on it.

TLDR: Even having the courage to solder the SD adapter I probably couldn't have fixed the console. A few hours spent in the service guy's garage but still nothing. He uses AutoGG and, upon loading the original NAND ("original" as in "before my update", not the retail of course) it reported a "Fake CPU key". He said it was bad, though I'm still not sure what it means since I couldn't find any documentation. He then re-created an image from a donor using the same CPUKey and AutoGG turned to green this time. New image flashed and… no glitch. He tried (a looong) full NAND erase and re-flashing the image but to no avail. Not sure what would happen by re-flashing the "original" (backup with the "Fake CPU Key") image, the guy says it's not worth it because it wouldn't work. He's gonna do some more tests, but suggested I try to find the retail NAND, uninstall the RGH and start again from scratch. So the story is still open ended. I'm also deeply hating Coronas.

Of course I didn't mean I'd lose the M$ warranty but the seller's warranty. In fact this glitch problem happened within the first year I had the console (and that time it wasn't me fiddling with it) and they repaired it at no cost. Unfortunately most sites selling CR4 won't ship to my country and if they did, the shipment would be more expensive than the board and I'd have to wait two weeks for delivery. A CR4 here is in the $60 - $65 range. If this guy can successfully flash my previous firmware I'm OK with that, boot times were not very stable but under 1 minunte 99% of the time. Thanks for your help

OK this seems to be far beyond my knowledge, I'll have to take the console to the service guy. I'd rather spend some bucks and get it working than fall into the temptation to solder the SD adapter/cable and completely ruin the board. There's one thing in my simple mental model that I still don't get: where is this glitch timing information stored? Is it in the RGH (or whathever) chip? Or is it in the NAND? If it's the latter case I'd expect the xeBuild firmware customization/patching to keep those settings exactly as in the original NAND dump… if it's the former, why does the console stop glitching? Is it because the bootloaders' code change and ruins the timings? That's something I thought about before updating my system, and a reason to try and assure the bootloader versions matched in the original and updated binaries. Hmm the console was advertised as having a CR4 when I bought it but since I couldn't open it without voiding the warranty I just recently learned that it's not really a CR4. Too late for any claims. Regards

Yep, I'm trying every day whenever I'm near the console, but never did the 5min unplug. I'll try it, thanks. I've just found a guy 3 blocks from home that does RGH so he'll be able to help if it doesn't boot anymore. I know it's off-topic but, is there something definitely wrong in the following xeBuild arguments for a Corona V4 4GB? Don't know if it's important, but when I teared the console down I could see a soldered board with "DGX v1.2S" printed on it, which I'm pretty sure is the RGH. The arguments are: -noenter -t glitch2m -r WB4G -a nointmu -c corona4g -f 17511 -b <redacted> -p <redacted> output.bin Thanks for your help.

Actually I did lots of research, read, payed attention, tried to think, asked questions in forums, read again and again for several weeks… I'm still a newbie and evidently I missed something, but probably if I'd just blindly followed the tutorials, the console would not have booted even once after the update. But it did, loaded Aurora, let me run Dashlaunch and confirm the new dashboard version was installed. I've been trying to boot it once again to flash the backup file but to no avail. I guess I'll need to re-flash it with a computer, but I'm not any good at soldering so I'll have to find someone to build me the SD card thing and solder to the mobo. Regards

But if I select glitch2 and tick CR4, the CB_A version in the updflash.bin is 13121, not 9188 as in the original flashdmp.bin. Also, Dashlaunch reported "Type: glitch2m" in the lower right corner of the screen before flashing the update. Can I safely use glitch2 with CR4 then? Thanks for your suggestion, Regards

Hello, I've updated my RGH'd Corona from dashboard version 2.0.17349.0 to 2.0.17511.0 using xeBuild GUI 2.099 (unofficial) and followed Swizzy's tutorial to create the update file[*]. Then I flashed the update using Simple NAND Flasher 1.4b. After the final reboot, the console took something like 2 minutes to glitch and finally boot, which is way longer than before (it used to boot in a few seconds). I checked the new dashboard version using Dashlaunch and it seemed that the update was successful. After that first boot I turned the console off and prepared a disk with the avatar files to finish the update process but now the console is not booting anymore, I guess because it's not glitching. There are no red lights or other failure indicators and, as stated before, the console successfully booted once after the update. Is there any chance that by updating the firmware I messed the glitch timing or something like that? Is there any way to fix it? Any help would be very much appreciated. [*] Also, I did some research of my own since while comparing the flash dump with the generated update file I noticed some discrepancies. In the dump, CB_A version was 9188 (and Dashlaunch reported the usage of Glitch2m) so I used -t glitch2m to create the update file. Also noticed that CB_B version was 13182 and found it was something related to the Winbond memory chips so I also used -r WB4G when creating the update file. After these adjustments, CB_A, CB_B, CD and CE all matched in the dump and update files, while CF and CG were updated from 17349 to 17551. Regards

The content.db file is inside the <aurora>\Data\Databases folder, where <aurora> is the folder where you installed the original Aurora package. If you installed it in an external hard drive it's easier to connect the drive to a computer, otherwise you can fetch the file through FTP. When I need a TU which is not in XboxUnity I usually google it specifically, so most of the time I get them from the first community forum in the results. But doing it for many games is too much work for me, that's why I'd love to find a source which at least lists the latest available TU for each title. Regards

I could finally get my hands on the database. Here's a query that will output TitleID, MediaID, BaseVersion[1], latest installed TU version[2] and the Title Name. Run it on the content.db file, if you don't have SQLite3 installed there's portable multiplatform software to do it, like SQLite Browser. SELECT printf("%X", I.TitleId) || ',' || printf("%X", I.MediaId) || ',' || I.BaseVersion || ',' || IFNULL(U.Version, '') || ',"' || REPLACE(I.TitleName, '"', '""') || '"' FROM ContentItems I LEFT OUTER JOIN TitleUpdates U ON I.TitleId = U.TitleId AND I.MediaId = U.MediaId AND I.BaseVersion = U.BaseVersion; Just out of curiosity, where do you check for available TU's? Is there an official feed or something? I recently wrote a scrapper to get all available XBLA DLCs for XM360 from the official marketplace and I would love to know if there's something similar for TU's. Since XboxUnity doesn't support huge files, I'm always missing the latest updates for some games. [1] Since you're using this to search for TU's, keep in mind that you must match not just the TitleID, but also the MediaID and BaseVersion of your games. [2] Only if the TU was installed through Aurora. For bigger TU's which you probably installed manually, this field might not be very helpful.