Quote - Out of curiosity...how does "Hard_Lock keys" (Dongle's) stack up against (compare too) mass produced keys made from a "Gold Master Disc"(Matrix),

Quote - For example...Let's say I took my Lightwave dongle over to my neighbors house, and removed his dongle, and inserted mine, would I be able to run his/her version of Lightwave? (Given it's running the same Sentinel Driver)

If the software is mass production, your neighbour's dongle must work with you.
But this is no problem, the purpouse of the dongle is to prevent pirate copies, if your neighbour has a dongle it means that he has purchased the software.
You can make any copies as you want of the software, install it on all the computers you want, but you will need the dongle installed to run the software, so you only can run one software at the same time. If you want to run the software at another computer where the software is also installed you must remove the dongle from one computer and put it in the other computer.
You have a great flexibility in use of the software, you only need the dongle to run it, the problem is only when you put the dongle somewhere that you don't know where it is.
The protection works fine, it's very easy to copy or download a software, but how do you copy or download a dongle?
To copy a dongle is not an easy task, even it can be done.

 

Quote - BTW...although I'm sure it would drive up software cost's

Yes it does, the cost of a dongle is not high, can be 20$ that is very much bigger than few cents of a CD, but this is not important becausedongles are used by very expensive software. Someone that sells a software for 5,000$ or more would not care to spend 50$ more in the cost. To have a profit of 5,000 or 4,950 will not make any difference.

Quote - , I think the "Dongle Approach" would be the most secure.(although I know a dongle can be faked with a software dongle that tricks the application into thinking a hard-lock key exists, I would think that it's gotta be harder to crack).

Well, it is not. As any software with serial numbers, registration scheme, specially burned CDs is cracked, Microsoft XP activation code is cracked, so dongle protected software is cracked in the same way without any trouble and a downloaded lightwave work will work fine without any dongle.
The easy solution, you don't copy the dongle, you crack the software that use it!

Quote - BTW...One reason I ask is because...as I recall...when I got the "Ozone" plug-in for Lightwave...All that E-on Software needed from me was my Lightwave hard-lock key number.Then they sent me my "permanent" serial number for Ozone (that I assume was also specifically generated to be "tied" to my dongle number...and in turn...my copy of Lightwave).

BUT!!!
With my copy of "Ozone" for Cinema 4D...E-on asked for my C4D Core application serial number before sending me my permanent serial number for Ozone

Is the plugin the same for Lightwave and Cinema4d or are different plugins?
I have the impression that they are only verifying if you are a valid user before giving you the permanent serial number, but I think that any "permanent serial number" will work too!

I have a funny story.
A friend of mine that is running a company purchased a computer some years ago, the computer came with Word 2000 installed.
He moved all the data from his old computer and was using the new computer with the new Word 2000. All worked fine until one day Word 2000 refused to open and appeared a message:
"trial period expired you must register Word 2000"
Ok, no problem as he had all the bills and notes of the computer. There were two ways to register the software: by internet and by phone. He started with the most easier that was by internet, but there were no ways to establish the communication with Microsoft.
Now it was the turn to try the telephon, he dialed the number without any answer, after many tries and some hours he was able to enter into contact, he passed all his information and they told him that will send him the code to enable Word 2000.
Many hours later and no code, he phoned again (several tries) and they replied that were working on it.
Next day, nothing!, he phoned again and the same blah, blah, blah, nothing!
As he is running a business and playing games, he needed to use Word 2000 (time is money), so tired of wanting for the activation code, he took his car, went downtown and purchased a pirate Word 2000 for 10$, installed it and was able to return to his business.
Two weeks later he received the activation code!!!!!!!
With this kind of service they are promoting piracy, who is not a pirate is forced to become one!

Damn!!!, there'sno way to edit my posts:
What you read
 " As he is running a business and playing games"
you must read
" As he is running a business and not playing games"

***"The easy solution, you don't copy the dongle, you crack the software that use it!"***

 

Yes...but wouldn't it mean that not only would the serial number need to be cracked, but the dongle associated with it too?

 

In other words..not 1...but 2 things would need to be cracked. and those 2 would have to be compatible with each other?

 

"Is the plugin the same for Lightwave and Cinema4d or are different plugins?"

 

I believe the Ozone Plug-in for Lightwave is different than the one for C4D....The Interface is similar...but updates and patches come at different times with different versions IIRC.

 

Tom

Another "Service promotes Piracy Story."

 

When I was on staff at the 3DC, I was working closely with Pixologic on some promotional marketing of ZBrush.

(Newsletter, Contests, Banners, Building a forum and gallery for them, etc...)

I closed one deal by requesting a dozen or so NFR copies of ZBrush (1.2 back then I think) so I could dole out some copies to some of the hard working staff.(All Volunteers)

 

Non-Problematic...everybody's happy....that is until we started encountering the notoriously horrific licensing procedure they had back then.

 

After a while...most got fed up with having to contact Pixologic every other day for a new license, then waiting...sometimes days to get a replacement license, and they eventually just uninstalled it, never to even look at it again.

 

Others kept at it because...well....when it ran...it was an awesome program.

 

In an unrelated phone call to Pixologic...I asked if the problem had something to do with copies being  NFR's (Not For Resale).

 

'No...NFR's are identical to the paid versions,complete with updates,etc...." 
....said the voice on the other end.

 

It wasn't that long before forums everywhere... were filled with the screams of horror and frustration of the licensing procedure.(From Paying customers)

 

I had talked with many folks about it... and several of them got so fed up, they "Bought" the retail version...but "installed" the warezed version so they could get around the licensing problem...and actually get some use out of the app..

 

In a later unrelated phone conversation with Pixologic...I asked if they knew paying customers were using "alternate" versions due to the licensing problem.

(No names mentioned, offered, or requested...by either party)

 

"Yeah..we know...but it'll be fixed in version 1.5" said the voice on the other end.

 

Pixologic eventually did get the problem resolved around version 1.5 I think,
(Paid upgrade IIRC)

And 2.0+ is off the hook one of the most robust graphics apps on the market today and is used

by many motion picture and gaming studios these days.

 

( Ever hear of .... WETA Digital .... ILM,....Electronic Arts .... to name just a few)

 

Anyway...The long and the short of it is that people were willing to "Buy" the software...and they did...but installed and used the cracked versions instead so they could actually get some work done.

It was simply the more stable version back then.

 

So I guess I should say it wasn't really a "service" related problem...

Pixologic was trying to fulfill customers needs as quickly as possible.

But rather a software licensing "Feature" that sent folks into the shady part of the net...

To cop what they had already bought.

 

Tom

 

 

Quote - The reverse is not decrypting, is to follow the algorithm in the reverse direction..

This is not always easily done.

For example, if the algorithm for checking a serial number S is to compute some hash d of S and use d to decrypt some other block of data E to a known block M, generating a serial is going to be a rather difficult problem if you don't know d.  In particular, attempting to solve the equation  Ed º M (mod n) for d where E, M, and n are known (and n is extremely large) is an extremely difficult problem.

The trick is that the serial has to hash to a certain integer d - but the program doesn't actually have that number, so no amount of reverse engineering is going to reveal it.  The resulting hash is known to be correct only when it correctly solves a particular equation.

This can be taken one step further, and once the has is verified to be correct, it is then used to decrypt a block of code needed for the installation to continue; this way, disassembling the program and finding the code that checks the serial number and changing it to bypass this check won't work because you will be missing an essential piece of code.

Of course, nothing is ever perfect.  It literally is a game of cat and mouse, with the software developers having to constantly develop new and novel ways of protecting their software from piracy, and the crackers are constantly finding ways of defeating new protection schemes.

Regardless of the complexity of the protection scheme, there is a simple way to thwart keygens.  Just have two keyspaces, A and B, where B is a subset of A (and where A is significantly larger than B so a key in A has a very small probability of being in B).  All keys distributed with licensed copies of the program are from the smaller set B.  The program will accept any key from the larger set A, while the algorithm for checking to see if the key belongs in B is kept a secret.

Although the program will run with invalid keys, any key that is sent back to the company can be easily checked and determined if it was generated by an unauthorized keygen (and the installation using it locked out of updates and such, or possibly even the user of the unauthorized installation finding themselves in legal hot water if the company chooses to proceed with legal action)

Of course, checking serial numbers here to make sure that people are only using licensed software for their renders is simply infeasible.

Quote - For example, if the algorithm for checking a serial number S is to compute some hash d of S and use d to decrypt some other block of data E to a known block M, generating a serial is going to be a rather difficult problem if you don't know d.  In particular, attempting to solve the equation  Edº M (mod n) for d where E, M, and n are known (and n is extremely large) is an extremely difficult problem.

You are thinking in mathematics, but you must think in software code.
Software code is very limited to some few functions: add, substract, multiply and shift.
Division can be used in only a small amount because it is slow.
Many mathematical functions have no inverse, software code always has an inverse.
If in the forward direction you shift right, in the backward direction you shift left.

Quote - This can be taken one step further, and once the has is verified to be correct, it is then used to decrypt a block of code needed for the installation to continue; this way, disassembling the program and finding the code that checks the serial number and changing it to bypass this check won't work because you will be missing an essential piece of code.

In almost all  cases no code is encrypted (it was common in DOS). All is reduced to checking to key, if the key is ok then the software goes on, if the key is invalid the program aborts.
If you bypass the verification, any key that you enter will give ok and the program will continue.
Very few software encrypts the code and in general encryption cannot be done.
The reason why you cannot encrypt the code in Windows is because Windows allocate dynamically the program in memory and Windows must relocate all the program references to memory to the address where the program reside in memory.
What Windows does when you start a program is:
1)- Load the code in memory.
2)- Relocate all memory referrences
3)- Tranfer control to the code so it begins to run.
If the code is encrypted Windows in the relocating process will change the value of parts of the encrypted code!!!
The program only starts after the relocation!. When the program is decrypting the code and reach a part that was changed by Windows it can give an decryption error or if it pass the code will have a wrong memory referrence that will make Windows crash when the program is executed.
You can see that is very difficult and tricky to make a software that can be encrypted and limited only to small programs.
The only thing that you can encrypt without problem is data.

Quote - Yes...but wouldn't it mean that not only would the serial number need to be cracked, but the dongle associated with it too?

 

In other words..not 1...but 2 things would need to be cracked. and those 2 would have to be compatible with each other?

Yes, it must be cracked in two points or more, no needs for compatibility, neither serial number nor dongle exist anymore.

Quote - You are thinking in mathematics, but you must think in software code.
Software code is very limited to some few functions: add, substract, multiply and shift.
Division can be used in only a small amount because it is slow.
Many mathematical functions have no inverse, software code always has an inverse.
If in the forward direction you shift right, in the backward direction you shift left.

Running software code in reverse, or inverting individual instructions, will not yield a function that reverses what the original function did.  A very simple example - taking an integer and multiplying it by itself.  This is so simple it can be done with a single multiply instruction.  Inverting this - taking the square root of a number, requires many more steps, though it is still doable in a reasonable amount of time.

Practically any mathematical algorithm can be implemented on a computer.

On the x86, code can be executed from any location in memory (newer extensions add the NX bit to prevent this, in order to thwart things like buffer overflow attacks).  A program could store an encrypted function as data, and decrypt it and call the location of the decrypted code as a function pointer.  (Ironically, Vista would balk at this unless DEP was turned off for the program in question).

It would certainly be possible to design an operating system that could handle code that was stored in encrypted form on disk, and to be able to decrypt it as it loads it into memory (upon being passed the decryption key).

Quote - A program could store an encrypted function as data, and decrypt it and call the location of the decrypted code as a function pointer.

Only if the code has no reference to any data (only works with registers).

Quote - It would certainly be possible to design an operating system that could handle code that was stored in encrypted form on disk, and to be able to decrypt it as it loads it into memory (upon being passed the decryption key).

Yes it is possible, the operational system must decrypt first before relocating the data, but this is not the way as Windows works.

Anyway encrypting the code will help nothing, you can always dump the memory after the code was decrypted and so you will have the executable without any protection.

I'm sure Renderosity has a vested interest in discouraging and preventing the spread of warez.
I'm also sure that applies more directly to the spreading of Renderosity Marketplace warez.

Now, if it could be done practically, and efficiently, I'd say the best place to start on the crusade to alienate the warezer's would be to demand serial/registration/proof-of-purchase info for the target application before any purchases from here could be finalized.

Quote - Only if the code has no reference to any data (only works with registers).

It can access any data that it knows the address of (though unless the program itself is capable of resolving memory references as it loads additional code into its own address space, the address of any data it accesses will need to be known at compile time).  It can certainly access the stack, through the esp register.

Code dynamically loaded by a program during execution is the same as code loaded by the operating system at load time - so long as the pages that the code is loaded to are executable.  Certain architectures (in particular, the x86) for the most part allow code to be executed from anywhere; others go to great lengths to insure that no page is allowed to be both writable and executable, which would make a scheme such as this impossible without some sort of awkward kludge.

Another possible way to do it would be to have an encrypted DLL that the program decrypts and then links to at runtime

Quote - Now, if it could be done practically, and efficiently, I'd say the best place to start on the crusade to alienate the warezer's would be to demand serial/registration/proof-of-purchase info for the target application before any purchases from here could be finalized.

Will help nothing, showing a serial number proves nothing, you can show any serial number that downloaded, borrowed or created with a keygen.
Registration is not mandatory, registers only who want to register and most people never register.
It only remains the bill, if someone is able to find where it is and of course it was not thrown in the trash.

Quote - It can access any data that it knows the address of (though unless the program itself is capable of resolving memory references as it loads additional code into its own address space, the address of any data it accesses will need to be known at compile time).

No, the real adress is not known at compile time

Quote -   It can certainly access the stack, through the esp register.

In the stack are only stored local variables and cannot be stored global or static variables.

Quote - Code dynamically loaded by a program during execution is the same as code loaded by the operating system at load time - so long as the pages that the code is loaded to are executable.

The code loaded is not exactly the same needed to be executable

Quote -   Certain architectures (in particular, the x86) for the most part allow code to be executed from anywhere;

Quote - others go to great lengths to insure that no page is allowed to be both writable and executable,

What can be marked as not executable is data, the code to be executed must alway be market as executable and it must be writable too, if not no dynamic allocation of memory would be possible.

Quote - Another possible way to do it would be to have an encrypted DLL that the program decrypts and then links to at runtime

A dll is an exe file, only the extension was changed, the same procedure apllied to exe files is applied to dlls, ocx, acm, drv, ax, and much more. All are exes!

You are not understanting what relocation means, I'll give an example:

CODE SEGMENT
MOV    EAX,[MYDATA]
INC     EAX
IMUL    [SCALE]
balh blah blah
CODE ENDS

DATA SEGMENT
MYDATA DWORD  0
SCALE   DWORD  25
BLAH      WORD  ?
blah blah blah
DATA     ENDS

 This program is accessing from memory MYDATA and SCALE, but as the compiler does not know when the data will be when the program is loaded into the computer memory, it assign values starting from 0 in the data segment and of course the code segment also start from 0.
So the code created by the compiler will be
MOV    EAX,[0000]
INC     EAX
IMUL    [0004]
balh blah blah
But the real adress cannot be 0000, 0004, etc, at this location is stored the interrupt table of the 80xx86.
Also the compiler cannot know where is the data used by other module of the program, each module has his own compilation.
To solve the problem of the unknown memory locations, the compiler create a table of all the memory references and the position in the code where it are.
This table is passed to the linker that will join all the codes created by all the modules and also will create a global table of all the memory references that cannot be resolved by the linker.
The resultant code (it can not be used because has no real memory references) is stored in the exe file, but also is stored the memory reference table in the exe (is stored in the heading of exe before the code itself).
Until now the code is not usable unless you have the miracle when what is in the code and where the memodry is are the same.
When Windows want to execute the program, it loads the code somewhere in the memory and also allocates memory where data will be. Then Windows takes the relocation table, looks at each entry, calculate the exact real memory address and using the other table entry it modifies the code changing the value of the memory referrence to the correct one.

Not only data is relocated, many times code itself is relocated if you use tables.

Want something more dramatic on relocation?
Let see this code in C MessageBox(0,"Hello","",0);
You are calling the function MessageBox, the C compiler will create the code for this line, the code will be pushing the parameters in the stack and then calling the routine MessageBox
PUSH 0
PUSH 0
PUSH [xxxx]  ( the address of the string Hello)
PUSH 0
CALL ???????
What the HELL it will call?, where's the address of MessageBox, where it is located?
MessageBox is a Windows function, this routine doesn't exist in the exe file!!!!
Your compiler, linker and the exe file generated have no way to know where Windows will load in memory the function MessageBox.
What exist in the code in the exe file is CALL 0000 (not exactly this, it use call tables but in the end is resumed in this way).
All Windows functions calls are CALL 0000 in the exe file, no matter which function you use.
When Windows load the code it also will relocate this CALL 0000 and modify the code with CALL 0E83406FA, where 0E83406FA is the real address of MessageBox.
Next time Windows start the address can be 12345678, but your exe file has always 00000000

 

Amazing, kawecki, that you didn't notice my sarcasm....

heh heh...I picked up on it Mike.

I guess the descriptive context of the exchanges between kawecki and Talain could be considered approaching the threshold of validating the TOS, But I'd bet that 99% of us have no idea of what they are talking about, or know how to implement and deploy such things....I think it still fall within the scope of the TOS. I also happen to find it quite interesting reading.

 

Hey...if nothing else...I can fake topical knowledge of such things at dinner parties...After all... the party goers wouldn't  likely know if I knew what I was talking about anyway....lol

 

That is...unless one of them DID know about such things, and caught me bull sh**ting while standing around the guacamole dip..

I suppose that very much depends on which parties I choose to attend.

I though the dongle solution might be a viable alternative, but then again...what do I know about "Reverse Engineering", "Cracking Codes", and "Using Mathematical Algorithms" to make it all happen?..I suspect my brain just couldn't wrap my head around it even I was trained on the subject.

 

I'd wager that 99$ of the exchange might as well be written in Egyptian hieroglyphics...I simple know little to nothing about compiling code....But I still find it fascinating to bear witness to a debate/exchange...between two folks. whom are obviously experienced on the subject....and happen to know what they are talking about.

:.

Smart (and funny) people, are among the folks I like to hang out with most.

 

 

Now...How do I attach an image to this post and get to the last page without it being blank?

 

8 )

 

Tom <~~~ Bustin Mike Chops.

 

Yer a regular comedian there, Tom. :woot:

Quote - Amazing, kawecki, that you didn't notice my sarcasm....

Sorry, I didn't understood the esence.

Quote - I guess the descriptive context of the exchanges between kawecki and Talain could be considered approaching the threshold of validating the TOS, But I'd bet that 99% of us have no idea of what they are talking about, or know how to implement and deploy such things....I think it still fall within the scope of the TOS. I also happen to find it quite interesting reading.

It's only knowledge, but knowledge is like a knife, you can eat with it and you can kill someone, it only depend on how you use it.
Any technical software knowledge can be used for hacking (used in a bad way) and real hackers have very much technical knowledge than I have.
 If making public the knowledge would be forbiden then wouldn't exist people to make any software.
I agree that 99% don't understand what we are speaking about, but I think that is very useful for them realize that things are not in the way as are told and what is secure is not really secure.
You have a lock for your door that the propaganda tell that is 100%, you feel secure after installed it in your home. But this lock is nothing secure, it can be picked in few seconds and you don't know it.
Making public this knowledge is not an incentive to thieves, the burglars don't need it, they already know and use it and who doesn't know it will learn it in jail that is a University of crime.
Making public this knowledge will make you realise that the lock is a fiasco, protect you nothing and you wasted your money. If you knew that the lock was not secure, you should never had purchased it and purchased something better instead.
There's a great security industry, they create you the illusion of security, but it's only an illusion, if it would be real another huge business would be destroyed: Insurance.
 

I know how relocation works, kawecki.

The DLL trick would work because Windows does all the relocation for you when you link to it, either at load time or dynamically with the LoadLibrary call.  The same as linking to any other DLL, except this one was just created.

If the operating system was designed to support it, it would even be possible to have the DLL "file" exist only in memory, and protected so that no other process would be allowed to access it.

And some hacker would find a way around it anyway.  (Or the more likely scenario, with a database of stolen keys would just create the keygen, rendering the rest of the protection scheme moot).

Quote - The DLL trick would work because Windows does all the relocation for you when you link to it, either at load time or dynamically with the LoadLibrary call.  The same as linking to any other DLL, except this one was just created.

DLL is just another exe file, DLL load into a memory when an exe file needs this DLL and is relocated before is executed, so no difference between an ordinary exe file.
The only way to have an encrypted EXE or DLL is to load it into memory, decrypt and only then relocate, but this is not the way how Windows work.
It is possible to make an encrypted EXE, but the task is very tricky and is not possible to have 100% encrypted, only a part of the code can be encrypted.
This is not easy task, is needed some knowledge that normal programmers haven't, you must be very careful what you are doing and any debug, bug correction, patch or update will turn into a pharaonic job.

Quote - If the operating system was designed to support it, it would even be possible to have the DLL "file" exist only in memory, and protected so that no other process would be allowed to access it.

But this kills the DLL concept!. DLL are libraries for anyone and any task use them.
If you want to some DLL to be exclusive to why, why do you use a DLL? You can link a static library to your code and all will be contained in your EXE.

How do you patch an encrypted file?
A patch is a small program that change some bytes of code to correct a bug. If the code is encrypted there will be no way to patch the program.
Patches are useful because can be easy downloaded from any site, as a patch only works with the original code you can make the patch public and with free access.
With encrypted software patches are not possible, for any bug correction you must release a full program that can be big, not so easy to download or get and of course you cannot make it public!

I know someone with a dog called Patch. Found him and his 8 siblings on the Fojal river.

Attached Link: RivaTuner

Hey Kawecki, you're a technical guy - could you answer me a question please? I downloaded this freebie app, called Rivatuner, which is an overclocking/tuning app for Nvidia vid cards. I have a GeForce 7600 which is already pretty quick, but this program sped it up pretty well. I played around with the settings with Lightwave and the game Oblivion, and it did real well.   Then I tried it with Poser 7, and although the preview display sped up somewhat, it caused P7 to crash the second a render was finished. I tried it several times, with different figures and props and so on, each time with the same result - Poser 7 just crashed. Not a hang, but just *poof* - gone.

Any idea why, or what could be done to prevent it?
Also, due to other things I've seen, it seems that P7 completely takes over my video card, so I'm wondering if they have some sloppy OGL programming going on in P7.
For example, I often have LW and Poser open at the same time. if I open LW first and load something, all is well. But if I load Poser 7 first, then LW, the OGL performance in LW is horrendously slow. I don't know much about it, but I wonder if Poser simply hijacks everything it can get ahold of in the video memory and takes over the whole vid card for that matter.

Quote - A dll is an exe file, only the extension was changed, the same procedure applied to exe files is applied to dlls, ocx, acm, drv, ax, and much more. All are exes!

I think this is the only thing I have learned new out of all this tech speak....the rest  totally baffles me

MikeJ:
I can help very little, I know very little of video cards.
I don't know what Riva turner does, if its speeds the clock or does another thing.
Overclocking can make a hardware run faster, but not always works.
The speed of the hardware depend on a clock, faster the clock faster the hardware. Overclocking makes the clock run faster beyond fabricant's specification and can make the hardware fail or not.
If something is specified to have 100 MHz max, but it doesn't mean that with 101 MHz will not work, it means that the fabricant garantee you that it will work up too 100 MHz, above 100 MHz the fabricant is not more responsable.
How much above 100 MHz?, well it will depend of the quality of the component and luck. Probably it will work at 110 MHz, it's only 10% above, probably it will not work at 120 MHz, but if you have luck it will work. The same model, the same version, one will work more above, other less.
The only way to know is to experiment, if it doesn't work or crash too much, use less overclocking.
Anyway is not very safe to overclock too much, even when application doesn't crash. Temperature!!!
Temperature depend on the clock, faster the clock more hot becomes the component, so exist the risk of burning the component..
You can touch the all the components of the hardware. Components can be hot but not enough to cause harm to your fingers, if something is at that level, reduce the overclocking, put another fan. If you can touch without problem then all is fine.
If you are able to run games without problem then Riva turner is ok (check the temperature). I think that the problem of Poser 7 is that is full of bugs, why should a video card make crash an application?

I once had a video card fry itself due to heat, and that was without overclocking it.  My 6800GT would frequently hit well over 100 degrees C (according to the software that reported the temperature; I would not have believed it possible for IC chips to continue working at all at such a temperature).  Eventually it got to the point where my system would not run for more than a minute or two after booting up without crashing (in this case, displaying a constant pattern of random colors on the screen and do nothing else).

I replaced it with a 7900GT which runs much cooler.

Anyway, in most cases I don't recommend overclocking, or at least be very careful with it.  In MikeJ's case it seems like the OpenGL functionality on his card can't handle the increased clock speed.  (note that I have absolutely no idea as to the internals of the card itself).  If Poser 7 works fine at your card's stock speed but crashes or hangs when you try to overclock it, then you shouldn't overclock it.

100 C degrees, damn!, this is hot.
I always had problems with CPU fans in my computer, less than half a year an the fan is gone.
People use fans for years and don't know that is a fan inside the computer.
I solved the problem adding one more fan (a bigger one) in the base of the cabinet somewhere below the CPU..

Thanks kawecki, for all the info. I pretty much knew what it was doing, 'casue I read as much as I could before doing anything at all.
temperature is not a problem, because the RivaTune program has a setting in it to adjust the fan speed on the card itself, to cause it to run faster, longer, at certain temperatures - all kinds of possibilities. Plus, I have another program which constantly monitors CPU and inner case temperatures (HD temperatures as well), and that display is always up where I can see it. I have a 3.2 ghz Pentium and it never goes above 45C. The case temp never goes above 44C, and the Nvidia software shows the vid card temp at all times too. An hour of Oblivion with everything set at max made a temp of 56C in the card.

*"*In MikeJ's case it seems like the OpenGL functionality on his card can't handle the increased clock speed. "

Not true. I had both the memory speed and the core clock up 25%, playing Oblivion, running Lightwave, and twisting and spinning hi-res texture models around in Deep Exploration, all with no problems at all. Nice speed increase, no problems at all, no instability as far as I saw in a few hours of messing around and rendering.

It was only Poser 7 that had a problem with it, and I tried it with Poser 6, too, also with no problem.
They did do some mucking around with Poser's OGL in Poser 7, which is what leads me to believe somethin' ain't right there.

Oblivion uses DirectX.

If other OpenGL apps seem to work fine but Poser 7 consistently crashes, then it could be something to do with the app itself (it's clear that thing still has a few bugs that need to be fixed).

If you get the same problems even when you are running your video card at the stock speed, then it's not even the overclocking that's causing it, just Poser 7's bad programming.

Though it's probably the case that nVidia deliberately rates their 7600 parts at lower speeds than they're actually capable of so they don't compete with their higher-end 7900 parts.

The story of a Bug and Microsoft.
More than ten years ago I had no idea about 3D, as I always had interest in the theme I downloaded a 3D rendering library from Intel. The library was a pack of DLLs and application examples for Windows 3.1, it was well before any Windows 95, DirectX or OpenGL.
In the package were included some applications and the source code of the applications. Some examples were amazing, you were able to rotate the famous teapot, change its material, apply textures or environment maps and load other models. As I knew nothing about the theme the first step of learning something is to compile the source code and see if it works the same as the demo.
As I use Borland C compiler, I had to change a little the sintaxis of the code and after some work I had my compiled demo running. The next step should be to understand the code, introduce own alterations and so on, but before this the compiled version and the original version must run in the same way, if not you have no refference where a possible error can be.
I played with my compiled version and it worked fine, but in some particular case it crashed. I opened the original demo, run the particular case and no crashes in the demo. Repeated the test many times and always the same story, why version crash and Intel's do not.
I must have done something wrong with the code, so my version was not the same as the original.
I looked at my code and it was exactly the same in the point of the crash, the error was a floating point error. Once unable to find the error, I had to use the debug and run instruction by instruction to find the point where the error happens. I find the point, but no information about the source of the error. The error was that some floating point variable has an undefined value and crashed in the moment when was used. The question was why the variable had a wrong value?
I spend a lot of time trying to find where the variable came wrong and reached the conclussion that a function call to some Intel's DLL returned the wrong illegal value. The DLL was doing something not to be done!
As I only had the code of the apllication and no code of the DLL, I began to disassemble the DLL. After a lot of work I had the source code of the function responsable for the error and it was a bug there, Intel forgot one POP instruction in the subroutine return.
I tweaked a little the hex code of the DLL correcting the bug and apllication run fine without any crash.
Well, I found the bug and corrected the error, do you think that is the end of the story?, no it's jsut the begining of another biger one!
The question is easy, Intel DLL has a bug, but why the bug makes crash only my code and not their original code?????
I supposed that the source code of the package was not the same as the used in their demo. Not always the source code that comes together with the executable are the same, many times the executable is compiled with a newer version of the source code. So it must be something different in the demo exe that make it not crash.
Even I had the source code I had to disassemble the demo to try to find where was the difference. After a lot of work I had the demo source code, compared it to my source code and amazing, it was equal!!!!!!
Something impossible is hapenning, I and Intel used the same code, but my code crash and Intels do not!, a nightmare!!!!
Both executable codes cannot be the same, one crash and the other don't, as the source codes are the same there must exist some difference of how is generated the executable. I compared  the executables and are exactly the same in the part of the program, so the difference must reside somewhere outside the demo program.
I compared the whole exe and there were some differences, the reason of the difference was that I used Borland's compiler and Intel used Microsoft's compiler.
As the part of the code is the same the difference must reside in the prologue added by the compiler before the code start to run.
After hard work and a lot of more dissamblies I found it!!!!
The difference was in how Microsoft and Borland deal with exceptions (something that is wrong and can make the computer malfunction).
Intel DLL had a bug that in some cases a floating point NAN value was returned (an illegal value), it is a serious error because a floating point operation never can return this value and any attempt to use this value will cause an invalid operation of the floating point processor (something as try to divide by zero, or zero divide by zero, square root of a negative number).
Once the buggy DLL returned a wrong and illegal value the next time it was tried to be used the floating point unit raised an exception that started the execution of an exception routine (something must be done, the program did something not to be done) and the response of Borland to this error was quite different to MIcrosoft.
Borland compiler is very strict, it don't let pass errors, when an error happens it aborts the program.
Microsoft compiler on the other side cared very little of errors, so in this case this error was ignored, the program was not aborted and let the program continue working with a wrong result.
Well, a wrong pixel doesn't cause any harm, but if it is a wrong sum of your bank account????

yeah, Oblivion uses DirectX - 9.0c to be precise, but I thought it also used OGL?
I say that because on my old machine I had a GeForce 5700 AGP, which couldn't handle Oblivion. Then I upgraded to a GeForce 6600, AGP, and it ran it great. My newer machine has a PCI-e x16 GeForce 7600 GT, which, as I've mentioned does pretty well. Gonna move up to SLI for the next machine, a dual core AMD 64 bit, hopefully in February.

In any event, I was under the impression that DirectX was a software-based accelerator? Although I wouldn't claim to know much about it.

---

I finally had a crash with Poser 7 - the same type of crash; the poof, I'm outta here kind - immediately at the end of a render, with out any overclocking on the vid card this time. Hasn't ever happened with LW or anything else, OC or not. I don't know what they did to P7's OGL, but I think something happened somewhere.

Kawecki, are you trying to say maybe it's the way it was complied?

Quote - Kawecki, are you trying to say maybe it's the way it was complied?

No, if it crash then is a bug, my curious case was the inverse, a bug didn't made crash.