just incase anyone didn't believe them already here goes the analysis (I do this sort of thing for a living) first off CherryOS.exe is what we call in the security industry "packed", that means that they have taken a compiled binary and run it through an obfuscator to make it hard to reverse engineer (or at least with hard if all you're doing is strings)...this is common for virus writers, worm writers, 31337 bot net kiddies, and on the legitimate side, game developers do this a lot...its not very common among the commercial (or free) legitimate software market (mostly because it doesn't work and doesn't do any good) so, the easiest way to defeat the packing is simply to let it start up (this one has several annoying checks for debuggers so its easiest to just attach after its loaded)...

the eula for this thing says its a violation to reverse engineer it, but if you do disassemble it you find they never had the rights to license it in the first place, so I don't feel worried to put this here...

if you want to follow along I downloaded a trial copy of CherryOS this morning and I got the latest version of pearpc as of this morning off of sourceforge (not from cvs, just the tarball), I am using windows XP with Interactive Disassembler (IDA)...

ready...here goes:

so the first thing we want to do is find some strings which are common to both, they will not in and of themselves give you the answer you're looking for but they will give us a good starting point, we will then use these to get a context on the code that uses these strings, we will then compare the functions (or in this case class methods) to see if they are similar (or in this case identical)

so, example number one lets look at something in the cpu emulation code (because that is the heart of the code)

direct your editor to cpu/cpu_jitc_x86/jitc.cc line 465 you will see the following small function

this first line allocates space on the stack for three stack variables to be used as function arguments to

the hf_printf function

.text:0040E8C3 cmp eax, 20000h.text:0040E8C8 jz short loc_40E8DE

this is checking to see if eax != 0x00020000, now normally function arguments are passed on the stack (on x86 at least), unless you're using a call convention called fastcall...I take it as hardly a coincidence that pearpc specified FASTCALL be used for this function and here it is, this line is one to one if(a != 0x00020000), then you see they jump to the return label if eax (or the first function argument) is equal to this

the lea (load effective address) instruction there is the equivalent to va_start(ap, fmt), it is loading the address of the first argument to this function after the format specifier, it then takes this plus the first argument and passes it on to another function (presumably ht_vprintf, so lets check that out some

the first thing to note here is that the functions in the source code and the functions in the disassembly are directly adjacent to each other with nothing but alignment padding between them, this is generally a sure sign they were compiled from the same source file (and are part of the same object file in linking)...

so looking at its content it should do little more than pass a global variable (stdout), the format string (fmt) and the varargs type to another function...and this is exactly what we find here as well...so just to be sure lets check out that global variable and make sure its stdout...a quick cross reference on it demonstrates is commonly used and always for output to the console, that sounds like stdout to me...

now lets go one function deeper just incase you're not convinced, after all these have been simple functions up to this point (mostly for the readers benefit you can find as many examples as you want in here) if this code is in-fact the pearpc code we will expect the function they call at .text: 00491F00 to be ht_vfprintf, the code for which follows

now remember to ignore the if 0'ed out code as it will not be compiled, if these two are identical we will expect to see a local variable of size 1024 bytes, a call to ht_vsnprintf passing the expected arguments, and then a call to fputs passing the buf and the file pointer then a return of the output of ht_vsnprintf...

this is exactly what we see, allocation for 1024 bytes (400h), plus stack space for 3 function arguments, and

stack space for one local 32 bit integer argument, then we see a call to a function passing arguments exactly as it does in the pearpc code then passing to a function now that second function, is at .text:004A3E60, if you look there you get a jmp to this

_3bz7j9l0:005C74EC off_5C74EC dd offset msvcrt_fputs

that's right, that second function call is exactly and verifiably a call to fputs()...

ok, I take it you're convinced that jitc_error_program() in jitc.cc is identical to code found in

cherryos.exe, but its a small function, so lets do some checking (go back to looking at cpu/cpu_jitc_x86/jitc.cc)

if the code was stolen, we would expect to find jitc_error above it (you might expect to find jitc_init, but it has a different language specified because its not extern "C", so it might be there but doesn't have to be)

sure enough you find exactly jitc_error (.text:0040E870) right above jitc_error_program, then you find

jitc_error_msr_unsupported_bits (.text:0040E840) right above that, and so on and so forth...

now, lets do something a little different, I noticed that pearpc makes use of __FILE_ from time to time for

debugging purposed, lets see if we can use this to see what the source files are named in cherryos.exe