Who owns your files?
Security thorough obscurity
Reverser's Anonymity Academy
21 Jul 1999
by [blue]
Courtesy of Reverser's page of reverse engineering
NAME chown - change owner SYNOPSIS /usr/ucb/chown [ -fR ] owner[.group] filename ... DESCRIPTION chown changes the owner of the filenames to owner. The owner may be either a decimal user ID (UID ) or a login name found in the password file. An optional group may also be specified. The group may be either a decimal group ID (GID ) or a group name found in the GID file. Only the super-user can change owner, in order to simplify accounting procedures. OPTIONS -f Do not report errors. -R Recursively descend into directories setting the ownership of all files in each directory encountered. When symbolic links are encountered, their ownership is changed, but they are not traversed.
So far so good... now read this beautiful essay by [blue] and then download this file chown.zip... and up you go, you superuser you... :-)
There is a crack, a crack in everything That's how the light gets in
( )Beginner (x)Intermediate ( )Advanced ( )Expert

Yet another example of Micro$oft dirty tricks: security thorough obscurity.

Who owns your files?
Security thorough obscurity
Written by [blue]


The trick: made them think they are secure. Keep repeating this.

Tools required

None really. Win32 development tools if you want to implement ideas from this essay.

You should know about Windows NT administration, Windows NT security model, ACL, ACE, Win32 programming (sorry... no assembly required :-)

A good book on NT administration is Windows NT 4 Server Unleashed by Jason Garms (you can find it on the Web).

Target's URL/FTP


Program History

Too long to put here...


Since the first multi-user operating system arise the necessity for controlling the access to resources. This leads to another problem: the system administrator needs a lot of rights to perform his daily duties (for example to do backups), but how we can protect some files from being accessed by sysadm? A company can have a lot of sensitive information: payroll lists, customers lists, etc. How can we protect this kind of files from being accessed by sysadm without anyone noticing?

In UNIX it's just not possible. The root account is omnipotent. When NT appears it claims it solved this problem. Please read the following statements carefully.

An owner cannot change the ownership of a resource they own. The owner can only give another user or group permission to take ownership of a resource. Security of resource is thus maintained by preventing users from creating or editing files and then making them look as if they belonged to someone else.

For example, if a user assign the No access permission to a file, a member of the Administrators group can still take ownership of the file and make changes to it. The user, by checking the ownership of the file, would see that the administrator owned the file, and had disregarded the No Access permission on the file.

Microsoft Education and Certification - Administering Microsoft Windows NT 4.0, page 133

Good, very good.

If an administrator wants to access a file that he or she is not granted access to, the administrator must first take ownership of that file. Once ownership is taken, the administrator will have full access to the file. It is important to note that administrator cannot give ownership back to the original owner. If this were so, the administrator could take ownership of a file, examine it, and then assign it back to the original owner without that owner's knowledge.

NOTE: Because administrators have backup privileges, an administrator could back up a file (or entire volume) and restore it onto another system. The administrator could then take ownership of a file on this new system, examine it, and then restore from backup with original permissions, without the owner's knowledge. Please keep this in mind when thinking about file security.

Knowledge Base Article Q102099 - Administrator Access to Files

Friendly warning.

The key distinction between C-level and B-level security is in the notion of access control. In a C2 (DAC) system, owners have absolute discretion about whether or not others have access to their objects.

Knowledge Base Article Q93362 - C2 Evaluation and Certification for Windows NT

Looks ok. The owner of a file should deny sysadm any access to file and that's it. The only thing sysadm can do it's to take ownership of the file and then give himself necessary rights, but this cannot go unnoticed: user can see the change of the file owner. Many people believe in those statements, and they give a feeling of security that administrators cannot view users' files if the permissions are set properly. However, it is simply not correct.

There are two possibilities to change the owner of a file using Micro$oft tools.

Services for Macintosh:

Windows NT 4 Server Unleashed, Chapter 10, Jason Garms

I take a look in Services for Macintosh documentation (including Microsoft Official Curriculum materials): there is no mention of first side effect: changing Macintosh owner also changes NTFS owner. Of course you can figure it out but after all that noise about "no possibility to SET owner" they don't give even a fine print warning. As you can see you have to dig, to search books to find what beast did you installed on your server.

POSIX Chown utility from Resource kit.

This is a different beast: it does not run in Win32 subsystem. POSIX subsystem like Services for Macintosh has it's own rules.

How about writing normal Win32 program to change the owner of a file? It's also possible (I'll give you a hint shortly). With administrative privileges (Backup, Restore and Take Ownership) it is always possible to change the owner of a file (without destroying the Access Control List!), even if administrators have explicit No Access to the file.

Win32 Security API

The key function is SetFileSecurity:

The SetFileSecurity function sets the security of a file or directory object.

BOOL SetFileSecurity(
  LPCTSTR lpFileName, // address of string for filename
  SECURITY_INFORMATION SecurityInformation, // type of information to set
  PSECURITY_DESCRIPTOR pSecurityDescriptor // address of security descriptor


Points to a null-terminated string specifying the file or directory for which security is set.
Specifies a SECURITY_INFORMATION structure identifying the contents of the security descriptor pointed to by the pSecurityDescriptor parameter.
Points to a SECURITY_DESCRIPTOR structure.

Return Value

If the function succeeds, the return value is TRUE.

If the function fails, the return value is FALSE. To get extended error information, call GetLastError.


The SetFileSecurity function is successful only if the following conditions are met:

Things are clear now: we have to construct a valid security descriptor and apply it to file we want to modify.

The details are left to the reader :-).

Few starting points:

Final Notes

Giving this we should question every Micro$oft affirmation. If they say we can't probably we can.

Ob Duh
I wont even bother explaining you that you should BUY this target program if you intend to use it for a longer period than the allowed one. Should you want to STEAL this software instead, you don't need to crack its protection scheme at all: you'll find it on most Warez sites, complete and already regged, farewell, don't come back.

You are deep inside reverser's page of reverse engineering, choose your way out:

Back to corporate survival




redhomepage red links red anonymity red+ORC redstudents' essays redacademy database redbots wars
redantismut redtools redcocktails redjavascript wars redsearch_forms redmail_reverser
redIs reverse engineering illegal?