I have the following data:

.data:004305FC word_4305FC     dw 1583h                
.data:004305FE word_4305FE     dw 35B6h                
.data:00430600                 dw 6835h
.data:00430602                 dw 6553h
.data:00430604                 dw 6351h
.data:00430606                 dw 23F5h
.data:00430608                 dw 6845h
.data:0043060A                 dw 6344h
.data:0043060C                 dw 6823h
.data:0043060E                 dw 2342h
.data:00430610                 dw 2474h

In addition, I have the following disassembly of the code accessing the data:

mov     eax, [ebp+Variable_1]
xor     ecx, ecx
mov     cx, word_4305FE[eax*2]
mov     eax, [ebp+Variable_1]
xor     edx, edx
mov     dx, word_4305FC[eax*2]

It looks like array within another array. Am I correct? If not, what do you think the data structure is? If it is a single array, why is it been accessed through 2 different "heads" word_4305fc and word_4305FE?

Thank you.


The following is in response to the comments below. Thank you, guys, so much for your input! I really do appreciate it and RE community in general. I feel as if my question needs certain clarification. I do realize that this is an array. I also clearly see that Variable_1 is an index to the array. In addition, I can see iteration. However, it is not my question. What I am really looking for is clarification or possibly an explanation. How would I be able to distinguish if this array is indeed more complex data type? Why did compiler choose to refer to this data type with 2 different angles: using 2 global variables both word_4305fc and word_4305FE? Is there a specific reason for it? Is it an indication of more complex data type?

  • 1
    It's an array of words starting at 0x4305FC, that code is accessing its members at indices [Variable_1 + 1] and [Variable_1] respectively. – DCoder Jun 11 '13 at 18:32
  • I agree with the above comment. Moreover it looks like a part of an iteration loop. – dna Jun 11 '13 at 19:27
  • To amend my previous comment, it's not a "more complex data type" because changing the value of Variable_1 changes the accessed offset by 2 bytes, and the exactly same amount of bytes gets read from that offset. In a more complex data type, the members of the array would be larger. – DCoder Jun 12 '13 at 4:23

As Dcoder indicated, an array of short data types begins at the lower address, and the increment of the base of the array by 2 corresponds to adding 1 to the index. Consider the following C code:

short array[256];

// ...
cx = array[variable_1+1];
// ...

// ...
dx = array[variable_1];
// ...

Consider the choices that the compiler has in compiling these snippets of code. It could produce code like this:

mov eax, [ebp+Variable_1]
xor ecx, ecx
mov cx, word_4305FC[eax*2+2] ; note the +2 and the -FC address

Or maybe:

mov eax, [ebp+Variable_1]
inc eax ; note this
xor ecx, ecx
mov cx, word_4305FC[eax*2] ; note the -FC address

Or, in the case of what you posted, this is an equivalent code sequence:

mov eax, [ebp+Variable_1]
xor ecx, ecx
mov cx, word_4305FE[eax*2] ; note the -FE address

What the compiler did was to eliminate the "+2" in the address displacement, or the "inc eax" in the index computation, and replaced it by adding 1*sizeof(short) to the address of the array. This allows for a more optimized computation that does not have any increments taking place at runtime.

  • And elimination of +2 by the compiler made IDA present it as 2 variables, didn't it? – PSS Jun 11 '13 at 22:24
  • IDA represented it as two variables because as far as IDA was concerned, it IS two variables, since it's accessed from two different locations. If you want to alter that, you can go to the earlier address and use the alt-numpad* key combination to create a single array at that location. – Rolf Rolles Jun 11 '13 at 22:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.