Lessons VI : Open source, closed source và việc bảo vệ software

Open source, closed source và việc bảo vệ software

 

Đa số software mình xài đều là bản được cr@ck hoặc có keygen hoặc serial kèm theo. Nghĩ lại nếu mình làm software thì mình sẽ bảo vệ nó ra sao đây, bà con có cao kiến gì ko?

PS: trong UDS có bác Merc, bác chỉ bảo cái nì với nhé, thanks.

 

Trac(UDS)

 

 

Theo Merc được biết, protect các software có rất nhiều dạng. Từ dạng đơn giản chỉ là yêu cầu số đăng kí tới các dạng sử dụng khóa cứng. Mục tiêu trước tiên của các coder là phải giảm thiểu khả năng disassembly (dịch ngược) và debug của các cr@cker : Sử dụng các packer, antidebug, CRC check … Thêm đó là sử dụng một thuật toán mã hóa mạnh để mã hóa quá trình tạo License.

Các soft lớn cỡ vài ba nghìn $ thì đa số sử dụng khóa cứng như Adobe Acrobat Reader, Orcad … Thêm nữa, khi mà Internet được phổ biến rộng rãi như hiện nay thì các hãng phần mềm áp dụng quá trình đăng kí online (gần như là chỉ có bỏ tiền ra mua thì xài ổn).

 

Merc(UDS)

 

 

Nếu được thì Merc có thể nói chi tiết một số kiểu protect thường sử dụng được ko. Xin cảm ơn

Sau khi suy đi tính lại thì cuối cùng mình quyết định là sẽ làm theo kiểu là dựa vào hardware ID để sinh ra serial, và quả thật là lưu ở đâu cũng sẽ có vấn đề hết. Theo mình thấy thì bất cứ việc reg nào cũng có chuyện so sánh (ở đây ko nói đến validate online nhé) giá trị A (giả sử là giá trị dựa vào hardware để sinh ra) và giá trị B (key mà mình đưa cho khách hàng).

Mới đầu mình nghĩ mình sẽ nhúng cái đoạn đọc hardware ID + 1 đống cộng trừ nhân chia ==> A rồi sau đó sẽ so sánh với B.
Có 2 vấn đề với cách trên:
1. Đoạn code xử lý trên bị decompile: mình làm .NET và mình cũng có 1 số tool để chống decompile nhưng thật sự là ko tin tưởng lắm. Mình cũng đã thấy 1 số soft chống decompile rất tốt nhưng ko biết nó chống bằng tool gì (tiêu biểu là SQL Examiner – google for more)
2. Giả sử chuyện (1) ko xảy ra, sinh ra giá trị OK=A. Giá trị A này sẽ được lưu ở 1 vùng nhớ (ko biết dùng từ này đúng ko) nào đó rồi sau đó user sẽ nhập giá trị B rồi so sánh với A, valid thì OK. Vấn đề là có thể access vùng nhớ đó để lấy ra giá trị A, lúc đó thì chỉ việc lấy giá trị đó=B là OK. Cái này làm mình đau đầu hết sức, vì 1 lần mình đã ngồi nhìn 1 ông cr@ck cái XML Spy bằng cách này (Merc biết ông này nhưng đừng nói ổng nhe, ổng là computer virus angel – anh Khiêm đó – hồi đó làm chung cty với mình)

Cuối cùng mình nghĩ mãi rồi mình tính làm theo các bước như sau:
1. user xài 1 software để scan hardware ID ==> A, email A cho mình
2. mình sẽ dựa vào cái A này để sinh ra B
3. nhúng B vào trong code rồi build –> exe
4. khi reg thì app sẽ dùng (1) + (2) ==> A1
5. so sánh A và A1, nếu match thì OK

Nói tới đây thì thấy nó hơi củ chuối nhưng mình cũng ko biết cách giải quyết ra sao nữa, hic

 

Trac(UDS)

 

 

Em hôm trước vừa mới biết (theo em đoán thui) có một soft same same ý tưởng của anh. Tức là khi khác hàng bỏ tiền ra mua, tụi coder sẽ nhập số Serial tương ứng vào chương trình cho khách hàng đó, rồi build lại file .exe. Up lại lên site và gửi link cho customers. Với các chương trình kiểu này, có thể tin rằng Cr@cker không thể Gen được số Serial thực, mà phải thay đổi code trên chương trình để nó chấp nhận bất kì một số Serial nào đó.

Hiện nay các phần mềm code bằng .NET vẫn còn đang trong giai đoạn “tìm hiểu” của tụi Cr@cker. Mà soft code bằng .NET chỉ cần decompile là gần như ra hết trơn. Em có nghe nói có mấy trình bảo vệ cho soft code bằng .NET, điển hình là obfucastor.

Theo em cách bảo vệ tốt nhất là anh cố gắng xây dựng cái Check Routine thật mạnh và thật “kín” (có nghĩa là khó tìm ra đoạn nào là đoạn check này). Thứ hai là tìm hiểu các công cụ dùng để chơi .NET, sau đó anti chúng. Chứ sử dụng tool sẵn có của hãng thứ 3 thì chỉ sau 1 thời gian là sẽ bị bypass ngay. Mà tool mạnh thì phải mất tiền mua

 

Merc(UDS)

 

 

Tôi xin có chút ý kiến về cái này: thường cracker sẽ dựa vào các thông báo bằng messageBox đề phăng ngược lại tìm đoạn code chứa câu lệnh so sánh, sau đó ráng chỉnh sửa để cho nó Jump tới đoạn kiểm tra đúng. Tôi thấy một soft có ý tưởng rất hay là nếu kiểm tra không đúng nó không báo gì hết?. Quả thật như vậy rất khó cho tụi cracker nó tìm được điểm để đặt breakpoint.

Để chống memory dump, bạn có thể để vài biến trong đó chứa key mà khách hàng nhập vào, mục đích là đánh lạc hướng khi cracker cố gắng đọc từ memory ra để lấy key so sánh nhưng key thật sự thì bạn nên encryp nó.

Tôi nghĩ không cách nào để bảo vệ tuyệt đối, chỉ có là chúng ta làm cho nó khó bị xử hơn thôi.

 

Nicole82(UDS)

 

 

@Merc: mình nhớ lộn, nick của anh Khiêm rồi, hic. Merc cho mình hỏi là hoàn toàn có thể thay giá trị của 1 vùng nhớ đúng ko. Giả sử mình thay được giá trị thì coi như cách của mình cũng tèo luôn. Trên HDD có vùng nào được gọi là bất khả xâm phạm ko ta, mình thì mĩnh nghĩ chắc là ko có, chạy ra ngoài DOS scan 1 hồi cũng ra (đương nhiên là soft của mình ko hay đến nỗi mà bà con phải ngồi cr@ck nhưng mà biết cách bảo vệ thì cũng quá lí thú)

@nicole82: đồng ý

Quote:

Tôi nghĩ không cách nào để bảo vệ tuyệt đối, chỉ có là chúng ta làm cho nó khó bị xử hơn thôi.

đúng là mình cũng thấy cr@ker sẽ giới hạn vùng tìm kiếm bằng cách check cái message box đó; nhưng mình cũng thấy là cr@ker hoàn toàn có thể manage xem hiện tại cái application đang dùng vùng nhớ nào (có cái tool nhưng mình ko biết tên và cũng ko biết xài; chỉ nhìn thấy thôi)

đọc các tài liệu về obfuscaste cho .NET (ngay cả cái chữ obfuscate cũng chỉ có nghĩa là làm cho khó hơn thôi chứ ko phải là bảo vệ ) thì nó cũng nói là có nhiều cách, 1 trong những cách mà nó reccomend là đặt tên biến dài, khó hiểu + chạy lòng vòng, đây có phải là ý của bạn ko nhỉ. Mà nói thiệt là nếu mà muốn thì chạy lòng vòng cách mấy cũng bị mò ra.

Xem ra chuyện bảo vệ software là 1 câu chuyện dài

 

trac(UDS)

 

 

Quote:

Xin Merc nói kỹ hơn cái này, có phải là mình build lại cái exe luôn phải ko (nghĩa là cr@cker remove cái đoạn check). Sẵn đây hỏi luôn, đây có phải là cách mà 1 số soft bị cr@ck bằng cách chép đè file exe?

Cái này có nhiều cách, đơn giản nhất là chuyển mã assembly của đoạn code check ser. Nó kiểm tra nếu ser đúng thì nhảy đến đoạn code A (đăng ký thành công) nếu sai nhảy đến đoạn code B (Serial không hợp lệ). Điều mà cr@cker làm ở đây là sửa lại chút xíu để nó làm ngược lại, nhảy đến A thay vì đến B (je–>jne). Có thể nói cách này là 1 cách đơn giản nhất để cr@ck 1 soft, tuy nhiên trong nhiều trường hợp thì lý thuyết là bạn đã cr@ck nó, còn thực tế thì vẫn là trial. Cấn phải đọc tài liệu và thực hành nhiều mới được

Quote:

Rất tiếc là có thể thay đổi giá trị vùng nhớ anh ạ

Cái này dùng nhiều trong hack game và fish serial. Dùng một chương trình view memory để xem giá trị của các thanh ghi, từ đó thay đổi giá trị của các thanh ghi và cờ nhớ (Tìm tài liệu Assembly đọc sẽ rõ hơn)
Thân!

 

Chicknsoup(UDS)

 

 

Nếu bác mà dùng hardware ID thì khéo nhé. Vì hardware ID là cách chỉ cho 1 máy reg 1 lần với 1 key tương ứng nào đó và key đó đem wa máy khác sẽ ko work .Nhưng giả sử có thể patch cái hardware ID kia lên cho các máy khác để chúng đều giống nhau về hardware ID thì tức là key kia sẽ valid lên những máy đó . –> Chỉ cần soft được buy 1 lần, có thể bị xài “chùa” lên các máy còn lại.

Còn nghĩ ra phương thức sinh code thật phức tạp thì sao? Phức tạp tới độ ko mò ra thì cũng có, nhưng chi phí tính toán và suy nghĩ để code sẽ tốn rất rất nhiều ,liệu sản phẩm làm ra có đáng giá để bù hao lại chi phí ban đầu ?

Còn theo kiểu protect 1 chiều hay dùng để mã hóa section file ,tức ko có private key thì ko cách gì giải mã được thì cũng bị tèo theo nguyên tắc đầu : chỉ cần soft được buy 1 lần ,từ valid key sẽ mò ra key dùng để mã hóa và tất nhiên là ….

Check Online là phương pháp có vẻ hoàn hảo về mặt protect .Nhưng xét trên diện rộng thì ko phải ai cũng có Internet để connect mà đăng kí software. Do đó soft khó đem lại sự dễ chịu cho khách hàng .(nếu là khách hàng ko thân thiết lâu năm với sản phẩm ) Ví dụ: xét bản Norton Antivirus 2007 và 2005 hay 2006 sẽ thấy sự khác biệt về lượng người sử dụng.
Nhưng Check Online theo kiểu nhận data từ Server để decrypt các func bị hide thì sau khi đã valid ít nhất 1 bản, khả năng làm ra 1 bản non-check online là rất cao.

Về .NET,dù là gì đi nữa thì cũng là code .Mà code thì thể nào cũng bị dịch ngược tất. Vấn đề là thời gian thôi.

Anti-Cr@ck đúng là 1 câu chuyện dài.

 

Trickyboy(UDS)

  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: