Thursday, May 28, 2015

Scaling the Real-time Web with ASP.NET SignalR - on Channel9

Great talk about scaling patterns for SignalR depending on the type of messages that run through your system.




Wednesday, May 27, 2015

Visual Studio Code: a Sublime/Atom like ASP.NET vNext Editor

Cool! There's a preview version out of Microsoft Visual Studio Code: https://code.visualstudio.com/

It's an editor that highly resembles Sublime Text, or GitHub Atom but then for .NET development! It's cross platform no less, so that's AWESOME.


https://code.visualstudio.com/Go check it out - I'll be using it today! It seems to work best with Node or Mono apps right now, has built in Git support and a lot of other coolness.

Monday, May 25, 2015

Note to self: RTFM for ElasticSearch installation.

As mentioned previously, we're running the ELK stack to monitor our cloud services. Since I wanted to keep running the latest and even beta/pre-release versions of these apps, I've manually installed the apps, as opposed to using apt-get or docker.

Anyway - at some point ElasticSearch started taking up 100% CPU load on the machine and stopped responding a couple of minutes later.
So I stopped ElasticSearch and started it again - this time not in deamon mode. This started showing me the exceptions that were occurring.


As it turns out ElasticSearch wants you to change 2 configuration settings on your machine: number of open files and disable swapping.



After doing this - ES runs like a charm again.
By the way - increasing the number of open files on Ubuntu Server is described here: http://posidev.com/blog/2009/06/04/set-ulimit-parameters-on-ubuntu/


Friday, May 22, 2015

Find a production bug that causes 100% CPU load

This actually happened in my previous job, but I hadn't shared it. We had a piece of software that caused the production server to run at 100% for a couple of minutes, before going down.

So we tried to analyze it using windbg first, using this excellent how-to:


But ... that didn't work. Because there was a mismatch between windbg or sos plugin on my machine and the .net version on the server or something. And of course - I was not able to touch the production server to do it on the machine itself.

Nevertheless, this is a great post. Check it out: http://improve.dk/debugging-in-production-part-1-analyzing-100-cpu-usage-using-windbg/

Wednesday, May 20, 2015

Decompiling an illegal 'patch' application - does it secretly install or run malware? - Part 2

Recently I looked inside an illegal application patch, that 'unlocks' an application by messing with the license code checks of the application. I was convinced that the patch would do not only that, but also install some form of malware on the computer. As it turns out: that particular patch didn't.

So I decided to take a look into another one. As opposed to the previous patch application, this one wasn't written in .NET, so not only the decompilation will not be as easy, also the decomiled sources will probably not be as meaningful.




For decompilation, there is of course Boomerang, which is free and open source, but I decided to see if there is an online 'decompilation as a service'. Turns out there is at https://retdec.com/:


OK - let's run the patch through this decompiler:


OK - you can inspect a whole bunch of things here, but you can also just download everything. That's what I did. In the downloaded zip, there is the decompiled machine code, the call graphs and decompiled C code.

Looking a the callgraph, I didn't see anything that got my alarm bells going or anything. Again, an attempt was made to mess with the applications .dll files.

So let's see if I can make anything from the C code:


At the bottom of the file - the external function calls are listed. Turns out the application calls into the Windows API, seems to be messing with some files and things, but nothing really surprising. OK, let's see what this looks like in code:




I found code that I didn't really grasp and had to start Googling. The code tries to get a handle for the running process and then starts looking for dlls. That's remarkable since the patch application is just one .exe file. There are no dlls with the application - let alone something called 'dup2dispatcher.dll'.

... or are there? That brought me to this post: https://blog.malwarebytes.org/intelligence/2013/03/obfuscation-malwares-best-friend/ which talks about packers - and how it is often used to disguise malware. Although I haven't seen any malicious code yet, I'm a bit more suspicious of course.

Inspecting the application with the ExeInfo tool, reveals the dup2patcher.dll, which is packed inside the EXE:





So - the patch logic or malicous code could be in there. It seems like that .rsrc section holds the actual dll source and you can save it off to your disk. Insepecting the bytecode revealed this XML section at the bottom, which is an assembly manfiest:



I can read this, which makes me think that none of the obfuscation techniques were applied as suggested in the mentioned blogpost. However, I'm not able to inspect this code with DotPeek.

So ... I'm afraid this is how far I could come. As you can see - the only dependent assembly is Windows.Common.Controls. Since the patch probably has some kind of windows form - that all makes sense. I would have expected system.web in case the assembly went out to connect to some remote box or download some kind of executable.

However - I haven't been able to look inside this dll, so this is where it ends for me. If you have any tips - please drop me a line or suggestion.

Monday, May 18, 2015

Decompiling an illegal 'patch' application - does it secretly install or run malware?

A friend of mine called me the other day with the following story: "I downloaded a torrent application which contains a patch. I ran the patch application but it didn't work. Do I have a virus now?"

My first reaction was of course: "Yes buddy - you're screwed". But I decided to have him send the application over so I could take a look at it.



As it turns out, this patch is a .NET application - so not only will it be easy to decompile, it will also be very readable.

So I was expecting things like the patch secretly installing key loggers or some other secret background service or making the computer part of  a botnet.

I opened up my trusty DotPeek and had a 'peek' inside. First I opened the references tab - see what BCL libraries the application uses:


OK - that was surprising: System.Web wasn't there. I was expecting that at the very least. OK, see what resources it carries then:


Remarkable: nothing but some icons and a background image. That doesn't seem too evil. But, OK, I must be missing something - let's check out the sources:


Aha - I thought: the 'SeekAndDestroy' method must do something bad. As it turns out, it doesn't. It just opens some .exe and .dll files and replaces some byte sequences with another. So unless that injected byte sequence is the actual malware ( which I don't think ) ... it seems this patch actually only tries to mess with the application license check. Wow, I didn't see that one coming, seems this patch is clean!

Friday, May 15, 2015

You think you know C#? Dive deeper!

Last year during the TechDays I saw these talks by Bart de Smet.



I was really really blown away by these talks. The depth of his understanding of the C# language, the .NET framework, the CLR and even down to machine code was just *freaking* amazing. 

So let me give you an impression what it felt like. I was doing 160 in my Panda ( which is 'pretty good' for a Panda ). You know - I know a bunch of patterns, SOLID things, SCRUM style working, try to keep code coverage up, messaging patterns and I have an idea what Martin Fowler is talking about most of the time. Felt pretty good. And then:

I was ready to park my Panda right there, on the side of the road. What's the point of driving 160 if others drive 300+ ?


It actually took me a while to not think 'this would have taken him 1 second' while working on projects the week after. So I decided to thank him for his talk - to which he responded very friendly:



Shortly after, I found his courses on PluralSight 'C# Language Internals' part 1 and 2. Which I'm doing right now and it's very interesting. I'm not sure whether I can directly apply this knowledge in my daily things, but I'm very happy that the CLR is not as much of a black box to me as it used to be.

Last week, I went down a different rabbit-hole while chasing the SIMD rabbit. That got me to view the 'Making .NET Applications Even Faster' course. Another WOW for me there. This course goes into detail about the Garbage Collector and the difference between debug and release builds. That difference is also discussed in the language internals course in detail, so that helped. 

I guess what it comes down to in short is this: A couple of years ago, I thought it wasn't necessary to know about low level stuff if you're using .NET and I was wrong. Not only can it be very useful, it's also a very interesting new world that will open your eyes to why certain things are the way they are. 

If you think you understand C#, do yourself a favor, get a PluralSight subscription and dive deeper! And these courses are great to get started.