Blowfish Advanced 97 beta 1
(encryption decryption)

by Jon

(12 October 1997 - 1 January 1998)

---

Courtesy of fravia's page of reverse engineering

Well, we'll have to open a special section of my site, dedicated exclusively to encryption and decryption (or, better, decryption of encryptions :-)
In the mean time you'll find here a short, but important essay by Jon (the protection scheme of this target is utterly stupid, but the target itself is VERY important for our endeavours), a letter to us by Mark Rosen, author of Kremlin, and my answer... short afterwards I got a letter from Markus Hahn (the author of this very target: Blowfish advanced), you'll be able to find this too below, together with my answer.
Enjoy and add any comments you believe should figure in the new section... I hope to develop all this in a full-fledged project as soon as I have the time

From the same Author (Jon): encryption tutorial and kremlin 1 AND kremlin 2

Tools needed:
W32DASM 8.9 (any version will do)
Hex Workshop 2.53 (or whatever you prefer)
Fetch BFA97 at: 
http://www-hze.rz.fht-esslingen.de/~tis5maha/software.html

I've always liked the Blowfish Advanced series, since the '95 version was 
released. Back then I just leeched it using the keyfile by Madmax!.
But now there's a new version out: BFA '97 beta 1. This one has a LOT of 
improvements and additions, so of course I loved it. Since this version 
is a beta, there are some functions that are missing. For an example a 
Register Dialog(!). I quickly realized that I wouldn't be able to easily 
fetch a serial from memory using Softice. Bye bye "live" approach. 
So I disassembled it with W32Dasm 8.9. 
I noticed that in the about box (where there usually is a Register dialog...) 
there was the nag text "Unregistered evaluation copy", I searched for it
in W32DASM and found it at line 218390. Disassembled text:

* StringData Ref ->"The Hunt for Red October" ;Weird name. Sounds like it's searching for a keyfile.
                                  |
:00461047 BA58154600              mov edx, 00461558
:0046104C E85BE1FEFF              call 0044F1AC
:00461051 84C0                    test al, al
:00461053 7412                    je 00461067 ;Interesting! If true jump to Registered_release.

* StringData Ref ->"Registered Release" ;This is what we want the about box to say.
                                  |
:00461055 BA7C154600              mov edx, 0046157C
:0046105A 8B83E8010000            mov eax, dword ptr [ebx+000001E8]
:00461060 E8C3EFFBFF              call 00420028
:00461065 EB10                    jmp 00461077    ;jmp unregistered cram

* Referenced by a Jump at Address:00461053(C)
* StringData Ref ->"Unregistered Evaluation Copy" ;The nag text found in the about box.
                                  |
:00461067 BA98154600              mov edx, 00461598
:0046106C 8B83E8010000            mov eax, dword ptr [ebx+000001E8]
:00461072 E8B1EFFBFF              call 00420028   ;eat this before continuing

I know that this program uses a keyfile named bfa97.usr for it's registration info 
(the '95 version used the same concept, a file named bfa95.usr). And the function 
named "The Hunt for Red October" is most likely the one that checks the keyfile.
So lets examine this function... It will JE (jump if equal) to good_guy if the 
keyfile's valid and to bad_guy otherwise...
Why not change it to JNE (jump if not equal). This will make it jump to good_guy 
if the keyfile's not valid! 
To do this, highlight :00461053 7412 and you'll see in the status line that the 
offset is 00060453h. Now open your favorite hex-editor and go there. Next you need
to change 74 (JE) -> 75 (JNE). Save the file, run BFA97 and check the about box... 
It will now display "Registered Release"! Elementary stupid reversing!
BTW, you don't need to make a fake bfa97.usr file. If the file doesn't exist it's
also considered invalid :-)

I find it quite strange that a author of an encryption program can't come up with 
a stronger protection scheme... 
It 's the same with Kremlin, that lets you select "unselectable" algorithms trough 
the stupid (and huge) Window$ 95 registry (read my other essay about kremlin ).
Why don't these authors use their encryption skills to protect better?

I hope you enjoyed (and possibly learned from) this essay :-)
Greetings to +ORC, fravia+ all the +HCU'ers, PC '97, UCF and all +crackers!

Jon 

"I find it quite strange that a author of an encryption program can't come up with 
a stronger protection scheme..."

    Hey. Nice reverse engineering page. I saw the thing on Kremlin... I'm
the author of Kremlin! Oops! Well, I guess next time I'll spend more time on
the protection scheme -- I concentrated on making a good program, not making
a good protection scheme. Kremlin 2.0 will be really cool and will, now,
have better security features and won't be as stupid. If the Jon guy who
cracked the program wants a free copy, just tell him to e-mail
mrosen@peganet.com and I'll give him one -- nice work.
I thought up of a "uncrackable" mechanism. Not really, but it's mathematically
unbreakable. It's pretty simple:
    generate two large primes, p and q. Store the result of p*q (called c)
in the program. Yoru registration keys are p or q. If the registration code
goes evenly into c, then you have a correct registration system. The
difficultly lies in factoring c. You might think factoring is easy, but try
factoring a 128 digit number! That's actually the problem -- your reg codes
will be 128 digits long! I guess if you store the number using letters and
numbers (80 possbile chars instead of 10 possible), you can get a 16 digit
reg code. Not bad. I think I'll do this.

    Have you thought of any better ones? The only other thing I can think of
to avoid cracking (assuming  you don't have a shitty system in the first
place like me) is to include some sort of checksum. BTW, here's a cool
checksum (fletcher checksum. in software, it's better than a CRC)
    
    s1 = 0;
    s2 = 0;
    for (x=0;x<len;x++) {
        s1 += data[x];
        s2 += s1;
    }
    checksum = s1+s2;  

    it works! think about it: a simple addition checkum would have a 1/256
chance of having two errors cancel themselves out (for example 0x00 0x256
would give the same checksum as 0x256 0x00). I can't figure out the chances
needed to do that with the fletcher checksum, but it's really small!
elegantly neat.

Mark Rosen
Mach5 Software (http://www.mach5.com/)

Dear Mark,    
Thanks for your letters, hope you'll agree to see them published here together 
with my answer to you (I know that you'll read this essay by Jon, as soon as I publish it...  
btw, his "encryption" tutorial has been re-written and re-published as well).

I actually believe that there are much SIMPLER ways of protecting effectively 
your software than to use a 128 digit number, here some ideas that I (or others) 
will develop in the next months:

checksums
Just use some of the HEADER data (you remember good old dos programs, don't you)
that nobody remembers or uses nowadays. Alter one of them in a file that you 
MUST open (no filemon easy track) and then use IT (with due "feeling", i.e. not 
obviously) as checksum (or, even better, as check-checksum). You get the idea?
Should be pretty easy to implement.

crippled sharez
Well, cripple it EFFECTIVELY, don't just allow easy reenables... compile the
sharez ANEW, without the routines you don't want lamers to use... they will 
have to write them ex-novo, which is NOT what normal-level crackers do (yes, 
we do it, but we are a race apart).

unregistered lamer nagging
Well, why don't you use some of the  most obscure values of the API functions?
There are THOUSANDS of them, values that nobody uses or remembers or even knows
exactly what they are supposed to mean... gosh, you could even open a "commonly 
found" *.dll inside windows/system and modify its FIXED (unused) VALUES... normal 
lamers will never understand what's going on...

call funny_existing_API
get  funny_existing_return_value
use it to fire lotta useful things in your program AND THE NAG... you dig it? :-)

later, hope my site was useful for you
fravia+

Hi,

I see you really like Blowfish Advanced 97, and I was astonished how straight you
found the registration routine.

Ok, you wrote:
"I find it quite strange that a author of an encryption program can't come up with 
a stronger protection scheme..."

Well, I don't spend much time on writing hard-to-break shareware-protection 
schemes.
I don't know how much you know about _real_ computer security, but for 
myself it's just waisted time to try to write a super-software protection 
scheme.
Of course it might delay the cracking process for some weeks, but 
then... Users who register my software are the ones who support me 
and push me to continue improving the software. For crackers and illegal 
"serialz-users", well, you should know what you're doing. 
For myself it's better to improve the quality of my software that 
to join the "hacker-warz" :) 
Sorry that the registration-code in BFA97 was so easy to break - 
in comparison to the file encryption functions of the program.
I'd like to hear your opinion...

Markus
-- 
Markus Hahn

I have only one answer: Dear Markus, your program is VERY good, it's the encryption program I like BEST (and I have tryed quite a lot of them) and I'll buy it myself -it's a promise- as soon as your gamma or delta versions, without bugs will be out... at the moment there are some heavy bugs inside: the most annoying one, for me, is that if you keep blowfishing and unblowfishing a WHOLE directory, where you have modified only SOME files (say 12-13 out of a total of 250) there comes a moment where you ARE NOT ALLOWED any more (by your beta) to unblow some files UNLESS you copy them in another directory...
Hope this will help you developing your smart product. fravia+ (January 1998)

---

You are deep inside fravia's page of reverse engineering, choose your way out:
homepage links anonymity +ORC students' essays academy database
tools cocktails antismut CGI-scripts search_forms mail_fravia
Is reverse engineering legal?

---