Why tampered Strong name assembly continue to work?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I am always of the belief that once a strong name assembly is built, you
cannot modify it without invoking the verification failure on loading.

But the other day, a colleague of mine in the midst of getting something
done with the managed Directx library, Microsoft.DirectX.dll version
9.12.589.0, accidentally tripped the time bomb as Microsoft no longer
supporting this.

He could not stop what he was doing and found with the help of Lutz
Reflector the function
Microsoft.DirectX.InternalHelper.CheckTimeBomb()

and he changed the year using a binary editor from 2006 to 2518.

He ran his application and did not receive any TimeBombException and
obviously his hacked code works. But it begs the question how a strong name
assembly could be hacked in this manner without tripping the verification
check?

I ran sn -vf on the command line for the Microsoft.DirectX.dll and it failed
the verification. Here is the disassembled code of the function to show the
change:
..method public hidebysig static void CheckTimeBomb() cil managed
{
.maxstack 4
.locals (
[0] [mscorlib]System.DateTime time1)
L_0000: ldloca.s time1
L_0002: ldc.i4 2518
L_0007: ldc.i4.s 10
L_0009: ldc.i4.5
L_000a: call instance void [mscorlib]System.DateTime::.ctor(int32, int32,
int32)
.....
}

Is this a security slip up? On a small demo I developed, any tampering of a
strong name assembly would fail the verification.

Any one has any idea why this works?

Thanks.

Leon
 
Is the assembly in the GAC? I think that its only checked when the
assembly is copied into the GAC, but after that its assumed that the
assembly is fine.

Try this with your own assembly.

Andy
 
Scott M. said:
Strong Name alone doesn't do it. GAC registration is needed.
Click to expand...

You've got it backwards. Loading of an assembly from the GAC doesn't do
strong-name verification, while loading an assembly from anywhere else does.
If you modify the binary copy of an assembly in the GAC, strong-name
verification won't detect it.

See

http://msdn.microsoft.com/msdnmag/issues/06/07/CLRInsideOut/default.aspx

for a recent article on the subject.

-cd
 
I didn't say it did. What I said was that you need a strong name to do a
GAC registration and the GAC registration is what will cause tampering to be
prevented.
 
If you use GacUtil.exe to install it into GAC, it prevents tampered strong
name assembly from installation.

But if you install a untampered one first, use dir /b /s in cmd to find the
directory of the strong name assembly and then use cmd's Copy to replace it
with the tampered one, it is as good as real one!!

Of course you need admin privilege to do all this replacement and
installation. In an LUA arrangement, the user is denies such privilege
operation.

Leon
 
Of course you need admin privilege to do all this replacement and
installation. In an LUA arrangement, the user is denies such privilege
operation.
Click to expand...

And thus, my point.
 
Of course you need admin privilege to do all this replacement and
installation. In an LUA arrangement, the user is denies such privilege
operation.

And thus, my point.
Click to expand...
The sad part is that the majority of Win2K/XP users are operating with the
security turned off - including many developers - by running in Admin
account. All my machines, including my development machines, operate in LUA
and I am safe from this kind of hacking.

Have to wait for Vista!

Leon
 
Back
Top