Tại nhà tuyển dụng trước đây của chúng tôi, chúng tôi đã sử dụng một thành phần của bên thứ ba về cơ bản chỉ là một tệp DLL và một tệp tiêu đề. Đó là mô-đun cụ thể xử lý in ấn trong Win32. Tuy nhiên, công ty làm thành phần bị phá sản nên tôi không thể báo cáo lỗi mà tôi đã tìm thấy.Bí quyết gỡ lỗi yêu thích của bạn là gì?
Vì vậy, tôi đã tự quyết định khắc phục lỗi và khởi chạy trình gỡ rối. Tôi rất ngạc nhiên khi tìm thấy mã chống gỡ lỗi hầu như ở khắp mọi nơi, như thường lệ IsDebuggerPresent, nhưng điều đó làm tôi chú ý là thế này:
; some twiddling with xor
; and data, result in eax
jmp eax
mov eax, 0x310fac09
; rest of code here
Tại cái nhìn đầu tiên tôi chỉ bước qua thói quen đó được gọi hai lần, sau đó mọi thứ vừa đi chuối. Sau một thời gian, tôi nhận ra rằng kết quả twiddling bit luôn giống nhau, tức là jmp eax luôn nhảy ngay vào hướng dẫn mov eax, 0x310fac09. Tôi đã giải mã các byte và ở đó, 0f31, lệnh rdtsc được sử dụng để đo thời gian giữa một số cuộc gọi trong DLL.
Vì vậy, câu hỏi của tôi đối với SO là: Bí quyết gỡ lỗi yêu thích của bạn là gì?
Đó là ý kiến của tôi rằng tôi thực sự không muốn mã chạy trên hệ thống của tôi đã có mọi thứ được thực hiện để ngăn chặn gỡ lỗi. Nó cho thấy rằng tác giả của mã không thể tin cậy được. – bruceatk
Tôi đồng ý với bruceatk, đặc biệt là đối với các tệp DLL và các thành phần khác mà tôi sử dụng để xây dựng ứng dụng của mình. Tôi ít quan tâm đến các ứng dụng đầy đủ mà tôi sử dụng. Tôi không ngạc nhiên khi công ty bị phá sản :) - họ sẽ dành thời gian sản xuất mã tốt hơn là bảo vệ nó. – Michael
@bruceatk để bạn không chạy Windows? Bản thân hệ điều hành chứa một số thủ thuật chống gỡ lỗi để giúp ẩn một số cơ chế bảo vệ thú vị hơn của nó. – mrduclaw