Cách Reverse Engineer Một Ứng Dụng Với Claude Code

Reverse engineering nghĩa là nghiên cứu một phần mềm đã hoàn thiện để hiểu cách nó hoạt động, thường là không có mã nguồn gốc hoặc bất kỳ tài liệu thiết kế nào đi kèm với nó. Bạn nhìn vào những gì nó làm, nó được lắp ghép ra sao, và nó giao tiếp với cái gì, và từ đó bạn làm việc ngược lại để có một mô hình về hành vi của nó.

Người ta làm điều này vì những lý do chủ yếu không có gì hào nhoáng và chủ yếu là hợp pháp. Các nhà nghiên cứu an ninh reverse engineer các chương trình để tìm ra một lỗ hổng trước khi ai đó có ý định xấu hơn làm điều đó. Các developer reverse engineer các định dạng file và giao thức network để một chương trình mới có thể tương tác được với một chương trình cũ mà không ai sẽ viết tài liệu cho họ. Các nhà lưu trữ và người đam mê reverse engineer phần mềm cũ để giữ nó chạy được một khi phần cứng gốc và công ty đứng sau nó đều đã biến mất. Và đôi khi lý do chỉ đơn giản là một chương trình mà bạn phụ thuộc vào làm một điều gì đó không có tài liệu, và bạn cần biết đó là gì, trước khi bạn có thể tin tưởng nó hoặc tìm cách xử lý nó.

Không có gì trong số này là mới. Các nhà nghiên cứu an ninh và các nhà lưu trữ phần mềm đã làm việc này hàng chục năm với disassembler và debugger, từ lâu trước khi có bất kỳ agent AI nào tồn tại. Thứ đã thay đổi là tốc độ: một agent có thể đọc một bản disassembly hoặc một method đã decompile và tóm tắt nó trong vài giây, công việc mà trước đây mất của một người có kỹ năng cả giờ đồng hồ. Đó là một sự gia tăng năng lực thực sự, và đó chính là lý do ranh giới pháp lý và đạo đức ở phần sau của hướng dẫn này quan trọng hơn bây giờ, không phải ít hơn, vì cái rào cản đã từng làm chậm người ta giữa sự tò mò và việc sao chép nay hầu như đã biến mất.

Phần còn lại của hướng dẫn này cụ thể hơn: nó đi qua một công cụ, tên là REA, kết nối một agent như Claude Code với loại phân tích này, và những thói quen đáng có sẵn trước khi bạn hướng nó vào bất cứ thứ gì.

Sự khác biệt quan trọng nhất ở đây là giữa nghiên cứu cách một thứ hoạt động và sao chép phần biểu đạt được bảo vệ của nó. Reverse engineering để học một interface, một định dạng file, hoặc một phần hành vi, về mặt pháp lý, là một hành động khác với lấy mã hoặc tài sản của người khác đưa vào một sản phẩm của riêng bạn.

Thông lệ được xây dựng quanh sự khác biệt đó được gọi là clean-room design. Một người hoặc một phiên nghiên cứu bản gốc và viết một đặc tả bằng ngôn ngữ thông thường về những gì nó làm: interface, định dạng dữ liệu, hành vi của nó, bằng từ ngữ của riêng họ, không có mã gốc nào được sao chép vào tài liệu. Một người hoặc một phiên riêng biệt khác, chưa từng thấy bản gốc, sau đó xây dựng một triển khai mới chỉ từ đặc tả đó. Điểm mấu chốt là kết quả cuối cùng có thể được chứng minh là đến từ một bản mô tả bằng văn bản, không phải từ chính công trình gốc.

Hai quyết định của tòa án Mỹ cũ hơn thường được trích dẫn về điểm này, và đáng để biết về chúng, mặc dù không cái nào là một sự cho phép chung để reverse engineer bất cứ thứ gì. Sega Enterprises Ltd. v. Accolade, Inc., được Ninth Circuit quyết định năm 1992, liên quan đến một công ty đã reverse engineer hệ thống lockout của một console chơi game để các game của riêng họ chạy được trên console đó. Tòa án nhận định rằng việc sao chép trung gian liên quan trong quá trình reverse engineering đó, thực hiện để tiếp cận các yếu tố chức năng không được bảo vệ cần thiết để game chạy được trên phần cứng, là fair use dựa trên các sự kiện cụ thể của vụ án đó. Sony Computer Entertainment, Inc. v. Connectix Corp., được cùng tòa án đó quyết định năm 2000, đi đến kết luận tương tự khi một công ty reverse engineer phần mềm khởi động của một console để xây dựng một emulator cho một loại máy tính khác, lại coi việc sao chép trong quá trình là fair use nhằm phục vụ cho một sản phẩm được viết độc lập, có khả năng tương tác.

Hãy coi cả hai điều này là bối cảnh lịch sử, không phải lời khuyên cho tình huống của bạn. Đó là hai quyết định phúc thẩm cụ thể về các sự kiện cụ thể, fair use được quyết định theo từng vụ án, các quốc gia khác vạch ra những ranh giới này khác nhau, và các luật sau này nhằm chống lại việc vượt qua các biện pháp bảo vệ sao chép đã thu hẹp điều này đáng kể đối với phần mềm gắn với DRM. Bất kỳ ai định xây dựng trên loại công việc này, đặc biệt là bất cứ thứ gì dự định đưa ra thị trường hoặc bán, nên nói chuyện với một luật sư thực sự trước khi dựa vào bất kỳ điều gì trong số này.

REA vạch ra ranh giới của riêng mình độc lập với những gì một tòa án cuối cùng có thể quyết định về một vụ án cụ thể nào đó. Theo DISCLAIMER.md của dự án, REA không hỗ trợ và sẽ không giúp vượt qua DRM, kiểm tra license, hệ thống anti-cheat, hoặc các biện pháp bảo vệ kỹ thuật khác, hoặc sao chép phần mềm độc quyền hoặc mã và tài sản được bảo vệ của nó, và dự án nói rõ ràng rằng đầu ra phân tích không cấp bất kỳ quyền nào đối với chương trình gốc. Quy tắc thực tế theo đó: chỉ phân tích phần mềm bạn sở hữu, tự viết, hoặc được phép kiểm tra theo cách khác.

Phiên bản Node.js quan trọng ở đây. README của chính REA nêu rõ yêu cầu của nó chính xác là: Node.js 22.x (>=22.23.4), 24.x (>=24.22.1), hoặc 26.12.1+, cộng với npm. Kiểm tra lại với README trực tiếp trước khi bạn cài, vì loại yêu cầu này thay đổi giữa các bản phát hành.

Lệnh thiết lập là npx rea-agents setup. Theo README, nó dẫn bạn qua việc chọn các agent nào để đăng ký REA với, cho bạn thấy các thay đổi nó đề xuất thực hiện trước khi bạn đồng ý, và giữ lại bản sao lưu cấu hình hiện có của bạn. Khởi động lại agent của bạn sau đó để nó nhận MCP server mới; chính hướng dẫn của REA nói rõ điều này.

Đối với một bản cài đặt command-line bền vững hơn là chạy npx một lần, README mô tả npm install --global rea-agents, theo sau là rea --help để xem những gì có sẵn. Từ một bản cài đặt global, rea update đưa bạn sang phiên bản mới theo lịch trình của riêng bạn thay vì tự động, và chạy npx rea-agents@latest setup sau đó cập nhật lại đăng ký agent để khớp.

Trước khi hướng REA vào bất cứ thứ gì bạn không hoàn toàn sở hữu, hãy thử nó trên một ứng dụng nhỏ bạn tự viết trước. Với REA đã được thiết lập, yêu cầu Claude Code mở ứng dụng nhỏ đó và mô tả những gì nó thấy, function theo function, và so sánh điều đó với những gì bạn đã biết mình viết. Bài tập đó xác nhận thiết lập thực sự đã hoạt động, và nó cho bạn cảm giác về cách bằng chứng của REA, một file, một function, một call, đọc như thế nào trong thực tế trước khi bạn dựa vào nó cho bất cứ điều gì quan trọng.

Đưa ý tưởng clean-room ở trên vào một hình thức cụ thể bằng cách dùng hai phiên Claude Code riêng biệt. Phiên đầu là một phiên viết đặc tả: hướng REA vào phần mềm bạn được phép nghiên cứu, và yêu cầu agent viết một đặc tả bằng ngôn ngữ thông thường về interface, định dạng dữ liệu, và hành vi của các function chính của nó, hoàn toàn bằng từ ngữ của riêng nó, không có mã gốc hoặc pseudocode nào được sao chép nguyên văn vào tài liệu.

Phiên thứ hai là một phiên build, được bắt đầu mới, không có bộ nhớ của phiên đầu. Chỉ đưa cho nó file đặc tả, không gì khác: không phải binary gốc, không phải transcript của phiên đầu, không phải đầu ra thô của REA. Yêu cầu nó xây dựng một triển khai mới, độc lập, thỏa mãn đặc tả, và cho bạn biết khi có điều gì trong đặc tả đó không rõ ràng thay vì lặng lẽ đoán xem chương trình gốc đã làm gì.

Giữ chúng là hai phiên thực sự riêng biệt, không phải hai giai đoạn của một cuộc hội thoại dài, là phần quan trọng. Một phiên duy nhất vừa nghiên cứu bản gốc rồi viết bản thay thế đã làm mờ chính xác ranh giới mà clean-room design tồn tại để giữ cho rõ ràng, vì không có cách nào để chứng minh, sau sự việc, rằng nửa sau không dựa vào nửa đầu.

Hãy sáng suốt về những gì điều này mang lại cho bạn. Một quy trình hai phiên có tổ chức là một thông lệ hỗ trợ cho một luận điểm clean-room sau này nếu có ai từng hỏi một thứ gì đó đã được xây dựng ra sao. Nó không phải là một bảo đảm pháp lý tự thân, và nó không thay thế việc có một luật sư thực sự xem qua bất cứ thứ gì bạn định đưa ra thị trường hoặc bán.