Latest Update cause access violation in Spyware Blaster

[hotasy2k]

After updating the latest detection update dated 16/04/08, and immunized spybot, i can't open spywareblaster, it caused a access violation error.
I then unimmumized spybot and i can open spywareblaster but as soon as i immunized it, the same error occur whenever i open spywareblaster.So high chance is the latest detection update is causing problem to spyware blaster.
Anybody having the same problem or know of a fix for it, pls kindly help me. Thanks
Spybot version: 1.5.2.2
Spywareblaster version: 4.0

[md usa spybot fan]

hotasy2k:

I am having no difficulty running SpybotSD.exe Version 1.5.2.20 and spywareblaster.exe Version 4.0.0.0 together.

Does the "2k" at the end of your username indicate Windows 2000 by any chance?

[hotasy2k]

no i'm not using win2000, i'm using winxp sp2 fully updated, are ur spybot & spywareblaster fully updated, becos, b4 the latest update for spybot, i do not have this problem, only after that then this problem occur.

Just did an unimmunize for spybot and able to open spywareblaster without error and disable all protection for spywareblaster., fully immunized spybot and enabled protection for spywareblaster protection one by one, protection for IE and restricted site can be enabled successfully, but protection for firefox can't same access violation error.

[PiCoPi]

I can verify the error too, just updated Spybot and SpywareBlaster has a problem with firefox.

Here is a printscreen!

Using Vista Ultimate here, but I don't think the OS is the issue, SB just blocks sth that SpywareBlaster uses to read from.

[MikeRophone]

Same SNAFU here with a Win XP SP2 laptop.

Truthfully, I'd rather have a working SpywareBlaster running in the background than an updated SpyBot, until it's fixed.

Spybot 1.5.2 is a winner, so I'll always have both. :bigthumb:

[Always Confused]

I, too, am getting an error when trying to start Spyware Blaster, version 4.0.0.0, after updating Spybot version 1.5.2.20 a few minutes ago, using Windows Vista Home Premium.

"Error Access violation at 0x005F71FC (tried to read from 0x07C60344), program terminated."

[EDIT]

Please see this thread in the Spyware Blaster forum:

http://www.wilderssecurity.com/showthread.php?t=206415

I removed all Firefox (Minefield) immunization in Spybot; Spyware Blaster then started (albeit with quite a bit of protection disabled, as expected.)

[MikeRophone]

Yes, it seems that by unimmunizing SpyBot, you remove some of the enabled protection in SpywareBlaster at the same time. :rolleyes:

[Javacool]

Hi,

I've tracked down the cause of this error.


Problem Details:

This problem is being caused by Spybot S & D writing invalid entries to the Firefox hostperm.1 file.

Specifically, Spybot is writing entries using unicode characters, such as:
"meine-Grußkarten.de"

This is invalid. According to the specification, these International Domain Names should be properly encoded as punycode before being written to the file. In the case of the domain listed above, it should be written to the file as:
"meine-grusskarten.de"

(More information on punycode, for anyone who's curious: http://en.wikipedia.org/wiki/Punycode)


Resolution:

For the time being, I would recommend undoing/disabling immunization for Firefox in Spybot S & D - to prevent Spybot from writing these invalid entries to the file.

This should allow you to fully enable protection in SpywareBlaster.


Other Notes (for PepiMK):

A quick fix on Spybot S & D's end would be to simply remove those sites from the database, until the Spybot program itself is fixed to write the properly encoded entries to the file.


Best regards,

-Javacool

[Gramm]

Hi, new on this forum - found it by looking for info on this Spywareblaster problem; relieved to find I'm not the only one having the problem!
Interestingly enough, I've been having (more or less) the same problem for a couple of weeks or so on one machine that I still run on Win98se (there is a reason!) - can't remember exactly when, but suddenly when trying to start Spywareblaster for an update it would freeze and could only be "switched off" by the Alt/Ctrl/Del buttons - every time, just as it started to load the Firefox protections.... however, in these cases, there was no error message at all!
On three other machines (two XP Pro, one XP Home), no problems - until today.....
...Another (temporary) quirk with Firefox was with Vista - FF wouldn't start, and the process couldn't be stopped - however, that's all been sorted now, thankfully!

Gramm

[lking]

Hi,

For the time being, I would recommend undoing/disabling immunization for Firefox in Spybot S & D - to prevent Spybot from writing these invalid entries to the file.

This should allow you to fully enable protection in SpywareBlaster.


I'm having the same problem with getting the Error Access Violation. Regarding your solution, how do I disable the immunization for Firefox in Spybot S & D?

[md usa spybot fan]

lking:


I'm having the same problem with getting the Error Access Violation. Regarding your solution, how do I disable the immunization for Firefox in Spybot S & D?
To undo the immunization for Firefox:
Go into Spybot » Immunize.
Right click on the right hand pane and select "Deselect all".
Check just those items listed as "Firefox".
Click the "Undo" button at the top of the right pane.

[lking]

Thanks. I think I now have everything protected. Am I going to have to go through this every time I run Spyblaster?

[PiCoPi]

Thanks. I think I now have everything protected. Am I going to have to go through this every time I run Spyblaster?
Hopefully not, as the is issue is going to be fixed :)

[PepiMK]

@Javacool: Well, first, I just don't like your attitude. While everyone can see that there's a problem, it's clearly not just on our side. An access violation is always the fault of the developer of an application where he did not handle errors the way he should (well actually where he doesn't at all ;) ). Except for a few cases where code injection has taken place, and I hope you don't suggest this.

And I'm sorry, but you've got it wrong. The hostperm.1 file is not expecting domains in Punycode at all - it is written in UTF-8 by default, which is quite a difference. And UTF-8 is a text format that was designed specifically to be able to be detected. Which means that any application that is designed to deal with UTF-8 files (as SpywareBlaster is) is supposed to be able to detect whether the file is ANSI or UTF-8, and handle it accordingly (UTF-16 may need BOMs, but UTF-8 is designed to be recognizable without BOM). So, to provide you with a piece of information for the curious as well ;)
http://en.wikipedia.org/wiki/UTF-8
Read the part about the rationale behind the design.
(btw, Firefox, doesn't recognize the ANSI format either, but at least it doesn't crash on this error ;) )

That does not mean I don't see a problem on our side as well - we should store the domains list in UTF-8 format, but that is, contrary to your bad error handling in SpywareBlaster (sorry for punching into that wound, that's something that actually happens to everyone, but since you decided to put the blame on one side only... ;) ), nothing that would needed to be fixed inside the program itself, just in the database.

Sorry if this sounds aggressive, but I just didn't like the attitude that when you can't admit that your program is not able to handle unexpected errors, you run and ask others to fix it, while the fault is actually on both sides.

[PiCoPi]

Peace brothers!

@PepiMK when will be the new database available to update? (Hope you won't come onto me now :p:, ok j/k!)

[PepiMK]

Hehe, I'm at peace, I'm just a bit cynical ;) Since I shouldn't be typing at all, my wrists actually should be faaaar away from any keyboard (a bit of RSI), and the guy on duty this night does not call back. Could be tomorrow morning (9 hours plus time to prepare and test updated update) then.

[Javacool]

@Javacool: Well, first, I just don't like your attitude. While everyone can see that there's a problem, it's clearly not just on our side. An access violation is always the fault of the developer of an application where he did not handle errors the way he should (well actually where he doesn't at all ;) ). Except for a few cases where code injection has taken place, and I hope you don't suggest this.

It was not my intention to suggest that no fault existed in SpywareBlaster, and I apologize if it seemed that way.

The access violation in SpywareBlaster is indeed because some code does not expect certain Unicode characters. And this will be fixed in an upcoming release.

However, it is still contrary to the expected Firefox behavior to store domains without first converting them to punycode in the hostperm.1 file.


And I'm sorry, but you've got it wrong. The hostperm.1 file is not expecting domains in Punycode at all - it is written in UTF-8 by default, which is quite a difference. And UTF-8 is a text format that was designed specifically to be able to be detected. Which means that any application that is designed to deal with UTF-8 files (as SpywareBlaster is) is supposed to be able to detect whether the file is ANSI or UTF-8, and handle it accordingly (UTF-16 may need BOMs, but UTF-8 is designed to be recognizable without BOM). So, to provide you with a piece of information for the curious as well ;)
http://en.wikipedia.org/wiki/UTF-8
Read the part about the rationale behind the design.
(btw, Firefox, doesn't recognize the ANSI format either, but at least it doesn't crash on this error ;) )

That does not mean I don't see a problem on our side as well - we should store the domains list in UTF-8 format, but that is, contrary to your bad error handling in SpywareBlaster (sorry for punching into that wound, that's something that actually happens to everyone, but since you decided to put the blame on one side only... ;) ), nothing that would needed to be fixed inside the program itself, just in the database.

Sorry if this sounds aggressive, but I just didn't like the attitude that when you can't admit that your program is not able to handle unexpected errors, you run and ask others to fix it, while the fault is actually on both sides.

I realize the file itself is written in UTF-8 format, but the domains are expected (by Firefox) to be written in converted punycode format. (I know it's weird, and I encountered it while testing a while back, but this is the current behavior of Firefox on Windows.)

Please try adding the site mentioned above (or any International Domain Name) to Firefox's Cookie exclusion list using the built-in window in Firefox. FF first converts the domain name to punycode before storing it in hostperm.1.

In fact, entries written directly to the hostperm.1 file with unicode characters (including the "meine-Grußkarten.de" site) aren't properly loaded or used by Firefox. This can be verified by writing the following cookie entry to the hostperm.1 file:



host cookie 2 meine-Grußkarten.de

Firefox loads and parses it incorrectly. (On some language versions of Windows - I haven't verified for all - it is displayed as "meine-Gru????", and doesn't have any effect against the real site.)

I'm not saying this is necessarily the best way for Firefox to be doing things, especially since it stores the data as a UTF-8 file. But for whatever reason, it's the current behavior.

So we are absolutely working on a fix on our end, to handle malformed hostperm.1 files, and I take full responsibility for SpywareBlaster not being able to do so in all circumstances. I wasn't trying to imply that no fault existed on our end, and I'm sorry if it came across that way.

However I'd also highly recommend a fix in Spybot's database for the short-term, as the entry mentioned above is also not what Firefox is expecting, and is misinterpreted by Firefox as well.

Best regards,

-Javacool

[PepiMK]

Sorry that I have to say that you're wrong again ;) Since I am pretty sure that Firefox does not expect the average user to convert any umlaut domain to Punycode by himself and then enter the converted format into the Firefox GUI ;)

Your example is badly chosen there (well, absolutely not your fault since you seem to be a native English speaker and knew just that ß right away now) - try to add test-äöü.de through the Firefox GUI (Cookie exceptions for example), and afterwards look into the hostperm.1 file. This domain will be stored as UTF-8, with no Punycode involved at all.
"ß" is probably the bad example since "ß" is "ss" both in Punycode and in UTF-8. Take my example from above instead and see that it will look like, when viewed as ANSI, as test-äöü.de, which clearly is just the UTF-8 representation and not any Punycode representation. If it would have been stored as Punycode, it would look like xn--test--kra0kzb.de.

Actually, Punycode and UTF-8 are kind of contradicting even - Punycode was designed to use just a small subset of ANSI, so if domains would have to be stored as Punycode, it would not matter at all whether they would be ANSI or UTF-8, since ANSI and UTF-8 would be absolutely identically for any Punycode-formed domain and the problem wouldn't even exist ;)

@edit for another comment: or do you regard "converted Punycode" as something different?

[Javacool]

Sorry that I have to say that you're wrong again ;) Since I am pretty sure that Firefox does not expect the average user to convert any umlaut domain to Punycode by himself and then enter the converted format into the Firefox GUI ;)

On my installation of Firefox on a test machine here (Firefox 2.0.0.13 on Windows XP SP2), Firefox automatically converts the domain name input to punycode (EDIT: see below - in some cases).

I input "meine-Grußkarten.de" in the "Address of web site:" box on the Cookie Exception list screen, and Firefox first converts it to punycode before storing it in the file. (This is also represented in the interface itself.)


Your example is badly chosen there (well, absolutely not your fault since you seem to be a native English speaker and knew just that ß right away now) - try to add test-äöü.de through the Firefox GUI (Cookie exceptions for example), and afterwards look into the hostperm.1 file. This domain will be stored as UTF-8, with no Punycode involved at all.
"ß" is probably the bad example since "ß" is "ss" both in Punycode and in UTF-8. Take my example from above instead and see that it will look like, when viewed as ANSI, as test-äöü.de, which clearly is just the UTF-8 representation and not any Punycode representation. If it would have been stored as Punycode, it would look like xn--test--kra0kzb.de.

Actually, Punycode and UTF-8 are kind of contradicting even - Punycode was designed to use just a small subset of ANSI, so if domains would have to be stored as Punycode, it would not matter at all whether they would be ANSI or UTF-8, since ANSI and UTF-8 would be absolutely identically for any Punycode-formed domain and the problem wouldn't even exist ;)

@edit for another comment: or do you regard "converted Punycode" as something different?

It looks like Firefox's behavior is slightly more complicated than I initially expected. It does not, by default, convert any and every domain name that contains non-A-Z characters to punycode. It does however, perform some sort of normalization process on all domains before storing them, and it converts some domains to punycode.

You are absolutely right that "test-äöü.de" is not converted to punycode, when input in the Cookie exception box. I believe this is because the characters are clearly not regular "a" "o" and "u" characters. (The punycode / normalization is mainly used for display in Firefox to help prevent phishing.)

However try the following domain name:


tūdaliņ.lv

When input in the Cookie exception window, Firefox converts it to "xn--tdali-d8a8w.lv" and it's stored in the hostperm.1 file that way.


So it seems the expected Firefox behavior is more complex than originally thought.

However, if you wouldn't mind, it seems Firefox still expects "meine-Grußkarten.de" to be stored in the file as "meine-grusskarten.de". If you could either remove this particular site from the Spybot database temporarily, or fix it to write as "meine-grusskarten.de", it would help resolve the problem for all SpywareBlaster+Spybot users until I can push a new version out, and it would also conform to how Firefox expects that particular domain to be written. :)

If you'd like to open a Project Tracker entry on this issue, I'd also be happy to work with you to try to figure out exactly how and why Firefox converts some domains to punycode before storing them in hostperm.1, and others not. Such work would allow both of our programs to better conform to whatever algorithm Firefox is using to decide. :cool:

Best regards,

-Javacool

[PepiMK]

Btw, if you didn't try to put the blame onesided, I apologize for the harsh words.

Hmmm... that indeed looks quite complicated! ä, ö and ü are standard German umlauts that are clearly not ANSI characters. My first though there was that a German locale might be the cause here, but actually my system, from Windows in the back to Firefox in the front, is english.

And sure I don't mind, see the post above yours, it'll be updated asap (remove flag set for current entry, and correct entry added). Got hold of the guy on duty meanwhile and we agreed to do it tomorrow morning (starting in about 8 hours), not now, since we then could check where the unfinished file got in at all (see other post by md_usa_spybot_fan, the duplicate entries are another thing that shouldn't have happened).

More tomorrow, need to look up the Punycode stuff I already wrote first, been to long to remember everything (SDHelper does some phishing detection by checking domains for similarities to a list of payment sites).

[JohnBurns]

Ok -for those of us who don't really understand the issues - I have a question. Is Spybot S&D fixed yet? I have Spybot S&D 1.5.2.20, Latest Detection Update 4/9/2008, and at that point, there seems to be no problem. I would like to wait to update Spybot S&D after a solution has been reached between it and SpywareBlaster. When will it be safe to use both without fear again?????

[PiCoPi]

Ok -for those of us who don't really understand the issues - I have a question. Is Spybot S&D fixed yet? I have Spybot S&D 1.5.2.20, Latest Detection Update 4/9/2008, and at that point, there seems to be no problem. I would like to wait to update Spybot S&D after a solution has been reached between it and SpywareBlaster. When will it be safe to use both without fear again?????
At about 8 hours from now!

[JohnBurns]

Thanks for info, PiCoPi!

[Yodama]

hello,

new Spybot S&D detection update released today will fix this issue and Spyware Blaster will not be affected by the Firefox Immunization anymore.

[hotasy2k]

Just updated the latest update dated 17/04/08, it fixed the problem. Thanks for the fix.

[PiCoPi]

Yep fix worked great. Congrats to all the SB team members :heart:

[Carol]

Thanks for the "quick fix". It's very much appreciated.

Carol

[ME_2&]

I am much impressed with both parties .. major tip o' the hat to Pepi for the dedication under physical detriment and also javacool for all the :cool:

Firefox is a browser in motion and it does indeed have some 'interesting' quirks, one of the reasons to have alternates both within the Mozilla framework and others like Opera :)

[Teme-84]

The problem was also here. Well I just updated Spybot and now SpywareBlaster is working normally again. I was already wondering what's wrong..

[kissbaby]

thank u ,,all is good now

[donnydoodle]

It's still not working for me:sick:

[md usa spybot fan]

donnydoodle:

What did you attempt to do to resolve the problem?

[donnydoodle]

I downloaded the new S&D update. I even downloaded and reinstalled the current version of Spyware Blaster.

Still get the access violation.

[md usa spybot fan]

donnydoodle:

Did you reimmunize Firefox?

[Terminator]

When I downloaded the update it didn't immunize correctly and left 4 items in 4 different sections un-immunized even though I pressed "immunize" 3-4 times.

To solve the problem I un-immunized everything and waited a few seconds then re-immunized and hay presto problem solved:santa:.