Friday, February 15, 2013

So, what's next?

The next major version of Cameyo is making great progress. Since it brings so many big changes, it is not expected for general availability before a few more months. Still, there will be an early Beta offered for volunteers who have a Cameyo account.
We'll send out a newsletter when the Beta program opens. Here's a brief description of the new version's features:

  • FAST! The Cameyo package file format is being redesigned with performance in mind. The "ZIP" format will be replaced with a proprietary, optimized file format which improves the virtualization engine's retrieval of virtual files, and also fast editing of virtual pacakges. The virtual registry pre-extraction will no longer occur either, making virtual packages launch even faster upon first run.
  • Two virtualization modes:
    • Next version
    • RAM mode: virtual apps will be running directly from memory, without being pre-extracted to disk.
    • Disk mode: just like today, virtual application files will be first extracted to disk and then used. This usage scenario is still the most optimized for frequently-used apps (or apps used over the network).
  • Virtual registry keys will no longer be pre-extracted (except on Windows XP).
  • Program's files will be stored in a different location than data (changed) files.
  • The above will make Cameyo apps more terminal server friendly.
  • Auto-update feature will be released.
  • Password / certificate protection for protecting against editing of virtual apps that you create.
  • Hopefully, some additional things too. But can't commit on these just yet...
Still not sure whether the version will be named "2.5" or "3.0", but one thing's for sure: this new version will bring big improvements.
Stay tuned. Subscribe to the newsletter.

Monday, January 21, 2013

Auto Update

You've all been quite clear about requesting an AutoUpdate feature for Cameyo'd apps. You asked for simplicity, which is something we value a lot at Cameyo.
This feature has been developed & ready, but for now it is only available for one specific virtual application: Cameyo itself!


The latest Cameyo build (2.0.873) contains a new AutoUpdate feature, which has been generically designed for ANY Cameyo virtual application. We've been able to beta testing it (by providing a 2.0.872 earlier build to our beta testers), and it seems to do the job. So here's a preview of what will be soon made available for any Cameyo'd app:




video

Noticed that updates can be deployed while the virtual app is in use?
Also, if you own an iPhone / iPad, you might find it similar to their app updating functionality. That's how simple we believe updating should be.

How it works:


Client side
On the virtual app side, the autoupdate path can be either linked to a Cameyo server or to any path containing the package's XML file (network share or http(s)).
If linked to a Cameyo server, then all the configuration is done for you and you don't need to worry about a thing.
If you link the virtual app to your own autoupdate path (i.e a network share with up-to-date apps), then the package just needs to know where to find an XML for that latest version. This is indicated in the app's "AutoUpdate". For example, an XML path may be:
\\server\cameyo apps\MyApp.xml
or:
https://mycompany.com/cameyo apps/MyApp.xml

Server-side


On the server, the XMLfile has to indicate the latest app's version and the update mode:
<AutoUpdate><Pkg version="2.0.873" updateCondition="IfHigher"/></AutoUpdate>
And in the same directory, the EXE file has to be present with the same name (ending with .EXE instead of .XML), so there need to be two files:
MyApp.xml
MyApp.exe

That's it. Easy to configure, easy to use.
There's a lot of extended conditions, modes, exceptions that can be customized into the XML, but that's not the aim of this post.

Tuesday, July 24, 2012

How the Stuxnet virus inspired Cameyo's next version


Writing viruses & malware is among the less honorable activities a developer can do. Not only because it blindly targets random users (=vandalism), but also because 99% of virus writers just modify existing samples, without truly being the “genius geeks” that some people think they are.
Yet from time to time some virus creations stand out from the rest, and actually do bring innovation. Sometimes their inventions are even admirable. Such was the case for the Stealth.Frodo.4096 virus. Back in the old days of DOS, this virus gave a false (clean) view of infected files when they were opened. When users (or antivirus programs) opened an infected file, all they saw was a clean copy of the file, without the virus in it. This trick was perhaps the forefather of file-system virtualization, back in 1989!

But how is any of this relevant to us? Cameyo’s next version will allow executing virtual applications directly from memory, without pre-extracting their EXEs/DLLs/files to disk. This feature is currently code-named Cameyo Stealth mode. As it turns out, one of its mechanisms was inspired by no less than… the Stuxnet virus!

In November 2010, Iran has officially admitted that a stealth virus had infected their nuclear facilities. How long has it been sitting there unnoticed? Few people know; probably years. This was accomplished by the Stuxnet’s stealth abilities.

While working on Cameyo’s Stealth mode, I was impressed by some of the Stuxnet virus’ stealth mechanisms: particularly its ability to execute code without first writing it to disk. The virus writers knew they had to avoid leaving traces on disk to keep their malware invisible, and have thus implemented some execute-from-RAM mechanisms. And since this is exactly what Cameyo users have been requesting for some time, well… hey! Nice match.
About Cameyo Stealth mode
By not leaving traces on the computer, Cameyo virtual apps bring several new advantages:
* Portability & mobility: less files need to be taken / synchronized along with your Cameyo app. Hence your virtual apps are even easier and quicker to transport via the cloud, USB disk-on-keys, DropBox and LAN.
* Disk space: less temporary space used by Cameyo apps.
* Privacy & security: by not leaving traces on the machine, stealth virtual apps provide better privacy even if you forget to erase the application at the end.
* Copyright & security: Cameyo expiration features will become even stronger, for software makers who choose the package their applications with Cameyo.

So when you’ll be using the next Cameyo version, know that some of it was inspired by the Stuxnet virus. Ironically, the virus helped make Cameyo apps more secure and mobile. Of course, the mechanism described here is just one little piece out of the entire Cameyo Stealth mechanism (which is rather huge), but those virus’ anonymous writers deserve that credit.

For those interested in learning more about the technical aspects of Stuxnet, there is a detailed article here.

Wednesday, June 13, 2012

Cameyo 2.0 (geeks only!)

Cameyo 2.0 is now out of Beta. It is now linked to the cloud Cameyo Online service & library, supports Windows 8, and brings many goodies which you can read here. I won't go over these in this article.
Instead, I would like to take you on a tour into an advanced aspect of Cameyo 2.0 usage. I saved this for the geeks among you: the different ways in which you can customize Cameyo virtual apps' behavior.

Let's say you want to modify the behavior of a Cameyo app. Be it for changing its startup menu, its repository location, its expiration date, or even its environment variables.
If you're a Cameyo geek (a "Cameyozi"), you already know about the Package Editor and I would be insulting your intelligence if I went over this here. But here are a few other methods which you may not know about:

1. Environment variables (dynamic app configuration):
With Cameyo 2.0 apps, you can now configure every INI setting through environment variables. For example, let's say you have an application called "Appname.cameyo.exe" and you would like to use the same executable with different configuration each time (for each different user, different machine or each script that may run it).
Since you are a Cameyozi, you already know that the different parameters of the application are contained in VirtApp.ini (which is really most of what the Package Editor configured, despite its fancy UI).
But you can also change these variables by declaring environment variables with the same name, prefixed by "CAMEYO_".

Playing with the virtual repository's location
For example if you want to force the repository dir (BaseDirName INI variable) to be in \\\Server1\MyRepository, you can set an environment variable like this:
CAMEYO_BASEDIRNAME=\\\Server1\MyRepository
Then, run the virtual app and its repository will go there.
Note that the repository path can always include Cameyo / system variable names. For example if you want the repository to go to the Cameyo-defined variable ("%") documents folder:
CAMEYO_BASEDIRNAME=%Personal%
If you want it to go to system-defined variable ("%%") HOMESHARE folder (thanks to MHo for the trick):
CAMEYO_BASEDIRNAME=%%HOMESHARE%%

Changing the startup menu on-the-fly
As another example, let's say you want to change the startup menu of an application from a script:
CAMEYO_AUTOLAUNCH=%Program Files%\Soft1.exe>>First menu item;%Program Files%\Soft2.exe>>Second menu item
and run your app.
Here's what you'll see:
(with "First menu item" executing %Program Files%\Soft1.exe etc, within the virtual context)

Even geekier
Want to change the startup directory of a virtual app (instead of leaving it to the virtual exe's directory)?
CAMEYO_STARTINGDIR=C:\SomeDir
Want to add two environment variables to the virtual app's context?
CAMEYO_ENVVARIABLES=MYENV1=Something1:==:MYENV2=Something2
(":==:" is the separator, for allowing you to use both the ":" and "=" characters in your values)
("%ExistingValue%" is substituted by the variable's existing value, if any)

OK, let's stop here. One last note: if you work through cmd.exe or BAT files, be aware that "%" and ">" are special characters and you need to make sure DOS doesn't replace your values with something else.

2. Persistently modifying a virtual package, without the Package Editor
Want to modify a package persistently, but from a script? Find Cameyo's Packager.exe (C:\Users\me\AppData\Roaming\VOS\Cameyo\%Program Files%\Cameyo) and launch it with:
Packager.exe "-SetProperties:AppID=NewAppID,,Expiration=31/12/2012" "C:\AppName.cameyo.exe"
(",," is the separator, for allowing you to use single "," characters in your values)
Note that you can add a "-Quiet" as a first parameter to Packager.exe, to avoid messages (exit codes indicate success / failure).


3. SDK
You know that there is a C++ / .NET SDK for manipulating Cameyo packages and processes, right?

4. Streamed on-the-fly INI (Web / ASP.NET)
OK, this one is not totally useful for most of you, since it is not completely exposed in the SDK and is used only internally for now (by Cameyo Online servers), but just for your Cameyozi-culture, here's how it works:
The Cameyo Web servers are capable of providing the same virtual app executable, but with different configurations / behavior for different cases. Here's how it works: the Web server provides the binary
executable file. At the end of it, it calls an obscure Cameyo SDK function named "QuickBuildAppendiceIndexFile". This function, along with some database-stored information about the package, is capable of plugging an entire INI string at the end of the executable package string. So by streaming AppName.cameyo.exe + a dynamic INI string + the header returned by this function, the downloaded executable will behave with the new INI behavior.
Neat, isn't it? What, you don't care? Oh well!
Actually when you think about it, there can be a number of interesting applications to this: providing a single EXE app with dynamic metadata (logins, encryption keys, expiration dates, launch parameters...)




Oh oh, hopefully I didn't go too geeky this time. Hopefully you could pick something interesting / useful for your Cameyozi culture. As always, leave a note if you have some smart ideas.

I'd like to dedicate this article to Max who has been helping me with communication and localization during my work on Cameyo 2.0.

Sunday, May 6, 2012

Welcome, Windows 8 !

Cameyo 2.0 will support Windows 8.
But beyond that, I would like to show you a prototype of Cameyo Metro - a Metro-style console designed to let you deploy & manage Cameyo apps on different computers. Be it your company's IT, or your friends & family, you can now deploy virtual apps without having to manage complex deployment scenarios. All from the palm of your [PC / Windows tablet or phone].
Please watch, enjoy, and more importantly - send in your comments & suggestions (by email, or directly here). 
Welcome Windows 8!

video

Wednesday, April 25, 2012

The latest Cameyo 2.0 Beta contains a secret feature. No, it's not the clicking-on-the-logo trick (which now displays the version number). It's virtual services & drivers support.
It is hidden because it's still experimental. Not sure whether it will be unhidden for the official 2.0 version yet.
To activate it with apps generated by build >= 2.0.785, type:
   VirtApp.cameyo.exe -services:direct

If you wish to skip the confirmation window, you can also do:
   VirtApp.cameyo.exe -services:direct,skipconfirm

First, it's important to understand that even when this functionality will get "out of the oven", Cameyo will:
1. not enable service / driver virtualization by default; it'll have to be explicitly enabled.
2. ask the user for confirmation / authorization that they indeed want to integrate services / drivers.

User-mode services
These services, visible in Windows' Service Manager, are plain executable files that execute as SYSTEM. While building this feature, I initially considered running those services entirely by Cameyo, without any interaction with the Service Manager. However, I decided to abandon this route and take a more Windows-like approach. The approach taken here is to integrate a stub Cameyo virtual loader into the Service Manager, and have it launch the service virtualized. That way, the service will function in the most realistic way - both in terms of user account (i.e. SYSTEM), tokens, service options, and service commands.
Virtual services have the ".AppID.Cameyo" suffx, allowing them to be easily distinguished and removed along with the virtual app.


Drivers (!)
Those of you who have some experience with app virtualization probably understood the meaning of my exclamation point. I don't think any app virtualization product dared dealing with drivers. And there is a good reason for that! Drivers cannot be virtualized. However, their integration into the machine can. Now, let me explain this daring new initiative:
Just like with service virtualization (see above), the idea here is to temporarily integrate drivers into Windows. This is something Cameyo never does, and it requires admin privileges / elevation. Which is why it'll always have to be explicitly enabled.
Now, drivers that require the app's files to be in a certain directory (i.e. C:\Program Files\AppName) or under a certain registry key, will fail (remember, we don't virtualize driver's operations, only their integration into the system). Drivers that just do their job without accessing the app's files or registry (i.e. TrueCrypt), will work.
So with regards to drivers, it's not black & white. But hey, that's why nobody does this...
Any testings & feedback will be good.
This whole section & functionality is dedicated to Mule, who's been asking me about service virtualization almost since I started to work on Cameyo 2.0  :)

Wednesday, April 18, 2012

Cameyo 2.0 and community votes

Those of you who have been playing with Cameyo 2.0 lately may have noticed the following peculiar window:


What's behind all this? Vote for what? Is Cameyo going to replace democracy? 
Well, without going that far, the idea is that now with the public library (which is getting bigger and bigger every day), this allows users to flag apps that work well with Cameyo's virtualization, and those that don't.

So what do you do with this info?
It's quite simple: the more of you vote, the better quality apps everyone will get. Indeed, reporting virtual apps that don't work well, helps the Cameyo community in two ways:
- Once there will be enough votes, Cameyo's library server will be able to automatically filter out apps that don't seem to work well, so that users won't even see them (at least beginner users).
- This information is also very useful for our own quality insurance and development. By spotting apps that don't work well, we'll be able to find & fix more virtualization issues.

So now it's time for you to fulfill your civic duty and give back to the Cameyo community... by voting!