Unexpected termination

[Igeru]

Hello everybody

I recently published a thread concerning two questions, but got answered for only one of them, so here Im asking the second one again, hope you could help me..

How can I detect an unexpected termination of a program?
My program encrypts files, how can I possibly roll back the changes that were made on the file if he was not fully encrypted / decrypted (and therefore will never go back to it's original state)?

thanks

[JVene]

Well, you can't really.

Unexpected might mean power failure, disk failure - one machine I serviced was under a water leak (afterwards it was nicknamed the sparkler).

You can read up on exceptions, but they can't catch all operating system errors.

Some operating systems have their own exceptions features and you can often arrange to catch those something like exceptions, but that still won't tell if if the power suddenly cutoff or that the processor fried.

What you can do is process to a second output file such that there's a status code written as the last step. If that status code doesn't appear, the work wasn't completed. One typical approach is to write to a file with a recognizable working extension (sometimes .$$$ or similar), and rename only after successful completion.

[Igeru]

Ok, so I can write a file with a unique extension or a registry value everytime a file starts to encrypt / decrypt and change it once it's done, therefore I'll know whats the status on the next program run.. right?

By the way I didn't mean unexpected to the extent of power cuts or massive hardware failiure..

How does industrial encryption programs handle this?
If the program does not leave the source file unchanged and creates a new file which is the encrypted, they have to do something if the program shuts down (even by ctrl alt del) while the encryption is running..
no?

thanks

[JVene]

By the way I didn't mean unexpected to the extent of power cuts or massive hardware failiure..

I know, but the fact is that really is part of unexpected termination - it's a reasonable scenario to encounter which ought to be "handled" in a logical way, which is why I injected the point.

True, there are messages sent to Windows applications during shutdown (ctrl-alt-del in Windows brings up a task manager dialogs).

In other environments it is similar. You might be thinking of MSDOS, which is not considered secure or industrial, so any use of it is a "force fit" of this concept. However, there are interrupts representing these concepts that can be intercepted - none of them are entirely reliable.

[Igeru]

Yeah sure, understood why you brought up the power cuts and the rest..

Just to be sure I understand, you are saying that the world's leading programs which handle files, when shut down abnormally could damage the file they were handeling and there is no good way to overcome this?

[Paul McKenzie]

Just to be sure I understand, you are saying that the world's leading programs which handle files, when shut down abnormally could damage the file they were handeling and there is no good way to overcome this?

You mean like the UNIX operating system? Turn off a UNIX machine abruptedly, and then get ready to cry when you turn the machine back on.

Regards,

Paul McKenzie

[Igeru]

lol I didnt mean UNIX.. but why?

[Paul McKenzie]

lol I didnt mean UNIX.. but why?

But whether you mean UNIX or not illustrates the general point.

If the program, regardless of what it is, is writing or changing a file at the time the machine goes down, you're out of luck, unless the program stores backups before doing the operation, using techniques like this:

http://en.wikipedia.org/wiki/Snapshot_(computer_storage)

The UNIX operating system is just an example of a program (the OS is the program), that will more than likely corrupt the file system if turned off without the proper shutdown. Having said that, most operating systems work this way.

Regards,

Paul McKenzie

[andrey_zh]

Either the problem is obviously simple or I don't understand something....

Well, You have a file (say 'source.txt') which you want to encrypt. Create a file witch the name say '~source.txt.my_scrambler_tmp' and send encrypted data to it.

When you program gets to the end of 'source.txt', securely erase source.txt, then rename ~source.txt.my_scrambler_tmp into 'source.txt'.

If you (or your program/its user) see file with extension '.my_scrambler_tmp' it means encryption ended unsuccessfully and 'source.txt' is still not encrypted. White this in Troubleshoot section of user documentation.

That's ok that you need some free space on the disk(equal to 'source.txt' size)

[JVene]

You have it right.

Specifically with the file system, Windows registry, other control files (like /etc/rc in Unix), the process you outline is the only general approach which fits the circumstances.

There may be fault tolerant versions of operating systems, hardware and file systems which can help somewhat, but generally computer systems have too many potential sources of failure to rely upon them.

Honestly, the more you know how things work in a computer, the more amazed one is that they work at all

The notion of "in place editing" of files is known to be flawed (reasons already discussed), and the theory applies similarly to exception safety of copying objects in C++.

[andrey_zh]

You could also encrypt your file cluster by cluster (by 4096B by default on NTFS). NTFS grants that all read/write operations are either successful of recoverable, but you still need to save the number on the last cluster successfully proceeded.

Saying this I feel myself at fault. I would strictly recommend you to do this in a way I've described in my post #9. As cluster size could vary, some folks still use FAT, and even Linux file systems on Windows via third party drivers.

But what is you reason to encrypt/decrypt in a single file?

[Igeru]

But what is you reason to encrypt/decrypt in a single file?

what?

[andrey_zh]

Why do you want to encrypt your file and write encrypted data over the original?

Some modern file systems provide encryption on file system level (i.e. NTFS, EXT3)

[Igeru]

Sorry, I didn't understand why not to do what I do.. please explain..
thanks

[JVene]

I believe andrey_zh is pointing out that the service of encrypting a file may be available from the operating system, making the act of encoding within the application seem like extra work.

My own reaction is based on experimental work done a few years ago for a security firm. The encryption service in Windows (all versions from NT4 though Vista) is implemented in such a way that a nefarious utility can be used to "blank out" the administrator password, permitting access to the operating system and automatic decryption of those files encrypted by the operating system. Based on this research work, I can safely conclude the OS feature in Windows is all but cosmetics. I can now invade any system in about 3 minutes and copy all such files.

So, Igeru, the client for which I did this research agrees that encryption of files by applications is most pertinent.