Guardship disassembles mã NET của bạn và sau đó biên dịch mã MSIL của thực thi của bạn vào ứng dụng không được quản lý bản địa bằng cách tạo ra hai phần: 1. Module Bắt đầu [Your_App_Name] năm; 2. Thư viện [Your_App_Name] lib
các ứng dụng của bạn (WinForms, WPF) mà mục tiêu .NET Framework được biên dịch sang ngôn ngữ trung gian (IL). Vào lúc chạy, just-in-time (JIT) biên dịch dịch IL để mã gốc. Guardship dịch NET thực thi của bạn để mã gốc để làm cho nó ẩn. Khi bạn chạy file thực thi bảo vệ nó có tất cả các tính năng và chức năng của ứng dụng quản lý thực hiện trong bộ nhớ máy tính. Nhưng NET trình duyệt lắp ráp và ăn cắp sẽ không có khả năng đọc file thực thi .NET bảo vệ của bạn.
Tại sao Guardship chuyển đổi để thực thi không được quản lý?
Có một vài disassemblers cho dịch ngược không được quản lý thực thi viết bằng ASM, C, C ++. Tuy nhiên không ai trong số họ sẽ quản lý để sản xuất mã đủ thể đọc được giá trị nỗ lực. Bạn sẽ dành nhiều thời gian cố gắng để đọc các nguồn dịch ngược với các khối lắp ráp bên trong, hơn là viết các ứng dụng cùng hoạt động từ đầu.
Trong thực tế, bất kỳ thành phần thực thi có thể được tháo rời và khám phá. Sự yên thân mà một decipherer có thể đảo ngược-kỹ sư mã nguồn ứng dụng của bạn phụ thuộc vào cách siêu dữ liệu đầy đủ về mã nguồn của ứng dụng trình bày bên trong module exe. May con số decipherer ra ban đầu tên lớp, phương pháp, dòng làm việc, cấu trúc, vv? Một trình biên dịch về cơ bản làm gọn mã nguồn ứng dụng của, chuyển đầu ra vào một định dạng đó là phù hợp hơn để thực hiện thời gian chạy máy. Nó có thể là một mã máy hoặc mã byte IL được xử lý bởi thời gian chạy trung gian CLR. Tuy nhiên do và lớn, rất nhiều thông tin về mã của bạn ứng dụng mã nguồn (gỡ lỗi, ý kiến, vv) chỉ đơn giản là có thể bị mất trong quá trình soạn thảo nhỏ gọn
Yêu cầu .
.NET Framework 2.0
hạn chế :
chức năng TNHH
Bình luận không