I decompiled one dll using Hex-Ray but it decompiled array type input argument of dll to int. Any idea how to handle this ??

double dzSell(int a1, double a2, int a3, int a4, int a5)

int a1 is array type in dll

Sadly i can not comment Marware answer so putting it here

so e.g. line like this

v9 = *(double *)(a1 + 8 * (v5 - 1));

should be changed to ???

v9 = *(double *)(a1[2] * (v5 - 1));

and int a1 to double *a1 ??

  • I am personalyl almost giving up on Hex-Rays, it is extremely buggy, right now I am having a simialr problem, except Hex-Rays insist that this double is stored in "rax", except it is a 32bit app, and nowhere in the disasm RAX (or any hack to allow that somehow in 32bit) is ever used, Hex-Rays just assumes extremely wrong. – speeder Jan 27 '16 at 3:32
  • @speeder what are you using then ? – franck Oct 17 '16 at 18:03

I'm not sure I understand the problem, but if you want to transform a1 to pointer type just pass cursor on the function prototype, press Y and edit the type of the function argument to, for example, int * or whatever pointer type you need. That's a type of the function you'll get:

double dzSell(

int* a1,

double a2, int a3, int a4, int a5)

I recall I couldn't handle this case using Hex-rays, I managed to refactor all occurrences of the pattern like: a1 + 0 is the first index - a1[0], a1 + 4 is the second - a1[1] ...and so on.

Had some trial and error to distinguish between structs and arrays and it worked.

UPDATE Can't comment. This statment meaning depends on the context, what's the value of v5?

  • v5 - 1 can be an array operation

  • But without code, int a1 in the function declaration is the return value (look at the function bottom you'll probably find a return a1;) it's a double array, and v9 is the result of *(double *)(a1[2] * (v5 - 1));

  • *(double *) : is not actually a double pointer, this cast is added by Hex-rays,(according to the above assumption) it merely means the index of the double array resulted from (a1[2] * (v5 - 1));

  • Knowing where v5 come from will be the key, but probably it's just declared and not used


here is the example how Hex-Rays decompile pointers

/* The computational routine */
extern "C" __declspec(dllexport) void myfun2 (double x, double *y, double *z, int n)
    int i;
    /* multiply each element y by x */
    for (i=0; i<n; i++) {
        z[i] = x * y[i];

int __cdecl myfun2(double a1, int a2, int a3, int a4)
  int result; // eax@3
  int i; // [sp+0h] [bp-4h]@1

  for ( i = 0; i < a4; ++i )
    *(double *)(a3 + 8 * i) = a1 * *(double *)(a2 + 8 * i);
    result = i + 1;
  return result;

so clearly pointer variables are converted to int, it means that casting double * -> int must be done as a2 and a3 are used to access the array. For proper casting i used (uintptr_t)buffer

  • According to the StackOverflow rules you need to update the question, not to insert additional answer – w s Jan 29 '16 at 5:21

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.