Author Topic: UASM 2.37 Release  (Read 215 times)

johnsa

  • Member
  • ***
  • Posts: 438
    • Uasm
UASM 2.37 Release
« on: June 20, 2017, 10:47:48 PM »
1) Listing generation bug fixed (as per other thread with a binary 0 being left in the text output).

2) New 32bit code-generation features (implict DS segment override support and assumed size from register):

Code: [Select]

; OLD Style that worked with jwasm/uasm etc up to 2.36.
mov ds:[0C2100Dh],eax
mov ds:[0C2100Dh],ax
mov ds:[0C2100Dh],al
add ds:[0x1234],ax
add ds:[0x12341f25],eax
mov eax,ds:[0C2100Dh]
mov ax ,ds:[0C2100Dh]
mov al ,ds:[0C2100Dh]

; NEW Style for 2.37, implicit DS and size from register.
mov [0C2100Dh],eax
mov [0C2100Dh],ax
mov [0C2100Dh],al
add [0x1234],ax
add [0x12341f25],eax
mov eax,[0C2100Dh]
mov ax ,[0C2100Dh]
mov al ,[0C2100Dh]
imul eax,[12345]
add eax,[0x8c888880]


For 64bit code generation the new absolute immediate addressing (moffs64* from Intel Manuals) mode is now supported :
In addition fixes have been applied to allow un-sized immediate only addressing modes which jwasm/uasm through to 2.36 didn't support correctly.
So the below are now all valid options:

Code: [Select]

add eax,[0x0c888880]
imul rax,[1234]
sub eax,[0x12535]
sub rax,[0x14242054]
mov rax,[0C2100Dh]

mov rax,[SOME_ADDR]
mov rax,[10+(100*256)]

mov [0C2100Dh],rax
mov [0000788880888880h],al
mov rax,[0000788880888880h]
mov rax,7FF8807FF660h
mov eax,[00007FF6601D1010h]
mov ax,[00007FF6601D1010h]
mov al,[00007FF6601D1010h]
mov rax,[0C2100Dh]
mov eax,[0C2100Dh]
mov ax ,[0C2100Dh]
mov al ,[0C2100Dh]
mov [0C2100Dh],rax
mov [0C2100Dh],ax
mov [0C2100Dh],al
mov [0C2100Dh],rax
mov [0C2100Dh],ax
mov [0C2100Dh],al
mov [0000788880888880h],rax
mov [00007FF6601D1010h],al
mov [00007FF6601D1010h],ax
mov al ,[00007FF6601D1010h]
mov ax ,[00007FF6601D1010h]
mov eax,[00007FF6601D1010h]
mov rax,[00007FF8807FF660h]           
mov rax,7FF8807FF660h
mov qword ptr [0C2100Dh],rax
mov [0C2100Dh],eax
mov [0C2100Dh],eax
mov [00007FF6601D1010h],eax
mov QWORD PTR [00007FF8807FF660h],rax



jj2007

  • Member
  • *****
  • Posts: 7206
  • Assembler is fun ;-)
    • MasmBasic
Re: UASM 2.37 Release
« Reply #1 on: June 20, 2017, 11:07:11 PM »
As usual, works like a charm for my big sources :t

habran

  • Member
  • ****
  • Posts: 991
    • uasm
Re: UASM 2.37 Release
« Reply #2 on: June 21, 2017, 08:55:41 AM »
Just to add some more info:
For instructions MOV moffs64 only AL, AX, EAX and RAX are allowed, using other registers will cause invalid instruction operands error
and only MOV instruction is allowed, not ADD, SUB, IMUL...
so    MOV RCX,1122334455667788H  works

but   MOV RCX,[1122334455667788H] doesn't
here is a legal encoding:
Code: [Select]
    mov [00007FF6601D1010h],rax
    mov [00007FF8807FF660h],eax
    mov [00007FF8807FF660h],ax
    mov [00007FF8807FF660h],al
    mov rax,[00007FF6601D1010h]
    mov eax,[00007FF6601D1010h]
    mov ax,[00007FF6601D1010h]
    mov al,[00007FF6601D1010h]

INC and DEC are also working now but only 32 bit addresses are legal:
Code: [Select]
    inc qword ptr [0C2100Dh]
    inc dword ptr [0C2100Dh]
    inc word ptr [0C2100Dh]
    inc byte ptr [0C2100Dh]
    dec qword ptr [0C2100Dh]
    dec dword ptr [0C2100Dh]
    dec word ptr [0C2100Dh]
    dec byte ptr [0C2100Dh]
Cod-Father

LiaoMi

  • Member
  • **
  • Posts: 97
Re: UASM 2.37 Release
« Reply #3 on: July 18, 2017, 07:44:10 AM »
Holla!

Code: [Select]
.code
start:
lea rcx, [rip+6]
lea rcx, [rip-6]



Error in encoding on the EIP RIP  :(

Are there any "assembler" tables to test the whole range of possible assembler variations?  :redface: Then you can compare the addressing with masm64  ..

habran

  • Member
  • ****
  • Posts: 991
    • uasm
Re: UASM 2.37 Release
« Reply #4 on: July 18, 2017, 10:08:03 AM »
Are you kidding LiaoMi :dazzled:
ML64 doesn't know RIP ::)
However, 0x67 was already fixed in next release, now it is assembled:
Code: [Select]
    19:     lea rcx, [rip+6]
00007ff691621014 48 8D 0D 06 00 00 00             lea rcx, ptr [rip+0x6]
Cod-Father

LiaoMi

  • Member
  • **
  • Posts: 97
Re: UASM 2.37 Release
« Reply #5 on: July 18, 2017, 02:12:55 PM »
Are you kidding LiaoMi :dazzled:
ML64 doesn't know RIP ::)
However, 0x67 was already fixed in next release, now it is assembled:
Code: [Select]
    19:     lea rcx, [rip+6]
00007ff691621014 48 8D 0D 06 00 00 00             lea rcx, ptr [rip+0x6]

Thanks!

I meant for other cases  :biggrin: Of course I read about it  :icon_exclaim: Here http://www.codegurus.be/Programming/riprelativeaddressing_en.htm#Mode64

Here for example there are such tests for disassembler:
N-version Disassembly Differential Testing of x86 Disassembler.pdf http://security.di.unimi.it/~gianz/pubs/issta10-nversion.pdf
source https://github.com/hlide/differential_testing_of_x86_disassemblers

Quote
Differential Testing of x86 Disassemblers

x86 Disassemblers translate a stream of machine code into a sequence of assembly instructions which can produce completely unreliable results due to bad decoding of an instruction. This project is about the correctness of the instruction decoder, the component of disassemblers that is responsible for the decoding of machine instructions using a n-version disassembly methodology based on differential analysis which is specific for Intel x86 architecture.

Given an arbitrary string of bytes, we use multiple (n−1) disassemblers to decode the instruction potentially starting with the first byte of the string, and then we compare the output of the various disassemblers to detect discrepancies. Any discrepancy is a symptom that the instruction decoder of at least one of the tested disassemblers is buggy.

The nth instruction decoder is a CPU-assisted instruction decoder which does not perform itself the decoding, but instead delegates the duty to the perfect instruction decoder implemented in the CPU. While it does not output a disassembly code, it can infer some information about the instruction the string encodes (e.g., whether the instruction is valid, the length of the instruction, and the type of operands) to check whether the output produced by the tested disassemblers is compliant with the format of the instruction.

The output of each disassemblers is normalized to allow a comparison between them and computing a coefficient of agreement, the rationale being to be more confident in the output with the highest agreement among disassemblers.