Công Cụ Giải Mã JavaScript

Một học sinh tiếp quản dự án JavaScript đầy những tên biến cụt lủn, chuỗi đã mã hóa, biểu thức lồng nhau và các hàm rối đến mức không lần ra được. Trang vẫn chạy, nhưng cả nhóm không ai giải thích nổi dữ liệu đi từ biểu mẫu đến kết quả cuối bằng đường nào.

Trình gỡ rối mã JavaScript giúp phần nào làm cho đoạn mã đã bị biến đổi ấy dễ xem xét hơn. Tùy vào thứ bạn đưa vào, nó có thể phơi ra cấu trúc, đơn giản hóa một số kiểu làm rối, giải mã vài chuỗi hoặc trả về một bản chạy được nhưng dễ đọc hơn hẳn.

Gỡ rối mã không phải là lấy lại mã nguồn gốc. Chú thích, những cái tên có nghĩa, ranh giới giữa các mô-đun, kiểu dữ liệu TypeScript và cả mạch suy nghĩ của người viết đều có thể đã mất hẳn. Những kiểu biến đổi tinh vi cũng kháng lại việc phân tích tự động.

Tuyệt đối đừng chạy một đoạn JavaScript lạ chỉ để xem nó làm gì. Việc phân tích an toàn bắt đầu từ sự cho phép, một bản sao được giữ nguyên, việc xem xét mà không chạy, và một môi trường kiểm soát được dựng riêng cho loại mã có thể gây hại.

Làm rối mã JavaScript nghĩa là gì

Làm rối mã là sửa mã sao cho người ta khó hiểu nổi, trong khi phần chạy vẫn giữ nguyên. Lập trình viên dùng cách này để ngăn việc sao chép dễ dãi, giấu bớt phần nghiệp vụ hoặc khiến việc dịch ngược thêm vất vả.

Một đoạn JavaScript bị làm rối thường có:

• Tên biến chỉ một chữ cái hoặc chẳng mang nghĩa gì.
• Những mảng chuỗi mã hóa dài dằng dặc.
• Lời gọi hàm đi đường vòng.
• Những phép tính chẳng để làm gì.
• Biểu thức điều kiện lồng nhau nhiều tầng.
• Luồng chạy bị xáo trộn có chủ ý.
• Các chuỗi ký tự viết dưới dạng thoát.
• Hàm dựng hoặc thực thi mã ngay lúc chạy.
• Nhiều lớp bọc lặp đi lặp lại quanh một thao tác đơn giản.
• Mã chết, chỉ tổ kéo sự chú ý khỏi phần chạy thật.

JavaScript rút gọn cũng khó đọc, nhưng việc rút gọn sinh ra là để giảm dung lượng tệp. Làm rối mã thì nhắm tới chuyện khác: giấu đi ý nghĩa.

Định dạng và gỡ rối là hai việc khác nhau

Nếu vấn đề chỉ là mã bị dồn hết vào một dòng, hãy bắt đầu bằng Trình Định Dạng JavaScript. Việc gỡ rối chỉ cần đến khi mã vẫn cố tình khó hiểu dù đã định dạng xong.

Gỡ rối có thể giúp lộ ra những gì

• Chỗ bắt đầu và kết thúc của các hàm, các khối.
• Những lần tra cứu lặp lại vào bảng chuỗi.
• Các giá trị văn bản đã mã hóa hoặc viết dạng thoát.
• Địa chỉ mạng được ghi một cách vòng vo.
• Bộ xử lý sự kiện và các điểm bắt đầu chạy.
• Những phần tử trên trang mà đoạn mã chọn hoặc sửa.
• Việc truy cập kho lưu trữ, cookie, bộ nhớ tạm hay biểu mẫu.
• Các hàm dùng để chạy đoạn mã sinh ra tại chỗ.
• Những nhánh thừa hoặc đặt vào để đánh lạc hướng.
• Đường đi chung của dữ liệu, từ đầu vào tới đầu ra.

Kết quả nào cũng phải kiểm lại. Một phép biến đổi có thể làm sáng tỏ chỗ này mà vẫn để nguyên chỗ kia khó nhằn như cũ.

Gỡ rối tự động không thể hứa điều gì

Một trình gỡ rối không bảo đảm sẽ:

• Lấy lại tên gốc của hàm và biến.
• Trả về những chú thích đã bị xóa.
• Dựng lại cấu trúc thư mục của dự án.
• Bóc hết mọi lớp làm rối.
• Hiểu đúng đoạn mã sinh ra lúc chạy.
• Bảo đảm kết quả chạy được an toàn.
• Chứng minh đoạn mã là vô hại.
• Cho bạn quyền sao chép hay đăng lại mã của người khác.
• Tự sửa các lỗi logic.
• Lấy về mã phía máy chủ, thứ vốn chưa từng nằm ở đây.

Phân tích JavaScript an toàn hơn bằng cách nào

1. Xác nhận bạn được phép. Chỉ phân tích mã của chính mình, tài liệu lớp học giáo viên đã cho, hoặc mã mà bạn có quyền xem xét.
2. Giữ nguyên bản gốc. Ghi lại nó từ đâu ra và, nếu việc điều tra đòi hỏi, tính mã băm đáng tin cho tệp.
3. Đừng chạy nó. Hãy bắt đầu bằng việc xem xét mà không thực thi.
4. Định dạng một bản sao. Dùng trình định dạng khi đoạn mã bị nén lại.
5. Chỉ gửi đi thứ không nhạy cảm. Bỏ khóa riêng, token, dữ liệu học sinh và mã nội bộ ra trước khi dùng bất kỳ công cụ trực tuyến nào.
6. Chạy việc gỡ rối. Lưu kết quả thành một tệp phân tích riêng.
7. So bản gốc với bản ra. Xem những phép biến đổi nào thực sự đã xảy ra.
8. Tìm điểm bắt đầu chạy và tác động phụ. Để ý việc truy cập mạng, kho lưu trữ, DOM và việc chạy mã ngay tại chỗ.
9. Ghi lại những gì tìm được. Lưu bằng chứng kèm số dòng, và ghi rõ cả những chỗ còn chưa chắc.
10. Chuyển mẫu rủi ro lên trên. Mã lạ hoặc có thể độc hại là việc của người làm bảo mật có kinh nghiệm, trong môi trường đã được duyệt.

Một khung xem xét không cần chạy mã

Xem xét tĩnh nghĩa là đọc mã mà không thực thi. Đó là chỗ nên bắt đầu khi gặp một đoạn mã lạ.

1. Xác định các điểm bắt đầu chạy

Hãy tìm lời gọi hàm trực tiếp, các bộ lắng nghe sự kiện, bộ xử lý chạy khi trang tải xong, bộ hẹn giờ, phần khởi tạo mô-đun và các hàm được nhập vào. Việc chạy thường bắt đầu từ đó.

2. Xác định đầu vào

Tìm xem mã có chạm tới:

• Các ô của biểu mẫu.
• Tham số trên địa chỉ trang.
• Cookie.
• Bộ nhớ cục bộ hoặc bộ nhớ phiên.
• Phản hồi từ API.
• Bộ nhớ tạm.
• Tệp người dùng tải lên.
• Văn bản và thuộc tính của chính trang đó.

3. Xác định đầu ra

Hãy để ý:

• Những thay đổi trên trang.
• Các yêu cầu gửi qua mạng.
• Việc chuyển hướng.
• Việc tải tệp về.
• Thay đổi trong kho lưu trữ.
• Thông báo trong bảng điều khiển.
• HTML sinh ra tại chỗ.
• Lời gọi tới dịch vụ bên ngoài.

4. Tìm phần chạy mã tại chỗ

Những hàm như eval(), việc dựng hàm ngay lúc chạy và các đoạn mã tạo ra từ chuỗi đều đáng xem kỹ. Có chúng không đồng nghĩa với ý đồ xấu, nhưng việc hiểu mã mà không chạy sẽ khó hơn nhiều.

5. Lần theo các chuỗi đã mã hóa

Đoạn mã bị làm rối có thể cất địa chỉ hoặc thông điệp dưới dạng thoát, hệ mười sáu hoặc Base64. Chỉ giải mã bản sao của những giá trị vô hại, và đừng chạy thứ vừa giải ra.

Những tình huống học tập và phòng vệ có thật

1. Lấy lại khả năng đọc cho bài tập nhóm

Một nhóm phát hiện quá trình build cũ chỉ để lại đúng tệp JavaScript đã bị biến đổi. Mã nguồn thì chẳng ai lưu.

Nhóm định dạng rồi gỡ rối một bản sao, từ đó lần ra các hàm chính và những bộ chọn phần tử trên trang. Tên có nghĩa được đặt lại dần dần, và chỉ dựa trên phần đã kiểm chứng được.

Tệp dựng lại trở thành nền tạm để bảo trì, nhưng nhóm ghi rõ rằng đó không phải bản gốc y nguyên.

2. Học về việc làm rối mã trong giờ tin học

Giáo viên đưa ra một đoạn mã vô hại, chỉ cộng hai số. Một bản để nguyên dễ đọc, bản kia đổi tên biến và mã hóa chuỗi.

Học sinh so hai tệp, chạy công cụ gỡ rối rồi giải thích cái gì lấy lại được, cái gì thì không.

Giờ học xoay quanh sự minh bạch của phần mềm, việc bảo trì, quyền sở hữu trí tuệ và giới hạn của kiểu bảo mật dựa vào sự khó hiểu.

3. Soi một tiện ích của bên thứ ba

Người quản trị trang web của trường được phép đánh giá một tiện ích nhỏ của bên ngoài trước khi cài.

Đoạn mã được soi xem có yêu cầu ra ngoài, có đụng cookie, có thu thập nội dung biểu mẫu và có sửa DOM hay không. Tài liệu chính thức và điều khoản riêng tư được đối chiếu với những gì mã thực sự làm.

Hành vi nào không giải thích được thì báo cho bên cung cấp, chứ không bỏ qua chỉ vì tiện ích trông có ích.

4. Truy tìm nguyên nhân chuyển hướng bất ngờ

Một lập trình viên mới vào nghề thấy trang thử nghiệm tự chuyển sang nơi khác sau khi tải một đoạn mã lạ.

Đoạn mã được gỡ khỏi trang, giữ lại làm bằng chứng và đem ra xem xét mà không chạy. Việc gỡ rối giúp lộ ra địa chỉ đích và điều kiện khiến trang nhảy đi.

Mã chỉ được đưa trở lại trang đang hoạt động sau khi đã rõ nguồn gốc và mục đích.

5. Hiểu một phần cấu hình đã mã hóa

Một đoạn mã hợp lệ chứa bảng chuỗi gồm nhãn giao diện và đường dẫn API. Rất khó nối từng giá trị với chỗ nó được dùng.

Lập trình viên lập bảng đối chiếu giữa vị trí trong mảng và giá trị đã giải mã, rồi đổi tên các tham chiếu trong một bản làm việc.

Mẩu nào trông giống Base64 thì đưa qua Công Cụ Giải Mã Base64, và chỉ khi đã biết chắc giá trị đó là dữ liệu vô hại.

6. Kiểm tra một trò chơi dùng trong lớp

Một cô giáo muốn dùng trò chơi chạy trên trình duyệt do cựu học sinh viết. Phần JavaScript của nó cố tình viết cho khó đọc.

Mã được rà soát xem có kết nối mạng, có thu thập dữ liệu, có quảng cáo, có tải mã bên ngoài và có chèn HTML thiếu an toàn hay không. Trò chơi chỉ được thử trong môi trường cách ly đã được duyệt.

Nếu không thể giải thích chắc chắn nó làm gì, cô chọn tài liệu khác.

7. Tìm lỗi trong bản gói chạy thật

Một học sinh đưa lên ứng dụng đã rút gọn và làm rối, rồi một cái nút hỏng, mà chỉ hỏng ở bản chạy thật.

Trước hết là xem mã nguồn, cấu hình build và source map. Một bản gỡ rối của gói có vấn đề giúp chỉ ra chỗ phép biến đổi lúc đóng gói đã đổi cách chạy.

Việc sửa được làm ở mã nguồn dễ đọc và ở quy trình build, tuyệt đối không sửa thẳng vào tệp sinh ra.

8. Đánh giá nhanh một mối nguy

Người quản trị phát hiện một đoạn mã lạ bị chèn vào trang thử nghiệm. Tệp được cách ly và ghi rõ nguồn gốc.

Việc xem xét tĩnh tìm các địa chỉ đáng ngờ, dấu hiệu thu thập thông tin đăng nhập, mã được chèn vào và cách nó bám trụ trong hệ thống. Mẫu này không được chạy trên máy tính dùng hằng ngày ở trường.

Phần phân tích tiếp theo thuộc về bộ phận bảo mật, theo đúng quy trình xử lý sự cố của nhà trường.

Những kiểu viết đáng xem kỹ

Bối cảnh mới là thứ quyết định. Gặp kiểu viết như vậy thì nên tìm hiểu, chứ đừng dán ngay cái nhãn độc hại.

Đổi tên biến trong lúc phân tích

Mã bị làm rối hay dùng những tên kiểu a, b và _0x4fa2. Chỉ đổi tên một biến sau khi đã gom đủ bằng chứng về vai trò của nó.

Ví dụ:

const a = document.querySelector("#email");
const b = a.value;

Trong bản làm việc, nó có thể thành:

const emailField = document.querySelector("#email");
const emailValue = emailField.value;

Tên phải mô tả đúng cái đã kiểm chứng được. Đừng vội đặt kiểu stolenPassword khi bằng chứng chưa cho phép kết luận như vậy.

Chú thích cho bản phân tích

Hãy viết chú thích tách bạch giữa điều quan sát được và điều chỉ mới suy ra:

// Quan sát: đọc giá trị của ô email.
// Suy đoán: có thể dùng khi gửi biểu mẫu.
// Cần kiểm tra emailValue được gửi đi đâu trước khi kết luận mục đích.

Cách viết này giữ cho những chỗ chưa chắc luôn hiện rõ, và ngăn một phỏng đoán bị nhắc lại như thể đã là sự thật.

Công cụ giải quyết những vấn đề nào

• Một tệp JavaScript hợp lệ vẫn khó hiểu dù đã định dạng.
• Bài tập nhóm chỉ còn lại đúng bản gói đã biến đổi.
• Giờ học cần so sánh mã dễ đọc với mã bị làm rối.
• Một tiện ích của bên ngoài cần được soi trước khi dùng.
• Trang thử nghiệm có một lần chuyển hướng không rõ lý do.
• Mảng chuỗi mã hóa đang giấu các giá trị cấu hình.
• Lỗi chỉ xuất hiện ở bản chạy thật có thể đến từ quá trình build.
• Một đoạn mã lạ cần được đánh giá mà không chạy.

Những lỗi thường gặp khi gỡ rối

Chạy đoạn mã trước đã

Mã lạ có thể sửa trang, liên hệ dịch vụ bên ngoài, thu thập thông tin hoặc tải nội dung về. Hãy bắt đầu bằng việc xem xét mà không chạy.

Tưởng kết quả là an toàn

Một đoạn mã dễ đọc hơn vẫn làm đúng những việc nguy hiểm như bản gốc.

Trông đợi đúng mã nguồn ban đầu

Chú thích, tên gọi, mô-đun và kiểu dữ liệu đã bị xóa thì gần như không lấy lại được.

Đưa mã nội bộ lên công cụ trực tuyến

Phần nghiệp vụ, token, hệ thống của trường và dữ liệu học sinh không được gửi đi khi chưa có phép.

Phân tích mã khi chưa được phép

Mã đọc được không có nghĩa là hết ràng buộc về pháp lý, hợp đồng hay đạo đức. Chỉ phân tích thứ bạn được phép.

Đổi tên quá sớm

Một cái tên sai sẽ làm lệch cả phần điều tra còn lại. Hãy lần theo đường đi của dữ liệu trước khi gán ý nghĩa.

Sửa thẳng vào bản gói sinh ra

Sửa xong thì lần build sau là mất. Khi còn mã nguồn dễ đọc và cấu hình build, hãy sửa ở đó.

Bỏ qua source map

Source map có thể nối bản chạy thật với các tệp gốc. Hãy xem có bản đồ nào được phép dùng không, trước khi ngồi dựng lại bằng tay.

An toàn và quyền riêng tư

JavaScript có thể chứa địa chỉ, mã định danh API, token, chú thích nội bộ, tài khoản thử và dữ liệu người dùng. Việc gỡ rối chỉ phơi ra những giá trị vốn đã nằm sẵn ở đó: khó đọc, nhưng chưa bao giờ thật sự bí mật.

Đừng dán thông tin đăng nhập của hệ thống thật, mã nội bộ của trường, hồ sơ học sinh hay đoạn mã riêng của bên thứ ba vào một dịch vụ trực tuyến.

Nếu phát hiện đoạn mã có thể độc hại:

• Ngắt nó khỏi trang đang hoạt động.
• Giữ bản gốc ở nơi an toàn.
• Ghi lại tìm thấy nó ở đâu và khi nào.
• Đừng chạy nó trên máy dùng hằng ngày.
• Báo cho người quản trị phụ trách.
• Làm theo quy trình xử lý sự cố của nhà trường.

Câu hỏi thường gặp

Danh sách kiểm tra cuối cùng

• Đã xác nhận có quyền xem xét đoạn mã.
• Tệp gốc đã được giữ nguyên.
• Không chạy bừa bất kỳ đoạn mã lạ nào.
• Đã xem bản đã định dạng trước.
• Kết quả gỡ rối được lưu riêng.
• Đã tìm ra điểm bắt đầu chạy, đầu vào, đầu ra và tác động phụ.
• Các địa chỉ mạng đã được ghi lại.
• Phần chạy mã tại chỗ đã được soi thêm.
• Điều quan sát được tách bạch với điều phỏng đoán.
• Không gửi đi mã nội bộ hay dữ liệu học sinh nào.
• Các mẫu có thể độc hại đã được chuyển đi đúng cách.

Công cụ liên quan

Dùng Trình Định Dạng JavaScript khi vấn đề chỉ là mã bị nén. Còn Trình Rút Gọn JavaScript thì chỉ dùng để tạo bản chạy thật từ mã nguồn dễ đọc và đã kiểm thử.

Dùng Trình Định Dạng HTML và Trình Định Dạng CSS để xem cấu trúc và phần trình bày của trang.

Khi đã chắc một chuỗi vô hại là Base64, hãy dùng Công Cụ Giải Mã Base64 và coi kết quả như dữ liệu chưa đáng tin.

Đôi lời khép lại

Trình gỡ rối mã JavaScript giúp ích cho việc bảo trì hợp lệ, học trên lớp, gỡ lỗi, soi mã của bên thứ ba và điều tra phòng vệ. Nó làm một đoạn mã khó nhằn dễ tiếp cận hơn nhiều, nhưng không dựng lại được những gì đã bị bỏ đi.

Hãy bắt đầu từ sự cho phép và việc xem xét không chạy mã. Giữ bản gốc, định dạng rồi gỡ rối trên bản sao, ghi lại bằng chứng, và đừng chạy đoạn mã lạ trên máy tính dùng hằng ngày.

Mục tiêu không phải là làm cho mã trông gọn gàng hơn, mà là hiểu đoạn mã ấy đọc gì, sửa gì, gửi đi đâu, lưu lại gì và tải về những gì — trong khi vẫn giữ an toàn cho người dùng, hệ thống và thông tin riêng tư.