First, I have to say that this thread has me worried a little bit. Why do you want the uname command to output the wrong info?

The uname command typically resides in /bin or /usr/bin and it obtains information by invoking the uname(2) system call. Here is the man page for the Solaris uname command. Note that, as iamcollins mentions, there is support for using the SYSV3 environment variable to override the values returned by uname(2). I have only seen this feature on Solaris. If anyone sees it on another OS, please respond to this thread and tell us the OS.

Both the uname command and the uname function are part of the posix standard. But Posix does not strongly limit what info is returned. The various uname versions had differly too widely for any consensus to be reached.

The root user can certainly replace the standard uname command. If root replaces the uname command with, say, the famous, "hello world" program, then "uname -a" will return "hello world". And you can create a slightly more complex replacement command as well. It could understand the expected uname arguments and issue appropriate error messages if the arguments were wrong. It could read the data to display from a little config file rather than having it hard coded. Even an elaborate replacement uname command is still going to be very trivial and could be written by any competent C programmer. All of this seems very obvious and I wonder why it is even slightly interesting.

This thread is clearly about the uname command and not the uname system call. Originally, this "system call" simply had the output string hard coded. These days, it tends to be a real system call and read the data from the kernel. Most OS's still have some way to write data into the kernel. And this could be used to overwrite the data in the kernel. With some OS's even a shell script running adb could do it. Any solution along these lines is going to be very OS specific. And, at least on Solaris, the SYSV3 environment variable could then be used to ignore the incorrect data in the kernel and output the correct values anyway. So replacing the uname command is the only way to complete success.