An Explanation of how Make_Mak for Visual Basic Works
(A Visual Basic tough protection?)
by flipper
(20 October 1997)
Courtesy of fravia'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
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 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) [box01@ids.on.ca]
(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 - 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.
<![CDATA[section 1 of 1 of file nothing.zip <UUENCODE 5.32 by R.E.M.>
begin 644 nothing.zip
M4$L#!!0````(`-E\4R,\62@5^P```)P!```+````3D]42$E.1RY&4DVMC\U*
MPT`4A;]I)FUJ">K.ZB98R4I$%QK=204WXB)0040($D,;TA]H6O`Q^D@^@*_A
MLN`#*..=-B#=>^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-/"DY<]fgb82j!q%#x; MG.+T>87"(W6[DWP!O23@0*HWR,M`SFR0!>EP4N;C?E"FTRP;G_#)-4MV:$G=
M9V7YTL^"[N2-4*$C";G:&*_M>'Y^`5!+`P04````"`#D?%,CJ^_M1EH```!R
M````"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>KI#,DIQ46R6H
M@4`!UXI4O\1<A)">:X0K4!@`4$L#!!0````(`.)\4R.ZVKDY]04```X6```+
M````3D]42$E.1RY%6$7M6&],4U<4/^]/:46@e3$4ao`zl?lc,`2$3hl5ap4r M0,;0.<9F&'381%KWVC>V#XQ'_(*KLB]+7-R<6<;'q6q+/ra9l.ab9qq.mp]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"-'1XE@S9Z6Y44S$6/K"0@4URI8NBO$D8_&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]"Y!G%HJ)F0L>,3EX)7@I?H:`:ZP?9>-7EOD#_C>+?C!UM/.2FX)MP\9"^;
M'N^;.H6M9PU21;#XJ*#I/5\UWJ=/0.^&=D%U?7I4$$ZON^0W99O%F_;3\@&J
M;(`.A7($,X\)`TT0$;^>B93S9"A2+EI#D?*XS5@R64<BY?$?0lb)7?8#e[gs MO`DZ/-Z\%E_[7;*.ACT>O[1/]K7)S>V2['Y3\<ANOU3C:9%]?m\;`>DEC[?5
MU^'/2XS/?MFG2,VR6VK>*[N;6]^19,7K]7C;%F;>X6U^?:];"O@D?Z!9#BS,
M-/\Z>DC_$=5N,\1/`0^N;?45R0(/8($ZBW;S\R!BGH&>8`_\"C=@#&:T^]Z$
M?H(W,7'!!&E0MSI-`RL2>(A'MV%9#=PRJ`9+1O6L'A,DJ;H_2<!>\S,X51-7
M>:TN$;7%ZLP@8)G7RO&J06M/GM>>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>[G#1*FR?)C/F.7F8
M)V]@^DDNU1]QS.FOQ/0J5V)/752^@\V(@R+\S4&I<ui4zv+ck<9\3e9do#q< M!_$.UFFI$ET!2>(QQ_N3HUB2J`<0x7>>>H&E34^RM\\6;26XV)(L2-3@R((T
M2,B4HXN<f<j*.j>,DV0J"U/7))DFBZ=!,CE52B;/#)*HPXDY(5$GP?I_2U0_
M=)$P9$4!C)AHWA7%HW'GR4FBPNWUPY+>?_T>4/_1Z%7M"ZJJ9_1#J_`G'`Y3
M"]&^]"&M9?1#J^[ELKU/C/OF(T*,':S"I&^AL4.OB&UIK'T6[X-;,,"]Q#T]
M\_$<hibbz]=c^%9$:3%tgxdl=f[5^w=n!:e;)60v##;a(9@%k@111=_)?5,9 MJ\MSU>@T"Y,Z1@RM=$>=N%MF0&K&<"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<">[7H<H MKT.\*/+F["L%S,6T3H_&OM5B1A-[^24`-0JT)Y5B44.-F@G="?6K4HL5TIC%&" MZ>P]6U+$,?TBXR#?Y0#7C07]#9B(_X:Z?'+[>D,:FF@#M4PTR!U83N-PN]?0
MR67K'!LH1S%E*:$\=LJ$TR_4'0GV8WM!\03$&Q`62@P$T/C(\G,+CIF_C^&G
M/A=C2WLK'>U?4$L#!!0````(`/1\4R-@&FC6\04````6```,````3D]42$E.
M1U`N15A%[5AO3%-7%#_O3VE!H,B8#H;P.K'[(R**M)VV5!P6R!"80^<8,^f@ MPR;:NM="VW3XP'O$+6F5?%YTCRTCV93';0C(E!HLF=L;5Z?9A-?M@LBUQA&@4" MEMB%/W?GOO=":2L9P2YQ.YNF[[][?O">?><]^]yyys;k>U$M``@(")$$C29DP,
MW(72X!$]Y'0X5O%CW^70SR\WG]0SS1>_$$XR\'WL0)SQ9PT5<8/i4</gs&!# MU#!8'C58.9\&*\="&^])*H2(<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*"" M_Z?/K)O\?$8X<"="T:?6W!WYG_-=#=W#XB8$FVH_.?">S#H;>YT>D9^JTAG!I*
M)F3\Q)TKH:NA*W0VPSU@/-1`#HVPYZSO!;\S]M:0]3>XVT<LU=,3`u-gl/6\ M1J@-F8YSLMR+]1,#R@<HP]`AJ*R/CW/<V="57?+H2/7_;<E8\2(4-TZE0CE!1" M/S?<!A'^]$RDAB712`UO&(S4I%5A26<8C="1D?`"#=AQR")BBG1=U$'1[RMJ]" M^^Z1="K3L<?N$_:*W4W3N$T376P&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@"%AQ;M]?F<BQ`#c3gr):?!1[s0o0$>^`7N`7C,"/;>QWZ"5:G
M=N=TD`_-*_)EL#23A0QT&SDK@$F'!L@I;$C*T4&VI/B33!RUO)"1Y.X2*]=E
MH;1$G1XX++-R.4/2R.VY*>UY<G^e_7&ys$n*##j^1oks-^h:fukjzamk51[= MSBW;="S16E)<#:%-:'A&EH_34,72+@6.68JD#EWXY;LDBI;KZHQ8!M?-)Q=;A" MX]_C$MKW>GW4>/G:19?+4P8;+)OAJ"4'RF$);'/Y?,Y.E[#%^P[\MKVNOC+[
MQ?JKKMW9KV7#0TG*V5V6C/>>@XB9Q]!.7\:"E*/P]*)"A)@F4P&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 Fravia+, 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 [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 Project 8
homepage
links
anonymity
+ORC
students' essays
academy database
tools
cocktails
antismut CGI-scripts
search_forms
mail_fravia
Is reverse engineering legal?