{"id":709,"date":"2013-10-02T22:11:17","date_gmt":"2013-10-02T20:11:17","guid":{"rendered":"http:\/\/blog.rewolf.pl\/blog\/?p=709"},"modified":"2013-10-02T22:26:11","modified_gmt":"2013-10-02T20:26:11","slug":"solving-redbeansoups-1st-crackme-ironpython","status":"publish","type":"post","link":"http:\/\/blog.rewolf.pl\/blog\/?p=709","title":{"rendered":"Solving RedBeanSoup’s 1st Crackme (IronPython)"},"content":{"rendered":"

I’ve solved this little crackme quite some time ago, but I haven’t had time to publish the results. Besides this, protection wasn’t too hard, so I wasn’t sure if there is really anything to publish. Crackme was published on 14 January 2010<\/em> on crackmes.de<\/a>, difficulty was set to 3 (Getting harder<\/em>). Honestly speaking, without IronPython<\/a><\/strong> I would say that difficulty of this crackme is 1 (Very easy, for newbies<\/em>, in the terms of crackmes.de scale), but with IronPython<\/strong>… well, it proved to be hard enough for me. Below analysis will shed some light on IronPython <\/strong>internals, there will be also part about .NET<\/strong> (as IronPython <\/strong>is just .NET Python<\/strong>), I’ll also cover the protection part, but it will not take too much space.<\/p>\n

<\/p>\n

IronPython<\/h3>\n

I’ll not describe IronPython <\/strong>in general, but this specific case, so things may vary for different executables. Crackme is shipped as a zip package and contains 9 files:<\/p>\n

    CrackMe1.dll\r\n    CrackMe1.exe\r\n    IronPython.dll\r\n    IronPython.xml\r\n    Microsoft.Dynamic.dll\r\n    Microsoft.Scripting.Core.dll\r\n    Microsoft.Scripting.Debugging.dll\r\n    Microsoft.Scripting.dll\r\n    Microsoft.Scripting.ExtensionAttribute.dll\r\n<\/pre>\n
Microsoft.*.dlls<\/em> are part of Dynamic Language Runtime<\/a><\/strong> (DLR<\/strong>) that runs on top of the .NET<\/strong> framework, IronPython.dll<\/em> is IronPython <\/strong>runtime (with some .xml config). Crackme itself is split into two parts, executable and dll. Executable is just a host application that runs the proper module from the DLL:<\/p>\n
\/\/ PythonMain\r\n[STAThread]\r\npublic static int Main()\r\n{\r\n  return PythonOps.InitializeModule(Assembly.LoadFile(Path.GetFullPath(\"CrackMe1.dll\")), \"Program\", new string[]\r\n  {\r\n    \"IronPython, Version=2.6.10920.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35\",\r\n    \"mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\",\r\n    \"System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\",\r\n    \"System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\",\r\n    \"System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a\",\r\n    \"System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\",\r\n    \"System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\"\r\n\t});\r\n}\r\n<\/pre>\n
So, analysis will be done only on CrackMe1.dll<\/em>. It contains only one class called DLRCachedCode<\/strong>:<\/p>\n
\"ironpython_pic1\"<\/p>\n
As you can see names are not obfuscated, which seems very promising, especially function names like CheckKey$17()<\/strong> or KeyEncrypt$16()<\/strong>. Unfortunately code generated by IronPython <\/strong>compiler is more than enough in the term of obfuscation<\/em>. All functions and objects are accessed through System.Runtime.CompilerServices.CallSite<\/em> template class, for example:<\/p>\n
  \/\/Part of the KeyEncrypt$16() function\r\n  CallSite> arg7;\r\n  object arg6 = (arg7 = (CallSite>)strongBox.Value[284]).Target(arg7, arg4, globalContext);\r\n  line = 126;\r\n  CallSite> arg9;\r\n  CallSite> arg10;\r\n  object arg8 = (arg9 = (CallSite>)strongBox.Value[285]).Target(arg9, globalContext, (arg10 = (CallSite>)strongBox.Value[286]).Target(arg10, arg2, globalContext), \"09887778\");\r\n  line = 127;\r\n  CallSite> arg11;\r\n  CallSite> arg12;\r\n  CallSite> arg13;\r\n  (arg11 = (CallSite>)strongBox.Value[287]).Target(arg11, arg4, (arg12 = (CallSite>)strongBox.Value[288]).Target(arg12, globalContext, (arg13 = (CallSite>)strongBox.Value[289]).Target(arg13, arg2, globalContext), \"redbeansredbeans\"));\r\n<\/pre>\n
Static analysis of this code is pretty much impossible, only some partial information can be gathered (code flow, strings, names of .NET<\/strong> objects). There is also one cool feature that gives some information about the original python code. In the above snippet there are assignments like “line = 126;”<\/em>, those are line numbers from the original python script. Quick look at the #US<\/strong> (user string heap) stream from .NET<\/strong> image reveals some useful informations:<\/p>\n
00000CF8: #US\r\n\t...\r\n        You must register to fully enjoy this software.\r\n\t...\r\n        Later, I'm Too Poor\r\n\t...\r\n        RedBeanSoup\r\n\t...\r\n        Thank you!\r\n        Accepted\r\n         - Registered to\r\n        Please check your registration information try again.\r\n        Invalid Key\r\n\t...\r\n        09887778\r\n        redbeansredbeans\r\n\t...\r\n        UTF8Encoding\r\n        RijndaelManaged\r\n        CryptoStream\r\n        CryptoStreamMode\r\n\t...\r\n        blocksize\r\n        key\r\n        text\r\n        crypt\r\n        \/+=\r\n        -\r\n        Fully Registered Version\r\n        finalkey\r\n\t...\r\n        BlockSize\r\n        GetBytes\r\n        IV\r\n        translate\r\n        strip\r\n        CreateEncryptor\r\n\t...\r\n        Serial\r\n        ToBase64String\r\n\t...\r\n        iv\r\n        ToUpper\r\n\t...\r\n<\/pre>\n
Judging only by those strings, I can tell that there will be Rijndael<\/strong> (“RijndaelManaged”<\/em>, “BlockSize”<\/em>, “IV”<\/em>) and Base64 <\/strong>(“ToBase64String”<\/em>) algorithms involved. There are also some fancy strings like “09887778”<\/em> or “redbeansredbeans”<\/em>, that might be somehow related to the serial number generation. At that point I’ve stuck, so I had to switch to dynamic analysis.<\/p>\n
.NET Profiling<\/h3>\n
Having some bad experience with .NET<\/strong> bytecode debuggers in the past, I decided to give a try to .NET profiling API<\/strong>. There is a nice article about this topic written by Matt Pietrek<\/em> and dated back to 2001 year:<\/p>\n
http:\/\/msdn.microsoft.com\/en-us\/magazine\/cc301725.aspx<\/a><\/p>\n
It describes all the basic stuff behind .NET<\/strong> profiling and as a bonus it contains source code of simple profiler called DNProfiler<\/strong>. Link to the source code is broken, but I managed to put my dirty hands on it :) so here is the link to the original package:<\/p>\n
Hood0112.zip<\/a><\/p>\n
As those sources are 12 years old, they’re a bit outdated. Sample from the article is using ICorProfilerCallback<\/strong> while there is already ICorProfilerCallback4<\/strong> (since .NET 4<\/strong>). Crackme is compiled for .NET 2.0<\/strong>, so I’ve updated this project to use ICorProfilerCallback2<\/strong>. .NET profiling API<\/strong> enables user to trace all entries and exits from every function (user defined as well as .NET<\/strong> runtime). Mentioned project doesn’t implement those hooks, but I’ve added it to gather some information about execution path. Below you can find patches that I’ve made to the project:<\/p>\n
ProfilerCallback.patch<\/a><\/p>\n
Amount of data gathered by this tool is unbelievable, when all hooks are enabled (enter\/leave<\/em> for every function) there is also huge slowdown. It would be possible to skip generation of some data, and filter output to collect only information useful from the crackme solver point of view, but honestly speaking it overwhelmed me a bit so I dropped that idea. Sample output:<\/p>\n
  ModuleLoadFinished: X:\\xxx\\RbsCrackMe1\\CrackMe1.dll\r\n  ModuleAttachedToAssembly: CrackMe1\r\nAssemblyLoadFinished: CrackMe1  Status: 00000000\r\nObjectAllocated: array of System.String\r\nJITCompilationStarted: IronPython.Runtime.Operations.PythonOps::.cctor\r\n  AssemblyLoadStarted\r\n    ModuleLoadStarted\r\n      ObjectAllocated: array of System.Object\r\n      HandleCreated\r\n      HandleCreated\r\n      HandleCreated\r\n      HandleCreated\r\n      ObjectAllocated: System.Reflection.Assembly\r\n      FunctionEnter: System.Reflection.Assembly::IsAssemblyUnderAppBase\r\n      FunctionEnter: System.Reflection.Assembly::GetLocation\r\n      FunctionEnter: System.Reflection.Assembly::get_InternalAssembly\r\n      ObjectAllocated: System.String\r\n<\/pre>\n
Due to lack of time and other stuff that was waiting I’ve stopped playing with this profiling stuff and decided to move on.<\/p>\n
ILSpy Debugger<\/h3>\n
ILSpy <\/strong>debugger worked surprisingly well on this crackme, there was one minor issue, namely it wasn’t working on x64 Windows<\/em>, so I had to use it inside VMWare<\/strong>. I was debugging on C#-level<\/strong> as it was way more convenient than IL-level<\/strong>. There are basically two functions that needs to be traced: KeyEncrypt$16()<\/strong> and CheckKey$17()<\/strong>. KeyEncrypt$16()<\/strong> triggers first, debugging this code might be a bit complicated, but the bottom line is just about looking at the values\/objects returned from all those cryptic CallSites<><\/strong> calls. During debugging there are a lot of references to the array of objects called strongBox.Value[n]<\/strong>, this array is initialized inside MainForm$7()<\/strong> function. It is easier to check indexes in this array from the Reflector<\/strong>, because ILSpy <\/strong>decompiles it as a proper array initialization and Reflector <\/strong>generates assignment operator for every array element:<\/p>\n
\/\/ILSpy:\r\n    object[] value = new object[]\r\n    {\r\n        \/\/...\r\n        CallSite>.Create(PythonOps.MakeGetAction($globalContext, \"BlockSize\", false)),\r\n        CallSite>.Create(PythonOps.MakeInvokeAction($globalContext, new CallSignature(1))),\r\n        CallSite>.Create(PythonOps.MakeGetAction($globalContext, \"GetBytes\", false)),\r\n        CallSite>.Create(PythonOps.MakeSetAction($globalContext, \"IV\")),\r\n        \/\/...\r\n    };\r\n    ((StrongBox)array[0]).Value = value;\r\n\r\n\/\/Reflector\r\n    object[] objArray3 = new object[0x15a];\r\n    objArray3[0x11c] = CallSite>.Create(PythonOps.MakeGetAction($globalContext, \"BlockSize\", false));\r\n    objArray3[0x11d] = CallSite>.Create(PythonOps.MakeInvokeAction($globalContext, new CallSignature(1)));\r\n    objArray3[0x11e] = CallSite>.Create(PythonOps.MakeGetAction($globalContext, \"GetBytes\", false));\r\n    objArray3[0x11f] = CallSite>.Create(PythonOps.MakeSetAction($globalContext, \"IV\"));\r\n    object[] objArray2 = objArray3;\r\n    ((StrongBox) objArray[0]).Value = objArray2;\r\n<\/pre>\n
Below there are some most interesting values from this array:<\/p>\n
strongBox.Value[284] -> \"BlockSize\"\r\nstrongBox.Value[286] -> \"GetBytes\"\r\nstrongBox.Value[287] -> \"IV\"\r\nstrongBox.Value[289] -> \"GetBytes\r\nstrongBox.Value[291] -> \"_textBox1\"\r\nstrongBox.Value[293] -> \"translate\"\r\nstrongBox.Value[295] -> \"strip\"\r\nstrongBox.Value[297] -> \"_textBox1\"\r\nstrongBox.Value[299] -> \"GetBytes\"\r\nstrongBox.Value[301] -> \"_textBox1\"\r\nstrongBox.Value[304] -> \"CreateEncryptor\"\r\nstrongBox.Value[305] -> \"IV\"\r\nstrongBox.Value[311] -> \"FlushFinalBlock\"\r\nstrongBox.Value[314] -> \"ToBase64String\"\r\nstrongBox.Value[317] -> \"iv\"\r\nstrongBox.Value[320] -> \"CheckKey\"\r\nstrongBox.Value[322] -> \"ToUpper\"\r\nstrongBox.Value[325] -> \"translate\"\r\n<\/pre>\n
There is also second global array that is worth to note (let’s call it globalArray<\/strong>):<\/p>\n
PythonGlobal[] globalArrayFromContext = PythonOps.GetGlobalArrayFromContext(globalContext);\r\n<\/pre>\n
\"ironpython_pic2\"<\/p>\n
Having all those information ready I can start proper debugging. KeyEncrypt$16()<\/strong> creates new RijndaelManaged <\/strong>object, and sets explicitly BlockSize<\/strong> to 128<\/strong>. Next it converts “09887778”<\/em> string to byte array (GetBytes<\/strong>). Following line reference “IV”<\/strong> and “GetBytes”<\/strong> from the strongBox <\/strong>array and “redbeansredbeans”<\/em> string from the #US<\/strong> stream, I’ve assumed that it sets the initialization vector IV<\/strong> to “redbeansredbeans”<\/em>. In the next step crackme performs strip()<\/strong> and translate()<\/strong> operations from python <\/strong>runtime on the “_textBox1”<\/strong> which contains entered user-name. All gathered information are put into CreateEncryptor <\/strong>function (from RijndalManaged <\/strong>object) and written into CryptoStream <\/strong>object. Below code represents what is happening (it is part of the keygen, so it is not 1:1 code from the crackme):<\/p>\n
  System.Text.ASCIIEncoding ascenc = new System.Text.ASCIIEncoding();\r\n  RijndaelManaged rm = new RijndaelManaged();\r\n  rm.BlockSize = 128;\r\n  rm.KeySize = 256;\r\n  ICryptoTransform ict = rm.CreateEncryptor(ascenc.GetBytes(\"09887778\"), ascenc.GetBytes(\"redbeansredbeans\"));\r\n\r\n  string name = (0 == args.Length) ? \"ReWolf\" : args[0];\r\n\r\n  byte[] result;\r\n  using (MemoryStream msEncrypt = new MemoryStream())\r\n  {\r\n    using (CryptoStream csEncrypt = new CryptoStream(msEncrypt, ict, CryptoStreamMode.Write))\r\n    {\r\n      using (StreamWriter swEncrypt = new StreamWriter(csEncrypt))\r\n      {\r\n        swEncrypt.Write(name);\r\n      }\r\n      result = msEncrypt.GetBuffer();\r\n    }\r\n  }\r\n<\/pre>\n
The last thing before call to CheckKey$17()<\/strong> is conversion of encrypted stream to base64 <\/strong>(Convert.ToBase64String()<\/strong>). CheckKey$17()<\/strong> is fairly easy to analyse, at first it makes generated base64 <\/strong>string uppercase (ToUpper<\/strong>), next it calls python runtime function called translate()<\/strong> which strips base64 <\/strong>output from this three characters “\/+=”<\/em>. CheckKey$17()<\/strong> gets only 16 characters from the output string. Those characters are split into four groups and separated with “-“<\/em>. This new string is compared to entered serial number, yes the whole protection is just strcmp…<\/strong> Below you can find link to the keygen (written in C#<\/strong>):<\/p>\n
I hope you enjoyed this analysis even though it was just plain strcmp.<\/p>\n","protected":false},"excerpt":{"rendered":"
I’ve solved this little crackme quite some time ago, but I haven’t had time to publish the results. Besides this, protection wasn’t too hard, so I wasn’t sure if there is really anything to publish. Crackme was published on 14 January 2010 on crackmes.de, difficulty was set to 3 (Getting harder). Honestly speaking, without IronPython […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[14,15,13,3],"tags":[],"_links":{"self":[{"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=\/wp\/v2\/posts\/709"}],"collection":[{"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=709"}],"version-history":[{"count":37,"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=\/wp\/v2\/posts\/709\/revisions"}],"predecessor-version":[{"id":754,"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=\/wp\/v2\/posts\/709\/revisions\/754"}],"wp:attachment":[{"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=709"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=709"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=709"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
rwf_rbs_keygen.cs<\/a>
\nrbs_keygen.zip<\/a><\/p>\n