Search code examples
arraysassemblyreverse-engineeringdisassemblyida

What is the beginning and the end of this disassembled array?

In a disassembled dll (by IDA), I reached an array, which is commented as an array of int (but it may be of byte):

.rdata:000000018003CC00 ; int boxA[264]
.rdata:000000018003CC00 boxA            dd 0                    ; DATA XREF: BlockPrepXOR+5FC↑r
.rdata:000000018003CC04                 db  0Eh
.rdata:000000018003CC05                 db  0Bh
.rdata:000000018003CC06                 db  0Dh
.rdata:000000018003CC07                 db    9
.rdata:000000018003CC08                 db  1Ch
.rdata:000000018003CC09                 db  16h
.rdata:000000018003CC0A                 db  1Ah
.rdata:000000018003CC0B                 db  12h
.rdata:000000018003CC0C                 db  12h
.rdata:000000018003CC0D                 db  1Dh
.rdata:000000018003CC0E                 db  17h
.rdata:000000018003CC0F                 db  1Bh

Can I interpret the data as

  1. {000000h, E0B0D09h, 1C161A12h, ..} or
  2. {0, 90D0B0Eh, 121A161Ch, ...} or
  3. {00h,00h,00h,00h, 0Eh, 0Bh, ..} ?

From the comment (from IDA), can you confirm that the array ends at CC00h + 253*4 = D01Fh ? I have another array starting at D020h:

.rdata:000000018003D01D                 db 0F9h ; ù
.rdata:000000018003D01E                 db 0A2h ; ¢
.rdata:000000018003D01F                 db  3Fh ; ?
.rdata:000000018003D020 array4_1248     db    1                 ; DATA XREF: BlockPrepXOR+39A↑o
.rdata:000000018003D021                 db    2
.rdata:000000018003D022                 db    4
.rdata:000000018003D023                 db    8
Solution

  • That's just the AES decryption's T8 matrix as described in this paper.
    You can easily identify it by looking for the DWORDs values on Google (e.g. this is one of the results).

    So that's just data for an AES decryption function.

    Note also that the interpretation of a sequence of bytes as a sequence of multi-byte data (WORDs, DWORDs, QWORDs, and so on) depends on the architecture.
    For x86, only the little-endian interpretation is correct (this is your case 2) but data may undergo arbitrary manipulations (e.g. it can be bswapped) so, when looking on Google, always use both the little and the big-endian versions of the data.

    It's also worth noting that IDA can interpret the bytes as DWORDs (type d twice or use the context menù), showing the correct value based on the architecture of disassembled binary.