Steganography VI - Hiding messages in .NET Assemblies
4.58/5 (18 votes)
An article about hiding instructions at the end of methods in an .NET Assembly
Introduction
An application contains lots of lines which leave the stack empty. After these lines any code can be inserted, as long as it leaves the stack empty again. You can load some values onto the stack and store them off again, without disturbing the application's flow.
Finding silent hiding places
Let's take a look at an assembly's IL Assembler Language code. Each methods contains lines which put something onto the stack, or store something off the stack. We cannot always say what exactly is on the stack when a specific line executes, so we should not change anything between two lines. But there are some lines at which we know what is on the stack.
Every method has to contain at least one ret instruction. When the runtime environment reaches a ret, the stack must contain the return value and nothing else. That means, at a ret instruction in a method returning a Int32, the stack contains exactly one Int32 value. We could store it in a local variable, insert some code leaving the stack empty, and then put the return value back onto the stack. Nobody would notice it at runtime. There are much more lines like that, for example the closing brackets of .try { and .catch { blocks (definitly empty stack!) or method calls (only returned value of known type on the stack!). To keep the example simple, we are going to concentrate on void methods and ignore all the others. When a void method is left, the stack has to be empty, so we don't have to care about return values.
This is the IL Assembler Language code of a typical void Dispose() method:
.method family hidebysig virtual instance void
Dispose(bool disposing) cil managed
{
// Code size 39 (0x27)
.maxstack 2
IL_0000: ldarg.1
IL_0001: brfalse.s IL_0016
IL_0003: ldarg.0
IL_0004: ldfld class [System]System.ComponentModel.Container
PictureKey.frmMain::components
IL_0009: brfalse.s IL_0016
IL_000b: ldarg.0
IL_000c: ldfld class [System]System.ComponentModel.Container
PictureKey.frmMain::components
IL_0011: callvirt instance void [System]System.ComponentModel
.Container::Dispose()
IL_0016: ldarg.0
IL_0017: ldarg.1
IL_0018: call instance void [System.Windows.Forms]System
.Windows.Forms.Form::Dispose(bool)
IL_0026: ret
}
So what will happen, if we insert a new local variable and store a constant in it, just before the method returns? Yes, nothing will happen, except a little bit of performance decrease.
.method family hidebysig virtual instance void
Dispose(bool disposing) cil managed
{
// Code size 39 (0x27)
.maxstack 2
.locals init (int32 V_0) //declare a new local variable
...
IL_001d: ldc.i4 0x74007a //load an int32 constant
IL_0022: stloc V_0 //store the constant in the local variable
IL_0026: ret
}
In C# the methods would look like this:
//Original
protected override void Dispose( bool disposing ) {
if( disposing ) {
if (components != null) {
components.Dispose();
}
}
base.Dispose( disposing );
}
//Version with hidden variable
protected override void Dispose( bool disposing ) {
int myvalue = 0;
if( disposing ) {
if (components != null) {
components.Dispose();
}
}
base.Dispose( disposing );
myvalue = 0x74007a;
}
We have just hidden four bytes in an application! The IL file will re-compile without errors, and if somebody de-compiles the new assembly, he can find the value 0x74007a.
How to disguise a secret value
To make life harder for people who disassemble our application and look for useless variables, we can disguise the hidden values as forgotten debug output:
ldstr bytearray(65 00) //load an "A"
stloc mystringvalue //store it
.maxstack 2 //set the stack size to exclude runtime exceptions
ldstr "DEBUG - current value is: {0}"
ldloc mystringvalue //simulate forgotten debug code
call void [mscorlib]System.Console::WriteLine(string, object)
In order to stay invisible even in console applications, we should rather disguise it as an operation. We can insert more local/instance/static variables, to make it look like the values were needed somewhere else:
.maxstack 2 //adjust stack size
ldc.i4 65 //load the "A"
ldloc myintvalue //load another local variable - declaration inserted above
add //65 + myintvalue
stsfld int32 NameSpace.ClassName::mystaticvalue
//remove the result from the stack
This example demonstrates how to hide values at all, so only this version will be used:
ldc.i4 65;
stloc myvalue
There is no need to insert two lines for each byte of the message. We can combine up to four bytes to one Int32 value, inserting only half a line per hidden byte. But first we have to know where to insert it at all.
Analysing the Disassembly
Before editing the IL file, we have to call ILDAsm.exe to create it from the compiled assembly. Afterwards we call ILAsm.exe to re-assemble it. The interesting part is between these two steps: We must walk through the lines of IL Assembler Language code, finding the void methods, their last .locals init line, and one ret line. A message can contain more 4-byte blocks than there are void methods in the file, so we have to count the methods and calculate the number of bytes to hide in each of them. The method Analyse collects namespaces, classes and void methods:
/// <summary>Lists namespaces, classes and methods
/// with return type "void"</summary>
/// <param name="fileName">Name of the IL file to analyse</param>
/// <param name="namespaces">Returns the names of all namespaces
/// found in the file</param>
/// <param name="classes">Returns the names of all classes</param>
/// <param name="voidMethods">Returns the first lines of all method
/// signatures</param>
public void Analyse(String fileName,
out ArrayList namespaces, out ArrayList classes,
out ArrayList voidMethods){
//initialize return lists
namespaces = new ArrayList(); classes = new ArrayList();
voidMethods = new ArrayList();
//current method's header, or null if the method doesn't return "void"
String currentMethod = String.Empty;
//get the IL file line-by-line
String[] lines = ReadFile(fileName);
//loop over the lines of the IL file, fill lists
for(int indexLines=0; indexLines<lines.Length; indexLines++){
if(lines[indexLines].IndexOf(".namespace ") > 0){
//found a namespace!
namespaces.Add( ProcessNamespace(lines[indexLines]) );
}
else if(lines[indexLines].IndexOf(".class ") > 0){
//found a class!
classes.Add( ProcessClass(lines, ref indexLines) );
}
else if(lines[indexLines].IndexOf(".method ") > 0){
//found a method!
currentMethod = ProcessMethod(lines, ref indexLines);
if(currentMethod != null){
//method returns void - add to the list of usable methods
voidMethods.Add(currentMethod);
}
}
}
}
Given the number of usable methods, we can calculate the number of bytes per method:
//length of Unicode string + 1 position for this length
//(it is hidden with the message)
float messageLength = txtMessage.Text.Length*2 +1;
//bytes to hide in each method, using only its first "ret" instruction
int bytesPerMethod = (int)Math.Ceiling( (messageLength /
(float)voidMethods.Count));
Now we are ready to begin. The method HideOrExtract uses the value of bytesPerMethod to insert the lines for one or more 4-byte blocks above each ret keyword.
/// <summary>Hides or extracts a message in/from an IL file</summary>
/// <param name="fileNameIn">Name of the IL file</param>
/// <param name="fileNameOut">Name for the output file -
/// ignored if [hide] is false</param>
/// <param name="message">Message to hide, or empty stream to
/// store extracted message</param>
/// <param name="hide">true: hide [message]; false: extract
/// a message</param>
private void HideOrExtract(String fileNameIn, String fileNameOut,
Stream message, bool hide){
if(hide){
//open the destination file
FileStream streamOut = new FileStream(fileNameOut, FileMode.Create);
writer = new StreamWriter(streamOut);
}else{
//count of bytes hidden in each method is unknown,
//it will be the first value to extract from the file
bytesPerMethod = 0;
}
//read the source file
String[] lines = ReadFile(fileNameIn);
//no, we are not finished yet
bool isMessageComplete = false;
//loop over the lines
for(int indexLines=0; indexLines<lines.Length; indexLines++){
if(lines[indexLines].IndexOf(".method ") > 0){
//found a method!
if(hide){
//hide as many bytes as needed
isMessageComplete = ProcessMethodHide(lines,
ref indexLines, message);
}else{
//extract all bytes hidden in this method
isMessageComplete = ProcessMethodExtract(lines,
ref indexLines, message);
}
}else if(hide){
//the line does not belong to a useable method - just copy it
writer.WriteLine(lines[indexLines]);
}
if(isMessageComplete){
break; //nothing else to do
}
}
//close writer
if(writer != null){ writer.Close(); }
}
Hiding the message
The method ProcessMethodHide copies the method's header, and checks if the return type is void. Then it looks for the last .locals init line. If no .locals init is found, the additional variable will be inserted at the beginning of the method. The hidden variable must be the last variable initialized in the method, because the compilers emitting IL Assembler Language often use slot numbers instead of names for local variables. Just imagine a desaster like that:
//a C# compiler emitted this code - it adds 5+2
//original C# code:
//int x = 5; int y = 2;
//mystaticval = x+y;
.locals init ([0] int32 x, [1] int32 y)
IL_0000: ldc.i4.5
IL_0001: stloc.0
IL_0002: ldc.i4.2
IL_0003: stloc.1
IL_0004: ldloc.0
IL_0005: ldloc.1
IL_0006: add
IL_0007: stsfld int32 Demo.Form1::mystaticval
IL_000c: ret
If we inserted an initialization at the beginning of the method, we could not re-assemble the code, because slot 0 is already in use by myvalue:
.locals init (int32 myvalue)
.locals init ([0] int32 x, [1] int32 y) //Error!
IL_0000: ldc.i4.5
IL_0001: stloc.0
...
So the additional local variables has to be initialized after the last existing .locals init. ProcessMethodHide inserts a new local variable, jumps to the first ret line and inserts ldc.i4/stloc pairs. The first value being hidden is the size of the message stream - the extracting method needs this value in order to know when to stop. The last value hidden in the first method is the count of message-bytes per method. It has to be placed right above the ret line, because the extracting method has to find it without knowing how many lines to go back (because that depends on just this value).
/// <summary>Hides one or more bytes from the message stream
/// in the IL file</summary>
/// <param name="lines">Lines of the IL file</param>
/// <param name="indexLines">Current index in [lines]</param>
/// <param name="message">Stream containing the message</param>
/// <returns>true: last byte has been hidden; false:
/// more message-bytes waiting</returns>
private bool ProcessMethodHide(String[] lines, ref int indexLines,
Stream message){
bool isMessageComplete = false;
int currentMessageValue, //next message-byte to hide
positionInitLocals, //index of the last ".locals init" line
positionRet, //index of the "ret" line
positionStartOfMethodLine; //index of the method's first line
writer.WriteLine(lines[indexLines]); //copy first line
//ignore if not a "void"-method
if(lines[indexLines].IndexOf(" void ") > 0){
//found a method with return type "void"
//the stack will be empty at it's end,
//so we can insert whatever we like
indexLines++; //next line
//search start of method block, copy all skipped lines
int oldIndex = indexLines;
SeekStartOfBlock(lines, ref indexLines);
CopyBlock(lines, oldIndex, indexLines);
//now we are at the method's opening bracket
positionStartOfMethodLine = indexLines;
//go to first line of the method
indexLines++;
//get position of last ".locals init" and first "ret"
positionInitLocals = positionRet = 0;
SeekLastLocalsInit(lines, ref indexLines, ref positionInitLocals,
ref positionRet);
if(positionInitLocals == 0){
//no .locals - insert line at beginning of method
positionInitLocals = positionStartOfMethodLine;
}
//copy from start of method until last .locals,
//or nothing (if no .locals found)
CopyBlock(lines, positionStartOfMethodLine, positionInitLocals+1);
indexLines = positionInitLocals+1;
//insert local variable
writer.Write(writer.NewLine);
writer.WriteLine(".locals init (int32 myvalue)");
//copy rest of the method until the line before "ret"
CopyBlock(lines, indexLines, positionRet);
//next line is "ret" - nothing left to damage on the stack
indexLines = positionRet;
//insert ldc/stloc pairs for [bytesPerMethod] bytes
//from the message stream
//combine 4 bytes in one Int32
for(int n=0; n<bytesPerMethod; n+=4){
isMessageComplete = GetNextMessageValue(message,
out currentMessageValue);
writer.WriteLine("ldc.i4 "+currentMessageValue.ToString());
writer.WriteLine("stloc myvalue");
}
//bytesPerMethod must be last value in the first method
if(! isBytesPerMethodWritten){
writer.WriteLine("ldc.i4 "+bytesPerMethod.ToString());
writer.WriteLine("stloc myvalue");
isBytesPerMethodWritten = true;
}
//copy current line
writer.WriteLine(lines[indexLines]);
if(isMessageComplete){
//nothing read from the message stream, the message is complete
//copy rest of the source file
indexLines++;
CopyBlock(lines, indexLines, lines.Length-1);
}
}
return isMessageComplete;
}
Extracting the hidden values
The method ProcessMethodExtract looks for the first ret line. If the number of bytes hidden in each method is still unknown, it jumps two lines back and extracts the number from the ldc.i4 line, which had been inserted as the last value in the first method. Otherwise it jumps back two lines per expected ldc.i4/stloc-pair, extracts the 4-byte blocks and writes them to the message stream. If an ldc.i4 is not found where it should be, the method throws an exception. The second extracted value (after the number bytes per method) is the length of the following message. When the message stream has reached this expected length, the isMessageComplete flag is set, HideOrExtract returns, and the extracted message is displayed. Extracting works just like hiding in reverse direction.
No key ?!
Sure you'll have noticed that this application doesn't use a key file to distribute the message. An intermediate assembly contains less void methods than an intermediate sentence contains characters, so a distribution key as it is used in all preceeding articles would only mean pushing loads of additional nonsense-lines into a few methods, and that would be much too obvious.
A key file for this application could specify how to disguise the values - debug output, operations, instance fields, additional methods, and so on. I'll add such a feature in future versions, if somebody is interested in it.