RECEME - Remote Command Execution through eMail Exchange

• Download executable - 1.18 MB 
• Download source or contribute (github)
• Download PowerPoint presentation - 223 KB

1. Introduction

REmote Command Execution through eMail Exchange, or RECEME, successfully attempts to solve the problem of remote code execution. The proposed solution executes any .NET runnable code on a computer (where the service application is up and running) in the form of an 'ICommand'.

The commands can be fired from any other location by sending an email/twit/(or any other mode in principle, e.g., SMS/phone/etc.) to the connected communication client (email-box in the current implementation).

2. Background

There are several pains in automation areas in traditional communication systems. VPN etc., are not everybody's cup of tea. Also, connection oriented communication services are not accessible from behind certain firewall settings.

Let's discuss a practical problem:

Problem: Our team mate had to be in office till 12 every night to start a process and check its execution and results (build completion) and then go home. The problem was he would only have to start the build when a certain management decision triggered him to do so. Generally, he gets a mail just before 12AM from some other country where it is still daylight to start a build. And this does not happen everyday so he cannot start an automated scheduled build every day at 12 midnight. The mails are conversation like and have no specific format so that he could not set an Outlook rule for it. And even if he did, he had no response being sent to his home. Even if that happened and something failed, he would have no way to start the build again.

Sad story: His peace of mind was off, he was late for office every morning.

Answer: He can now peacefully use "RECEME" and control the huge build servers from the comfort of his home, may be while he is half awake.

I list here a few pre-requisites to understand the basic concepts behind this service, and to develop custom commands for your usage scenarios:

1. C# .NET (may be 2.0; ideally 3.0)
2. Basic concept of interface and abstraction
3. Some idea on Reflection
4. Knowledge of C#, Web Services, Reflection, and connectivity to public free-email services like GMail/Twitter/Hotmail/Outlook/Exchange/etc.

3. How does RECEME work

The RECEME service application can be started on a system and connected to a desired CommunicationClient. Presently, the supported communication clients are:

1. Emails - GMail / Hotmail / Outlook / Exchange (for corporate emails)
2. Social Networking - Twitter
3. Future - SMS / BluFi / Phone / Basically any communication medium

Once the service is running, you can communicate with your system (where RECEME is running) just by sending an email/twit/SMS from any medium. The communication mode is through the RECEME application running on systemXYZ. The basic architecture of how it works is explained in the image above. The communication works in a simple request-response way. For example, you send a request email and the RECEME service sends you back a response email.

The RECEME service and you can be connected to separate communication clients and still work successfully.

Also, there is an advantage of deploying custom commands while still being on a remote location. In this case, you can create a command in a DLL and send the DLL with the "deploy" command. RECEME installs this new command, and then you can send this new command to get serviced.

The built-in commands and how you can create custom commands are explained below. In principle, it is possible to run any code on the same computer. Also, any communication client can be used by implementing AbstractCommunicationClient.

A more generalized scenario supported by RECEME is:

4. Using the code

Things to do to make it work:

4.1. Developing custom Commands using the ICommand interface

Implement the ICommand Interface:

public interface ICommand 
{
    string Run(string options);
}

An implemented ICommand interface class built into a DLL can be dropped in the <Environment.CurrentDirectory>\Commands directory.

Important point to note: Sample implementations are available in the attached zip file. Also, in the same folder, you will find Command.Core.dll, which contains the ICommand interface. You need to add this DLL as a reference to your project before starting to develop any custom command (ICommand) for your use. In case of any issues, please do not hesitate to bug me (contact information at the end of this article).

Once this is done, start RECEMEapp.exe. The RECEME service is thus started and connected to the email service.

After this, send an email from anywhere in the world to the connected email box and get response in a few minutes from the RECEME service. It is also connected to Twitter, and it is also logically possible to extend this concept to be connected to SMS/VoiceTelephony, etc.

Once the service is up, expect to communicate with the started service from anywhere in the world at anytime.

If all is fine, you get replies to your local mail box from the RECEME service every time you request it, with a command

4.2. What could be achieved...

Technically, the proposed solution (also the attached implementation) successfully attempts to solve the problem of remote code execution:

1. Without the need to establish direct/indirect connection between two systems
2. Physically and network-wise independent, but still controls a remote process
3. 2-way communication (send a command and get back a response)
4. Immensely attractive and easy
5. Needs no additional overhead of cost, time, resource, effort
6. Just one line of configuration to manage (actually, four basic words)

More practically, let us assume a scenario, when I am at office and I want to check what's going on in my home computer. What do I do?

I just send an email to my GMail/Hotmail/etc. from any mail client I currently have access to, from anywhere in the world... and within a matter of a couple of minutes (may be less), I get a response back to my mail showing me the current screenshot of my home desktop or the current processes running and how much process or memory they consume, or are they hung (may be I also want to kill the hung process).

Now, let's re-visit the points above:

1. I did not have to establish any connection with my home computer
2. Both my current computer and home computer were still independent of each other
3. I sent a command and got back a response
4. Was easy
5. At no additional cost
6. The one line configured service was already running on my home computer

Some part of the above problems can be solved with a lot of intermixing of existing technologies and plug and play development components.

More details can be found in the document available for download (use link at the beginning of the article).

4.3. Sample commands already available

Binaries and sample commands (with source code of how to implement commands) are also available for download (use link at the beginning of the article).

In principle, anything possible in the world of programming is possible to be made into a command, just by implementing the ICommand interface. Some basic commands are available with the following explanations.

$CMD command=notepad,options="<FilePathToOpen>"
$CMD command=iexplore,options="<LinkToOpen>"
$CMD command=deploy,options="<WebLink_Of_ICommandDll_ToBeDownloadedAndDeployed>"
$CMD command=process,options="notepad.exe"
$CMD command=screenshot,options=<DONT_CARE>
$CMD command=ping,options="192.168.1.2"
$CMD command=runprocess,options="ping -n 10 mymachineOrIP"

$CMD command=lock,options="<lockoptions>",key"<SecretKey>" 
$CMD command=unlock,options="<unlockoptions>",key="<Secretkey>"

5. Points to note

For currently implemented communication clients, please write the commands in the subject line of your email. The body of the email is not read, so it does not matter what you write there.

Please use " and not “ for specifying commands.

SendMail of GMail client is known to fail from behind some firewalls or if GMail is blocked by other sources (like filthy corporate policies :P). So please see the logs to understand the issue.

SendMail from all communication clients may throw WebException sporadically. Thus, a retry mechanism was built in to retry to send response from RECEME, for three times. Please check if any firewall is blocking sending mails.

TwitterClient is known not to work since Twitter changed it authorization to 3-legged XAuth. I am working on it...

------------ Thanks to Caludio Tortorelli (in the discussion section of this article) for clarifying these points and helping me find some bugs

6. Applicability

1. Automation (Public/Personal)
2. Multisite code execution (something like connectionless-secure grid computing)
3. Work from remote location
4. Domestic appliances [working on a USB-switch to start/stop my TV at home while in office]
5. Need to create a communication client for "bluefi"

7. What's next?

1. A scheduler module is planned between command identification and execution for deferred command execution.
2. A pluggable codec module for more security.

Contact

• Email: arnab [DOT] i<AT>gmail[DOT]com
• Website: http://arnabpal.blogspot.com

8. History

Past a few months of head banging :P

• September 23, 2010: A few bugs fixed and certain points clarified.
• September 17, 2010: Approved by CodeProject community.
• September 12, 2010: Posted on Codeproject.com
• March 14, 2010: Discussed and demonstrated in public for the first time.
• December 2009: Thinking started...