More P/Invoke fun... creating a remote thread in a target process from C# using P/Invoke of Windows API calls.

Openssl wrappers for .NET are available at Sourceforge OpenSSL.NET. Very poorly documented but turns out to be very easy to use. Simply add the ManagedOpenSsl.dll reference to your c# code and have at it. Sample code:

I had to do some basic P/Invoke calling from C# today and am sharing the code just for giggles. P/Invoke is essentially calling functions that reside in an unmanaged DLL from managed code. It's fairly straight forward to do with the hardest part being parsing the MSDN to get the proper signatures for the functions you wish to DLLImport. There is a great resource at pinvoke.net that contains user submitted signatures for cut and paste reuse. I highly recommend this resource. Last but not least here is my code that demonstrates encrypting and decrypting static blobs with hardcoded constant key values. Not real world, but a reasonable demonstration none the less.

I was messing around with optimizations and IDA Pro today in an attempt to get some dead code compiled into a program intentionally. I thought this would be a 10 second task, and in some ways it was. However, it took a while because I ended up finding something odd out about Visual Studio 2008 (untested on older versions).

Let's take the following code:

#include "stdafx.h"
#include "windows.h"
#include "stdio.h"

static void foo()
{
printf("Inside function foo. This should never be called\n");
return;
}

int _tmain(int argc, _TCHAR* argv[])
{
printf("This is main. It doesn't do squadoosh!\n");
return 0;
}

Under unix world with gcc I can simply compile this program using the flag -O0 to disable optimizations. I then can execute objdump -d to determine that indeed my code is present in the binary.

*SNIP*

08048374 foo:
8048374: 55 push %ebp
8048375: 89 e5 mov %esp,%ebp
8048377: 83 ec 08 sub $0x8,%esp
804837a: c7 04 24 98 84 04 08 movl $0x8048498,(%esp)
8048381: e8 2a ff ff ff call 80482b0 printf@plt
8048386: c9 leave
8048387: c3 ret

08048388 main:
8048388: 55 push %ebp
8048389: 89 e5 mov %esp,%ebp
804838b: 83 ec 08 sub $0x8,%esp
804838e: 83 e4 f0 and $0xfffffff0,%esp
8048391: b8 00 00 00 00 mov $0x0,%eax
8048396: 83 c0 0f add $0xf,%eax
8048399: 83 c0 0f add $0xf,%eax
804839c: c1 e8 04 shr $0x4,%eax
804839f: c1 e0 04 shl $0x4,%eax
80483a2: 29 c4 sub %eax,%esp
80483a4: c7 04 24 cc 84 04 08 movl $0x80484cc,(%esp)
80483ab: e8 00 ff ff ff call 80482b0 printf@plt
80483b0: b8 00 00 00 00 mov $0x0,%eax
80483b5: c9 leave
80483b6: c3 ret
80483b7: 90 nop

However in Visual Studio it's not quite as cut and dry. I disabled all optimizations and spent what amounted to nearly two hours trying to disable whatever it was that was keeping the compiler from adding my deadcode to the binary. I ended up chatting with a coworker of mine and he suggested I remove the "static" modifier from the foo function. Sure enough, as soon as I did this I was able to compile the dead code into the function. So after much face banging into desk I figured out that Visual Studio will always optimize out static functions regardless of the optimization settings configured in the project properties.

This makes no sense since the word static is intended to only allow the local file access to the function, it should have no impact on the optimizations of the binary as a whole. If anyone with more programming expertise than I can explain a valid reason for this optimization, please help me out.

mjxg pointed me at this nifty Python cheat sheet. I had been avoiding learning another scripting language due to the fact that I had everything I really needed already stubbed out in perl. Last week I was forced to use it for some quick code and was reasonably impressed. Other than the annoyances of mandatory white space (yik) and a lack of reasonable block commenting (supposedly ### works, but I learned that too late), I felt that Python was indeed fairly straight forward to use. Anyhow, here is the cheat sheet for your long term use.

Credit to Matt Harrison @ http://panela.blog-city.com

I came across an interesting transcript of a presentation today. Linus Torvalds, of Linux Kernel fame, gave a presentation at Google discussing the good, the bad, and the ugly, of source code revision management. His general mantra is "You are all stupid and ugly", but that being said he has an interesting take on source code repositories as well as discussing the specifics of his custom open source repo, "git".

While the talk was actually quite interesting to read from a personality point of view (Linus is never short on jabs and opinions), it is also interesting to read from a repository point of view. It never really occurred to me how much a centralized source code management system could be improved upon. It has been in use for so many years, it's just one of those things that you assume is being done right. I guess it makes sense to never assume (You think I'd have learned that by now).

One quote that caught my eye:

"If you have ever done any security work, and it did not involve the concept of network of trust, then it wasn't a security work, it was masturbation. I don't know what you were doing but trust me, it's the only way you can do security, and it's the only way you can do development. The way I work, I don't trust everybody. in fact I am a very cynical and untrusting person. I think most of you are completely incompetent."

I guess I'm not only incompetent, but according to Linus I masturbate for a living! If you can get past the attitude, it's a pretty interesting take on a very old topic.