> Change the way the program works here
Then it isn't really the same program if the changes are fundamentally different, so in essence, it isn't direct copying anymore. But changing another person's program in non-superficial ways is often as difficult as just solving the problem from scratch.
Cheating is also harder to detect in introductory classes because there are often few good ways to implement the algorithm in the first place (say, factorial, or pre-order traversal of a binary tree). Consequently, these tools tend to work better in larger projects, such as in an operating systems class.
> rename all the variables, and always use the same variables for your loops (x,y,z or i,k,l for example) between assignments and it'd be hard to detect.
It turns out this is trivial to detect; see MOSS [1] for an example of the type of analysis that is done on programs.
However, more often than not, cheating is detected by teaching assistants simply by hand ("Hmm, this submission looks familiar"), but instructors pretend that there is some sophisticated cheat-finding system to scare off students. Usually typos are dead give-aways, especially when two students have the same typo in the same comment at the same identical spot. In my academic misconduct cases, students were most often identified through spelling and grammar errors.
I imagine that there exist many more instances of cheating than instructors catch, and that we really only get the low-hanging fruit (and frankly, my job isn't to be the cheating police, so I don't go out of my way to find it). But catching the most obvious cases and having a severe punishment as a deterrence is often enough. ("If you cheat, you likely won't get caught, but if you do, goodbye -- it's automatic failure at minimum, and possibly suspension or expulsion.")
[1] http://theory.stanford.edu/~aiken/moss/ and the actual research paper http://theory.stanford.edu/~aiken/publications/papers/sigmod...