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) Overwriting the .dtors section by Juan M. Bello Rivas Dịch sang tiếng Việt: SeekZero Giới thiệu Bài viết này trình bày một cách ngắn gọn một kỹ thuật dùng để chiếm quyền điều khiển và đổi hướng thực thi của một chương trình C được biên dịch bằng gcc. Người đọc xem như đã quen thuộc với kỹ thuật tràn bộ đệm cơ bản và định dạng ELF. Tổng quan gcc cung cấp một số kiểu thuộc tính (attributes) cho hàm, đặc biệt hai trong số đó làm chúng ta quan tâm là: cấu tử (constructor) và huỷ tử (destructor). Các thuộc tính này phải được lập trình viên mô tả theo cách tương tự như sau: static void start(void) __attribute__ ((constructor)); static void stop(void) __attribute__ ((destructor)); Hàm với thuộc tính 'constructor' sẽ được thực thi trước hàm main(), trong khi các hàm được khai báo với thuộc tính 'destructor' sẽ được thực thi ngay sau hàm main(). Khi tạo các file thực thi dạng ELF, đặc điểm này sẽ được thể hiện trong hai vùng khác nhau là: .ctors và .dtors. Cả hai vùng sẽ có cách sắp xếp như sau: 0xffffffff <function address> <another function address> 0x00000000 LƯU Ý: Nếu bạn muốn biết tường tận về điều này, bạn nên xem mã nguồn gcc-2.95.2/gcc/collect2.c. Bắt đầu từ đây, có một số điểm cần quan tâm: * .ctors và .dtors sẽ được ánh xạ (map) vào không gian bộ nhớ của tiến trình thực thi và mặc định là vùng ghi được. * Các vùng này không bị xoá khi sử dụng lệnh strip(1) với file thực thi * Chúng ta không quan tâm người viết ra chương trình có tạo các hàm làm cấu tử hoặc huỷ tử hay không vì cả hai vùng này cũng đều tồn tại và được ánh xạ vào bộ nhớ. Khảo sát chi tiết Chúng ta sẽ minh họa những gì đã đề cập ở trên.