3

I see a lot of in and out instruction in IDA. I know what those are supposed to do, but I do not know how to treat them and I'm making no advancements in understanding the code.

Short example: First instructions of my current assignment are:

seg000:00000000                 mov     edx, 61666A1Fh
seg000:00000005                 fincstp
seg000:00000007                 fnstenv byte ptr [esp-0Ch]
seg000:0000000B                 pop     esi             ; EIP
seg000:0000000C                 sub     ecx, ecx
seg000:0000000E                 mov     cl, 33h ; '3'
seg000:00000010                 xor     [esi+12h], edx
seg000:00000013                 add     edx, [esi+12h]  ; 
seg000:00000016                 xor     ecx, 0FFFFFF96h
seg000:00000019                 test    [ecx+esi*8+957C08Fh], dl
seg000:00000020                 push    eax             ; ??????
seg000:00000021                 mov     bl, 0DEh ; '¦'
seg000:00000023                 in      al, dx
seg000:00000024                 popa
seg000:00000025                 loope   near ptr 0FFFFFFACh

I'm a bit lost at 05h-0Bh as it's the first time I encounter FPU instructions, but I think that ESI should point to the where EIP is pointing to.

My main question is regarding 23h.

in al, dx

Should load a in AL a byte from port 6A1Fh? Is this relevant in any way or is code like this supposed to make my work harder or hide something? Maybe it's encrypted and at some point some decrypting algorithm will kick in. Or maybe that shouldn't be viewed as code?

Improve this question
4
  • Are you sure this is (32-bit) code? It seems a bit random to me -- as if disassembling data or 16-bit code. Can you add the actual opcode bytes in your listing, for verification?
    – Jongware
    Commented Jul 22, 2014 at 13:42
  • 1
    Could you post the binary itself somewhere so we can have a look at it?
    – Dmitry Janushkevich
    Commented Jul 22, 2014 at 13:54
  • This is what you are looking for? .686p .mmx .model flat seg000 segment byte public 'CODE' use32 Also, that's not CS it's EIP
    – user3002428
    Commented Jul 22, 2014 at 13:54
  • 99% sure this isn't code. If your .686p .mmx .model flat seg000 segment byte public 'CODE' use32 was generated by IDA, then it's probable that ida wasn't initialized correctly when you started it - if you give an ARM object file to ida, and tell it it's 32 bit Intel code, it'll happily try to disassemble it as intel code, but generate nothing but garbage. This seems to be what has happened here. Posting the hex code, or the binary if it isn't too large, as others have suggested, might help someone recognize the format and provide further clues.
    – Guntram Blohm
    Commented Jul 22, 2014 at 15:00

1 Answer 1

Reset to default
10

This is self-modifying code. The garbage instructions that you see will be altered dynamically, this way:

seg000:00000000                 mov     edx, 61666A1Fh
seg000:00000005                 fincstp
seg000:00000007                 fnstenv byte ptr [esp-0Ch]
seg000:0000000B                 pop     esi             ; EIP

Now esi points to the location of the fincstp instruction (00000005).

seg000:0000000C                 sub     ecx, ecx
seg000:0000000E                 mov     cl, 33h ; loop counter
seg000:00000010                 xor     [esi+12h], edx
seg000:00000013                 add     edx, [esi+12h]  ;sliding key

esi+12 (00000017) is being altered, turning this:

seg000:00000016                 xor     ecx, 0FFFFFF96h
seg000:00000019                 test    [ecx+esi*8+957C08Fh], dl

in to this:

seg000:00000016                 sub     esi, 0FFFFFFFCh
seg000:00000019                 loop    near ptr 00000010

i.e. esi = esi + 4, now it's 00000009 (and, then, 0x0000000d, 0x00000011, ...), and the loop continues via the value in ecx. It's a shellcode-style decryptor. More detailed descriptions of this technique can be found here and here.

Improve this answer
6
  • I was thinking that EIP will point to 07h. Question: if esi+12 is 17h why is the modified code starting at 16h? I suppose that if I want to manually discover what XORing the instructions at 17h with 61666A1Fh does I should do the XORing myself and then see what are the new instructions. Those links are not working.
    – user3002428
    Commented Jul 22, 2014 at 16:30
  • The byte at 16h isn't being altered, it just happens to have the same opcode (0x83). It's the parameters to it that are being altered. I've fixed the links.
    – peter ferrie
    Commented Jul 22, 2014 at 17:14
  • Thanks :) Are there any tools that can make decrypting easier for me or the best way is to try to recreate the decryption loop in a C program (or python script) ?
    – user3002428
    Commented Jul 22, 2014 at 17:54
  • 2
    Stepping through the code in a debugger will allow you to more easily decrypt it. If you can't load the given file directly into a debugger, you can copy the machine code and paste it into a file that can be loaded into a debugger, then set EIP to the beginning of the pasted code.
    – Jason Geffner
    Commented Jul 22, 2014 at 18:24
  • as far as why EIP points to 05h and not 07h, it's because the FPU remembers the exact location of the FPU instruction, in case an exception occurs (for resuming execution if the problem can be fixed by the exception handler).
    – peter ferrie
    Commented Jul 22, 2014 at 18:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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