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


Courtesy of Reverser'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!

Reverser+,

  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 reverser'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_reverser
Is reverse engineering illegal?