Xtreme firmware detection

[MacDennis]

thats exactally the point i was trying to get as well. it pains me to hear everyone saying this hack is going to be short lived...

Exactly, THIS hack is short lived.

You are missing the point, this thread is about the current Xtreme firmware. Which IS short lived.

sure the video is missing from some peoples back-ups, we can burn the video from now on. as well, we can spoof the physical format info and everything else microsoft wants (heck im sure we can even embed a completly original firmware in the iso and then it would be possible to return a perfectly original firmware... there would be no way for microsoft to detect this whatsoever, as the system was not designed to do this, we know this from reversing the firmware in the first place. im sick of the negitive attitudes ive been hearing all over this forum,

You are completely missing the point. This thread is about the CURRENT Xtreme firmware hack.

we should be fixing these problems now not just talking about them.

Ok, which solutions to the mentioned problems do you have so far?

i dont think microsoft can do anything, how much could you modify that firmware without damaging compatibilty of older pre hack titles? ...

Agreed. But again, that's not the point.

[elitedev]

whatever dude.

[MacDennis]

The topic of the thread is EXTREME FW detection, I believe McD was looking to address issues with the Extreme FW, since that is all that exists publicly.
It pains me to here all the WE can do this and WE can do that when in fact only C4E has proven his ability to address problems like this, and share the results. This board is now riddled with babies looking for a handout and mindless speculation about what's coming next.

Thank you Tiros. I couldn't have said it any better. Too bad many people think they are suddenly a 'hacker' after flashing a patched firmware to a dvd-rom drive. But that's not the point of this thread is it?  The points mentioned so far can be solved but it takes more time, energy, skill and above all a new firmware and fresh backups. Fact remains, the current backups for this firmware will be useless soon. Let's see who has a negative attitude then shall we?

@elitedev: is it so hard to READ a topic title? sheesh man ..

[elitedev]

okay.

[slider123456]

Could M$ do something similar to what sony did to stop new backups from working?

[MacDennis]

Could M$ do something similar to what sony did to stop new backups from working?

Yes.

"Disc main executable can in theory perform checks and probably will actually have them in the near future which also can't be patched .."

[Dzgx216]

I think MS is going to use the forced update approach.  The Dashboard will prompt for an update and not let you on live if you don't update it.  Then when you buy a new game, you'll need to update to play it.  They can force the updates on you eventually, or you're just stuck with a console that can only play gen 1 games.

  The real question being: What checks will they use.  MacDennis, I liked your ideas up on the first part of the thread.  I didn't use dvdinfo pro for this, I simply used one of my RAM dumps from the hitachi drive.  I just love that it spells out RITEK D01 in the ascii column.

  Another interesting thing to look is is not only WHAT they're going to check, but HOW they're going to check it?  For example, if they request the PFI are they going to send a command to the drive to use its existing PFI read routine again at a random time, pull what is already in the drives RAM or send a command to read the specific sector and report to the console its direct findings?  In order to spoof a result, we'd need to know what command is coming from the console and to figure out what command is being sent, we need a good understanding of what commands are sent currently and when/what order they're sent it.

   Another thought had occurred to me.  Robinsod mentioned in his post on the C/R protocol that type 2 challenges and responses existed, yet he had never seen one.  He continued to theorize that they might be broken. I assume it is also a possibility that they are lying dormant, and might become active in a later kernel version.

  My last and final productive thought for the day (The rest of my thoughts today will revolve around beer, pizza, money and vaginas)  Obviously we're not observing the actual C/R process here to get values for type 5/7 responses and the rest of the response table for that matter.  I'm assuming it is possible to "Duplicate" the read across whichever PSN's during the backup creation process, but I don't see any CPR_MAI in my SS for generating the rest of the response table.  Unless of course there's a routine in the FW that brute-forces the cpr_mai but I don't believe that there is enough information present to brute force it either.  An understanding of how the response table is being generated is crucial to understanding how to manipulate the hack further in order to make it adaptable.

[xboxleech]

Not exactly applicable to this firmware...but im pretty sure the hacked firmware will be modified to allow dvds with booktype dvd-/+r dvd+/-rw as oppose to making people just use "dvd-rom". This could be a simple check by ms.

Oh, everyone thinking ms might not implement checks, if they do, i would imagine they would implement them one at a time, in increasing/decreasing sophistication in order to nail as many people on live as possible. That would have the greatest impact and discourage people from using backups, particularly on live. People wouldnt be willing to risk it as they know future checks are gonna come out!

[stonersmurf]

Aren't you guys forgeting the true purpose of this hack, now that we have total access to the filesystem of over 50 games for the 360 plus xbox1 games, its time to find a true expliot to allows us to run unsign code. I don't really care about the games and if they update and we can't play the new ones. Maybe some of you do but thats not why most of us are here. I don't get joy from playing games, most of the joy is from fouling the system into playing those games.
But if I was to speculate what microsoft would do they would just simply dump the kernel from the dvd-drives ram and checksum it. Very simple and no need to rework a new Disc securety system that would cost way to much money. And we all know that ms would never do that. My guess is also all new 360 will come with read only chips in the dvd-drive, theres no need to upgrade the firmware on our side. And in my opion it was a big mistake to use a flash that was writeable.

Edit: Sorry if its alittle of topic but just seening if were all on the same page here.

[Dzgx216]

Stonersmurf,

        Agreed, the real goal is to hijack the system bios   However, It's fun to speculate a bit on the process eh?  I had so much fun speculating that I'm late going back to work on my lunch break.  Let's keep on topic though.

[Joergen]

What comes to non-flashable chips, you have to remember MS has to couple each drive to the corresponding motherboard with their unique keys. So unless they change the security of the 360 so the drives dont need unique keys anymore, they cant use solid state chips Though I bet theyd rather have us swap our drives than pirating their games, choises choises.

[xboxleech]

People keep talking about requesting things like the video partition or such other obvious things. However, if an xex knew what data was stored at an exact location (different location for each game) on an orignal disc, this would stop us from spoofing any ms request unless we could either make an exact replica of the original game or have some consistent offset between an original and a backup.

Not sure thats clear. Say for example an xex knew xyz was stored at some position 5 on an original disc. The xex could instruct the drive to read and return that value. If it did not match then the game is a copy. Since the position and data the xex looks for could be different for each game, we would have a hard time patching this.

I also think the idea about the x360 dumping the firmware and checksumming it sounds pheasible, althought not sure how long it would take, plus it could be spoofed. Also, it would mean leaving commands in future drives that enable users to dump the firmware so not quite sure about this.

To me that answer is pretty much this, ms have to check the contents of the disc, not the firmware, since this is harder to spoof, particularly if they can start using that bca.

[MacDennis]

People keep talking about requesting things like the video partition or such other obvious things. However, if an xex knew what data was stored at an exact location (different location for each game) on an orignal disc, this would stop us from spoofing any ms request unless we could either make an exact replica of the original game or have some consistent offset between an original and a backup.

If you are talking about sectors, the XEX can only request data from the game partition after unlocking of the drive. Thing is, the dumps are 1:1 RAW dumps of the game partition. All data in that dump is at the exact location.

Everyone seems to forget that the console ALREADY sends a command which can be used to verify the disc. Again, the command which returns the physical format data. This data screams to the console: 'I'm a copy, I'm a copy!'. Kernel / dashboard and game can issue this command and check the results. This is the first thing they will probably do, check the contents of this data. Easy, fast and 100% detection of the current hack.

I'm curious to know the which data is returned when you issue this command. Can someone dump this? You can use DvdInfoPro, advanced commands > physical format information.

[fasttrack]

I also think the idea about the x360 dumping the firmware and checksumming it sounds pheasible, althought not sure how long it would take, plus it could be spoofed. Also, it would mean leaving commands in future drives that enable users to dump the firmware so not quite sure about this.

To me that answer is pretty much this, ms have to check the contents of the disc, not the firmware, since this is harder to spoof, particularly if they can start using that bca.

This is something I've never understood, how can you spoof the checksum of the fimware?

I thought that firmware updates were performed via another controller chip, like the MTK on the Sammy - which isn't compromised - not via the firmware itself - which is?

If the controller isn't compromised then there is no way to bypass what is returned unless maybe you had some sort of modification to say the MTK chipset itself, ie a piggyback that would read and write to a separate firmware chip whenever any firmware requests are passed?

Or are the Hitachi and Samsung drives totally different in this sense?

Noticed that you can brick the Hitachi easily when changing versions due to flashing blocks in the incorrect order etc, so would it be correct to assume that in that particular instance the firmware itself does control what is input / output? If so is there no controller chip that could be used to flash the firmware on that model?

I'm confused lol, any help greatly appreciated

[xboxleech]

If you are talking about sectors, the XEX can only request data from the game partition after unlocking of the drive. Thing is, the dumps are 1:1 RAW dumps of the game partition. All data in that dump is at the exact location.

MacDennis, I was under the impression that the position of the ss meant that the data was not exactly the same, but your in a position to know better. Also, even though the dump is a 1:1, is the binary still burned in exactly the same position on the disc? I.e. since the ss is placed on the disc on the first layer (i think?) wouldnt this "shift" everything along, if that makes sense?

This is something I've never understood, how can you spoof the checksum of the fimware?

fasttrack, i was thinking more along the lines of storing an exact copy of the original fw somewhere and then sending that to be checksummed. However, each fw would have a different checksum due to the drives key. This would mean the checksum would need to be calculated before the drive left the factory and stored somewhere? I dont see ms doing this tbh.

[uberfry]

i don't know if this has been discussed before, but does the x360 ask for SS using a special command or does it ask to read PSN FD021E?

edit: nevermind, it wouldn't make sense that the value FD021E is in the fw
so it's possible that a newer firmware will actually read the sector instead of doing the other command
but still, that could be bypassed using a simple compare, then redirecting to the correct SS (on the backup)

[MacDennis]

MacDennis, I was under the impression that the position of the ss meant that the data was not exactly the same, but your in a position to know better. Also, even though the dump is a 1:1, is the binary still burned in exactly the same position on the disc? I.e. since the ss is placed on the disc on the first layer (i think?) wouldnt this "shift" everything along, if that makes sense?

The SS data is placed in an existing sector, between video and game partition on layer 0. Nothing is shifted, the SS is placed in an empty (unused) sector. The game data stays exactly the same.

fasttrack, i was thinking more along the lines of storing an exact copy of the original fw somewhere and then sending that to be checksummed. However, each fw would have a different checksum due to the drives key. This would mean the checksum would need to be calculated before the drive left the factory and stored somewhere? I dont see ms doing this tbh.

There are numerous ways in how the current firmware can be improved. But that's something for another thread.

[MacDennis]

i don't know if this has been discussed before, but does the x360 ask for SS using a special command or does it ask to read PSN FD021E?

Yes, a special command. Security sector PSN FD021E is automatically read amongst other things by the firmware when you insert a disc.

so it's possible that a newer firmware will actually read the sector instead of doing the other command
but still, that could be bypassed using a simple compare, then redirecting to the correct SS (on the backup)

The firmware already reads the sector. No need to do this at a later stage. And if they do, change the hardcoded references to this sector again.

[Geremia]

Everyone seems to forget that the console ALREADY sends a command which can be used to verify the disc. Again, the command which returns the physical format data. This data screams to the console: 'I'm a copy, I'm a copy!'. Kernel / dashboard and game can issue this command and check the results. This is the first thing they will probably do, check the contents of this data. Easy, fast and 100% detection of the current hack.

I'm curious to know the which data is returned when you issue this command. Can someone dump this? You can use DvdInfoPro, advanced commands > physical format information.

At least with 0800 fw it reports the real phisical format information, and i suppose also the xtreme fw does.

00000000 08 02 00 00 01 0F 31 10 00 03 00 00 00 FC FF FF ......1.........
00000010 00 21 7D BF 00 00 00 52 49 54 45 4B 00 00 00 44 .!}....RITEK...D
00000020 30 31 01 40 25 25 37 0C 00 28 64 00 28 64 20 1F 01.@%%7..(d.(d .
00000030 0C 0C 14 14 02 01 01 20 00 20 1F 0C 0C 14 14 02 ....... . ......
00000040 01 01 20 00 00 00 00 00 00 00 00 00 00 00 00 00 .. .............

Also the disk manufacturing information can report a backupinside
this is taken from PGR3

00000000 08 02 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................
00000010 00 00 00 00 00 80 0E 4C 07 93 C5 01 02 00 00 00 .......L........
00000020 00 00 00 00 C9 CC 6D 5D 5B DD 86 48 38 BF 6D 69 ......m][..H8.mi
00000030 75 52 8D 49 00 00 00 00 00 00 00 00 00 00 00 00 uR.I............
00000040 00 00 00 00 4D 53 32 30 30 31 30 34 45 30 58 31 ....MS200104E0X1
00000050 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1...............

Anyway these info are readed from the leadin, they are already dumpable with 0800 fw at LBA -3584 and -3585 (- is minus), so it would be not so difficult for skilled hackers to redirect 2F200 and 2F201 to somewhere in safa area, like the space between the end of video layer0 and start of game layer0, this way you can fake the disk you like.
I already tried to simply hexedit the fw and change 2F200 to 3F200 but doesn't affect anything

[Feflicker]

Ok, we all know there are ways to determine if a disc is pressed or not. The real question is: Why hasn't a game company (or any other) ever enforced a security check based on this lead-in type disc information? I think the answer is that it isn't very practical to maintain a database of this information, and not foolproof either... You'd be spending money on a quick fix, that would change much of your processes and cost $ to implement. Also, during development they rarely know this information about what the final disc will be. I mean, they just develop the game. Someone else sends it to get duplicated, and I am sure it is up to the publisher which company does it, etc...

As far as checking video data, I don't see that either. What if your disc is scratched on the video partition? Now you can't play the GAME!? I mean it's possible, and I know that is really what the thread is about, but I don't see it as probable. Especially since we could just inject the proper video partition into our ISO's and be back up and running in like 2 hours. That is a waste of reasearch $ for MS$, think about it. It's a business, they want to plan and spend $ wisely.

@fastrack: I agree, I thought about that too. You can't really spoof a checksum, if the controller reads the entire firmware and calculates it, it calculates it. You'd have to hack the controller to report the valid checksum, probably not happening! But as also mentioned, each drive has it's own checksum, since each firmare is unique to the drive/mobo marriage. Checksum verification is also unlikely imo.

I highly doubt we will ever see MS$ flashing our drive firmware either. This isn't a PSP. The PSP was designed to have firmware upgrades, it was planned all along (they were unlocking new functionality, etc). TOO MUCH RISK for MS$ to start flashing DVD firmware "just incase". They'd rather just flag you and ban you from Live. Look at their track record. They are mainly worried about protecting Live, not stopping backup execution. If they were worried about backups, they would have implemented some of these very ideas about disc validity in the Xbox1 (most of this speculation was possible even on Xbox1)! They also will not change the flash chips on new drives, they need the flash, they have to "marry" the drives to the mobos, chip needs to be writeable!

We are talking about MS$ putting more time/$/security against things that have been in the ATA/IDE specs for years. If they implemented more security via this route, they'd just be asking for another hacker to expose the flaws in this underlying PC technology. This tech was not designed for security! I'm betting they don't even bother, and just block Live access...

One thing we do know. The expected Live update is LATE. MS$ is usually good about releasing on time, so my guess is that they are working on "last minute additions"  It's unclear if MS$ can find a way to permanently block playing backups. However, we know they can annoy the hell out of us by making us change little things here and there in our firmware/ISO's and thus voiding any burned backups we already had in our possession (I think they are more worried about Live than annoying hackers though).