Forum:
a haiku about disassembler trust, bfu
trust disassemblers?
or do you have trust issues
i think i do too
dis-trust
i tend to use ida, but sometimes i don't
and when i don't, i tend to double check.. in ida
what if i can't double check in ida?
today i used ghidra (nsa implant)
i think i publicly complain enough about ghidra. this is fine, whatever, it's
adequate - but ida is better. anyways, i saw something weird in ida (not actually weird) and i wanted to know why. often, i read that the register $at is restricted to the assembler, but why does it show up?
since i couldn't look in ida, i looked in ghidra... oh! that looks different.
lets compare with a screenshot from ida!
ida output:
lw $a1, arg_0($sp)
addiu $a2, $sp, arg_4
li $at, 0xfff8
and $sp, $at
addiu $sp, -0x20
la $a3, _func1
la $t0, _func2
ok but now
ghidra output:
lw $a1, $sp
addiu $a2, $sp, 0x4
li $at, -0x8
and $sp, $sp, $at
addiu $sp, $sp, -0x20
lw $a3, -0x7800($gp)
lw $t0, -0x7bb0($gp)
ok. a bit different. lets check with yaxpeax
lw a1, (sp)
addiu a2, sp, 0x4
addiu at, zero, -0x8
and sp, sp, at
addiu sp, sp, -0x20
lw a3, -0x7800(gp)
lw t0, -0x7bb0(gp)
looks like ghidra! lets investigate!
our binary is in mipsel. ghidra does the honors of giving us the hex in bigendian. thats nice for sanity purposes, but when we had to put it in yaxpeax we had to convert our hex values back to LE (p.s. does anyone know the fix? otherwise idc i don't use ghidra)
i like that yaxpeax maintains the endianness of the hex i gave it. thanks ixi :D
https://dis.yaxpeax.net/mips/0000a58f0400a627f8ff012424e8a103e0ffbd270088878f5084888f
anyways, back in BE land, lets convert the following to binary:
-> 8fa5000027a600042401fff803a1e82427bdffe08f8788008f888450
if i typed that correctly, we will get
-> 10001111101001010000000000000000
-> 00100111101001100000000000000100
-> 00100100000000011111111111111000
-> 00000011101000011110100000100100
-> 00100111101111011111111111100000
-> 10001111100001111000100000000000
-> 10001111100010001000010001010000
following this scheme:
---------------------------------------------------|
[ opcode | rs | rt | rd | shamt | funct ]-|
[ opcode | rs | rt | immediate ]-|
[ opcode | address ]-|
---------------------------------------------------|
and berkeley's greensheet: https://inst.eecs.berkeley.edu/~cs61c/resources/MIPS_Green_Sheet.pdf
lets split:
(29) (5) (0)
[ 100011 | 11101 | 00101 | 00000 00000 000000 ] lui
(29) (6) (4)
[ 001001 | 11101 | 00110 | 00000 00000 000100 ] addiu/jalr
(0) (1) (0xfff8)
[ 001001 | 00000 | 00001 | 11111 11111 111000 ] addiu/jalr
(29) (1) (29) (0) (36)
[ 000000 | 11101 | 00001 | 11101 | 00000 | 100100 ] add/and/addu
(29) (29) (0xffe0)
[ 001001 | 11101 | 11101 | 11111 11111 100000 ] addiu/jalr
(28) (7) (0x8800)
[ 100011 | 11100 | 00111 | 10001 00000 000000 ] lw
(28) (8) (0x8450)
[ 100011 | 11100 | 01000 | 10000 10001 010000 ] lw
(my number conversions for the last 2 lw might be off, they're not super important here)
ok as we can see, this looks really similar to yaxpeax and ghidra. but we
still have the $at.. i wonder why?
after being confused for a long time, i noticed out of the 3 disassemblers,
ida supports mips pseudoinstructions (blegh!)
if we look at this columbia presentation, we can find some instructions -> pseudo-instructions: http://www.cs.columbia.edu/~sedwards/classes/2011/3827-fall/mips-isa.pdf
ok. if we add the values and make it a little bit more human readable, we get something like this
lui $a1, 0x0($sp) ; ;
addiu $a2, 0x4($sp) ; ;
addiu $at, $zero, 0xfff8 ; li $at, 0xfff8 ;
and $sp, $sp, $at ; ;
addiu $sp, 0xffe0($sp) ; ;
lw $a3, 0x8800($gp) ; func ptr -> _func1 ;
lw $t0, 0x8450($gp) ; func ptr -> _func2 ;
we see in the right-side panel that you get the $li pseudoinstruction, and
the disassembly looks a little bit more like ida's
the culprit to the lack of trust: pseudoinstructions
Report Topic
