First part 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.(c) flipper, 1997. All rights reversed.
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 a week ago, 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) [firstname.lastname@example.org]
Second part An Explanation of how Make_Mak for Visual Basic Works Written by flipper (upg) (This is a follow up to my previous document about the POPIt mail notifier) After a few more hours of looking at Make_Mak for Visual Basic, I realized that this was a project I couldn't do alone. So, here are my findings for this strange and very rare VB utility. Files You'll need and Their Locations 1. Make_Mak - http://www.programmersheaven.com/files/basic/MAKE_MAK.ZIP 2. OpenTrap - ftp.jwpepper.com/pub/pcmag/opentr.zip or ftp.zdnet.nis.newscorp.com/pcmag/1997/0701/opentr.zip 3. WinSourcer v7.0 you can find it on the Web Phase 1 ------- First off, we'll take a look at a compiled VB application. I created a project with one form, no controls, about half the size of the default window. I only put in one or two lines of code, then I saved the whole project, and made it an executable file. I then renamed it, and loaded Make_Mak up. Make_Mak is a program that can compile up to 3 Visual Basic MAK files in a sort of batch queue. There's one interesting option in it though. You can select the "DecompDefeter" so your final executable cannot be decompiled by Dodi's VBDIS. I had to find out what caused this, so I began to investigate. Before I continue, you might want a copy of the two files I'll be working with, so I'll post them below in UUENCODED format.
Inside the zip file you'll find the project file, the form file, the VB compiled executable, and the Make_Mak compiled executable. The unprotected file is called NOTHING.EXE and the protected is NOTHINGP.EXE. ** Notice a difference of 14 bytes between the two files. Phase 2 ------- Next, I tried to decompile the unprotected executable with VBDIS. No problems there. So I went on and tried it with NOTHINGP.EXE. VBDIS was stopped dead in it's tracks. The error message I got from VBDIS was: " contains unknown structure! You may send this program to DoDi to improve VB Discompiler" then another message box comes up, and finally that mysterious "Cheat!" message box pops up. I'd like to know what that means, but then again, getting ahold of Dodi is another matter. You can easily decompile my original example NOTHING.EXE, and get its source code listing, but that still doesn't explain why NOTHINGP.EXE won't decompile. Phase 3 ------- In comes WinSourcer v7.0. This program is one of the few that can determine if a program has been written in Visual Basic or not. So, I ran it on my two targets. Both programs have the same startup code - 1.0010 start proc far 1.0010 call far ptr VBRUN300_100 1.0015 add [bx+si],ax 1.0017 or [bp+si],dh 1.0019 add al,[bx+si] Both programs have the same VB code and text - 4.0000 db 48h, 49h, 9Ah, 38h, 20h, 00h 4.0006 db 08h, 00h, 1Bh, 00h 4.000A db 'This is the closing screen.' 4.0025 db 00h, 34h, 38h, 40h, 00h, 9Ah 4.002B db 38h, 10h, 00h, 30h, 00h, 0Bh 4.0031 db 00h 4.0032 db 'Message Box' 4.003D db 00h,0F4h, 52h, 48h, 49h, 35h 4.0043 db 0Eh, 4Bh, 49h,0D9h, 65h, 5Eh 4.0049 db 0Eh, 5Bh, 0Eh, 00h But what about Segment_3? [ original NOTHING.EXE ] 3.0000 db 00h, 00h, 19h, 00h, 00h, 00h 3.0006 db 00h, 00h, 16h, 00h, 00h, 00h 3.000C db 01h, 00h, 00h, 00h, 00h, 00h 3.0012 db 2Ah, 00h,0DFh, 34h, 04h, 00h 3.0018 db 06h, 00h, 97h, 32h, 02h, 00h [ protected NOTHINGP.EXE ] 3.0000 db 00h, 00h, 19h, 00h, 00h, 00h 3.0006 db 00h, 00h, 16h, 00h, 00h, 00h 3.000C db 01h, 00h, 00h, 00h, 00h, 00h 3.0012 db 2Ah, 00h,0C7h, 37h, 04h, 00h 3.0018 db 06h, 00h, 0Fh, 2Eh, 02h, 00h ^^^ ^^^ The two rows I've underlined have changes in them. I switched back and forth between windows to see what was different, and those four bytes changed along with a lot of other bytes in this segment of code. That can only mean one thing. Make_Mak is somehow removing the FORM name reference from my file. To find the Visual Basic "form and library table" search for bytes '03 20 81 80' in hex, the pattern only occurs once in the executable. In my last letter to Reverser+, I gave a short log listing from OpenTrap, but I'll once again give the most important lines just in case you missed them the first time. I was quick in assuming that Make_Mak opened a file that VB was using in my Temp directory, but upon closer inspection of my log, it looks as if that's a Make_Mak exlusive tmp file. 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 It's strange though, what is Make_Mak up to after VB compiles the application? Final Notes ----------- That's as far as I can get without some serious knowledge in assembler, but I can tell you this. POPIt was protected using Make_Mak, and as an interesting aside, so was Dodi's VBDIS.. Take a look at VBDIS, and search for the string ".FRM", you won't find any references. Here is the author's address - Christian Germelmann Promenade 58 37431 Bad Lauterberg Germany Think for a second. This protection cannot be _that_ difficult, as it was not written by a small or even large company at that. In conclusion, until we find a way to decompile Make_Mak itself, we may never know what kind of protection this is. As far as I know, the location I gave for this program is the only one on the net, so for now I'll consider it very rare indeed. written by flipper (upg) on 10/19/97 [email@example.com](c) flipper, 1997. All rights reversed.