       |
 |
|
 |
||
|
|
|
|
||
| The following article I once wrote for Palmtop-Pro Magazin (issue 2/1997).
Now I'm able to present the English version because a friendly guy did the translation job ;-) |
||
 ... is a bimonthly German publication that talks about any type of
handheld pc / palmtop computer / organizer ... |
||
Translation courtesy of Jean-Luc Damnet, |
||
| Anti-REVTRAN |
| With the appearance of
Revtran, the spectacular Mike Rudin's reverse translator for Psion series 3a/3c OPL, most
OPL programmers were afraid for their programs, because now all of their excellent code
(including the registration mechanisms) were open to prying eyes. We'll describe what can be done against it.
|
|
| Before we come to Revtran,
I take the liberty of a small, but necessary detour. What actually happens with our loved
OPL code when it is translated ? First, the Psion converts our source OPL text into a computerized mess. The size shrinks, because not only many variable names, but also all of our comments, are "stripped off". This mess is however not machine code, as one could perhaps think, but such a thing between OPL text and machine code. One describes it as tokenized code. If one opens such a translated file with a text editor, one can recognize some parts, e.g. texts. The files produced by the translation process are called "OPL object files" (* OPO, * OPA). Mike Rudin (1) wrote a piece of code which lets the translation process run backwards. Because of the reductions performed at translation time the re-translation does not produce strictly identical source code. Revtran replaces the deleted variable names by its own designations. And thus the curious contemporary can have a day. Over the years Revtran improved strongly in its successive versions. The original motto of OPL developers: "one does not put simply something garbage also in Program" - meaning certain mathematical formulas with power number - today no longer brings Revtran to an embarassement. Also by far, it is not sufficient to include only one stopper at program start : Revtran learned to omit unwanted procedures or to analyze only an individual procedure. If one lets skip some procedures, Revtran announces at least the start addresses of the skipped sections. One can find that same information from the object file, Revtran only makes it much more simple for the beginning hacker. One must give itself little more trouble to get out of the trap. The only genuine Revtran protection is to use another programming languages (like C). The programs or applications so developed are of the "image file" type (*.IMG, *.APP) and not reverse translatable with Revtran since they contain pure machine code.
|
|
| As the waves rolled, much
was heard as pros and cons against Revtran. Revtran even disappeared from the library in
the Psion forum of CompuServe. And it survived nevertheless - fortunately. I personally do not estimate the danger so high. Did someone try to reverse-translate e.g. Revtran with Revtran itself ? That succeeds, because Revtran is itself an OPL program ! And who's got afterwards the courage to examinate the centimeter-high stack of paper produced? One last comment : which program, if any, already contains exactly the code I need... OK. No new development for this discussion. But to all people who argue against Revtran: Revtran does not bring anything new to the world. We should regard it as a challenge and simply do what is needed for the protection of our programs!
|
|
| Some people only want to
have their programs protected, without spending too much time for it. There are several
programs (Shareware) to help them. Without guaranteeing completeness, the programs I know of at the time of this writing are : - OPP (2), an OPL development program with pre-processor and many advantages for developers. An option is the use of # pragma statements. " # pragma no_revtran " protects the translated program against Revtran. Prospective customers should test OPP exactly; the version available to me promises only protection up to the version 3.3a of Revtran. - NOREV (3), cannot be tested without registration, but it functions are protected in each procedure, so we can assume it works. - OPL Prot (4), of which I could only access the description : OPL Prot operates together with S3ATRAN on a DOS PC. It gives a protection only up to the version 3.3a of Revtran. You may find these programs on CompuServe (5) or in Steve Litchfields program library (6). OPL Prot can't be just downloaded, as its author wants to be contacted directly by email (4).
|
|
| If you would like to
"put your hands in the grease", you may now enter the experimentation room. However there are two prerequisites : - you should know how to use a Hex editor, - you should be curious enough to deal with the interior life of * OPO & co. Did you ever wonder how one could best defeat Revtran ? One comes out inevitably. Revtran must carry something out, that the actual does not have to : it must analyze the entire program code, in order to be able to re-create the OPL text. The program against which it runs may contain incorrect code ! Of course only in segments of code which are never used during the actual program run. Here is our chance ! Any program section to be protected is so prepared, and receives "siding " inserted, which will be executed. This can easily be carried out by a IF/ENDIF construction. I always caution that there are always several possibilities to program the same thing. This is no exception here. We shall however concentrate here on a single one. Later there will be no boundaries set to your experimenting creativity. The IF/ENDIF construction is inserted into the otherwise finished program, which is translated as usual. Then comes the hour of the Hex editor. Into the artificially created IF/ENDIF niches, some "crash code" will now be inserted. The byte size of the object file is not changed by this intervention. Let's enter into practical details.
|
|
| In the framework of this
article is not possible to explain the detailed structure of object files. Just remember
that the OPL code of the propared "niches" must be made sufficiently salient to
be later retrieved it the object file with an Hex editor. In order to understand what the OPL compiler/translator produces from our source code, let's have a look at some examples, which will later find some practical use.
|
 |
|
Sourcecode: |
Hexcode in object file: |
Example 1: IF 0 ENDIF |
4F 00 5B 03 00 4F 00 : "IF 0" 5B 03 00: branch destination below ENDIF |
Example 2: IF 0 PRINT CLS ENDIF |
4F 00 5B 05 00 92 A2 4F 00 : "IF 0" 5B 05 00: branch destination below ENDIF 92 : "PRINT" A2 : "CLS" |
Example 3: IF art%=$66 ENDIF |
22 00 4F 66 40 5B 03 00 22 00 4F 66 40: "IF art%=$66" 5B 03 00 : branch destination below ENDIF |
Example 4: IF art%=$66 PRINT CLS ENDIF |
22 00 4F 66 40 5B 05 00 92 A2 22 00 4F 66 40: "IF art%=$66" 5B 05 00 : branch destination below ENDIF 92 : "PRINT" A2 : "CLS" |
Example 5: IF $66 ELSE ENDIF |
4F 66 5B 06 00 BF 03 00 4F 66 : "IF $66" 5B 06 00: branch destination 1st instruction in ELSE BF 03 00: branch destination below ENDIF |
Example 6: IF $66 PRINT ELSE CLS ENDIF |
4F 66 5B 07 00 92 BF 04 00 A2 4F 66 : "IF $66" 92 : "PRINT" 5B 07 00: branch destination 1st instruction in ELSE A2 : "CLS" BF 03 00: branch destination below ENDIF |
| Examples 1 to 4 deal with
IF/ENDIF constructs in which the IF condition is never fulfilled, so the code placed
between IF/ENDIF is never used - that is our niche. Examples 1 and 3 only show the basic
pattern. Examples 2 and 4 contain actual additional code, that can look different... see
below. In examples 5 and 6, we shall now shift the "dead branch" into the ELSE/ENDIF area, here again example 5 only shows the concept.
|
| The next examples contain
only the different fillings, which must be inserted into their respective location (except
Example 10 which uses an IF/ENDIF construct). By manipulating the fillings Revtran "goes to the sky".
|
|
|
Source code: |
Hexcode in the Objectfile, its manipulation and explanations |
Example 7: PRINT "ABC" |
old: -2B-03-41-42-43-8B-92- new: -2B-00-41-42-43-8B-92- Inside the PRINT command (-2B ... -8b-) are enclosed: the number of bytes to print (03) and naturally the bytes to be printed (41, 42, 43 for "ABC"). A line feed command (92) is attached automatically. If the number of bytes is set to zero, the instruction is no longer correct and Revtran raises a "parse stack underflow" error. |
Example 8: CLS : CLS |
old: -A2-A2- new: -FF-FF- or new: -70-70- The one-byte instruction CLS (- a2 -) is replaced by an - FF -. Revtran doesn't know this code and raises an error "unknowQ code"; if one replaces the - A2 - by - 70 -, the error becomes "parse stack underflow" again; other values like - F0 - are also possible. |
Example 9: UP: (call of a subroutine with name UP) |
old: -53-LO-HI-82-
(branch instruction with LO/HI= Lo/Hi-Byte
of the subroutine pointer)
new: -53-11-11-82-
The procedure UP1 can no longer be found because of the changed pointer (from LO,HI to 11,11). Revtran raises a "VALUE absent..." error. |
Example 10: IF 0 : ENDIF |
old: -4F-00-5B-03-00- new: -4F-00-5B-FF-FF- The branch to the next instruction (03.00 - indicated in low byte/high the byte format) is now falsely addressed by the new instruction (ff, ff). Revtran announces "NO COMMAND stored for..."
|
| The manipulations presented
here are to be understood as demonstration examples. They should be not stubbornly taken
over, but rather be adapted to the actual conditions and circumstances. Likewise a check
for successful result must be carried. There is always a possibility that a manipulated
branch lands nevertheless "correctly" somewhere ! Do not forget: each important procedure must be protected individually. In practice, it is also meaningful to protect e.g. the password procedure with several variant layers. Also Revtran will develop itself further! The manipulation work is to be carried out particularly easily with such Hex editors, using Search & Replace commands. This way, one can attach the protection using the same source text very fast... False! The potential hacker also appreciates this procedure! "Hackers" are strictly speaking faulty (friendly said: rationally thinking) humans. They want to save work, time and cash. Make the work heavy for them, vary your protection methods. This will increase their expenses, the time they have to spend using the "tank breaker", and they will be discouraged. I have presented you with the basic method - now it's up to you to develop it, let your fantasy play!
|
|
| We have shown a way to
protect against reverse engineering by means of Revtran. To achieve this, the translated
OPL programs (object files) must be manipulated suitably with an hex editor. To get a better protection, one must spend some time to carefully craft the protection methods to be applied. However, one can only achieve an absolute protection against Revtran by use of another programming language. |
|
| (1) Revtran 4.2a (1995),
Author Mike Rudin, mrudin@cix.compulink.co.uk (2) OPP 1.6F (1996), Author Andy Clarkson, 100661.244@compuserve.com (3) NOREV v1.3, Author Raymond Stone, raymond@raymie.demon.co.uk oder 100573.2051@compuserve.com (4) OPL PROT, Author Marco Aicardi, peuricultura@ge.infn.it (5) CompuServe, GO PSION, Library 18/19 (6) The 3-Lib-Shareware-Library, Steve Litchfield, http://3lib.ukonline.co.uk/ (7) Hexeditor for Psion S3/3a, Part of "Commander 3", Yellow
Computing Computersysteme GmbH, PF 1136, D-74173 Bad Friedrichshall |
| Copyright: author Ulrich Krinzner: e-mail:
krinzner@snafu.de - Please don't reprint without permission! -
|
| [ Home | Haunted House | Download HH | more ... ] |
 |
