Hacking Why add anti-piracy measures to Devolution ?

[Ace Overclocked]

why cant people just be happy with everything they always have to complain about something i mean no program is ever going to be perfect there is always going to be flaws like microsoft windows and apple mac and what not untill the dev works out all the bugs and makes a patch for it cant you all just say thank you and be done with it i mean my god there must be at least 5 pages alone on this topic with nothing but bitching

Because if everyone was always complacent and never complained, nothing would ever change and improve?

Look guys, all the bitching you're doing is in vain, tueidj isn't even giving attention to this thread (and i'm sure he hyperfacepalmed when he saw it)

If it's alright to sing praise, it's also alright to provide with criticism.

if we want to have any result about AP removal, we need to talk to the developer.

That would be a waste of time, as tueidj likes to ignore questions and feedback regarding Devo's AP.

While i think some critiscism is healthy, this thread is going a little bit too far, let's stop the derailing shall we?

 

[wiismodrome]

As has been brought up earlier, the way to get people to change their minds is by using logic. If it can be demonstrated that there are sound reasons for eliminating anti-piracy measures, a rational individual should be motivated by reason to remove them. Importantly, this assumes that the individual is open and willing to listen to rational arguments. Whether or not such a strategy will be successful in this case remains unknown....

 

[Rydian]

Just want to make sure you're aware, but you came in later in the thread and some of the crap we're mentioning was stuff other people stated earlier in the thread. We're bashing things multiple people have been saying throughout the thread, not you specifically (you've just echoed one or two).

That may be true. I cannot confirm that.

The mention that it stopped working after the AP verification gave the "all clear" lights signal was why people doubted the claim from the start.

However, if so, then it is rather strange that the developer claimed earlier that Rogue Leader worked (when I originally reported the verification/loading failure). If it was just an application error, why did it work for the developer?

Different game revisions. Even the Wii often pushes out fixed game discs after the initial run if major bugs are found, and those are often built with newer SDK versions than what was available at the time the original game was compiled (and some games got quite a few revisions. Even when it's not the whole 1.0 vs. 1.01 thing for a single region (Ocarina Of Time on the N64 has 1.0, 1.1, and 1.2), regions don't all get games at the same time and generally (for example) the EU release is done later since more translation needs to be done if it's Multi-5 or something, which means by the time the game is compiled for the last time there's been more chances to fix bugs in the game logic itself and likely later tools are being used (for the engine).

 

[wiismodrome]

When other games passed Devolution's verification test (five flashes), the application created a .dvv file with the game ID plus a hash of some sort. With Rogue Leader, however, the file that was created was empty. This logically implies that the verification subroutine was not able to create the authentication hash and write it to the file, and that this occurred before the game was launched.

 

[Rydian]

The flashes indicated that the check passed, though. The file writing is just so the check isn't done on future boots from what I'm reading.

 

[wiismodrome]

The flashes indicated that the check passed, though. The file writing is just so the check isn't done on future boots from what I'm reading.

Yes. The check passed... but the application wrote a blank file. This suggests that the AP subroutine did not finish before crashing. If the AP check is successful, a .dvv with game ID and hash is written, then the game is launched. If the security hash is not present in the .dvv file, then the requisite authentication is not valid and the game cannot launch. Hence, it was not the game crashing.

 

[wiismodrome]

BTW, now the game is definitely crashing, with r100....

 

[retKHAAAN]

When other games passed Devolution's verification test (five flashes), the application created a .dvv file with the game ID plus a hash of some sort. With Rogue Leader, however, the file that was created was empty. This logically implies that the verification subroutine was not able to create the authentication hash and write it to the file, and that this occurred before the game was launched.

Actually, it logically implies that the loader was not able to properly recognize a game the was built using a buggy SDK. If you pay attention to yours and other's post in the release thread, the file is created with a partially correct gameID. So while you can assume "it's obviously the AP's fault"...it's only as logically implied as you choose to believe.

 

[wiismodrome]

No.... the file created was empty, not partially correct. Maybe some confusion exists here because the names of the .dvv files share a number of characters with the game ID?

 

[retKHAAAN]

No.... the file created was empty, not partially correct. Maybe some confusion exists here because the names of the .dvv files share a number of characters with the game ID?

That is precisely what I was just talking about... It's partially recognizing the gameID but failing to recognize past a certain point.

 

[Maxternal]

Also, the fact that when it DOESN'T accept the verification process it sometimes continues to loop sending out the 5 flashes makes me think that 5 flashes doesn't necessarily mean the verification process is FINISHED. One way or another, yes, this particular bug has been smashed in r100 and is with Rogue Leader there is not ANOTHER little bug with how it actually plays the game itself (as just mentioned)

By the way
Some of the main reasons mentioned here against the AP were damaged disk drives and newer, no-GC Wiis (once classic controller support is added.) Someone on the main thread already complained, saying they own three consoles and are constantly switching the hard drive between the three of them and this was causing a problem so we officially can say that the DVV files are per-console (be that based on the MAC address or the console's private keys or whatever) so the idea of validating your disk images on your hard drive with your retail disks won't work if Devolution thinks it's on someone else's console.
This made me think of the following possible workaround.
There was someone that mentioned that Devolution works fine in xNEEK so I was thinking, what if someone who had a bad drive or new Wii made a xNEEK installation extracted from their own NAND and ripped and verified their own retail disks onto their own hard drive on someone else's console running in a xNEEK environment based on their own NAND. I would assume the game would then be signed for use on the console with the broken or newer drive. Assuming this works, this would still not be cracking the AP, it's still doing it's intended job just as well as when used the normal way. It would just let more legit game owners use the features of Devolution. As long as the file is not moved from one place to another on the same hard drive there shouldn't be a problem unless it's actually looking at something unique in the hardware itself and not the NAND (which I'm sure is also possible).

The only minor complication I would see in the process is that Devolution needs AHBPROT access and I've heard the HBC doesn't do too well from xNEEK so it would have to be run from an AHBPROT compatible forwarder or something like that. I only have one console and can't really try this out and I don't have much experience with xNEEK either but it all seems to work okay in my head at least.

EDIT :
Even as such, it still wouldn't work for anyone who has their retail disks so physically damaged that they can't be verified by anything (which just requires the first 8 bytes of the disk IIRC so not too many people, I'd hope) so it wouldn't even be a fix for everybody.

 

[Rydian]

I don't even have a Wii so I can't comment as I've never run the program.

 

[Maverick Lunar X]

^ I lol'd

I've got two wii's, won't be able to test that idea until this weekend probably.

 

[Ericss]

By the way
Some of the main reasons mentioned here against the AP were damaged disk drives and newer, no-GC Wiis (once classic controller support is added.) Someone on the main thread already complained, saying they own three consoles and are constantly switching the hard drive between the three of them and this was causing a problem so we officially can say that the DVV files are per-console (be that based on the MAC address or the console's private keys or whatever) so the idea of validating your disk images on your hard drive with your retail disks won't work if Devolution thinks it's on someone else's console.
This made me think of the following possible workaround.
There was someone that mentioned that Devolution works fine in xNEEK so I was thinking, what if someone who had a bad drive or new Wii made a xNEEK installation extracted from their own NAND and ripped and verified their own retail disks onto their own hard drive on someone else's console running in a xNEEK environment based on their own NAND. I would assume the game would then be signed for use on the console with the broken or newer drive. Assuming this works, this would still not be cracking the AP, it's still doing it's intended job just as well as when used the normal way. It would just let more legit game owners use the features of Devolution. As long as the file is not moved from one place to another on the same hard drive there shouldn't be a problem unless it's actually looking at something unique in the hardware itself and not the NAND (which I'm sure is also possible).

Great idea. However, IIRC Sneek doesn't support all SM versions. People who have a unsupported SM version wouldn't be able to use this method.

 

[Maxternal]

Spelling Phail

EDIT : I couldn't help myself ... I think I need to go to bed now.

 

[tysonrss]

I would only use this if I could use the wiimote as a controller, otherwise I see it as completely useless.

 

[wiismodrome]

No.... the file created was empty, not partially correct. Maybe some confusion exists here because the names of the .dvv files share a number of characters with the game ID?

That is precisely what I was just talking about... It's partially recognizing the gameID but failing to recognize past a certain point.

Not sure what you're talking about. Have you actually spent any time using the program or looking closely at the .dvv files?

Take a game like Rogue Leader for example. The game ID is GSWE64. When Devolution attempts to verify the disc it will create a file called GSWE00.DVV.

If verification fails, the file created will be empty.
If the disc is successfully verified, the file will contain the game ID plus an AP hash.
What is important to note here is that the file is created whether or not the disc is actually verified.
Thus, the mere fact that the .dvv file exists is not evidence that verification has succeeded, because such a file will be created even for discs which never pass the AP test.

Going back to the case of earlier revisions of Devolution (< r100), it should be apparent that the AP check was failing. Why? Because a blank file was written, just as it would for any disc which failed verification.

Further, it stands to reason that the Devolution application will only launch a game once valid authentication has been confirmed. In the case of Rogue Leader, there was no such file present. Thus, there is no way that the game could have launched. Therefore, it was not the game crashing that was the problem. The game had no chance to even start, because the game was never verified and the absence of a valid .dvv file meant that Devolution would not start the game.

This is all simple logic.....

 

[obcd]

While the xneek method to verify a game on another wii sounds great, it might fail if Tueidj is using the wii unique id which is not stored in the nand.
There is an option to override that id by adding it to a file, but it only works when you use the proper es call to extract the id. If you use direct hardware access trough the registers, you will still get the wii original id.

xneek supports system menu 4.1 - 4.3. I guess that furfills at least 98% of the users.

The homebrew filter works perfectly under xneek. ahbprot is always disabled the proper way under neek.when the hbf is used to launch a program.
I bet postloader should work as well.

 

[tueidj]

Take a game like Rogue Leader for example. The game ID is GSWE64. When Devolution attempts to verify the disc it will create a file called GSWE00.DVV.

If verification fails, the file created will be empty.
If the disc is successfully verified, the file will contain the game ID plus an AP hash.
What is important to note here is that the file is created whether or not the disc is actually verified.
Thus, the mere fact that the .dvv file exists is not evidence that verification has succeeded, because such a file will be created even for discs which never pass the AP test.

Going back to the case of earlier revisions of Devolution (< r100), it should be apparent that the AP check was failing. Why? Because a blank file was written, just as it would for any disc which failed verification.

Further, it stands to reason that the Devolution application will only launch a game once valid authentication has been confirmed. In the case of Rogue Leader, there was no such file present. Thus, there is no way that the game could have launched. Therefore, it was not the game crashing that was the problem. The game had no chance to even start, because the game was never verified and the absence of a valid .dvv file meant that Devolution would not start the game.

This is all simple logic.....

The .DVV file is created (full of zeroes) before Devolution even checks for a disc in the drive, not because "the AP check was failing." Try it and see for yourself, load an .iso that you don't have a disc for and press the power button to exit when it flashes twice. You'll get an empty .DVV file even though nothing was ever checked.
The game couldn't start because the apploader had crashed IOS. Even if the verification procedure wasn't there, the game still wouldn't start. It would actually crash before the apploader finished, the fact that it's reading the actual disc (bypassing IOS) means it gets closer to launching the game than if it were reading from SD/USB, which would be the case if the disc check wasn't there. Your "simple logic" relies on circular reasoning, "the game couldn't launch because the AP check failed because the game couldn't launch".

 

[the_randomizer]

Hoo, boy....didn't think this would, uh, occur.