.text:00404B5A mov eax, [ebp+var_C]
.text:00404B5D imul eax, 3
.text:00404B60 mov ecx, [ebp+cursor_file]
.text:00404B63 mov dl, [ecx+eax]
.text:00404B66 mov byte ptr [ebp+var_1C], dl
.text:00404B69 mov eax, [ebp+var_C]
.text:00404B6C imul eax, 3
.text:00404B6F mov ecx, [ebp+cursor_file]
.text:00404B72 mov dl, [ecx+eax+1]
.text:00404B76 mov byte ptr [ebp+var_1C+1], dl
.text:00404B79 mov eax, [ebp+var_C]
.text:00404B7C imul eax, 3
.text:00404B7F mov ecx, [ebp+cursor_file]
.text:00404B82 mov dl, [ecx+eax+1]
.text:00404B86 mov byte ptr [ebp+var_1C+2], dl
Can it be true? It accidentally uses the green channel twice instead of the blue one. In something as important as the cursor handling it seems unlikely that it would go unnoticed. But then, this is in a fairly obscure part and wouldn't affect all colours in the cursor. Interesting.
3 comments:
Don't jump to conclusions.
Look closer at the method, especially at loc_404B9B and how data field dword_421344 is used -- from a quick glance I'd say the cursor resource seems to be loaded twice (once "correctly" and once the way you described) and both results are afterwars mixed together.
(Might be wrong, I haven't studied the code in detail ...)
I'm not jumping to anything, I appreciate your caution :-)
I also haven't studied the code in detail (yet). I thoroughly hope it is doing something very intricate and cunning with this piece of code: I'll certainly post here when I find out one way or the other!
Well, my experience tells me that whenever I thought to have found a bug or silly stuff in other programs, the error was usually on my part. ;-)
I'm sure it does something profound:
There seem to be some global variables included in the decisions -- do you happen to know what they are used for?
Post a Comment