Sign in to follow this  
DummyInput

Preventing PIX reverse engineering

Recommended Posts

Quote:
Original post by DummyInput
I've seen games around that do not allow Microsoft PIX to do captures, does anyone known how this is done?
Why? You want to disable a valuable debugging tool - about the only thing I see this doing is making it hard on yourself to diagnose bugs remotely.

Share this post


Link to post
Share on other sites
Hi,

PIX is supposed to be used when developing a game, If you need to do any patching after release you can always go back to your dev environment.
Its the same with debug symbols for example, you wouldn't release a game with them.

In any case I know for a fact that for example fallout 3 doesn't allow PIX captures showing: "This program has indicated that it cannot be used with Direct3D profiling/analysis tools" I assume this is more the case of PIX honoring some option that the application sets, rather than any impossibility of PIX actually capturing the data.
I simply can't find any documentation about it...

Cheers.

Share this post


Link to post
Share on other sites
Quote:
Original post by DummyInput
PIX is supposed to be used when developing a game, If you need to do any patching after release you can always go back to your dev environment.
Its the same with debug symbols for example, you wouldn't release a game with them.
Many large commercial software products do ship with debug symbols included, precisely so that engineering/QA can diagnose crashes over the phone with a client. This is especially useful if the client is running an environment which you don't have available for testing (such as a GPU from an unusual vendor).

Share this post


Link to post
Share on other sites
I guess that is probably true for some industries.
Its not something very common on the games industry though.

Just did a bit more digging and found out how to do it:
just pass 0x1 to "D3DPERF_SetOptions".

Cheers.

Share this post


Link to post
Share on other sites
What's the real deal ? What are your reasons for trying to prevent pix ? Debugging tools are not used for other reasons than debugging (could be useful to driver developers for example) and it's not like you're leaving useful perf on the table by leaving that option out.

LeGreg

Share this post


Link to post
Share on other sites
Why does it matter why he wants to do it? Why not just provide him with the information he requests if you know it instead of making him justify his purpose for using it? Thanks for posting the solution DummyInput, even if you had to dig it up yourself.

Share this post


Link to post
Share on other sites
Quote:
Original post by LeGreg
Debugging tools are not used for other reasons than debugging


Hi,

I'm afraid you are simplifying things a bit (unless your notion of debugging is a bit broader than mine). In the real world there are other issues as IP protection, EULAS, etc.
Maybe if you use PIX to capture a program command buffer its not breaking any agreements (you are just capturing the output of the program), however if your program is specifically setting an option telling you it doesn' t allow you to, you are probably breaking the contract, and can face legal consequences.

In any case, I understand where you are coming from. However I do agree with "Kchaa" in the sense that people usually are to quick to question motives, without adding to the solution.
By providing an answer for this problem you are providing a way for people to use this option to try to prevent reverse engineering, however you are also providing knowledge for people who really *need* to use PIX on release products to circumvent it.

Cheers.

Share this post


Link to post
Share on other sites
Ultimately, as has been posted, anyone sufficiently motivated will find a way of reverse engineering any product. However there isn't anything inherantly wrong with making it a non-trivial job [smile]

I would highly doubt there is a normal use-case (outside of internal or publisher QA) where you'd want an end-user to install the SDK and fire up PIX. It's just a bit too [wow] for any non-developer!

Any sort of IP or licensed tech may well require these sorts of actions on the developers part. If you distribute someone elses technology as part of yours then you can become liable for any lapses in not securing it (subject to the contract of course).

hth
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
Ultimately, as has been posted, anyone sufficiently motivated will find a way of reverse engineering any product. However there isn't anything inherantly wrong with making it a non-trivial job [smile]

Except, given that the switch is done via a known function call, such a setting is trivial to reverse.

Share this post


Link to post
Share on other sites
Quote:
Original post by nuvem
Quote:
Original post by jollyjeffers
Ultimately, as has been posted, anyone sufficiently motivated will find a way of reverse engineering any product. However there isn't anything inherantly wrong with making it a non-trivial job [smile]

Except, given that the switch is done via a known function call, such a setting is trivial to reverse.
Yes, indeed! But I suppose I could still argue that it'll stop your average "script kiddie" hacker from just firing up PIX and the app... but chances are if you're worried about this sort of thing then a script kiddie is unlikely to be your primary concern. hey-ho!


Jack

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this