XboxHacker BBS
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
April 16, 2014, 09:13:24 AM


Login with username, password and session length


Pages: 1
  Print  
Author Topic: SSv1 versus SSv2 (potential Kreon flaws)  (Read 21802 times)
Zak
Member
**
Posts: 22


View Profile
« on: January 21, 2010, 09:33:51 AM »

There seems to be a lot of confusion in the scene concerning the use of SSv2 over SSv1, so I decided to create a thread dedicated to the topic.

Right now, even c4eva seems unsure which SSv1 disks are fine and which are dangerous.
I am not an expert on this topic so please correct me when I write something untrue.

Here is what Abgx360's quickstart text about SSv2 explains:
http://pastebin.com/f1e0c6147

According to this, there are three sorts of SS:
1) SSv1 ripped by Kreon firmware
2) SSv1 ripped by old 0800 360 firmware
3) SSv2 ripped by new 0800 360 firmware (>1.60 afaik)

There is no dispute that Type 3 is safe.
According to c4eva, Type 2 is also safe but indistinguishable from Type 1.

The questions arise when it comes to Type 1 :
Since PC drives lack the capability to read angles, Kreon firmware only simulates them whereas 0800 does actual angle readings (multiple in case of SSv2). c4eva seems to believe that this is acceptable for Wave 1 and Wave 2 games but (for some reason) not for Wave 3 and above.

I can only speculate what his reasons for that assumption are.
My two theories:

A) He is afraid that the case mentioned in Abgx360's ("If a game was intentionally or accidentally mastered with one or more angles that deviated far from their CCRT targets, it would need to be ripped with a drive that does actual angle measurements in order to mimic the original disc's responses") will occur soon or has already occurred. Since Wave 3 games are still newly released, they might be affected by this.

B) Something changed on newer disks that makes the fake Kreon readings stand out.

I hope some of you can fill in the gaps of my analysis. Depending on the outcome of this analysis, it might make sense to change Abgx360 so that it only accepts SSv2 from now on and prefers/forces SSv2 over SSv1 when autofixing.

I'm looking forward to a constructive discussion to put this issue to rest once and for all.

Update 1:
According to Romps from #stealth360 scenario B) seems to be correct. Wave3 and onwards will rarely return angle 359 when ripped on a 360 drive. However when ripping on Kreon that value can happen more frequently apparently.
This would explain why c4eva only warned against Kreon rips from Wave 3 and above, not against SSv1 in general. It would also explain why SSv2 is only "preferred" since MS is unlikely to use heuristical/statistical differences as ban reasons.
Again take this with a grain of salt until someone with more knowledge confirms it.

Update 2:
Here's an old post where Kreon defends his firmware and that explains the problem with kreon fw a litte better.
http://www.xboxhacker.org/index.php?topic=11927.msg77960#msg77960
« Last Edit: January 23, 2010, 06:48:50 PM by Zak » Logged
me2611
Newbie
*
Posts: 6


View Profile
« Reply #1 on: January 21, 2010, 09:47:48 AM »

I would like some info on this also.

I have Vancouver 2010 witch is wave 4 but is SSv1

and bayonetta witch is wave 3 and is SSv1

All is green in ABGX and SplitVid is Valid.

Are these good to go on LT or is Only SSv2 wave 3-4 safe and Wave 1-2 SSV1?

Would love to hear more on this as i want to play some games on my newly flashed LT console.

Thanks
Logged
jelle2503
Xbox Hacker
*****
Posts: 1686


elitist prick


View Profile
« Reply #2 on: January 21, 2010, 10:02:52 AM »

does it even matter? you will never be safe on live and LT will get you banned if not this summer it'll be next december. please stop pretending you can do something about it to prevent a ban and be "safe" on xboxlive with a hacked firmware (same goes for the 20 previous firmware versions)

hacked fw + safe + xboxlive = no go
Logged

*
me2611
Newbie
*
Posts: 6


View Profile
« Reply #3 on: January 21, 2010, 10:14:25 AM »

At least you can try and make yourself that "little" bit safer lol.

Am just not sure witch SSv1 & SSv2 games are "Safer" to play online with LT
Logged
baberg
Member
**
Posts: 13


View Profile
« Reply #4 on: January 21, 2010, 03:01:52 PM »

Am just not sure witch SSv1 & SSv2 games are "Safer" to play online with LT
1) You are never safe.  Ever.  Stop thinking that you'll be safe on XBL and just enjoy whatever time you get.

2) If you're unsure whether your SSv1 disk is good or not, then you should just re-rip the game using a 0800 360 drive with iXtreme 1.61.  Yeah, it'll burn through DL discs but it's as "safe" as you can be

EDIT: Back on topic of the thread, you've got it nailed as I understand it.  Your suggested change to ABGX360 would require the re-rip and re-verification of every game ripped before 1.61 came out with the possible exception of Wave 1/2.  Looks like 1.61 came out in mid-May 2009.  According to ABGX360.net...

Wave 3 - More than 50 games, first mention I see on Google about Wave 3 is March 3rd talking about how to patch them for use on iX 1.4
Wave 4 - 42 games, first of which was on Oct 21, 2009. 
Wave 5 - L4D2, November 20, 2009
Wave 6 - Army of Two: 40 Days, January 17th 2010

So the biggest potential (if we ignore Wave 1/2, which we probably shouldn't) is the plethora of 2009 games that have Wave 3 video and were either ripped with a Kreon drive or ripped before 0800 was released.  That's going to be a lot of titles.

I'd think a good "first step" would be to change ABGX360 to warn about SSv1 any time it's encountered.
« Last Edit: January 21, 2010, 03:13:01 PM by baberg » Logged
lenselijer
Master Hacker
****
Posts: 138


View Profile
« Reply #5 on: January 21, 2010, 03:04:30 PM »

how can i force abgx to get a ssv2 from the database, i can only rip ssv1 with my kreon drive Sad
Logged
Coniger12
Master Hacker
****
Posts: 148


View Profile
« Reply #6 on: January 21, 2010, 03:12:43 PM »

Try altering the .iso with a hex editor. Not sure if abgx360 would want to mess with a ssv2, have to look at the source again.

As of now kreons don't have much of a future. No amazing discovery to get those drive to read the angles will happen.
Logged

I like being the only person to rip from Lite-Ons using uxrip360.
lenselijer
Master Hacker
****
Posts: 138


View Profile
« Reply #7 on: January 21, 2010, 05:40:42 PM »

i used xbox backup creator to inject the ss file of another game.

now abgx downloads a new ss from the database, but i still get alot ssv1

It seems only the latest games have a ssv2 file uploaded in the abgx database.
Logged
ATHEiST
Member
**
Posts: 47


View Profile
« Reply #8 on: January 21, 2010, 07:28:27 PM »

i used xbox backup creator to inject the ss file of another game.

now abgx downloads a new ss from the database, but i still get alot ssv1

It seems only the latest games have a ssv2 file uploaded in the abgx database.


Thats because abgx360 randomly chooses a validated SS etc, Hopefully in the next update to abgx360 it will contain a option to prefer ssv2 if its exists in db.
Logged
Zak
Member
**
Posts: 22


View Profile
« Reply #9 on: January 22, 2010, 05:42:09 AM »

Yes, abgx360 should prefer SSv2.
However I did some Stealth-DB digging and found out that this is going to require some DB cleanup and restructuring because it currently treats SSv1 and SSv2 exactly the same.

I'll explain by showing what abgx360 does for MW2:
If no/wrong SS is found, it loads the Xex_<XexCRC>.ini:
http://abgx360.net/Apps/verified/Xex_1F46C35A.ini

This file references 8 verified SS CRC's (not RAW SS CRC) of which abgx360 chooses one randomly.

It then downloads the corresponding <SSCRC><XexCRC>.ini files, for example the fourth one:
http://abgx360.net/Apps/verified/F935F56E1F46C35A.ini
The ini files for the last four <SSCRC> claim that they were ripped on Kreon, meaning the SS referenced in them should be SSv1.

When I downloaded the SS.bin files mentioned in these ini files (for example http://abgx360.net/Apps/StealthFiles/SS_F935F56E.bin ) , I noticed two interesting things:

1) The Raw SS CRC does often mismatch between ini and file. I believe this is by design but it means that you cannot blindly trust the ini information regarding source drive that abgx360 outputs. Only if the shown RAW SS CRC happens to match the one stored in the DB you can be sure that you have the correct file.

2) I picked the above example for a reason: the ini claims the SS was made by a Kreon drive but the actual SS.bin in the DB is SSv2. This demonstrates that the DB mixes SSv1 and SSv2 completely. SSv1 can verify a matching SSv2 and vice versa, even if the SSv1 was made on a Kreon.

I really hope the DB maintainers had the foresight to keep the original SS.bin and .ini files submitted by the uploader. Otherwise a lot of good SSv1 files made on old 0800 drives would have to be thrown out since they might as well come from Kreon.
Logged
DarKStreetS
Newbie
*
Posts: 1


View Profile
« Reply #10 on: January 27, 2010, 09:58:56 AM »

Quote
2) I picked the above example for a reason: the ini claims the SS was made by a Kreon drive but the actual SS.bin in the DB is SSv2. This demonstrates that the DB mixes SSv1 and SSv2 completely. SSv1 can verify a matching SSv2 and vice versa, even if the SSv1 was made on a Kreon.

I'm sorry if I am sounding like a noob, but if I understood you corectly, do you mean that SS.bin's in the abgx database are wrong? For example a SSv2.bin can well a SSv1.bin? I am really confused Smiley

Thanks.
Logged
Zak
Member
**
Posts: 22


View Profile
« Reply #11 on: January 27, 2010, 12:21:55 PM »

No problem, I can elaborate:

TLDR: DB saves first SS.bin and last ini.

Consider the following example verification of a game with XEX CRC 999999:
User A rips his disk using kreon and uploads the stealth files along with the ini file containing his details (name, drive,...).
Let's assume his SS.bin has SS RAW CRC 222222 and SS CRC 111111. (SS CRC only looks at a subset of the file).
The DB stores the SS as SS_111111.bin and the ini as 111111999999.ini (<SSCRC><XexCRC>)

Later, User B rips a disk of the same pressing using a new 0800 firmware.
He will have a different SS RAW CRC, say 333333 (every rip is unique in that regard) but the SS CRC is also 111111 even though it is SSv2.
When he uploads, the DB notices that the stealth files, including the SS, match the ones from User A.
It ignores the RAW SS CRC in that step and only looks at the 111111.
Since the SS matches, the DB does not store it (maybe abgx360 does not even upload it).
However it stores the new 111111999999.ini created by User B (RAW SS 333333, ripped by 0800) and overwrites the previous one.

The game is now verified and the DB contains the correct DMI, PFI. However it only contains the SSv1 (CRC 222222) uploaded by User A, stored as SS_111111.bin and an ini claiming that SS has RAW CRC 333333 and SSv2.
During autofix, abgx360 will show you the wrong ini file with the non-matching RAW SS. Which is misleading.

Note that this is not wrong behavior, it is simply from before the time where SSv1 vs. SSv2 made no difference. Some argue that it still does not make a difference.



Logged
Jimakos
Hacker
***
Posts: 62



View Profile
« Reply #12 on: January 27, 2010, 02:55:21 PM »

Can someone provide me some infos about what checks and processes dvd drive does when it loads a game?
Logged
jim
Newbie
*
Posts: 1


View Profile
« Reply #13 on: January 27, 2010, 07:30:22 PM »

No problem, I can elaborate:

TLDR: DB saves first SS.bin and last ini.

Consider the following example verification of a game with XEX CRC 999999:
User A rips his disk using kreon and uploads the stealth files along with the ini file containing his details (name, drive,...).
Let's assume his SS.bin has SS RAW CRC 222222 and SS CRC 111111. (SS CRC only looks at a subset of the file).
The DB stores the SS as SS_111111.bin and the ini as 111111999999.ini (<SSCRC><XexCRC>)

Later, User B rips a disk of the same pressing using a new 0800 firmware.
He will have a different SS RAW CRC, say 333333 (every rip is unique in that regard) but the SS CRC is also 111111 even though it is SSv2.
When he uploads, the DB notices that the stealth files, including the SS, match the ones from User A.
It ignores the RAW SS CRC in that step and only looks at the 111111.
Since the SS matches, the DB does not store it (maybe abgx360 does not even upload it).
However it stores the new 111111999999.ini created by User B (RAW SS 333333, ripped by 0800) and overwrites the previous one.

The game is now verified and the DB contains the correct DMI, PFI. However it only contains the SSv1 (CRC 222222) uploaded by User A, stored as SS_111111.bin and an ini claiming that SS has RAW CRC 333333 and SSv2.
During autofix, abgx360 will show you the wrong ini file with the non-matching RAW SS. Which is misleading.

Note that this is not wrong behavior, it is simply from before the time where SSv1 vs. SSv2 made no difference. Some argue that it still does not make a difference.


But since the SS CRC is only a subset of ss.bin, it would mean that at least that part of the file is 100% equal for a SSv1 and SSv2 that have the same SS CRC. The big question is if the rest of the file has any important use. Diggin up an old old thread Tongue http://www.xboxhacker.org/index.php?topic=7729.msg48872#msg48872 it would seem that the rest of the file not covered by the SS CRC would be some "other" challenge/response timing info from the particular ripping drive. Now, is that "other" part covered by LT emulation? I would think so, otherwise each backup would only work properly on a same model drive that was used to rip it, as that would be the only way to guarantee those same "other" c/r timings. I suppose that LT has some way to emulate those timings correctly, independently of the info on that part of SS. If that is the case, then the ABGX database is working properly by ignoring files with different Raw SS CRCs but identical SS CRCs, since only the info covered by the SS CRC would be of any use (e.g, the angle values used for response types 5&7, which is where all this debate started).
« Last Edit: January 27, 2010, 10:43:20 PM by jim » Logged
Nunta
Master Hacker
****
Posts: 142


View Profile
« Reply #14 on: January 27, 2010, 08:20:53 PM »

Im just glad halo 3 odst multiplayer disc is wave 2, its the only one il play online, that and odst when the reach beta comes out. il probably end up not caring seeing alot of people dont seem to think it matters, and even if it does we will all end up getting banned anyway.
Logged
endorium
Master Hacker
****
Posts: 142


View Profile
« Reply #15 on: January 29, 2010, 04:47:04 PM »

Just a question. Should I havessv1 and ssv2 checked in abgx?

I realise you are never safe on live just trying to make myself safer.
Logged
brk1
Newbie
*
Posts: 1


View Profile
« Reply #16 on: February 21, 2010, 04:35:31 PM »

Nice thread m8, I'm new to all of this but learning very fast,I got hold of some Samsung SH D162D , they were so cheap on ebay I couldn't refuse them, worked out 15 for 2 delivered, one was faulty (2009 model) ,so a replacement was sent without needing to return the faulty one,all drives had been flashed with some unknown firmware,spdwin would not touch them , but eventually I found a force method and flashed them all to standard SB00 firmware, even the faulty one flashed when forced and became useable again (the tray never used to open on this one), obviously someone must have had a go at flashing these drives and messed this one up, anyway all flashed fine to Kreon V1.0 , now I'm learning that they don't do the most accurate rips anymore ,now that LT drives are about and everybody is crying out for SSv2 files, ABGX has stacks of games that are still only verified as SSv1 games ,even some really new ones, Left 4 Dead 2 only has SSv2 files for the RF version of the game, all the Pal releases are SSv1 and if you set ABGX to 3 .Auto correct ,it will change a lot of games back to SSv1 files, as that is the only verified files they have of those games,the only safe way of getting these games to SSv2 is to manually inject the needed files, then leave ABGX on 0. Don't correct files option, and as people point out, ASBGX isn't 100% correct either. It only has verified files sent in by people and stored in their database, if everybody ripped using a Kreon drive then all the verified games will be SSv1. C4Eva doen't know what should and shouldn't be on the game iso's 100% ,we're all just going on hearsay at the moment, and ABGX is now getting lots of SSv2 files in their data base due to these requirements, if Kreon himself can't update the Kreon f/w due to hardware limitations , then we can only rip with kreon, then inject and verify via ABGX , but are we doing right or wrong are reading his own comments on the drives and the angle variations that might be needed from now on. With iso's containing wave 6 only a few months after wave 3 was still in use ,who knows what the future will hold, I'll keep my eye on this post to see how things progress Smiley
Logged
Nunta
Master Hacker
****
Posts: 142


View Profile
« Reply #17 on: February 21, 2010, 10:39:53 PM »

I found that a rip with an 0800 vs a kreon rip with ssv2 injected still had many many differences between iso's when using total commander to compare them, therefore i dont think using abgx to autofix ssv1 into ssv2 is safe. Im sticking with my 0800 samsung drive from now on.
Logged
Pages: 1
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM