An Explanation of how Make_Mak for Visual Basic Works
(A Visual Basic tough protection?)

by flipper

(20 October 1997)

Courtesy of reverser's page of reverse engineering

Well, an OPEN ongoing project... we need help on this by you all Visual Basic reverser... some of you had already seen the "first part" of this work by flipper, I'll publish the first part AND the second part even if there are some redundancies: this all makes interesting reading in my opinion... we have here a visual basic (apparently tough) protection against decompilation... who would have thought it?
Yes, as our French friends say: "Tout passe, tout lasse, tout casse"... You could (freely) translate this with "Everything has an end, everything can be cracked" :-)

First part follows
Second part is here

First part

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 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. 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, 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) []
(c) flipper, 1997. All rights reversed.
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 - 
 2. OpenTrap -                   
 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.

section 1 of 1 of file <uuencode 5.32 by R.E.M.> begin 644 M4$L#!!0````(`-E\4R,\62@5^P```)P!```+````3D]42$E.1RY&amp;4DVMC\U* MPT`4A;]I)FUJ&quot;&gt;K.ZB98R4I$%QK=204WXB)0040($D,;TA]H6O`Q^D@^@*_A MLN`#*..=-B#=&gt;^Y<yc!\g'o'?!rcyl"=-.[m9#hz\tuew+8+o3j$#7@0wu9t MZ1C1T9HXM\2%12++7%K(J(Y$J48Z>HWG^4Q+6K@R7[P[D6O8%::F#Q5\NS6V M252BFJB:H^LMU]M:Q(NXD(1]_O3$_ZA87WZU6W(SS-/&quot;DY<]fgb82j!q%#x; MG.+T>87&quot;(W6[DWP!O23@0*HWR,M`SFR0!&gt;EP4N;C?E&quot;FTRP;G_#)-4MV:$G= M9V7YTL^&quot;[N2-4*$C&quot;;G:&amp;*_M&gt;'Y^`5!+`P04````&quot;`#D?%,CJ^_M1EH```!R M````&quot;P```$Y/5$A)3D<n34%+\_,/\?#t<]=s"_+ey0hhrl\*s\p+sjq*m;4p MU#&V,-`Q,K'0,3(T1<AEY)?;&O%R>2;GY[GE%^7:*H%(0R5&gt;KI#,DIQ46R6H M@4`!UXI4O\1<a)">:X0K4!@`4$L#!!0````(`.)\4R.ZVKDY]04```X6```+ M````3D]42$E.1RY%6$7M6&amp;],4U<4/^]/:46@e3$4ao`zl?lc,`2$3hl5ap4r M0,;0.<9F&'381%KWVC>V#XQ'_(*KLB]+7-R<6<;'q6q+/]b M]L%D6[(1HE%80A?^W)W[WBU@QM`E3B?QM+?W_NX]YY[[Y]Q[SFU-(P$#`$B8 M"(%9VH*)@]M0'#RD!YP.#A?^U'LQ^,N+="2?,7-WY+Z43'/PXO#_*!1+[,X70" MLB'K%URH>L@:RA^R.@2_`2M'1WKC<j`p'(r>),3675I7IJ3:NCOYADHER:9V MBJ6*\9!B.%#\D8&quot;-'1XE@S9Z6Y44S$6/K&quot;0@4URI8NBO$D8_&amp;3MNLQN4DX<z MA0.;CPJAM"&K6#8PS/>(KK/B1DQ-KE#%5S!D/3C<&sxus!>$3[I@[/AVM9,T M!<2saj:*@8m\,.d"/][7/\r?@-(ajvs^[)@p6ggp8n\p#g9d$pgb2/;/d,"u MWLP<",ZH#@C\_+EC4T",#RL3P0OKOM__)Q?X+3B!W8_W;:="R=.RC'_">_)8Q, MS]&quot;Y!G%HJ)F0L&gt;,3EX)7@I?H:`:ZP?9&gt;-7EOD#_C&gt;+?C!UM/.2FX)MP\9&quot;^; M'N^;.H6M9PU21;#XJ*#I/5\UWJ=/0.^&amp;=D%U?7I4$$ZON^0W99O%F_;3\@&amp;J M;(`.A7($,X\)`TT0$;^&gt;B93S9&quot;A2+EI#D?*XS5@R64<by?$?0lb)7?8#e[gs MO`DZ/-Z\%E_[7;*.ACT>O[1/]K7)S&gt;V2['Y3\<anou3c:9%]?m\;`>DEC[?5 MU^'/2XS/?MFG2,VR6VK&gt;*[N;6]^19,7K]7C;%F;&gt;X6U^?:];&quot;O@D?Z!9#BS, M-/\Z&gt;DC_$=5N,\1/`0^N;?45R0(/8($ZBW;S\R!BGH&amp;&gt;8`_\&quot;C=@#&amp;:T^]Z$ M?H(W,7'!!&amp;E0MSI-`RL2&gt;(A'MV%9#=PRJ`9+1O6L'A,DJ;H_2<!>\S,X51-7 M&gt;:TN$;7%ZLP@8)G7RO&amp;J06M/GM&gt;&gt;HLGK[8]J95$KIVIE@_KW.9IJMS=45M56 M@.[33#NWUN^H+<s/!u@uk^4a43i"3qu'mq@$;@666g'i5^*6+%&jk#ibe]`z M']/O.OP&]KBEEKT^/[V\_"VRV^W-@R+[%CABMT`^+(<:M]_?W.:6MOK>AC_J M*ZLV)#U?=<7]6m(k2?!`dgyv4v?co:?a:i&(h=wa`ay4b\[3@p;q`7<y-qu7 MZIB31Z03X!T!'"U1^4:-UP$1BPCIT&9&^3H)>YU(IIQ&gt;[G#1*FR?)C/F.7F8 M)V]@^DDNU1]QS.FOQ/0J5V)/752^@\V(@R+\S4&amp;I<ui4zv+ck<9\3e9do#q< M!_$.UFFI$ET!2>(QQ_N3HUB2J`<0x7>&gt;&gt;H&amp;E34^RM\\6;26XV)(L2-3@R((T M2,B4HXN<f<j*.j>,DV0J&quot;U/7))DFBZ=!,CE52B;/#)*HPXDY(5$GP?I_2U0_ M=)$P9$4!C)AHWA7%HW'GR4FBPNWUPY+&gt;?_T&gt;4/_1Z%7M&quot;ZJJ9_1#J_`G'`Y3 M&quot;]&amp;^]&quot;&amp;M9?1#J^[ELKU/C/OF(T*,':S&quot;I&amp;^AL4.OB&amp;UIK'T6[X-;,,&quot;]Q#T] M\_$<hibbz]=c^%9$:3%tgxdl=f[5^w=n!:e;)60v##;a(9@%k@111=_)?5,9 MJ\MSU>@T&quot;Y,Z1@RM=$&gt;=N%MF0&amp;K&amp;<"cdpe9#`ct;%d9p+/u.*qa`%u]-jqe M`)\5-GB"`2,]DT\Q8*+AP#H&EE&?GLL`OC/RX!D&E@-&9NL92-3B5TX'%H`- M4,Q:5@"4@)V!9(!G82,#CP!LPL!%!RG4Z\4ZP+AB,SA9RTIZ3Y0Q@+',5GB. M@6SZ+HG)K`4HAVUZBTZW@/\="[;;'0H'==MOL_X#S?^ESK\ULS+N&lt;">[7H<`%h MKT.\*/+F["L%S,6T3H_&OM5B1A-[^24`-0JT)Y5B44.-F@G="?6K4HL5TIC%&amp;" MZ>P]6U+$,?TBXR#?Y0#7C07]#9B(_X:Z?'+[&gt;D,:FF@#M4PTR!U83N-PN]?0 MR67K'!LH1S%E*:$\=LJ$TR_4'0GV8WM!\03$&amp;Q`62@P$T/C(\G,+CIF_C^&amp;G M/A=C2WLK'&gt;U?4$L#!!0````(`/1\4R-@&amp;FC6\04````6```,````3D]42$E. M1U`N15A%[5AO3%-7%#_O3VE!H,B8#H;P.K'[(R**M)VV5!P6R!&quot;80^<8,^f@ MPR;:NM="VW3XP'O$+6F5?%YTCRTCV93';0C(E!HLF=L;5Z?9A-?M@LBUQA&amp;@4" MEMB%/W?GOO=":2L9P2YQ.YNF[[][?O">?&gt;<]^]yyys;k>U$M``@(&quot;)$$C29DP, MW(72X!$]Y'0X5O%CW^70SR\WG]0SS1&gt;_$$XR\'WL0)SQ9PT5<8/i4</gs&!# MU#!8'C58.9\&*\="&amp;^])*H2(&lt;BI\BQ-AC:ZX.+#/V=+$M=8%LH]3%VP+:(P'-" M0=",Q#AN#[D`A;?1T!/(PY]UB(!.9TFP!S5`]-_;1^`FC11,X=:2+.UAUG!O," MCQKXZN$8V\L[SO,;,;4Y!FN_A*CA<*PO?";&K@^?<L#XB2:IB[3Y^?.:MMKA MRVPH^Q([,3`48T^"+6H0]9_T<V-UAR_WQ7"RHYM("&="R8(;X;_05E4)H1K*&quot;" M_Z?/K)O\?$8X<"="T:?6W!WYG_-=#=W#XB8$FVH_.?">S#H;&gt;YT&gt;D9^JTAG!I* M)F3\Q)TKH:NA*W0VPSU@/-1`#HVPYZSO!;\S]M:0]3&gt;XVT<lu=,3`u-gl/6\ M1J@-F8YSLMR+]1,#R@<HP]`AJ*R/CW/<V="57?+H2/7_;&lt;E8\2(4-TZE0CE!1" M/S?<!A'^]$RDAB712`UO&(S4I%5A26<8C="1D?`&quot;#=AQR&quot;)BBG1=U$'1[RMJ]" M^^Z1="K3L&lt;?N$_:*W4W3N$T376P&amp;WZ/()V]SMHM?G?=,OO.+V='B#OK*LC))7" MO0'!*;H$YU[1Y>QX5Q`#'H_;TSD_\PZ/\XV]+L'O%7Q^I^B?GRG5'/UKM#S= M#O]G:MRJR9@&quot;%AQ;M]?F<bq`#c3gr):?!1[s0o0$>^`7N`7C,&quot;/;&gt;QWZ&quot;5:G M=N=TD`_-*_)EL#23A0QT&amp;SDK@$F'!L@I;$C*T4&amp;VI/B33!RUO)&quot;1Y.X2*]=E MH;1$G1XX++-R.4/2R.VY*&gt;UY<g^e_7&ys$n*##j^1oks-^h:fukjzamk51[= MSBW;="S16E)&lt;#:%-:'A&amp;EH_34,72+@6.68JD#EWXY;LDBI;KZHQ8!M?-)Q=;A" MX]_C$MKW>GW4&gt;/G:19?+4P8;+)OAJ&quot;4'RF$);'/Y?,Y.E[#%^P[\MKVNOC+[ MQ?JKKMW9KV7#0TG*V5V6C/&gt;&gt;@XB9Q]!.7\:&quot;E*/P]*)&quot;A)@F4P&amp;NU-I<%I%" M@#8"&%JB_5ME7BM\:N.A`,R5V+]9D$>EG![F^H8GL#Q-9O2S_2&EOT:5WVVB M\CNK9N7787J=^:%BV8+]@Y"P`QOP78J]+LBR'>I\&S"?[<NKO"S<!/[NR[1H MB:Z`(+"8HRUE*!8$Z@%X^)6E7F!QTS/JW6>SO!+,K".9AZC"D7EIA)`I:S<Y M-U4<MT]I)\E4,:;N23)-%DXC9'+*1B;/C9"XU8XY(7$[P?I_2E0^=),P%,?1 MJ6&B>7<<C\;?3W82Y^XN'Q;U_BMV0/I+I9?D!R1)R>B/5N$K'`Y3#9$?:N[D MC/YHU?U<MO>)=G\J(D0;5"MTRA9J@TI%8DL3[4F\'^9@@/N)>WM3\2RBF**; M-Q-X+J*T$'K`1!8ZM]*#.[><T",1D@R#=7@(DL"1R4OH.YE"ZGYSUW0<*R@: MVGT:R[LP%6#(]#0=81=:RT)8H0(\.D50K`*.GBV#"O!L/04K58"NO@16J0"O M%48L*D!+S^2S*M#1<&"U"M*I3U^C`KQGE,%:%2P!C,S6J2!+CE\9!>0`5()) M;5D*8`:+"G(!GH>-*G@,8!,&+@K(HUXO,0#&%55@5UN64SM1K0*,9;;`"RHH MH?>21)]5`#6P56E1:`[XS]$U6R(4N&8S)O\'3'W3ZYZYLM_:9(J8]64@WPX) MZ;?.ZE<>?&6F=4HT]K4<,^K4FU\F4*5`?9(HYF74*JO0O:=6.5HL4"7.)1Z" M)D:5SZL<Y)M28'JPH-P!L_#?4(=7W+=.DX\JVD(U$Q5R!Y;S&=SNE?3C2A2. M2LIAHBQFRF.A3/CY%8HCP7&,+P7<?OX6A#FSA@`J'UER8=XYLP\P_/P#4$L! M`A0`%`````@`V7Q3(SQ9*!7[````G`$```L````````````@`````````$Y/ M5$A)3D<N1E)-4$L!`A0`%`````@`Y'Q3(ZOO[49:````<@````L````````` M`0`@````)`$``$Y/5$A)3D<N34%+4$L!`A0`%`````@`XGQ3([K:N3GU!0`` M#A8```L````````````@````IP$``$Y/5$A)3D<N15A%4$L!`A0`%`````@` M]'Q3(V`::-;Q!0```!8```P````````````@````Q0<``$Y/5$A)3D=0+D58 715!+!08`````!``$`.4```#@#0````!4 ` end sum -r/size 34951/5270 section (from "begin" to "end") sum -r/size 17724/3803 entire input file
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

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 []

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

redBack to Project 8
redhomepage redlinks redanonymity +ORC redstudents' essays redacademy database
redtools redcocktails redantismut CGI-scripts redsearch_forms redmail_fravia
redIs reverse engineering legal?