Zune 3.0 CTP to Beta Converting Still Restarts!

[shutout5591]

The process for detailing a conversion from 3.0 CTP to Beta is outlined here:

XNA Creators Club Online - xna game studio 3.0 beta readme

however, when I did that, the game still restarted the zune. In fact, Microsoft's Alien Game also restarts the zune. So what do we make of this?

Can anybody extract the texas holdem or hectic file from the zune so we can decompile it?

I think they have added code in the unload content sections. Now, we are leaving them blank, but I think functions are needed there.

What else could it be?

[MKlucher]

Games that are deployed to the Zune will still restart the device after they exit. Games that we're included with the firmware upgrade do not have this side effect.

[shutout5591]

Originally Posted by MKlucher

Games that are deployed to the Zune will still restart the device after they exit. Games that we're included with the firmware upgrade do not have this side effect.

Are there any plans to change this? Doesn't it seem a little Microsoft-centric to have this happen?

[blackwood550]

There has to be a line of code that will allow us to exit games without restarting our Zunes.

[SimReality]

XNA Game Studio was, is, and will continue to be a developer tool for as long as we can tell. It is not meant for end-users such. There is no way to stop the restarting after a game closes as this is done by the framework. The best thing you can do is simply accept that you are using a developer tool that isn't targeted at end-users and therefore is not going to provide an optimal end-user experience. The other option is to wait patiently until Microsoft does launch their end-user plans for the Zune and see if those are better.

[fade3e]

Originally Posted by SimReality

XNA Game Studio was, is, and will continue to be a developer tool for as long as we can tell. It is not meant for end-users such. There is no way to stop the restarting after a game closes as this is done by the framework. The best thing you can do is simply accept that you are using a developer tool that isn't targeted at end-users and therefore is not going to provide an optimal end-user experience. The other option is to wait patiently until Microsoft does launch their end-user plans for the Zune and see if those are better.

not quite, i believe that the reason those two games dont restart is because being microsoft they made sure those ran perfectly and used a different library to load/unload, because xna is still beta i dont think microsoft wants you to run a game that has a glitch then load back to the firmware because it could cause buggs/messups so they reload the firmware to make sure there are no problems

[catnat109]

Originally Posted by fade3e

not quite, i believe that the reason those two games dont restart is because being microsoft they made sure those ran perfectly and used a different library to load/unload, because xna is still beta i dont think microsoft wants you to run a game that has a glitch then load back to the firmware because it could cause buggs/messups so they reload the firmware to make sure there are no problems

Ya you know cause Microsoft Games are so GREAT!

[SimReality]

Originally Posted by fade3e

not quite, i believe that the reason those two games dont restart is because being microsoft they made sure those ran perfectly and used a different library to load/unload, because xna is still beta i dont think microsoft wants you to run a game that has a glitch then load back to the firmware because it could cause buggs/messups so they reload the firmware to make sure there are no problems

Of course they don't restart because Microsoft made them. My point is related to why XNA Game Studio games still restart and why it's such a pain to get games on the Zune. XNA Game Studio is a developer tool not intended for end-users. The experience is not tuned for end-users so they shouldn't really expect a smooth user experience.

I will bet that even when XNA GS 3.0 comes out of beta, you will still see restarts and you will still need a full XNA Game Studio installation. It took them two years to get an end-user system set up for Xbox 360 and it will likely take them some time on the Zune as well.

[fade3e]

Originally Posted by SimReality

Of course they don't restart because Microsoft made them. My point is related to why XNA Game Studio games still restart and why it's such a pain to get games on the Zune. XNA Game Studio is a developer tool not intended for end-users. The experience is not tuned for end-users so they shouldn't really expect a smooth user experience.

I will bet that even when XNA GS 3.0 comes out of beta, you will still see restarts and you will still need a full XNA Game Studio installation. It took them two years to get an end-user system set up for Xbox 360 and it will likely take them some time on the Zune as well.

you raise a good point, although i wish it would come sooner

[SimReality]

I think everyone does.

[ZunePet]

> Can anybody extract the texas holdem or hectic file from the zune so we can decompile it?
See this thread: http://www.zuneboards.com/forums/fir...are-3-0-a.html

The .zcp files (2 Zune games and runtime) are digitally signed like the rest of the system.

> What else could it be?
My guess (not confirmed): digitally signed modules have extra privileges. This would include not resetting the device on exit, and potentially other things. Since only Microsoft can sign these modules, it knows what to trust.
They use the digital signatures/certificates all over the system to prevent homebrew modules getting into the system. Using it for games makes sense.

[shutout5591]

Originally Posted by ZunePet

> Can anybody extract the texas holdem or hectic file from the zune so we can decompile it?
See this thread: http://www.zuneboards.com/forums/fir...are-3-0-a.html

The .zcp files (2 Zune games and runtime) are digitally signed like the rest of the system.

> What else could it be?
My guess (not confirmed): digitally signed modules have extra privileges. This would include not resetting the device on exit, and potentially other things. Since only Microsoft can sign these modules, it knows what to trust.
They use the digital signatures/certificates all over the system to prevent homebrew modules getting into the system. Using it for games makes sense.

The digital signature is a good place to start, i will be pissed if thats the answer.

I downloaded it, and extracted it, but I have no clue how do deal with the zcp. A google search revealed nothing - maybe its proprietary and only the installer can deal with it?

[itsnotabigtruck]

Originally Posted by ZunePet

> Can anybody extract the texas holdem or hectic file from the zune so we can decompile it?
See this thread: http://www.zuneboards.com/forums/fir...are-3-0-a.html

The .zcp files (2 Zune games and runtime) are digitally signed like the rest of the system.

> What else could it be?
My guess (not confirmed): digitally signed modules have extra privileges. This would include not resetting the device on exit, and potentially other things. Since only Microsoft can sign these modules, it knows what to trust.
They use the digital signatures/certificates all over the system to prevent homebrew modules getting into the system. Using it for games makes sense.

I noticed the digital signatures, but never put 2 and 2 together like you just did. This is probably it, and that means we're doomed. :/

Originally Posted by shutout5591

The digital signature is a good place to start, i will be pissed if thats the answer.

I downloaded it, and extracted it, but I have no clue how do deal with the zcp. A google search revealed nothing - maybe its proprietary and only the installer can deal with it?

The .zcp format is what the Zune uses internally to store everything. It's definitely a proprietary format. I'm guessing the way the Zune software deploys it is by dumping the .zcp file straight onto the Zune (bypassing the XNA deployment system, etc.).

[ZunePet]

> but I have no clue how do deal with the zcp. ...
It appears to be a bundle of files. Uncompressed, but optionally encrypted!
The runtime.zcp ("ZContent\2\runtimeZune.v3.0.Beta.zcp") is not encrypted, so if you want to look at the structure, start there.
The two games appear to be encrypted (or at least scrambled/obscured)

QUICK NOTES: (very quick examination, some guesswork, take it FWIW)
offset 0x000 - some header, with "NX" in the middle
offset 0x1F0 - digital signature/certificate. Dump with 'certmgr'. Extra space padded with ZEROs
offset 0x29F0 - Bundle info in record-like format. Includes name, title etc, "PNG" and other interested types in games. Extra space padded with ZEROs
offset 0xF000 - approx 4KB of binary data ?? for what?
!!!! Extra space padded with ZEROs for runtime.zcp BUT extra space NOT padded with ZEROs for games !!!!!
Instead it is a repeating pattern of 16 bytes. NOTE: that typically indicates a 16byte block cipher (the result of 16bytes of zeros being encrypted). It could be something else.

My guess is everything after this is encrypted for the games. See the runtime.zcp for an example of non-encrypted data.
offset 0x11000 - directory of files in the bundle. Includes "mscoree3_5.dll", "Microsoft.Xna.Framework.dll" and others. Format is relatively easy to figure out.
Actual files follow in standard formats. You can dump/disassemble them with standard tools. Since the runtime.zcp is a digitally signed DLL, it can contain native (ARM) code as well as CLR/MSIL interpreted/sandboxed code.
I don't know the restrictions on the games (do they allow native code?)
As we know, homebrew games are limited to CLR/MSIL interpreted/sandboxed code.
Hope that helps.

[itsnotabigtruck]

Originally Posted by ZunePet

> but I have no clue how do deal with the zcp. ...
It appears to be a bundle of files. Uncompressed, but optionally encrypted!
The runtime.zcp ("ZContent2runtimeZune.v3.0.Beta.zcp") is not encrypted, so if you want to look at the structure, start there.
The two games appear to be encrypted (or at least scrambled/obscured)

QUICK NOTES: (very quick examination, some guesswork, take it FWIW)
offset 0x000 - some header, with "NX" in the middle
offset 0x1F0 - digital signature/certificate. Dump with 'certmgr'. Extra space padded with ZEROs
offset 0x29F0 - Bundle info in record-like format. Includes name, title etc, "PNG" and other interested types in games. Extra space padded with ZEROs
offset 0xF000 - approx 4KB of binary data ?? for what?
!!!! Extra space padded with ZEROs for runtime.zcp BUT extra space NOT padded with ZEROs for games !!!!!
Instead it is a repeating pattern of 16 bytes. NOTE: that typically indicates a 16byte block cipher (the result of 16bytes of zeros being encrypted). It could be something else.

My guess is everything after this is encrypted for the games. See the runtime.zcp for an example of non-encrypted data.
offset 0x11000 - directory of files in the bundle. Includes "mscoree3_5.dll", "Microsoft.Xna.Framework.dll" and others. Format is relatively easy to figure out.
Actual files follow in standard formats. You can dump/disassemble them with standard tools. Since the runtime.zcp is a digitally signed DLL, it can contain native (ARM) code as well as CLR/MSIL interpreted/sandboxed code.
I don't know the restrictions on the games (do they allow native code?)
As we know, homebrew games are limited to CLR/MSIL interpreted/sandboxed code.
Hope that helps.

I notice that this post hasn't received a significant amount of attention; maybe you should further develop your findings and post them in a new thread.

I and several other developers examined the format a bit, but none documented it à la what you did here.

It is clear that untrusted .NET code is heavily locked down. This even affected SIR TET - apparently untrusted applications can no longer use reflection to instantiate or call private/internal functions. This can be nothing except an attempt to prevent leverage of internal XNA functions and P/Invoke declarations for further development.

[shutout5591]

Originally Posted by itsnotabigtruck

I notice that this post hasn't received a significant amount of attention; maybe you should further develop your findings and post them in a new thread.

I and several other developers examined the format a bit, but none documented it à la what you did here.

It is clear that untrusted .NET code is heavily locked down. This even affected SIR TET - apparently untrusted applications can no longer use reflection to instantiate or call private/internal functions. This can be nothing except an attempt to prevent leverage of internal XNA functions and P/Invoke declarations for further development.

I do believe we should be giving this more attenton. Im talking hex dumps and such. If what ItsNotABigTruck said about the zcp file being raw compiled code bypassing the framework's deployment system is true, the zcp file is raw code and should have the data to make it not restart. We should be looking for hex differences between our compiled game with the xna game stdio, and its zcp file.

[Netrix]

Originally Posted by itsnotabigtruck

I notice that this post hasn't received a significant amount of attention; maybe you should further develop your findings and post them in a new thread.

I and several other developers examined the format a bit, but none documented it à la what you did here.

It is clear that untrusted .NET code is heavily locked down. This even affected SIR TET - apparently untrusted applications can no longer use reflection to instantiate or call private/internal functions. This can be nothing except an attempt to prevent leverage of internal XNA functions and P/Invoke declarations for further development.

I saw it, and thought it was interesting, but since I have no clue what any of that means (other than what he specifically explained), I could not do anything about it. Hopefully I will find the time to learn how to do that stuff.

[ZunePet]

> I notice that this post hasn't received a significant amount of attention; maybe you should further develop your findings and post them in a new thread.
FWIW: I lost interest in hacking the Zune a long time ago.
I posted my quick notes in case someone found it interesting FWIW. I'll leave it to others if they are interested.

I'd suggest:
Try something simple like patching a few non-critical bytes in the .ZCP file (eg: the zero padding) and force an update (using the manual update procedure). Then see if the games work.
and/or finding the code in the NK.BIN firmware that loads the .ZCP. You should be able to determine if/how the format is encrypted, and at least how to decrypt it (but not reencrypt it)
Good luck