Fabrice Roux *.*

Both Firefox and Thunderbird manage to turn off DEP when the Talkback addon is installed. It's the thingy that reports bugs back to Mozilla. Which 99.9% of the people can live without. :)

I read your article and had a look... Thunderbird is not having DEP turned on... Even stranger, when starting "thunderbird -p", this new instance has DEP turned on (so obviously it's not linked to some packer)

Btw, Thunderbird is of course not part of my exclusion list...

Going to google it.

Au mien il n'en rest qu'un à percer...

Unpacking the DLL doesn't remove the .aspack section in the header. This string triggers the DEP disabling.

I unpacked Opera.exe and its DLLs using CASPR and the aspack string is no longer in the executables. However, the DEP Status is still off for Opera.

Another backdoor or some other mechanisms for optout different from the documented ones?

I don't agree with you about ASPack. They are not the root cause of the problem. I don't know if ASPack was included in Borland Delphi but it seems that back in 2004 a lot of issues with DEP were Delphi/ASPack related. Microsoft is the one who chose to put these backdoors for some compatibility reasons.

Instead of a backdoor Microsoft should have put the pressure on ASPack by displaying specific warnings. If a program flaw was intercepted by DEP, they should check the exe header for a .aspack section. Then warn the user that the program they are trying to launch uses ASPack and doesn't play ball. In that case the user will be in control and will probably pressure the software vendor to fix this issue. Then the software vendor would chose to either dump ASPack or to transmit the pressure with a nice "make ASPack DEP compliant". I used ASPack for this example but it can be extended to the other backdoor strings.

In my eyes the compatibility mode already exist, it's the default OptIn. I haven't took the time to redo some tests but AFAIR Opera in AlwaysOn mode works. Which seems to mean that either the newer version of ASPack is DEP compliant or that Opera uses a different ASPack setup (packer + crypto ???) than XnView and IrfanView.

I chose to switch to FastStone Image Viewer a while back because I was looking faster/slicker solution. The only thing I miss is the one key full EXIF meta data display.

In my quest to the truth , I found a bunch of de-packers for ASPack and such. So using ASPack to protect your code is kinda limited. And the 3 main apps we are talking about are all Freewares.

I would understand that someone uses a packer on some software you launch multiple times a day (like an image viewer). But on a software you launch once per boot (like your antivirus), I really can't justify something that will make 100 to 300 ms launch boost that carries such a security issue.

ps: I don't use Talkback in my Firefox setups... I'd rather manually file a bug than having a call-back extension sitting around.

Thanks for important subject, Fabrice!

First of all, I suppose that ASPack should be eventually banned by both users and developers as a potential backdoor program.

The worst for me was the situation with antiviral program, that I had been using several years. It's a Doctor Web (http://www.drweb.com), all its modules are packed with ASPack. About a week ago I have discovered that Dr.Web becomes unable to start when DEP is turned in "on" state, i.e. AlwaysOn. Hence, all users of this antivirus are enforced (clearly or silently) to have the DEP in "off" (or OptIn/OptOut) state, creating a possible hole to malware(!) Now I gave up to use this program and switch to other DEF-friendly antivirus.

The second DEP bug that I noticed was in Firefox browser, and I had to switch off the Talkback add-on (this bug is linked to third-party component in FF and is known for developers, but still isn't fixed).

Today I encounter the problem with ASPack again: in XnView, which I'm using as a graphical viewer in Total Commander. After searching the possible solution (if any exists) I have found your blog.

In my opinion, ASPack is selected by some developers as a tool against the stupid hackers, to make their attempts to decrypt the program code more difficult. The serious developers, however, prefer the internal-made cryptographic algorithms and, of course, the digital signature, which is easy to check and essentially more hard to crack. On other side, for GNU/GPL code the encryption is completely unnecessary and this kind of programs could be DEP-friendly initially.

Encore un bon anniversaire à la pepette pour ses 12 mois !
et un message, aux heureux parents : grouillez vous! on attends les photos de l'anniv', nous!!!
biz

chris

Microsoft called the mode OptOut while it does OptOut plus dirty stuff in the back of the user. The "compatibility" DEP mode is OptIn, it's the default XP SP2 mode. It was OK back in august 2004 when the SP2 was freshly released.

Now 30+ months after the SP2 release, every single software vendor should provide apps fully DEP compatible. I easily found an open source efficient packer that is DEP compatible.

Calling this a backdoor is very unfair to Microsoft - what they did is providing compatibility. Without excepting these three executable protectors/compressors, programs using them would simply crash, period. What these wrappers do is decrypt/uncompress the executable sections in memory. To do that, the memory must be flagged as data. What they forget to do is to change them to code regions again once they are done with that - and that is to be considered a bug in those wrappers. So when jumping into the reconstructed code, the DEP mechanism would detect execution of data bytes, and immediately crash the program.

In fact DEP backdoor doesn't apply to malware... just legit software that are out of DEP supervising scope. A malware can do a lot of bad stuff without triggering anything on the host. DEP only intercept buffer overruns.

The only case where DEP might help with malware is if it has buffer overruns. :) But don't count on that... once the malware is in the place and that you run it you are screwed big time.

This effectively means that an evil (tm) program can do anything even if DEP is turned on; I wonder, what they were thinking about when making this possible...

I've seen a bunch of recurring comments on forums and newsgroups about this article.

The article title:
I weighted each and every single word found in the title. Microsoft called it's NX/XD bit implementation DEP. In no way I wanted to taint the reputation of these to bits or other OSes using this hardware technology to prevent bufer overruns. "Hardware DEP" says the ball in Microsoft Windows playground... not AMD/Intel or other OSes.
The title had to be short and efficient... I think I achieved my goal.

Backdoor or not?:
My definition of a backdoor is a more or less secret way to circumvent a security feature that was placed in the code on purpose. If there was a way to switch DEP off that was not implemented (read an exploit) I would call that a flaw. (bug/feature depending on which side of the Windows ownership border you sit)
In my eyes it's a Microsoft backdoor at the software management implemented on top of the (I hope reliable) hardware AMD NX bit and Intel XD bit. It redefines the OPTOUT mode to OPTOUT+BACKDOOR. If only Microsoft had created a 5th DEP mode called "Compatibility + OptOut" that warned the user when DEP was automatically disabled in the background. I wouldn't even have to post about that issue.

Warning to the various software vendors:
Late february 2007, I emailed both IrfanView and XnView... to date none of them replied. I have to admit that I used the probably widely spammed official email. Since I didn't found anything obvious on Opera website, I decided to hold off a little bit. Today I filed 2 bug reports at both Opera and IrfanView. These are not really bugs per se but they need to know about the issue generated by using ASPacked executables in Windows XP SP2.

Les deux sont des synonymes.

http://dictionary.reference.com/search?q=evidently

"Evidently" ? On ne dit pas "obviously" ?

merci. C'est pas trop tôt !!! lol

Bonjour Fabrice,

Juste un mot pour te féliciter sur la qualité des panoramiques exposés sur pbase. J'ai beaucoup apprécié, étant amateur du genre.

Bonne continuation et ... félicitations pour les dents !

Moi j'ai aussi eu BAD REQUEST :-)

Encore une fois, le site SNCF s'illustre pas sa médiocrité et s'engouffre dans la jolie série geoportail, INA etc

A noter que les syndicats avaient déjà posté sur le net des brèves pour alerter de la "prévisibilité" de la saturation.

Elle est vraiment trop mignone votre petite Pépette et elle a bien changé depuis la dernière fois que nous l'avons vue. De gros bisous à vous trois de la part des "Vauclusiens" !!

Qu'elle est belle ma fille !! C'est la petite pepette à sa maman. Une petite fille heureuse en famille.