> 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

"Leon" <newsgroup01.3.mailcenter***@neverbox.com> wrote in message
news:1EAABB7B-2328-4464-BC31-8398643DA80C@microsoft.com...
> 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

"Carl Daniel [VC++ MVP]" wrote:

> "Scott M." <s-mar@nospam.nospam> wrote in message
> news:u7q5bOU8GHA.4116@TK2MSFTNGP03.phx.gbl...
> > Strong Name alone doesn't do it.  GAC registration is needed.
>
> 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
>
>
>

"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>
wrote in message news:OuzBZEV8GHA.2288@TK2MSFTNGP05.phx.gbl...
> "Scott M." <s-mar@nospam.nospam> wrote in message
> news:u7q5bOU8GHA.4116@TK2MSFTNGP03.phx.gbl...
>> Strong Name alone doesn't do it.  GAC registration is needed.
>
> 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
>
>

"Scott M." wrote:

> 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.
>
>
> "Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>
> wrote in message news:OuzBZEV8GHA.2288@TK2MSFTNGP05.phx.gbl...
> > "Scott M." <s-mar@nospam.nospam> wrote in message
> > news:u7q5bOU8GHA.4116@TK2MSFTNGP03.phx.gbl...
> >> Strong Name alone doesn't do it.  GAC registration is needed.
> >
> > 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
> >
> >
>
>
>

"Scott M." wrote:

> > 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.
>
>
>