Bàn về bảo mật dự án VB6, VB.NET, Delphi... (1 người xem)

Liên hệ QC

Người dùng đang xem chủ đề này

PhanTuHuong

VBA & VB.NET for Excel & AutoCad
Thành viên danh dự
Tham gia
13/6/06
Bài viết
7,235
Được thích
24,741
Dạo này nhiều cao thủ chuyển đổi mã VBA sang môi trường lập trình hiện đại hơn. Viết chơi chơi thì không sao, nhưng tạo sản phẩm kinh doanh thì là cả vấn đề. Chả phần mềm nào là không bị crack, bản thân nhiều phần mềm chuyên dụng bảo mật còn bị hack. Biết vậy nhưng nhà có nhiều khóa còn hơn chỉ 1, 2 khóa. Các công cụ pack đã lạc hậu, giờ là mã hóa, ảo hóa, làm rối.... Kẻ trộm phải bẻ nhiều khóa quá cũng chán :)
Mời các chuyên gia vào chém cho vuiIMG_20250921_231102~2.jpg
 
Lần chỉnh sửa cuối:
Viết trên Delphi hay c++ mà không pack cũng bị crack như thường (mình không có khả năng) nếu pack thì bị phần mềm diệt virus lụm ! Nói chung chấp nhận !
 
Viết trên Delphi hay VB6 pack = thừa

nếu Delphi chọn Release và trong Project tìm mấy Tùy chọn Off nó đi là xong

còn Crack mấy năm trước Tôi có hỏi tay code nga nó keo không quá khó ... còn ai đó keo dịch ngược Mã Delphi hay VB6 ra mã thật hãy sờ trán nó xem

có nóng lắm không ... vài hàm tào lao có thể còn code viết kiểu Module liên kết hàm thì chờ xem --=0--=0--=0
 
Lần chỉnh sửa cuối:
Dạo này nhiều cao thủ chuyển đổi mã VBA sang môi trường lập trình hiện đại hơn. Viết chơi chơi thì không sao, nhưng tạo sản phẩm kinh doanh thì là cả vấn đề. Chả phần mềm nào là không bị crack, bản thân nhiều phần mềm chuyên dụng bảo mật còn bị hack. Biết vậy nhưng nhà có nhiều khóa còn hơn chỉ 1, 2 khóa. Các công cụ pack đã lạc hậu, giờ là mã hóa, ảo hóa, làm rối.... Kẻ trộm phải bẻ nhiều khóa quá cũng chán :)
Mời các chuyên gia vào chém cho vuiView attachment 309744
Bài này nói đến crack (bẻ khóa) cứ tưởng là bẻ khóa bản quyền phần mềm, thì ra là chống dịch ngược, làm rối mã nguồn.
 
Dạo này nhiều cao thủ chuyển đổi mã VBA sang môi trường lập trình hiện đại hơn. Viết chơi chơi thì không sao, nhưng tạo sản phẩm kinh doanh thì là cả vấn đề. Chả phần mềm nào là không bị crack, bản thân nhiều phần mềm chuyên dụng bảo mật còn bị hack. Biết vậy nhưng nhà có nhiều khóa còn hơn chỉ 1, 2 khóa. Các công cụ pack đã lạc hậu, giờ là mã hóa, ảo hóa, làm rối.... Kẻ trộm phải bẻ nhiều khóa quá cũng chán :)
Mời các chuyên gia vào chém cho vuiView attachment 309744
Có file demo cho anh em thử thì khả quan hơn. C# ,vbnet thôi nhé anh
 
Có file demo cho anh em thử thì khả quan hơn. C# ,vbnet thôi nhé anh
Bạn thử Pack C# hay VBnet xong úp lên đây xem ... Tôi nghĩ có người làm ok đấy ... còn tôi chịu thua

Nghe nói VBNet đang có chiều hướng chung số phận như VB6 rồi ... rảnh mò cái mới đi có vẽ ok
 
Có file demo cho anh em thử thì khả quan hơn. C# ,vbnet thôi nhé anh
Khi nào tôi up lên để mọi người test khả năng bẻ khóa nhé.
Bài đã được tự động gộp:

Bài này nói đến crack (bẻ khóa) cứ tưởng là bẻ khóa bản quyền phần mềm, thì ra là chống dịch ngược, làm rối mã nguồn.
Bẻ được khóa thì phải vượt qua các bước đó còn gì, có gì không đúng vậy?
Bài đã được tự động gộp:

Viết trên Delphi hay VB6 pack = thừa

nếu Delphi chọn Release và trong Project tìm mấy Tùy chọn Off nó đi là xong

còn Crack mấy năm trước Tôi có hỏi tay code nga nó keo không quá khó ... còn ai đó keo dịch ngược Mã Delphi hay VB6 ra mã thật hãy sờ trán nó xem

có nóng lắm không ... vài hàm tào lao có thể còn code viết kiểu Module liên kết hàm thì chờ xem --=0--=0--=0

Pack là công cụ ngày trước rồi, giờ hầu như không có ai phát triển loại công cụ kiểu này như UPX, Aspack, Pecompact...
 
Khi nào tôi up lên để mọi người test khả năng bẻ khóa nhé.
Bài đã được tự động gộp:


Bẻ được khóa thì phải vượt qua các bước đó còn gì, có gì không đúng vậy?
Bài đã được tự động gộp:



Pack là công cụ ngày trước rồi, giờ hầu như không có ai phát triển loại công cụ kiểu này như UPX, Aspack, Pecompact...
Nói đến crack là nói đến cách thức bẻ khóa bản quyền phần mềm (vd: keygen chẳng hạn), còn trong bài viết này là chống dịch ngược mã nguồn (hay anti-reverse engineering), chẳng qua là đổi tên biến loạn xạ khiến cho việc đọc mã nguồn trở nên khó khăn hơn, tất nhiên là nó không đúng rồi.
Mấy cái trò này trong .NET chỉ có tác dụng an ủi tinh thần lập trình viên thôi, mã nguồn vốn dĩ lồ lộ như thế sớm muộn cũng bị dễ dàng dịch ngược.
 
Cái này bác phải nói đến tại sao cần "chống" và "không chống", chống ai:
1. "Chống"
Vì mã nguồn liên quan đến bảo mật cấp độ cao, như viết cho Chính phủ, Ngân hàng, doanh nghiệp lớn, cần bảo vệ gắt gao.
Muốn tạo mã virus gieo rắc nỗi kinh hoàng cho thế giới.
Nhiều nhiều.

2: Tại sao "không cần chống":
Ứng dụng chỉ có mong muốn nguồn thu chân chính, không thu từ những ai không muốn chi trả. Phân bố cho nhiều người dùng để dành thị phần, nhiều người biết đến ứng dụng. Nhiều nhiều.

Theo tôi biết nếu cracker muốn bẻ phần mềm nào đó họ cần debbug từng dòng. Nếu bảo mật cao, thì tạo ra các lớp ảo, hàm ảo khéo léo lòng lộn nhau hàng chục hàng trăm lớp, với hàng trăm nghìn dòng như vậy. Mã hóa mã nguồn. Để chống người thường thì dùng cách thường, chống nhân tài, phải làm cho họ mất thời gian, mất kiên nhẫn, mệt mỏi.

Chống bypass, chống dịch ngược, chống phá khóa bản quyền/dùng thử, chống đánh cắp thuật toán, ... tất cả là một hệ thống "khủng khiếp" cho một người tầm thường muốn động đến.

Nói chung, phải biết mục tiêu ứng dụng đi đến đâu, đạt mục đích gì sẽ cần đến chống theo cách nào.

Cracker giỏi đa số chọn con đường chân chính, không ai trót dại đi học hỏi cho giỏi xong đi làm tội phạm. Trừ khi họ đang ở vị trí "bần cùng", "thù hận", "ác nhân", "bị điều khiển".
 
Bản thân tôi dùng dnSpy để mở NET nguyên bản, nó lộ toàn bộ code. Việc bẻ khóa trở nên dễ dàng với tình huống này. Tuy nhiên khi mã hóa thì việc dò, hiểu sẽ khó khăn hơn nhiều, file mở rộng phình to. Việc xác định điểm mấu chốt sẽ khó khi không còn những thông báo, chuỗi...như hình. Giờ diễn đàn nhiều bạn có khả năng lập trình tốt, thậm chí là chuyên nghiệp được học bài bản nên sẽ rõ vấn đề này. Tất nhiên ở đây nói về mức độ nghiệp dư, mở mang kiến thức, phù hợp với các tay ngang như tôi chẳng hạn :)dnSpy.png
 
Lần chỉnh sửa cuối:
Bác có bỏ công sức ra chống gắt gao làm gì cho mất thời gian, chống vừa đủ cho trộm không nhòm ngó nhiều thôi, nếu số bác đã bị trộm thì trộm luôn luôn kề cận bác. Nếu có bị trộm, theo luật "hoa quả" cái đó vẫn là của bác, thì mãi là của bác, có khi chưa chắc là của bác, mà bác lại lấy về rồi bảo mật, thì số bị trộm vẫn phải bị.

Nếu chống gắt quá, phải xây tường cao, rào chắn kĩ lưỡng, két sắt xịn xò, vệ sĩ cấp cao, gây ra chi phí khủng, chi trả bao nhiêu đó, rồi xui xui ứng dụng không ai thèm dùng cả. Trắng tay. Bán tất cả để trả nợ.

Theo tôi biết thì các nhân tài tiến sĩ lập trình trên thế giới đa số họ có tấm lòng rộng mở cho đi nhiều hơn, không xem tiền bạc là thứ quan trọng trong đời, họ xem con đường phát triển của thế giới là hướng đi, nên họ không quan trọng việc chặn crack, trừ khi ứng dụng của họ rất cấp thiết trong bảo mật.
 

Bác có bỏ công sức ra chống gắt gao làm gì cho mất thời gian, chống vừa đủ cho trộm không nhòm ngó nhiều thôi, nếu số bác đã bị trộm thì trộm luôn luôn kề cận bác. Nếu có bị trộm, theo luật "hoa quả" cái đó vẫn là của bác, thì mãi là của bác, có khi chưa chắc là của bác, mà bác lại lấy về rồi bảo mật, thì số bị trộm vẫn phải bị.

Nếu chống gắt quá, phải xây tường cao, rào chắn kĩ lưỡng, két sắt xịn xò, vệ sĩ cấp cao, gây ra chi phí khủng, chi trả bao nhiêu đó, rồi xui xui ứng dụng không ai thèm dùng cả. Trắng tay. Bán tất cả để trả nợ.

Theo tôi biết thì các nhân tài tiến sĩ lập trình trên thế giới đa số họ có tấm lòng rộng mở cho đi nhiều hơn, không xem tiền bạc là thứ quan trọng trong đời, họ xem con đường phát triển của thế giới là hướng đi, nên họ không quan trọng việc chặn crack, trừ khi ứng dụng của họ rất cấp thiết trong bảo mật.
Tôi tìm hiểu để biết thôi, khám phá lỗ hổng, phải nhờ công cụ chứ, sức đâu mà mò
Có dự án quan trọng bạn tâm huyết viết cả hàng nhiều năm rồi thì công việc bảo mật này cũng cần thiết chứ. Tôi không phải nhân tài, cũng không nhiều tiền nên vậy :)
Chả là tôi chuyển chương trình cũ từ VB6 sang VB.NET nên cũng phải nghiên cứu. Đừng ai xui C, C++ vì tôi nhìn ngứa mắt lắm dù việc chuyển đổi từ code gốc VB6 giờ rất dễ nhờ AI :)
 
Nếu bác có công sức nhiều năm nghiên cứu, người ta tìm đến mã nguồn của bác xem như bác có được truyền nhân về sau, còn hơn mã nguồn một ngày nào đó đi vào dĩ vãn không ai kế thừa. Mà nếu có nhòm được qua khe cửa cũng thấy được chút ít, bác nhiều năm vậy, phải được bác mở rộng cửa chưa chắc đã hiểu hết những gì trong đó. Nhòm qua khe cửa có khi lé con mắt, làm sao còn đủ khả năng nhòm này nhòm kia được.

Bác chớ sợ ai lấy của mình, sợ là ít ai tin tưởng những gì bác đã làm ra.

Nếu là em thì em chỉ cho lứa sau này làm ra nhiều thứ càng tốt, chứ không khuyên họ làm ra nhiều két sắt để cất giữ. Có khi không có nhiều vàng, kim cương đủ để vào đó.
Phần nào bị trộm thì còn phần khác bù đắp, nếu bỏ công dấu mà bị trộm siêu cấp lấy hết, cũng vẫn là xui.
 
Thôi thì chúng ta cứ trao đổi thêm cho đúng nội dung chủ đề. Ai quan tâm thì tiếp tục trao đổi, ai không quan tâm thì bỏ qua đi.
Thực ra là con AI nó hỗ trợ khá ổn nhưng cũng chỉ dẫn linh tinh nhiều nên cũng cần thêm thông tin nữa.
 
Sản phẩm từ AI đây:

Chống bẻ khóa (anti-cracking) cho phần mềm viết bằng VB.NET là một chủ đề khó, vì môi trường .NET vốn dễ bị dịch ngược (decompile). Tuy nhiên, có thể kết hợp nhiều lớp bảo vệ để nâng cao độ khó:




1. Bảo vệ mã nguồn (Code Protection)​


  • Obfuscation (làm rối mã):
    • Sử dụng các công cụ như .NET Reactor, ConfuserEx, Eazfuscator.NET, Themida, VMProtect để làm rối tên hàm, biến, control flow.
    • Chọn công cụ hỗ trợ Control Flow Obfuscation, String Encryption, Resource Encryption.
  • Virtualization / Mutation:
    • Một số công cụ (VMProtect, Themida, .NET Reactor) có thể chuyển một số hàm sang dạng bytecode riêng để tránh phân tích.
    • Dùng cho các hàm nhạy cảm (kiểm tra bản quyền, thuật toán bảo mật).



2. Bảo vệ file thực thi (Executable Protection)​


  • Packers/Protectors:
    • Bao bọc exe bằng Enigma Protector, Themida, VMProtect để chống debug, dump bộ nhớ.
    • Kết hợp cùng obfuscation trước khi pack để tránh bị unpack dễ dàng.
  • Anti-Debug / Anti-Dump:
    • Chặn debugger (OllyDbg, x64dbg, dnSpy debug).
    • Kiểm tra sự tồn tại của hook, patch, breakpoint.



3. Kiểm tra tính toàn vẹn (Integrity Check)​


  • Tự viết đoạn mã kiểm tra hash/CRC của chính file EXE. Nếu bị sửa đổi → thoát chương trình.
  • Kiểm tra các assembly phụ cũng vậy.
  • Có thể dùng multiple layers: một lớp trong code, một lớp trong protector.



4. Cơ chế bản quyền (License / Online Validation)​


  • Không nên chỉ lưu key trên client → dễ bị crack.
  • Nên dùng:
    • Server-side validation (mỗi lần chạy phải xác thực key).
    • Hardware binding (gắn key với HWID, MAC, CPU ID).
    • Time-limited license (license hết hạn phải gia hạn).



5. Phát hiện môi trường bất thường​


  • Chặn chạy trong máy ảo (VMWare, VirtualBox) nếu không cần.
  • Chặn chạy nếu phát hiện sandbox, profiler.
  • Thêm delay/anti-timing check để làm khó cracker.



6. Kết hợp nhiều lớp (Layered Security)​


Một quy trình hay dùng cho VB.NET:


  1. Obfuscate bằng .NET Reactor (bảo vệ tên, string, control flow).
  2. Bọc bằng VMProtect/Themida (ảo hóa hàm quan trọng + chống debug).
  3. Tích hợp kiểm tra hash nội bộ trong code.
  4. Áp dụng license online để chống patch keygen.



Lưu ý: Không có cách nào 100% chống bẻ khóa. Mục tiêu là tăng chi phí và thời gian để hacker nản lòng, thay vì “không thể bẻ”.




Bạn có muốn tôi soạn cho bạn cấu hình cụ thể (ví dụ kết hợp .NET Reactor + VMProtect) dành riêng cho phần mềm VB.NET, hay chỉ cần mức khái niệm thôi?
 
Những điều trên thiếu một cách nữa đó bác, là tận dụng dll, dll được làm rối, mã hóa DLL rồi LoadLibrary trong bộ nhớ khi chạy. Cracker chỉ có thể đọc được dll tại RAM khi giải mã. Cần chặn cracker đọc được khóa mã hóa. Nhưng LoadLibrary trong bộ nhớ là một kỹ thuật siêu phức tạp.

Tạo hàng trăm Dll ảo:

Kỹ thuậtMục tiêu
Tạo DLL giả có hàm thật nhưng không hoạt độngGây rối phân tích
Dùng tên DLL ngẫu nhiên hoặc mã hóaNgăn đoán tên
Load DLL từ memory, không ghi ra đĩaNgăn dump
Gắn kiểm tra integrity trong mỗi DLLNgăn sửa đổi
Chỉ gọi DLL thật khi điều kiện đúngNgăn brute-force
 
Tôi chỉ trình amateur nên càng đơn giản, có tools hỗ trợ thì càng tốt. Chứ kỹ thuật sâu quá thì như vịt nghe sấm thôi, nghe thằng ChatGPT phân tích là huyết áp cao luôn :)
 
E nghĩ nếu bảo mật có thể hàm gốc viết dll có thể dùng Go, delphi, rust, c++ cái nào nativate là múc. Còn .net lấy cái giao diện cho app còn lại chả mã hóa gì là lành nhất. Các cháu virut cũng ít dành giật
Bài đã được tự động gộp:

Bản thân tôi dùng dnSpy để mở NET nguyên bản, nó lộ toàn bộ code. Việc bẻ khóa trở nên dễ dàng với tình huống này. Tuy nhiên khi mã hóa thì việc dò, hiểu sẽ khó khăn hơn nhiều, file mở rộng phình to. Việc xác định điểm mấu chốt sẽ khó khi không còn những thông báo, chuỗi...như hình. Giờ diễn đàn nhiều bạn có khả năng lập trình tốt, thậm chí là chuyên nghiệp được học bài bản nên sẽ rõ vấn đề này. Tất nhiên ở đây nói về mức độ nghiệp dư, mở mang kiến thức, phù hợp với các tay ngang như tôi chẳng hạn :)View attachment 309745
ConfuserEx hình như là trình này phải ko anh?
Bài đã được tự động gộp:

Bản thân tôi dùng dnSpy để mở NET nguyên bản, nó lộ toàn bộ code. Việc bẻ khóa trở nên dễ dàng với tình huống này. Tuy nhiên khi mã hóa thì việc dò, hiểu sẽ khó khăn hơn nhiều, file mở rộng phình to. Việc xác định điểm mấu chốt sẽ khó khi không còn những thông báo, chuỗi...như hình. Giờ diễn đàn nhiều bạn có khả năng lập trình tốt, thậm chí là chuyên nghiệp được học bài bản nên sẽ rõ vấn đề này. Tất nhiên ở đây nói về mức độ nghiệp dư, mở mang kiến thức, phù hợp với các tay ngang như tôi chẳng hạn :)View attachment 309745
ConfuserEx hình như là trình này phải ko anh?
Bài đã được tự động gộp:

Sản phẩm từ AI đây:

Chống bẻ khóa (anti-cracking) cho phần mềm viết bằng VB.NET là một chủ đề khó, vì môi trường .NET vốn dễ bị dịch ngược (decompile). Tuy nhiên, có thể kết hợp nhiều lớp bảo vệ để nâng cao độ khó:




1. Bảo vệ mã nguồn (Code Protection)​


  • Obfuscation (làm rối mã):
    • Sử dụng các công cụ như .NET Reactor, ConfuserEx, Eazfuscator.NET, Themida, VMProtect để làm rối tên hàm, biến, control flow.
    • Chọn công cụ hỗ trợ Control Flow Obfuscation, String Encryption, Resource Encryption.
  • Virtualization / Mutation:
    • Một số công cụ (VMProtect, Themida, .NET Reactor) có thể chuyển một số hàm sang dạng bytecode riêng để tránh phân tích.
    • Dùng cho các hàm nhạy cảm (kiểm tra bản quyền, thuật toán bảo mật).



2. Bảo vệ file thực thi (Executable Protection)​


  • Packers/Protectors:
    • Bao bọc exe bằng Enigma Protector, Themida, VMProtect để chống debug, dump bộ nhớ.
    • Kết hợp cùng obfuscation trước khi pack để tránh bị unpack dễ dàng.
  • Anti-Debug / Anti-Dump:
    • Chặn debugger (OllyDbg, x64dbg, dnSpy debug).
    • Kiểm tra sự tồn tại của hook, patch, breakpoint.



3. Kiểm tra tính toàn vẹn (Integrity Check)​


  • Tự viết đoạn mã kiểm tra hash/CRC của chính file EXE. Nếu bị sửa đổi → thoát chương trình.
  • Kiểm tra các assembly phụ cũng vậy.
  • Có thể dùng multiple layers: một lớp trong code, một lớp trong protector.



4. Cơ chế bản quyền (License / Online Validation)​


  • Không nên chỉ lưu key trên client → dễ bị crack.
  • Nên dùng:
    • Server-side validation (mỗi lần chạy phải xác thực key).
    • Hardware binding (gắn key với HWID, MAC, CPU ID).
    • Time-limited license (license hết hạn phải gia hạn).



5. Phát hiện môi trường bất thường​


  • Chặn chạy trong máy ảo (VMWare, VirtualBox) nếu không cần.
  • Chặn chạy nếu phát hiện sandbox, profiler.
  • Thêm delay/anti-timing check để làm khó cracker.



6. Kết hợp nhiều lớp (Layered Security)​


Một quy trình hay dùng cho VB.NET:


  1. Obfuscate bằng .NET Reactor (bảo vệ tên, string, control flow).
  2. Bọc bằng VMProtect/Themida (ảo hóa hàm quan trọng + chống debug).
  3. Tích hợp kiểm tra hash nội bộ trong code.
  4. Áp dụng license online để chống patch keygen.



Lưu ý: Không có cách nào 100% chống bẻ khóa. Mục tiêu là tăng chi phí và thời gian để hacker nản lòng, thay vì “không thể bẻ”.




Bạn có muốn tôi soạn cho bạn cấu hình cụ thể (ví dụ kết hợp .NET Reactor + VMProtect) dành riêng cho phần mềm VB.NET, hay chỉ cần mức khái niệm thôi?
Pack nhiều lắm thì anh virut lại thịt sạch anh ạ, đổi code quan trọng còn lại .net làm frontend là đẹp bài, có tý python, 1 chút delphi 1 phần go hay c++ đọc hết bộ code đó họ cũng to đầu
Bài đã được tự động gộp:

Sản phẩm từ AI đây:

Chống bẻ khóa (anti-cracking) cho phần mềm viết bằng VB.NET là một chủ đề khó, vì môi trường .NET vốn dễ bị dịch ngược (decompile). Tuy nhiên, có thể kết hợp nhiều lớp bảo vệ để nâng cao độ khó:




1. Bảo vệ mã nguồn (Code Protection)​


  • Obfuscation (làm rối mã):
    • Sử dụng các công cụ như .NET Reactor, ConfuserEx, Eazfuscator.NET, Themida, VMProtect để làm rối tên hàm, biến, control flow.
    • Chọn công cụ hỗ trợ Control Flow Obfuscation, String Encryption, Resource Encryption.
  • Virtualization / Mutation:
    • Một số công cụ (VMProtect, Themida, .NET Reactor) có thể chuyển một số hàm sang dạng bytecode riêng để tránh phân tích.
    • Dùng cho các hàm nhạy cảm (kiểm tra bản quyền, thuật toán bảo mật).



2. Bảo vệ file thực thi (Executable Protection)​


  • Packers/Protectors:
    • Bao bọc exe bằng Enigma Protector, Themida, VMProtect để chống debug, dump bộ nhớ.
    • Kết hợp cùng obfuscation trước khi pack để tránh bị unpack dễ dàng.
  • Anti-Debug / Anti-Dump:
    • Chặn debugger (OllyDbg, x64dbg, dnSpy debug).
    • Kiểm tra sự tồn tại của hook, patch, breakpoint.



3. Kiểm tra tính toàn vẹn (Integrity Check)​


  • Tự viết đoạn mã kiểm tra hash/CRC của chính file EXE. Nếu bị sửa đổi → thoát chương trình.
  • Kiểm tra các assembly phụ cũng vậy.
  • Có thể dùng multiple layers: một lớp trong code, một lớp trong protector.



4. Cơ chế bản quyền (License / Online Validation)​


  • Không nên chỉ lưu key trên client → dễ bị crack.
  • Nên dùng:
    • Server-side validation (mỗi lần chạy phải xác thực key).
    • Hardware binding (gắn key với HWID, MAC, CPU ID).
    • Time-limited license (license hết hạn phải gia hạn).



5. Phát hiện môi trường bất thường​


  • Chặn chạy trong máy ảo (VMWare, VirtualBox) nếu không cần.
  • Chặn chạy nếu phát hiện sandbox, profiler.
  • Thêm delay/anti-timing check để làm khó cracker.



6. Kết hợp nhiều lớp (Layered Security)​


Một quy trình hay dùng cho VB.NET:


  1. Obfuscate bằng .NET Reactor (bảo vệ tên, string, control flow).
  2. Bọc bằng VMProtect/Themida (ảo hóa hàm quan trọng + chống debug).
  3. Tích hợp kiểm tra hash nội bộ trong code.
  4. Áp dụng license online để chống patch keygen.



Lưu ý: Không có cách nào 100% chống bẻ khóa. Mục tiêu là tăng chi phí và thời gian để hacker nản lòng, thay vì “không thể bẻ”.




Bạn có muốn tôi soạn cho bạn cấu hình cụ thể (ví dụ kết hợp .NET Reactor + VMProtect) dành riêng cho phần mềm VB.NET, hay chỉ cần mức khái niệm thôi?
Pack nhiều lắm thì anh virut lại thịt sạch anh ạ, đổi code quan trọng còn lại .net làm frontend là đẹp bài, có tý python, 1 chút delphi 1 phần go hay c++ đọc hết bộ code đó họ cũng to đầu
 
Lần chỉnh sửa cuối:
E nghĩ nếu bảo mật có thể hàm gốc viết dll có thể dùng Go, delphi, rust, c++ cái nào nativate là múc. Còn .net lấy cái giao diện cho app còn lại chả mã hóa gì là lành nhất. Các cháu virut cũng ít dành giật
Bài đã được tự động gộp:


ConfuserEx hình như là trình này phải ko anh?
Bài đã được tự động gộp:


ConfuserEx hình như là trình này phải ko anh?
Bài đã được tự động gộp:


Pack nhiều lắm thì anh virut lại thịt sạch anh ạ, đổi code quan trọng còn lại .net làm frontend là đẹp bài, có tý python, 1 chút delphi 1 phần go hay c++ đọc hết bộ code đó họ cũng to đầu
Bài đã được tự động gộp:


Pack nhiều lắm thì anh virut lại thịt sạch anh ạ, đổi code quan trọng còn lại .net làm frontend là đẹp bài, có tý python, 1 chút delphi 1 phần go hay c++ đọc hết bộ code đó họ cũng to đầu
Chương trình nào diệt vậy, tôi chưa test các máy tính khác. Hy vọng được bỏ qua :)
 


4. Cơ chế bản quyền (License / Online Validation)​


  • Không nên chỉ lưu key trên client → dễ bị crack.
  • Nên dùng:
    • Server-side validation (mỗi lần chạy phải xác thực key).
    • Hardware binding (gắn key với HWID, MAC, CPU ID).
    • Time-limited license (license hết hạn phải gia hạn).

e từng thấy có phần mềm viết bằng ASP.NET, phần chương trình exe cài trên máy chủ , có check CPU ID, nhà cung cấp cài lên server nào thì cố định chạy trên server đó thôi, ghost lại các kiểu cũng không chạy được !@@
tuy chạy trên web, nhưng phần mềm chạy mượt như viết bằng Winform
 
e từng thấy có phần mềm viết bằng ASP.NET, phần chương trình exe cài trên máy chủ , có check CPU ID, nhà cung cấp cài lên server nào thì cố định chạy trên server đó thôi, ghost lại các kiểu cũng không chạy được !@@
tuy chạy trên web, nhưng phần mềm chạy mượt như viết bằng Winform
ai biết viết máy chủ máy khách là có khả năng viết được

Nó đơn giản lắm hàm + mọi cái phía máy chủ còn máy khách Sent và get thôi
 
Động 1 tý là cụ BKAV đỏ lòm ngay, cảnh giác như diệt virus macro ngày trước! :)
Google và Kas có vẻ rất điềm tĩnh, chuẩn đoán tốt! Còn mấy phần mềm khác khá có thương hiệu cũng "nhạy cảm" y anh BKAV :)Virus.png
 
Tôi test đỏ lòm, nhưng chỉ quan tâm đến 1 số chương trình phổ biến. BKAV Pro, Microsoft luôn đỏ, Google thì có lúc loại được.
Cái xương là Microsoft đó anh chẳng lẽ cứ tắt win def.. như crack ứng dụng. Cái vấn đề nữa là khi pack nó đỏ lòm và không biết bị sao và lỗi chỗ code hệ thống nào.
 
Cái xương là Microsoft đó anh chẳng lẽ cứ tắt win def.. như crack ứng dụng. Cái vấn đề nữa là khi pack nó đỏ lòm và không biết bị sao và lỗi chỗ code hệ thống nào.

Ứng dụng của mình cũ viết trên VB6, pack đơn giản bằng VB6 mà một số máy tính (không nhiều) thằng Windows Defender nó chặn. Kể cũng lạ, chặn cả còn biết, đây lại dở ông dở thằng. Tôi đang đề nghị Microsoft xem lại nhưng gửi đi toàn báo lỗi phần up file :(
 
E thấy bảo mật ổn cách này vẫn là ok nhất.
Dùng Dll chính là hàm từ ngôn ngữ native là ok rồi dùng .net Call làm thơm nhất tận dụng cái UI của. Net
Viết NetCore thì nó sẽ thơm hơn chút không bị đỏ thế này.
1758635481983.png
Bài đã được tự động gộp:

Ứng dụng của mình cũ viết trên VB6, pack đơn giản bằng VB6 mà một số máy tính (không nhiều) thằng Windows Defender nó chặn. Kể cũng lạ, chặn cả còn biết, đây lại dở ông dở thằng. Tôi đang đề nghị Microsoft xem lại nhưng gửi đi toàn báo lỗi phần up file :(
Cái nó dỏ của việc anh Pack là cái thì nó đập cái không có thể do win cập nhật vá lỗi. lúc thì là lỗi ảo nên không biết đường nào mà lần.
 

File đính kèm

  • 1758635350022.png
    1758635350022.png
    115 KB · Đọc: 14
  • Debug.zip
    Debug.zip
    663.6 KB · Đọc: 0
  • Debug.zip
    Debug.zip
    663.6 KB · Đọc: 0
Dùng bản Dotfuscator miễn phí đổi tên này nọ thì chỉ còn 4 chương trình linh tinh báo virus thôi.
 
Dùng bản Dotfuscator miễn phí đổi tên này nọ thì chỉ còn 4 chương trình linh tinh báo virus thôi.
E nói thật a có dùng thì nếu crack họ đập vẫn ra bình thường. vì dubug được thì sẽ crack được quan trọng là app có đủ thơm hay không thôi.
Còn nếu ngon các hàm trong phải check sever hết mới ổn. khác cái thoát app luôn thì mới tịt sạch được ạ
 
E nói thật a có dùng thì nếu crack họ đập vẫn ra bình thường. vì dubug được thì sẽ crack được quan trọng là app có đủ thơm hay không thôi.
Còn nếu ngon các hàm trong phải check sever hết mới ổn. khác cái thoát app luôn thì mới tịt sạch được ạ
Tôi mở ra trong dnSpy rồi, chỉ mã hóa cơ bản thôi, code lộ lắm. Do được tích hợp với nhà VB.NET nên ổn hơn về mặt cảnh báo, chứ công cụ tôi có sẵn mà. Mục tiêu so sánh bản gốc, mã hóa nhẹ, mã hóa trung bình và mạnh. Càng lên cao thì cảnh báo virus càng tăng :)
 
Tôi mở ra trong dnSpy rồi, chỉ mã hóa cơ bản thôi, code lộ lắm. Do được tích hợp với nhà VB.NET nên ổn hơn về mặt cảnh báo, chứ công cụ tôi có sẵn mà. Mục tiêu so sánh bản gốc, mã hóa nhẹ, mã hóa trung bình và mạnh. Càng lên cao thì cảnh báo virus càng tăng
Trước em cũng rất là yêu .net nhưng nếu sét tốc độ thì thua native sét bảo mật(do trình mình non) nên viết họ mở tốt
Nên em chơi sang bài cùng lúc viết nhiều loại code
Cái nào chính thì dùng native (Go, Delphi, C++)
Cái nào mạnh AI, Phân tích(Python)
Giao diện thì dùng .net hoặc react hiển thị là thơm luôn, còn code chỉ Call từ Dll thôi trong dll có cả rồi. có phá thì phải phá vài ngôn ngữ mới ra được
 
Bạn đam mê code, còn tôi thì là bắt buộc nâng cấp sang môi trường mới mẻ hơn, chứ giờ cũng chán rồi, sờ vào cái gì cũng ngại. Hoạt động môn khác cho khỏe người :)
 
Bạn đam mê code, còn tôi thì là bắt buộc nâng cấp sang môi trường mới mẻ hơn, chứ giờ cũng chán rồi, sờ vào cái gì cũng ngại. Hoạt động môn khác cho khỏe người :)
Cái nào cũng phải có đam mê ạ, Cái nào thấy phù hợp thì làm thôi anh.
Trước em mê .net lắm giờ đang chuẩn bị bỏ nó đến nơi rồi.
 
Kaspersky chuyên nghiệp thật, gửi phản ánh 1 cái là có thông tin ngay:
Screenshot_20250924-075443.png
 
Mình nghĩ an toàn nhất là ứng dụng phải chạy khi có mạng , dữ liệu phải để trên server kiểm tra tính toàn vẹn file kiểm tra nếu file bị crack hay bị thay đổi này nọ gửi Mail báo cáo từ đó có biện pháp !
 
Mình nghĩ an toàn nhất là ứng dụng phải chạy khi có mạng , dữ liệu phải để trên server kiểm tra tính toàn vẹn file kiểm tra nếu file bị crack hay bị thay đổi này nọ gửi Mail báo cáo từ đó có biện pháp !
Crack thì không chống được chống unpaack thôi bạn.
Win to thế còn crack ầm ầm nữa là
 
các ngôn ngữ khác tôi không biết nhưng VB6 và Delphi nếu Viết DLL mà pack là thừa chỉ tổ làm mã chạy chậm đi và ôm cả đống virus kèm theo

VB6 có tùy chọn mã P còn Delphi có vài tùy chọn Off nó đi là xong khi builde chọn Release là xong

tại máy tôi mọi cái 64 bit hết mới viết DLL 32 bít xong thử một số cái trên VB6 của Windows 11 mới nhất thì toàn lỗi đăng ký các dll là VB6

có lẽ VB6 tuyệt chủng luôn rồi vì năm ngoái cũng Windows 11 chạy tốt này bản mới đăng ký DLL VB6 toàn báo lỗi

1758857971635.png

Tôi giờ này viết tạm OK trên Delphi bao gồm Pascal và mới nhập môm C++ builder nhưng vẫn dùng VBA chơi khi thấy code hay mở lên thử

xem thuật toán xong xóa = thế thôi vì cài VBA tốn trên 200 MB và quá nhẹ mà lợi ích mang lại nhiều

1758858270682.png
ChatGPT

Bạn gặp lỗi khi regsvr32 đăng ký DLL:


The module "C:\Visual Basic 6\Add-Ins\MyAddIns\AutoIndent.dll" was loaded but the call to DllRegisterServer failed with error code 0x80004005.<br>

Nguyên nhân chính:


  • 0x80004005 = E_FAIL (Unspecified error) → thường xảy ra khi:
    1. DLL yêu cầu thư viện COM/ActiveX cũ mà Windows 11 mới đã bỏ (nhất là VB6 runtime add-ins).
    2. Thiếu quyền admin (cần chạy cmd → Run as Administrator khi dùng regsvr32).
    3. DLL 32-bit nhưng bạn dùng regsvr32 bản 64-bit (hoặc ngược lại).



Cách xử lý:​


  1. Kiểm tra quyền admin
    • Mở Command Prompt (Admin)
    • Thử lại:

      C:\Windows\SysWOW64\regsvr32.exe "C:\Visual Basic 6\Add-Ins\MyAddIns\AutoIndent.dll"<br>
      (nếu DLL 32-bit).
    • Nếu DLL 64-bit → dùng:

      C:\Windows\System32\regsvr32.exe "C:\Visual Basic 6\Add-Ins\MyAddIns\AutoIndent.dll"<br>
  2. Kiểm tra runtime VB6
    • Microsoft đã ngừng hỗ trợ nhiều OCX/DLL đi kèm VB6.
    • Một số thư viện cũ (MSCOMCTL.OCX, RICHTX32.OCX, COMDLG32.OCX…) đã bị loại bỏ trong Windows 11 bản mới.
    • Bạn cần cài lại VB6 Runtime Extended Files (các bản do cộng đồng build lại, ví dụ từ vbforums hoặc github).
  3. Chạy chế độ tương thích
    • Copy DLL sang thư mục dễ quản lý (ví dụ C:\VB6DLLs\)
    • Đặt quyền Full Control cho user.
    • Thử đăng ký lại trong chế độ Compatibility Windows XP/7.
  4. Nếu vẫn không được
    • DLL viết bằng VB6 add-in thường không còn chạy tốt trên Windows 11 22H2/23H2.
    • Giải pháp lâu dài: port lại sang .NET (VB.NET/C#) hoặc viết COM DLL bằng Delphi/C++ như bạn đã làm gần đây.



Tóm lại: Windows 11 mới đã loại bỏ dần các thư viện cũ của VB6, nên add-in dạng DLL khó chạy ổn định nữa. Nếu bạn muốn chắc chắn dùng trong VBA/Office thì tốt nhất nên build lại bằng Delphi hoặc .NET.


Bạn có muốn mình hướng dẫn cách build lại DLL AutoIndent từ VB6 sang Delphi COM DLL để vẫn dùng trong VBA/Office mà không phụ thuộc VB6 runtime không?
Bài đã được tự động gộp:

1758858745371.png
Viết DLL trên bất cứ tools nào cũng OK sạch nhưng khi check xanh toàn diện như vậy xem như Tạm OK
 
Lần chỉnh sửa cuối:

Bài viết mới nhất

Back
Top Bottom