VB6 + Assembler? 1

[CassandraR]

Hi:

I am pondering how to add inline assembler code into a Visual Basic 6.0 SP5 program. The desire is to add some assembler code within a few or several subroutines.

Any suggestions?

Cassie

 

[chiph]

VB6 does not do inline assembler.

You would have to write a Win32-style DLL using C or C++ (which has the __asm keyword), and then call it from your VB program.

The books all say you can prefix your exported function in your C code with declspec(__dllimport), but I haven't had much luck with that -- I've always had to use the old-school module definition file (.def) where you declare the exported functions.

Chip H.

 

[CassandraR]

Thanks for your advice; it is much appreciated.

However, I am trying to use Microsoft Assembler (MASM) for the assembly code. Also, I would prefer to avoid the DLL route and use assembler code embedded into the VB code.

Cassie

 

[strongm]

This may be of interest:

http://www.tweakvb.com

 

[CassandraR]

Thanks Strongm. I had found that one and was looking for other possibilities. I might go with TweakVB if other solutions don't appear.

Cassie

 

[strongm]

I suppose the real question has to be why do you want to do it? Is inline assembler the only solution you can see to a problem, or are you just experimenting?

 

[CassandraR]

Hi StrongM:

The reasons for my search for inline assembler coding in VB6SP5 are (1) experimentation and (2) adding custom security features to our programs.

With the security features, we need to work at the machine code level to ensure tight, embedded hack-reduction. By embedding the assembler code directly in our program, we hope to partially hide the code in the VB code.

Cassie

 

[MichaelRed]

you should read the 'parable' of the locks. This makes your code "look like" it is WAY to valuable to ever even executre, much less place it anywhere a 'hacker' coulld try yo violate the security.







MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[CassandraR]

Hi MichaelRed:

Thanks for your comments. Not sure where I would find a copy of the parable of the locks.

The use of the security features is not meant to prevent a hacker from breaking the security. This is impossible to achieve. The use of the security features is meant to make it unprofitable for the hacker to spend the time to attack the program.

Cassie

 

[TheVampire]

I've seen references to calling assembly code from VB, and it didn't mention having to use a DLL to do it. Here's one of the references.

http://www.fawcette.com/archives/premier/mgznarch/vbpj/2000/02feb00/mc0200/mc0200.asp

HTH,

Robert

 

[CassandraR]

Hi Robert:

Many thanks! Some heavy reading and studying on this one, but it should give me the knowledge to proceed.

I shall combine it with the material from the MSDN web site (

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaskdr/html/askgui12172002.asp)

and attempt to do what is needed.

I would prefer to avoid using API calls, but if it is necessary, then so be it.

A star for you.

Cassie

 

[CassandraR]

Hi Robert:

I did some rummaging around the Visual Studio Magazine's web site that you pointed me to, the information that I needed was located. One page,

http://www.fawcette.com/Archives/premier/mgznarch/vbpj/1999/11nov99/jc1199/jc1199.asp,

contains the information needed to do inline assembler programming.

Many, many thanks to you Robert!

Cassie

 

[TheVampire]

Glad to help. As you can see, it's not for the faint hearted.

If it's possible, can you post back here on any neat things that you learn in the process of using this method? It may help someone else in the long run.

Robert

 

[CassandraR]

Hi Robert:

You are quite right -- it is not for the faint-hearted! Playing around with VB's compiler and linker sends shivers down the spine.

As for posting back here, I may do that -- depends on what I learn and whether it is worthy of posting. I may even post some more FAQs.

What I have learned so far is that
(1) one can catch VB's calling of the C2 C compiler (C2.EXE).
(2) change the compiler options.
(3) edit the assembler list files generated.
(4) re-assemble the edited assembler list files with MASM 6.11 or later.
(5) link the project using VB's linker (LINK.EXE).
(6) change the linker's options.

This affords incorporating not only inline assembler code, but also complete OBJ modules that were created by other means (assembler, C, C++, possibly Pascal, et cetera.)

It looks very promising. I'll post if and when there is something for me to post.

Cassie

 

[MichaelRed]

the 'parable of the locks' loosely translates to:


"only a fool would spend more on the lock than the contents of what is being locked"


"Spend" being a relative term, including the total cost. There are NUMEROUS canned soloutions which are quite reasonable.

This is certainly not my area of expertise, but having 'grown up' on assembler, and coded directly in binary for at least a few years, I still would not take on the task of 'dissassembling' a commercial program even with the tools currently available unless there was a HUGE benefit/fortune as the payoff. Even then, I would probably only do it as an 'ex-pat' living in a place where there was no extradition.

So, back to the 'parable'. If it is compiled, then the resultant code is already in 'machine' language - an hopefully optinmized, so having inserted 'in-line' assembler code will not make it more daunting to the 'hacker'. If fact, since the 'in-line' section will be treated differently, it will probably NOT include the full optimization, and thus actually be somewhat easier to disassemble than POVB (Plain Old Visual Basic.

As a FINAL sugg3estion (from me), IF you are intent on the path, you shoud get a real "hacker" (Security Expert) and discuss the process with you. In the RIGHT situation, you could hire one to 'demonstrate' some of the more common tools and techniques currently in use. At least, have some 'professional' review of the final product's "security" from their prospective.




MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[CassandraR]

Hi Michael:

Obviously you and I have different opinions on how to secure a product. I shall endeavor to add the security that I feel is necessary and sufficient.

As for canned products, most, if not all, have been compromised. The hackers love breaking the canned security methods. May I suggest reading Crackproof Your Software by Pavol Cerven? He discusses many canned security products and invariably mentions that each has been broken.

There was a lengthy discussion of one class of anti-piracy protection in thread thread222-538092.

As for the "lock", relying on the fact that VB6 compiles to machine code is a fool's way of securing a program. Hackers have methods and software tools (e.g. SoftICE) that allow them to quickly pick out the parts of the code that stop the piracy and allow them to patch that code. Hence, they take pride in building protection-breaking software for each program.

Using inline assembler code permits the software developer to add embedded, custom anti-hacking code to thwart the hacker. If that code varies from product version to product version then the developer can force the hacker to either give up on the product or spend considerable amount of time producing a protection-breaking program that must be custom tailored to each version of the program. What hacker will waste the time to break a program when the next version of the program has a modified protection, especially when the software is sufficiently low-priced as not to warrant the hacker's time?

You are right on the need for the huge payoff to the hacker. However, that is only part of the problem. By using custom in-house protection, will the developer convince the hacker that the hacker's time would be better spent on someone else's program?

One last thing, VB is poorly optimized. For example,

lngLongNumber = lngLongNumber / 2

take 75 machine cycles. The equivalent in inline assembler code takes two machine cycles. VB optimized? Don't believe so!

Cassie
The Adventuress

P.S.: Since the mid-1970s I have done assembler coding on a wide range of processors, all the way from the 6800 to Control Data's Cyber 170 series of scientific mainframes. Assembler is no stranger to me.