[KongchangAI]
· 2 min read· 1,299 words

VBA Machine-Locked License Verification System: A Complete Voice-Driven Programming Guide

VBA Machine-Locked License Verification System: A Complete Voice-Driven Programming Guide

Build a complete VBA machine-locked license verification system using voice-driven AI programming.

This guide walks through building a VBA machine-locked license verification system entirely via voice commands using VBYDS. It covers three-tier architecture separation, custom Base64 encryption, hardware-based machine code generation, network time verification, test-driven development, and code obfuscation for secure deployment — demonstrating how AI-assisted development pairs with solid engineering fundamentals.

Overview

A machine-locked license verification system is a common approach to software protection, but for VBA developers, building one from scratch has always posed a significant technical challenge. This article documents the complete process of a seasoned VBA developer using VBYDS (VBA Voice-Driven Programming Assistant) to build an entire machine-locked license verification system entirely through voice commands — covering architecture design, multi-task collaboration, encryption algorithm selection, testing and debugging, and final deployment.

Not a single line of code was written by hand throughout the process, yet the engineering mindset and security awareness behind it are well worth studying for every VBA developer.

bilibili source: vba一机一码VIP验证激活通用模块 全程靠嘴编程不写一行代码

bilibili source: vba一机一码VIP验证激活通用模块 全程靠嘴编程不写一行代码

System Architecture Design: Three-Tier Separation for Security

Core Component Planning

The entire machine-locked license system is divided into three core components:

  • Client-side: Contains the user activation form (FRM) and the registration/activation module, deployed on the customer's machine
  • License Generator: Contains the activation code generator form and the code-issuing module, kept only on the developer's machine
  • Functional Test Module: Used during development to verify permission control logic; not distributed with the final product

The core principle behind this separation is: code on the client machine and the developer's machine must be strictly isolated. The license generation logic must never appear on the client side — otherwise, users could generate their own activation codes, rendering the entire protection mechanism useless.

Activation Code Data Structure

For encoding information in the activation code, the developer deliberately avoided JSON format (which is cumbersome to parse in VBA) and instead adopted a compact comma-delimited format:

machine_code,permission_level,expiration_date,checksum

VBA's Split function can quickly extract each field. This design keeps activation codes shorter and easier to transmit, while drastically reducing parsing complexity on the VBA side.

Encryption Algorithm Selection: A Pragmatic Security Strategy for VBA

Base64 + Custom Character Mapping Table

The developer demonstrated a highly pragmatic approach to security when choosing the encryption algorithm. He selected Base64 as the foundational encoding scheme while requiring a shuffled and redefined Base64 character mapping table, making it impossible for standard Base64 decoding tools to directly recover the content.

The logic behind this choice is clear: VBA code is inherently viewable, and no matter how complex the encryption algorithm, the source code can always be reverse-engineered. Pursuing encryption strength at the VBA level is therefore unrealistic. The key is to achieve the following:

  1. Each developer uses a different character table — preventing developers using the same template from cracking each other's codes
  2. Combined with code obfuscation — increasing the difficulty and cost of reverse engineering
  3. Sufficient against ordinary users — true security relies on continuous product value, not purely on technical barriers

Machine Code Generation Strategy

The machine code is generated by taking hardware information (such as the hard drive serial number), hashing it with MD5, truncating to 16 characters, and adding a product prefix (e.g., VBA-). Characters are grouped in sets of four separated by hyphens, resulting in a professional-looking format like VBA-A1B2-C3D4-E5F6-G7H8.

The developer specifically noted: collecting too much hardware information can cause lag on some machines. Typically, a single hard drive serial number is sufficient to ensure uniqueness.

Network Time Verification to Prevent Tampering

To prevent users from bypassing expiration limits by modifying the local system clock, the system integrates a network time verification module. When the network is unavailable, it falls back to local time verification but logs the anomaly for subsequent evaluation.

Multi-Task Collaboration and AI Model Selection Tips

Key Principles for Parallel Collaboration

During development, the author ran two AI conversation tasks simultaneously: one using Kimi for form design (leveraging its multimodal capabilities) and another using DeepSeekAd Flash for writing algorithm modules.

This multi-task collaboration follows one critical principle: never let two tasks write code at the same time. Form design doesn't involve code writing, so it can proceed in parallel with code development. However, if both sides are writing code modules simultaneously, file conflicts will occur.

Using Different AI Models at Different Stages

  • Solution design phase: Use the free DeepSeek web version or Kimi for brainstorming
  • Core code writing: Switch to DeepSeek Pro (paid version) to ensure accuracy for complex logic
  • Form UI fine-tuning: Use Kimi's multimodal capabilities — you can even take screenshots of existing software UI as design references
  • Module integration: Use models like MiniMax for merging tasks

The author's rule of thumb: Use Flash for single modules; use Pro for two or more modules. Pro generates higher-quality core code, resulting in lower debugging costs downstream — which actually saves more time overall.

Test-Driven Development: Keeping the System Verifiable at All Times

Planning Test Capabilities from Day One

This is the most valuable lesson from the entire development process. The author repeatedly emphasized:

"You must keep everything in a state that's easy to test at any time. This is critically important. Whether something ultimately works out — especially whether it can grow more complex without going off track — depends on planning your testing capabilities from the very beginning."

This manifests in several specific ways:

  1. Clear registration data function: Reset to a "clean" initial state before each test
  2. Functional test form: Simulate feature availability under different permission levels (Free/VIP)
  3. Simulated expiration function: Verify that time-limit logic triggers correctly
  4. AI-automated testing: Let the AI run through the complete loop of registration → activation → verification → expiration on its own

The Engineering Value of AI Self-Correction

During testing, the Base64 module produced incorrect encoding/decoding results on its first attempt, but VBYDS's automatic debugging mechanism allowed the AI to read the error information and correct itself. This "write wrong → detect → fix" loop is the core value of Agent engineering.

The author offered an incisive summary:

"Nobody writes code perfectly in one shot, and that includes AI. The reason AI can produce correct code today is because Agent engineering gives AI the ability to self-iterate — it doesn't get it right the first time, but it can correct itself until it's right."

Deployment Security Configuration and Code Obfuscation

Configuration Items Every Developer Must Modify

After obtaining the template, every developer must modify the following items before it can be used securely:

  1. Product prefix: Differentiates machine codes across products and prevents activation code conflicts between them
  2. Base64 character table order: Prevents other developers using the same template from cracking each other's codes
  3. Registry storage path: Avoids using default paths that users can easily locate and delete

Important note: The Base64 character tables in both the license generator and the client-side registration/activation module must be kept perfectly identical; otherwise, activation codes cannot be parsed correctly.

Technical Details of Code Obfuscation

The registration/activation module distributed to end users needs to undergo code obfuscation to increase the difficulty of cracking. However, there's an easily overlooked technical detail: VBA's Const constants cannot be properly processed by obfuscation tools. Therefore, all constants need to be rewritten as Private Function forms, with assignment and return handled inside the function body — only then can the obfuscation tool process them effectively.

Final Thoughts

This VBA machine-locked license verification system development case demonstrates more than just the efficiency gains of AI-assisted programming — it showcases an engineering-oriented development mindset. From the three-tier separation architecture to pragmatic encryption security considerations, from test-driven development planning to deployment security details, every step reflects years of accumulated development experience.

As the author cited: in the age of AI, fundamentals matter more than ever. AI has lowered the barrier to coding, but architecture design, security awareness, and testing mindset — these "core skills" — still require developers to cultivate on their own. Those who use AI most effectively are often the ones with the strongest fundamentals.

#VBA license verification#machine-locked activation system#VBA code protection#Base64 custom encryption#VBA machine code generation#voice-driven programming#VBYDS#VBA code obfuscation#test-driven VBA development#AI-assisted VBA programming
Share:

Related articles