It is nice to have a nice surpise every once in a while...

Yesterday or the day before I was working on an issue one of our customers had, and I thought Hey I am going to try something I never tried before.
Well we at Borland had this tool called TDUMP, or Turbo Dump (that should give you an idea how old it is) it is the equivalent to DUMPBIN from MS. It basically dumps file information from various binary file formats, like any PE binaries, COFF OBJ, libs etc. (and a couple of undocumented formats) Well this customer issue appeared to something related to the debug information generated for his application. The Borland debug info files have the extention of TDS (Turbo Debugger Symbols) ... So I though what da hell let's try TDUMP on TDS files, you guessed it... there all the debug information is dumped out in plain text (LOT of TEXT)!

It made my day!

Thanks Eli or Matt or whoever did it!

Now that this JPEG virus have seen the light of day...

I have become curious about Side-by-Side execution... (which I used to think of as great, but I have been having doubts about this now...)

Because even though I am running XPsp2, which does not contain the GDIPLUS and SXS DLL's that contain the vulnerable code (I not mentioning MS Office's MSO.DLL), I still have older vulnerable versions of GDIPLUS.DLL's in the \WinSxS directories???

So if you have the situation where an application's .manifest file points to one vulnerable ones what happens then? you system as open as a non-SP2 system, you have to rely on the other SP2 mechanisms to block any malicious code? or if someone distributes their own copy of GDIPLUS.DLL there is a version of Crystal Reports that allegedly does this, so hopefully they do not have a .local file and the GDIPLUS in \System32 will be used.

After having a look at Windows rootkits, I feel particularly uneasy about this exploit and the JPEG exploit toolkit which have been released, because once they are married the implications for non-patched systems is enourmous!

Thankfully our anti-virus software kills any jpegs containing the exploit.

And MORE SP1 issues...

From MS this time !

http://blogs.msdn.com/astebner/archive/2004/09/20/232236.aspx

More SP1 woes!

Well it looks like it is not just Borland tools having problems with SP1!

Paul Wilson seems to have found one more issue ...

Delphi 8 and .net 1.1 SP1

1) delete all *.dc* (BUT just make a copy of your $(BDS)\lib BEFORE deleting all the *.dc* files)in the $(BDS)\lib dir and $(BDS)\lib\debug dir (do not touch the other files eg. .resource, .res and .nfm files)

2) go to the $(BDS)\source dir and run the makefile file with "default" and "debug" options.
So from command prompt in the $(BDS)\source dir you run

"make default debug" (without the quotes)

3) delete all old *.dc* in you project dir and re-build.
4) in VCL projects you might still see issues but all you need to do is remove the references to the VCL assemblies in the project pane and then do a re-build of the project.
5) if you still see any compiler error, either remove the offending assembley from the references and do a re-build.