What Time Does the Library Open?
A "Cinderella" protection for beginners


Most stupid protection

02 December 1998

by Sojourner

fra_00xx
981292
Sojourner
1000
P7
PC

A simple "Cinderella" protection, well explained, for beginners and gullible protectors alike.

 
 

There is a crack, a crack in everything That's how the light gets in

 

Rating

(x)Beginner ( )Intermediate ( )Advanced ( )Expert

 


"A useful essay for beginners to see a different perspective of the common time functions in order to reverse more fully a useful prog and to see a different kind of function called to impede us"


What Time Does the Library Open?

Written by Sojourner

Introduction

Originally I had been a Beta tester for this freely available program from ftp://ftp.mcneel.com/pub/rhino/rhino32.exe. Now ftp://ftp.mcneel.com/pub/1.00/demo. Go there and have a look around if you'r interested. I did. The "latest" demo is still there, along with models, plugs for 3DS Max, etc. How nice for us! Since I work on 3D projects I had a personal interest in this nice piece of software, and had grown to like its easy user interface and its capabilities.
Also, I suspected that my beta format would have been very close to the version 1.00 release that we were told would be shipping after the expiration... the "full" version would retail for only around $795. Thanks, but no thanks, there's no way I can pay such a sum for a 'full' version, when my own beta could work just the same.
Since the last beta had a "Cinderella protection" dated October 1998, and used a very bad protection scheme, I could have used it for the infinity just resetting my PC clock everytime I needed it... as I suspect most lusers around are doing. But, hey, after all I'm (beginning to be) a reverser! And I decided to have a look at the code!
Since this was only the second reversing I had tried, I was a little scared to tell the truth. After I had read Tristan's essay from 31 December 1997, and he encouraged "newbies, to try your hand," I was more encouraged and bold. Also I had read and "studied intensely" at least 30 of the other essays from the +HCU 'student essays' area. Additionally, I thought to myself, " If I can do this reverse, I'll have a nice useful tool to study. If not, well then I'll have at least learned something about code!" Time was running out and I didn't want to keep setting my clock time to run that program to suit its fancy. I put my gray cells to work.
A brief note: you will need at least close to 200 meg of free space on whatever drive you use to disassemble this with WDASM 89 or your time is wasted. The rhino_main.exe is what we'll be disassembling and it creates an 80 meg file to start! Enjoy.Take 20-30 minutes and go do something else while WDASM 89 does its thing. As always when you reverse, take good notes. It will save you hours of needless toil in the future. Get a good assembly and WinAPI reference also. If possible even a Win95,98 or NT programming book.They are invaluable.



Tools required

WDASM89, UltraEdit, Soft-Ice 3.2

Target's URL/FTP

Get Rhino Here!

Program History

This program started off as a beta nurbs modeler and is now in full production after about three years

Essay

Reversing Started:
There are two separate areas that will be involved in the successful reversing of this prog. Both involve time in some way. A note- I want to make sure you have already installed this program and are not trying to reverse the initial executable that needs to be unpacked first. We need to be at the same start point. Thanks :-)

Inside WDASM 89 you'll need to open up the "Import Functions" box and look for Kernel32 GetLocaltime. Why? Upon startup, Rhino is doing some checking with the local scene to see what time it is and then making comparisons with some predefined parameters, namely, 1998 (07CEh) and 11 (000Bh). See below in code. If everything is ok, you can stay. If not, well, you know what happens! Additionally, you could do a string search for "This beta version of Rhino has expired" and in this case you would be right where you needed to be. This is just because this protection is particularly stupid and doesn't always happen so easily, though.

* Reference To: KERNEL32.GetLocalTime, Ord:00F5h 
                                  | 
:00488AE9 FF15088D8C00            Call dword ptr [008C8D08] 
:00488AEF 66817C2404CE07          cmp word ptr [esp+04], 07CE <== Here and :00488AF6 7508 jne 00488B0E :00488AF8 66837C24060B cmp word ptr [esp+06], 000B <="=" Here :00488AFE 7D00 jnl 00488B0E 
As you can see, these two compares above check local time against the "factory" authorized times. Both factory times are in hex. The first will jump you out if the year isn't exactly 1998 and the second will jump you out if the month isn't less than November. These come out of the WinAPI function for GetLocalTime. But wait. See below at 00488B00. There soon follows a ret which completes our local time function--IF everything is okay. If not you are sent to the 00488B0E expired nag and then out the door.
:00488B00 33C0                    xor eax, eax 
:00488B02 5B                      pop ebx 
:00488B03 83C410                  add esp, 00000010 
:00488B06 C3                      ret 
 
:00488B07 6A00                    push 00000000 

* Possible StringData Ref from Data Obj ->"Beta copy expired" 
                                  | 
:00488B09 6810C67F00              push 007FC610 

* Possible StringData Ref from Data Obj ->"This beta version of Rhino has " 
                                        ->"expired." 
                                  |
:00488B0E 68E8C47F00              push 007FC4E8 
:00488B13 6A00                    push 00000000 
So we must change some things to help us out. Change 

:00488AF6 7508          jne 00488B0E     <== Here to EB08 jmp 00488B00 (be sure to get the right offset first) :00488AF8 66837C24060B cmp word ptr [esp+06], 000B :00488AFE 7D00 jnl 00488B0E <="=" Here to EB00 jmp 00488B00 
Now we get to stay no matter what time it is. Yippee! Case solved Uh. Sorry. Not quite true!. Go ahead and make these changes in WDASM 89 and let it run with your clock at different times. It will LOAD up perfectly and appear to function alright. Make these changes with your favorite hex editor permanent before going on. Now for the acid test. Set your clock ahead, to say, 2010, and run WDASM again with your "fixes." It will allow you to start up the program without that nasty nag screen to bother you. Also, it will not kick you out. So what's the problem you may ask. Remember the file we saved earlier? Go ahead and load it now. Have you loaded it? Good. Now modify it in some small way and save. Boom! Bamm! Bong! We're out the door again. What the heck happened? I thought we fixed that bugger! Well, I must admit, I agonized over this. Whenever you just touched the "Save" button you were history and fast! Originally, I thought it was due to the GetLocalTime function in some way and set appropriate breakpoints in WDASM to catch these. There are several by the way. I also could not catch the process that called the "Exit Process" function this time. I couldn't get any breakpoint "nibbles" here, so I decided to try another route to one of the functions that may check up on buttons and their status. Nada, not jack squat