DrunkenBlog

Finding the patterns in CherryOS

I added two more bits of evidence of evidence to The pits in CherryOS, one involving finding GPL'd code from another project (Cygwin), and one involving matching the code paths between CherryOS and PearPC:

'Profiling' the code paths of CherryOS appears to show it does... exactly the same thing that PearPC's code... even if they've changed some of the function names. If you stare at the below screenshots to see how things are connecting, you'll see it:

• CherryOS profile
• PearPC profile

The above is just an example, there's more at the source listed. (Source)

This one could get kind of confusing if you don't know what code paths are, so I wanted to try to break it down so non-geeks could have a better chance of grok'ing what's going on.

Here's the general idea behind what's happening. A programmer writes code in human-readable language (source code) which is then compiled into a language the computer can understand (what you double-click).

Think of compiled code as an exceedingly complex set of dominoes that are lined up, and when you double click an app you're setting off the first line. That line of dominoes will generally touch off another set of dominoes, sometimes multiple lines of dominoes, some of which will go on to set off other lines of dominoes and some of which will be reset to be run again.

Now, if you can imagine a line of dominoes setting off another group of dominoes, but handing off data to be acted upon by those dominoes, you have the basics of what a function of code is doing.

There are apps out there that let you run another application and watch exactly what it is doing as those calls are passed onto the operating system. These exist for a lot of reasons, like helping a programmer see what function, or code path, is giving an error. A programmer might also need to see what functions an application is spending all of its time in, so he can better gauge what parts of his application need more optimization.

To go back to CherryOS; if you took the pattern for what CherryOS does when it runs, and the pattern for what PearPC does when it runs, and laid them out on the floor, the color of some of the dominoes would be different but the pattern would be the same and anyone looking at them from above could see it.

When it comes to changing the colors of the dominoes, we go back to the human-readable language most developers program in. You might have a block of code called twinkle_twinkle which, when it's set off by a line of dominoes and handed some data, takes that data and displays it on the screen. twinkle_twinkle starts toppling its dominoes and displays what it was given to the screen, and then either dies or -- if the programmer has connected the last domino to another set -- starts another set of dominoes going.

Here's the thing -- with a set of dominoes, if you wanted to change what sets what group of dominoes off or what color the dominoes were, it's a complex process that might be impossible once you reach a certain level of complexity. Think of this as compiled code -- it might as well be set in stone.

However, source code isn't limited by meatspace, which means the programmer can link his code to set off the function twink_twinkle at any point he likes, from any part of the board he likes, and if he wants something else to be able to set off twinkle_twinkle all he has to do is write in a reference to it on any of the group of dominoes.

If he changes the name of the function twinkle_twinkle to asshat_pirate, he can change all the sets of dominoes that reference it with a simple find-and-replace in his text editor, and then the code is compiled so it can be double-clicked. The compiler then sees what is supposed to touch where, and automatically lays out the dominoes so that it works.

Which is pretty much what happened here; Maui-X did a find-and-replace on the name of some of the functions -- in the hopes that it wouldn't be obvious when comparing the two binaries looking for matches -- but can't change what those functions are actually doing and when, or the paths the code is taking, and hence can't hide the thumbprints of PearPC.

The functions have different names -- or colors to go back to the dominoes -- but the pattern is exactly the same, not just 'similarities', which again passes the threshold of guilt for anyone with the critical thinking skills above a toaster.

 Posted by drunkenbatman
    March 15, 2005, at 08:39 PM