[Mono-bugs] [Bug 82079][Wis] New - After applying Security Update for .NET Framework, Assembly User String table is written incorrectly

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by jim at zenzui.com.

http://bugzilla.ximian.com/show_bug.cgi?id=82079

--- shadow/82079	2007-07-11 20:24:21.000000000 -0400
+++ shadow/82079.tmp.7509	2007-07-11 20:24:22.000000000 -0400
@@ -0,0 +1,104 @@
+Bug#: 82079
+Product: Mono: Class Libraries
+Version: unspecified
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Wishlist
+Component: Cecil
+AssignedTo: mono at evain.net                            
+ReportedBy: jim at zenzui.com               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: After applying Security Update for .NET Framework, Assembly User String table is written incorrectly
+
+Please fill in this template when reporting a bug, unless you know what 
+you are doing.
+
+Description of Problem:
+After applying the Security Update for .NET Framework, the round-trip 
+reading and then writing of an Assembly produces errors in the User 
+String Table.  [Security Update for Microsoft .NET Framework, Version 2.0 
+(KB928365)]
+
+Analysis:
+When Cecil reads an assembly, it calls System.Encoding.Unicode.GetString
+(byte[], offset, length) to process the User String Table from the 
+assembly.  Unfortunately, the length of the string in the string table is 
+the # of characters (x2) + 1 (byte) for the null terminator.  The string 
+is actually terminated incorrectly as unicode NULL should be 0x0000, not 
+0x00.
+
+The routine System.Encoding.Unicode.GetString() does not expect to be 
+passed a length that includes the NULL & with the security patch applied 
+generates a string with \ufffd appended, causing all kinds of grief.  
+Prior to the update, this was innocuous as embeded NULLs in strings 
+caused the NULL & contents following to be dropped.  The Security Update 
+translates them into an Invalid Unicode Character (0xfffd).
+
+I found the offending problem in Mono.Cecil.Metadata\UserStringsHeap.cs, 
+ReadStringAt() and applied the fix (length-1) vs (length).
+
+>>> return Encoding.Unicode.GetString (this.Data, offset, length-1);
+
+Other locations where this routine is called all pass the correct (even) 
+length.
+
+Steps to reproduce the problem:
+1. Create a simple JavaScript program & compile with JSC (sorry, but 
+that's what I do, you could probably build any assembly that had a string 
+in it.
+
+Ex:
+import System;
+package Foo {
+   class Bar {
+      function hello() {
+           System.Console.WriteLine("Hello World");
+      }
+   }
+}
+
+jsc -t:library hello.js
+
+# builds hello.dll
+
+2. Next, read the .dll using Cecil & write it back out:
+Something like:
+using System;
+using System.IO;
+using System.Text;
+using Mono.Cecil;
+
+namespace Foo {
+   class Program {
+     public static void Main(string[] args) {
+        AssemblyDefinition Assembly;
+        Assembly = AssemblyFactory.GetAssembly(args[0]); // name on cmd 
+line
+        string outFilename = args[0] + ".out";
+
+        AssemblyFactory.SaveAssembly(Assembly, outFilename);
+     }
+   }
+}
+
+3.  Load the resultant output assembly in ILDasm or .NET Reflector :-).
+Inspect the IL for Main().  
+
+Actual Results:
+Note that the string is "Hello World\ufffd".
+
+Expected Results:
+"Hello World" in the original .dll
+
+How often does this happen? 
+Every time if you've applied the security update to .NET [Security Update 
+for Microsoft .NET Framework, Version 2.0 (KB928365)]
+
+
+Additional Information: