POPIt Visual Basic 3.0 Protection Scheme Explained
(but not solved)
by flipper
(19 October 1997)


Courtesy of Fravia's page of reverse engineering

Well, some interesting points are made here by flipper! (Opentrap seems a must-have program for our tools collection, BTW)
I have already sent this to +Sync a couple of days ago, but I have also decided to publish it (pending flipper's authorization :-) and I'll keep it (accessible only from the blackboard, just to reduce the lamers' load) until flipper will send a revised essay. I believe that there are quite a lot of important things in here!


Fravia+,



  I read +Sync's message on your blackboard, so I decided to write up a

little something. Instead of just sending an e-mail, I typed it in edit so I

could attach it at a later time. I hope this helps out.



            POPIt Visual Basic 3.0 Protection Scheme Explained

                             (but not solved)

                         Written by flipper (upg)



This is the message that appeared on October 12, just last week from +Sync.



"I have spent several days looking at a VB3 program called POPIt, and

have had very little success.  I have talked to Razzia as well as

several others on IRC and it seems that this program has not yet been

cracked.  I was hoping you could possibly post a challenge on the +HCU

page, looking for information on the scheme this program uses.  It

claims that it uses the hard drive serial number off of your computer as

part of the protection, but I have doubts as to the validity of this"



For the past couple of hours, I too was intrigued by this protection scheme.

Normally, the first thing you think of when cracking VB programs is to run

DoDi's VBDIS Decompiler, but it just won't work here. You get various error

messages, and the program quits. Sometimes, it even says the mysterious

phrase "Cheat" for no reason at all. I hope this 'essay' of sorts starts up

a new +HCU project, because what I'm about to tell you may very well change

the way you look at Visual Basic projects again.



Okay, why not use SoftIce here? Well why not? The truth is, I have yet to

install the new version, and my video card is incompatible with SoftIce.



So, what next? I took one of my own VB compiled programs, and tried to de-

compile it. It worked alright, without any errors. So I decided to download

"Decompiler Defeater" from NPI's website (I trust you can find this program

if you need it, check for "OVERRIDE.ZIP" using Altavista). After using it on

my own program (UDP Sniffer), I saw that it was nothing more than a useless

toy for lazy VB programmers. Look closely, it's protection can easily be

defeated. All it does is overwrite selected "important" bytes from the VB

executable file, like the main form's header 'code', or the actual form names

themselves. No wonder my programs stopped working after protecting them with

this piece of junk.



I checked out POPIT.EXE (16 Bit & 32 Bit vers), and discovered that NONE of

these tricks had been used. I tried to change bytes around various headers,

but nothing worked. So now it was obvious, this was no ordinary VB compiled

file. Back to Altavista, I searched for "OVERRIDE.ZIP" and came up with a

homepage that had another file listed on it called MAKE_MAK.ZIP. The descrip-

tion is as follows.



Description.......: Make_MAK is a Visual Basic AddOn-Compiler.

                    Together with an existing VB.EXE (any version !) this

                    program compiles one or more projects faster than you

                    ever could operate VB !

                    Besides, EXE-files will partly be essentially shorter

                    since VB is now unable to store data-'junk'.

                    Make_MAK supports drag'n'drop from any file manager.

                    ANTI-DISCOMPILER: check "DecompDefeat" and your apps

                    will be immune against 'reverse engeneering' !



That sounds like a nice program to protect my VB file, let's download it.

After searching Altavista again, I found a homepage where I could download

this wonderful gadget. You can get a copy at the following URL.



http://www.programmersheaven.com/files/file1.htm



So I decided to test this one out. Guess what? It stopped DoDi's decompiler

before it even had a chance to pick out my object data. But wait, it still

loads up the VBX files.. strange, let's have a look at my EXE file again.



Here's the original file, at the form resource entry point. To find it in

any VB file, search for the pattern '03 20 81 80' in hex, there's only one

location for it.



00001C00  03 20 81 80 FF FF 53 4E-49 46 46 00 00 00 00 06   . ....SNIFF.....

00001C10  00 01 00 53 4E 49 46 46-00 00 43 0B 00 00 FF 01   ...SNIFF..C.....

00001C20  FF 01 56 2F 57 43 53 50-49 4E 47 2E 56 42 58 00   ..V/WCSPING.VBX.

00001C30  46 0A 04 80 48 00 FF 01-54 E8 01 53 4E 49 46 46   F...H...T..SNIFF

00001C40  2E 46 52 4D 00 00 00 58-00 00 00 1A 00 1B 00 AF   .FRM...X........

00001C50  00 00 00 00 58 01 00 00-1C 00 1D 00 AF 00 00 00   ....X...........

00001C60  00 58 02 00 00 1E 00 1F-00 AF 00 00 00 00 58 03   .X............X.



Now, what about the same location in the "protected" one made by MAKE_MAK?



00001E00  03 20 81 80 FF FF 53 4E-49 46 46 00 00 00 00 06   . ....SNIFF.....

00001E10  00 01 00 53 4E 49 46 46-00 00 43 0C 00 00 FF 01   ...SNIFF..C.....

00001E20  FF 01 D2 18 FF 43 53 57-53 4F 43 4B 2E 56 42 58   .....CSWSOCK.VBX

00001E30  00 46 0A 04 80 48 00 FF-01 D4 20 02 00 00 AB 55   .F...H.... ....U

00001E40  1E DC 05 4D 5D 00 00 00-58 00 00 00 1A 00 1B 00   ...M]...X.......

00001E50  97 00 00 00 00 58 01 00-00 1C 00 1D 00 97 00 00   .....X..........

00001E60  00 00 58 02 00 00 1E 00-1F 00 97 00 00 00 00 58   ..X............X



Notice how the "SNIFF.FRM" file reference is missing? And the filesize of

the protected executable is smaller than the original version.



This means that something is happening DURING the compilation process.



I used OpenTrap (grab a copy at http://www.zdnet.com/, look for OPENTR.ZIP)

to see what was going on behind the scenes in Windows.



[ here's my log file, unimportant items clipped to save space ]



000144 VB opened C:\TEMP\~VB1139.TMP at 23:43:06.180

000145 VB closed C:\TEMP\~VB1139.TMP at 23:43:06.180

000146 VB opened C:\TEMP\~VB1139.TMP at 23:43:06.180

000147 VB closed C:\TEMP\~VB1139.TMP at 23:43:06.180

000148 VB closed D:\MIX\F\SNIFF.FRM at 23:43:06.230

000149 VB opened C:\TEMP\~VB1139.TMP at 23:43:06.230

000150 VB opened C:\VB\VB.EXE at 23:43:06.230

000151 VB closed C:\VB\VB.EXE at 23:43:06.230

000152 VB failed to open D:\MIX\F\SNIFF.EXE at 23:43:06.230

000153 VB opened D:\MIX\F\SNIFF.EXE at 23:43:06.230

000154 VB closed C:\TEMP\~VB1139.TMP at 23:43:06.560

000155 VB opened C:\TEMP\~VB1139.TMP at 23:43:06.560

000156 VB closed C:\TEMP\~VB1139.TMP at 23:43:06.620

000157 VB closed D:\MIX\F\SNIFF.EXE at 23:43:06.620

000158 VB closed C:\WINDOWS\SYSTEM\CSWSOCK.VBX at 23:43:06.670

000159 VB opened C:\WINDOWS\VB.INI at 23:43:06.730

000160 VB closed C:\WINDOWS\VB.INI at 23:43:06.730

000161 VB opened C:\WINDOWS\VB.INI at 23:43:06.840

000162 VB closed C:\WINDOWS\VB.INI at 23:43:06.840

000163 VB closed C:\VB\VB.EXE at 23:43:06.890

000164 WSASRV closed C:\WINDOWS\WINSOCK.DLL at 23:43:06.950

000165 WSASRV closed C:\WINDOWS\SYSTEM\WSASRV.EXE at 23:43:06.950

>000166 MAKE_MAK opened C:\TEMP\~EXE1174.TMP at 23:43:07.0

>000167 MAKE_MAK closed C:\TEMP\~EXE1174.TMP at 23:43:07.0

000168 MAKE_MAK opened D:\MIX\F\SNIFF.EXE at 23:43:07.0

>000169 MAKE_MAK opened C:\TEMP\~EXE1174.TMP at 23:43:07.0

>000170 MAKE_MAK closed C:\TEMP\~EXE1174.TMP at 23:43:07.0

000171 MAKE_MAK closed D:\MIX\F\SNIFF.EXE at 23:43:07.0

>000172 MAKE_MAK opened C:\TEMP\~EXE1174.TMP at 23:43:07.0

000173 MAKE_MAK failed to open D:\MIX\F\SNIFF.EXE at 23:43:07.0

000174 MAKE_MAK failed to open D:\MIX\F\SNIFF.EXE at 23:43:07.0

000175 MAKE_MAK opened D:\MIX\F\SNIFF.EXE at 23:43:07.0

000176 MAKE_MAK closed D:\MIX\F\SNIFF.EXE at 23:43:07.0

000177 MAKE_MAK opened D:\MIX\F\SNIFF.EXE at 23:43:07.0

>000178 MAKE_MAK closed C:\TEMP\~EXE1174.TMP at 23:43:07.0

000179 MAKE_MAK closed D:\MIX\F\SNIFF.EXE at 23:43:07.0

000180 MAKE_MAK opened C:\WINDOWS\CHGTOOLS.INI at 23:43:07.110

000181 MAKE_MAK closed C:\WINDOWS\CHGTOOLS.INI at 23:43:07.110

000182 MAKE_MAK opened C:\WINDOWS\CHGTOOLS.INI at 23:43:09.580

000183 MAKE_MAK closed C:\WINDOWS\CHGTOOLS.INI at 23:43:09.580

000184 MAKE_MAK opened D:\MIX\F\MAKE_MAK.EXE at 23:43:09.640

000185 MAKE_MAK closed D:\MIX\F\MAKE_MAK.EXE at 23:43:09.640

000186 MAKE_MAK opened D:\MIX\F\MAKE_MAK.EXE at 23:43:09.640

000187 MAKE_MAK closed D:\MIX\F\MAKE_MAK.EXE at 23:43:09.690

000188 MAKE_MAK closed C:\WINDOWS\SYSTEM\CTL3D.DLL at 23:43:10.900

000189 MAKE_MAK closed D:\MIX\F\MAKE_MAK.EXE at 23:43:10.900

000190 MAKE_MAK closed C:\WINDOWS\SYSTEM\VBRUN300.DLL at 23:43:10.900

000191 MAKE_MAK closed D:\MIX\F\MAKE_MAK.EXE at 23:43:10.960



Sorry for the extra long log file description, but I thought it was im-

portant to note what's happening here.



First, MAKE_MAK is loading, then you pick a MAK file to compile, it loads

up VB.EXE (the compiler), and then proceeds to compile the program, BUT

somewhere in between it accesses one of the temp files VB is making, and

does something to it.



>000166 MAKE_MAK opened C:\TEMP\~EXE1174.TMP at 23:43:07.0

>000167 MAKE_MAK closed C:\TEMP\~EXE1174.TMP at 23:43:07.0



Visual Basic's compiler created that file in my temp directory, and then

used it to compile the final application. Somehow, MAKE_MAK modified this

file, and changed its contents so that the final EXE file is in "shrouded"

form. I tried jumping to DOS and running undelete. I managed to salvage the

file above, but I came up with random strings from a recent Windows memory

dump of sorts.



That's about it. I know a few more things about POPIt though. You must con-

figure it to enable the registration button, then possibly someone could use

SoftIce on it to get a working reg name/num.



I'm working on a "Decompiler Defeater" re-build program that'll take care of

that kind of protection, but as for this new form of protection, I'll con-

tinue to work on it, but if anyone else has any ideas, feel free to e-mail

me with them.



Also, as a final note, I checked out MAKE_MAK's claim that it works with all

VB versions, and they were right. It successfully removed all references to

any FRM files from my VB executables (v3.0, v4.0, and v5.0).



flipper (upg) [box01@ids.on.ca]



(c) flipper, 1997. All rights reversed.
You are deep inside fravia's page of reverse engineering, choose your way out:

Back to the Blackboard
homepage links red anonymity +ORC students' essays academy database
tools cocktails antismut CGI-scripts search_forms mail_fravia
Is reverse engineering illegal?