DVDFab Decrypter's Worrisome "Feature"

[CobraPilot]

DVDFab Decrypter may have a worrisome "feature":

In WinXP, it excludes itself from Data Execution Prevention (DEP), allowing it to do *something* in the background. I don't know what that might be, but I sure don't like it, since I am NOT given any sort of warning of this self-exclusion.

As Microsoft explains: "Data Execution Prevention (DEP) helps protect against damage from viruses and other security threats."

This COULD be viewed as a malicious action by the developer, since there is no obvious reason why DVDFab Decrypter needs to be excluded from DEP's protection. Someone with a lot more knowledge about such matters than I would have to comment further on it, but I sure am suspicious.

To check your WinXP system:

o Control Panel, System, Advanced, Performance, Settings, Data Execution Prevention

If you use DVDFab Decrypter, you may find it in the list of programs to be excluded from DEP . . . and then you may want to ask "Why?"

[mpack]

As Microsoft explains: "Data Execution Prevention (DEP) helps protect against damage from viruses and other security threats."

The obvious answer is that it uses self modifying code (or on-the-fly code generation) for speed. It probably uses lots of underhand tricks in order to perform its function. Who knows?

I don't see much cause for concern. Just because self modifying code (done in a particular way) is a common technique for viruses and trojans to use doesn't mean that all software which uses those techniques is by definition a virus or trojan. The best way to guard again trojans and viruses is to only run trusted software on your PC - so if you don't trust DVDFab Decrypter then perhaps you should stop using it, regardless of whether DEP is turned on or not.

Or you could just email the authors and ask why they need DEP turned off for their app.

[CobraPilot]

I guess I miss the obviousness of your "obvious answer" since I can't fathom why turning off DEP would have anything to do with "speed." How could that help?

As to contacting the author(s), if something's fishy about the DEP turn-off, why would I expect to get a straight answer?

I'd feel more comfortable in hearing from a code guru NOT affiliated with DVD Fab who could shed some light on this.

Just my paranoia, I guess, but these days, being paranoid about malware is not unwarranted.

Any code gurus out there who could help explain this?

[Ethlred]

I have no idea if mpack's speculation is accurate but DEP does block self-modifying code. Changing code on the fly does make some things faster. There is no need to check a look up table every bloody time through a loop if you just set a jump to a specific address. Bypass flags, pointers, and other various state tests just by setting the addresses in an initial setup. Of course such code is bloody hard to debug and very much frowned upon in anything like a multi-programmer project.

Its a hacking tool from back when I last wrote any code in the 80's. Every bit (literally) was important and not to be squandered. Every cycle counted and branching used a lot of cycles. These days its not that bad and self-modifying code should be a very rare thing only used in inner loops that absolutely have to have the fastest code possible that cannot be done any other way.

[Ai Haibara]

That's not exactly what mpack meant, I believe. Look at it this way: DVD Fab's code could be designed to do a few things that trigger DEP's interest, like modifying its own code. Sure, malware does it. So do a few legitimate programs, here and there. It doesn't mean the latter programs are malware, as well.

So, assuming the only thing DVD Fab's doing wrong is making itself look like it could be malware to DEP, turning off DEP for DVD Fab would prevent DEP from 'complaining' about the program or preventing it from being run.

[mpack]

I'd feel more comfortable in hearing from a code guru NOT affiliated with DVDFab

Paranoia in several senses I see. The software and me.

I am in no way affiliated with DVDFab. In fact I have never even used their product(s).

[mpack]

These days its not that bad and self-modifying code should be a very rare thing only used in inner loops that absolutely have to have the fastest code possible that cannot be done any other way.

But if these tricks are used, they'll be used by apps that need to process GBs of data in a reasonable time, ie. precisely the kind of apps that populate the tools section on this site!

But I agree, eliminating branch overheads using self modifying code (or on-the-fly code generation) was always considered dirty trickery and frowned upon from a code maintenance POV.

[CobraPilot]

mpack, my apologies. The only "paranoia" I felt toward you, if any--and I certainly didn't mean to offend--, is because your original answer seemed to be purely speculative, with no indication you were a "code guru."

I certainly acknowledge that my poorly worded followup seemed to suggest you were somehow affiliated with DVDFab, and that was my error.

Ethelrod's response was more from a "code guru" point of view; he seems to have established his "bona fides" as to that status of expertise by citing his coding experience.

Again, my apologies if I gave offense.

[mpack]

Again, my apologies if I gave offense.

Well thank you for a very polite apology, but there was really no need. (a) I'm thicker skinned than that, and (b) I only wanted to make clear that I'm not offering biased opinions (ie. not affiliated with the authors of the tool)... before the notion spread too far.

As to not making my bona fides clear... I find on this site that if you claim to be knowledgeable on any subject you just get peoples backs up... Better just to offer advice which speaks for itself.

And oh yes, on my original response being "speculative". It certainly was, but without access to the DVDFab sources it kind of has to be. My point was simply that the kind of code behaviour that trips up DEP, Antivirus etc is not the exclusive preserve of malware: perfectly innocent apps might use the same coding techniques, usually for speed or lower memory consumption and so on: and I would be amazed if none of the tools available for download via this site used them, despite those techniques being considered inelegant by some purists.

[MOVIEGEEK]

The maker of DVDFab posted here a few months ago that he makes an exemption for DEP so the Pathfinder feature works properly,there is NO threat to your PC.
If you are paranoid you can remove the exemption and his programs should still work,you will have to remove the exemption everytime you update his programs though.

[CobraPilot]

Ahhhh! Now THAT'S an answer I was looking for (but couldn't find in a previous search on this topic).

Perhaps the author should explain this on his website to head off paranoics like me . . .

[Ethlred]

Ethelrod's response was more from a "code guru" point of view; he seems to have established his "bona fides" as to that status of expertise by citing his coding experience.

I have very little coding experience. It was twenty years ago on my Apple ][+, a much less complex system than those of today. However I find the experience valuable in knowing the processes of coding. If I had only learned Applesoft (Microsofts first commercial basic) it wouldn't have helped much. Nor did the class in Fortran in college some years before that, as the teacher was Idiot With a PHd. What does help was learning 6502 assembler and Forth. Forth for the ideas of how to break down a problem into small steps. Assembler for getting right down to the nitty gritty of how the code is handled in the CPU.

I don't want to give people the impression I know far more than I do. However I did play with self-modifying code in assembler because of the serious limits on speed and the heavy cost of conditional branching on the 6502 processor. Nothing useful was ever done by me except for the learning. I couldn't even remember the term 'conditional branch' last night. Some guru.

[mpack]

I have very little coding experience. It was twenty years ago on my Apple ][+

I'd guess that must be closer to 30 years than 20! Say between 1980-1983. I suspect we started out at around the same time. I too learned BASIC and FORTRAN at college. My first job however (1980) was writing programs in Apple Pascal on the Apple ][+ The BASIC I've almost completely forgotten, but the FORTRAN knowledge is still occasionally handy for reading FORTRAN source code (eg. in my copy of "Numerical Recipes").

My early employers taught me coding discipline, but I always loved getting close to the metal (learned from necessity during that era), which is why nowadays most of my work is for embedded devices - it gives me a good excuse to still write some code in assembler (albeit DSP assembler)... It's been donkeys years since I did any significant assembler work for PCs. My preference is embedded, but I still have to write a lot of PC apps which interface with the embedded widgets. Also my video processing hobby involves writing a lot of related PC apps in my spare time.