reversing of sunway sw64 ISA

It seems that Chinese are hiding information about their another homemade processor sw64 - try to find some technical details with google, baidu or gitee. At the same time they ported linux on this processor - and you even can find some details in openEuler project. I think this conspiracy is very funny and at least violating licenses for binutils/clang/gcc etc

Anyway lets see if we can reverse ISA for sw64 having only linux image and some source code from linux kernel (spoiler: also write processor module for ida pro)

registers

try to compare registers of sw64 with Alpha AXP - can you find any difference? at least we now know that processor has 32 general purpose registers and 32 for floating point, so fields for register encoding must be 5 bits

ELF relocs

relocs can be extracted from arch/sw_64/include/asm/elf.h. So the next thing which I wrote was small ida pro plugin to apply this relocs - nothing special, actually it was almost exactly copy of the same plugin for LoongArch

mnemonics

ida pro plugin to handle loongson elf relocs

It seems that you can't just go ahead and implement your own proc_def_t for processor module - bcs ida pro sdk don`t include needed symbols, you will just get something like

1>reg.obj : error LNK2019: unresolved external symbol "public: __cdecl proc_def_t::proc_def_t(struct elf_loader_t &,class reader_t &)" (??0proc_def_t@@QEAA@AEAUelf_loader_t@@AEAVreader_t@@@Z) referenced in function "public: virtual __int64 __cdecl xxx_t::on_event(__int64,char *)" (?on_event@xxxson_t@@UEAA_J_JPEAD@Z)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual bool __cdecl proc_def_t::proc_supports_relocs(void)const " (?proc_supports_relocs@proc_def_t@@UEBA_NXZ)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual char const * __cdecl proc_def_t::proc_handle_reloc(struct rel_data_t const &,struct sym_rel const *,struct elf_rela_t const *,struct reloc_tools_t *)" (?proc_handle_reloc@proc_def_t@@UEAAPEBDAEBUrel_data_t@@PEBUsym_rel@@PEBUelf_rela_t@@PEAUreloc_tools_t@@@Z)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual bool __cdecl proc_def_t::proc_create_got_offsets(struct Elf64_Shdr const *,struct reloc_tools_t *)" (?proc_create_got_offsets@proc_def_t@@UEAA_NPEBUElf64_Shdr@@PEAUreloc_tools_t@@@Z)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual bool __cdecl proc_def_t::proc_perform_patching(struct Elf64_Shdr const *,struct Elf64_Shdr const *)" (?proc_perform_patching@proc_def_t@@UEAA_NPEBUElf64_Shdr@@0@Z)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual bool __cdecl proc_def_t::proc_can_convert_pic_got(void)const " (?proc_can_convert_pic_got@proc_def_t@@UEBA_NXZ)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual unsigned __int64 __cdecl proc_def_t::proc_convert_pic_got(class segment_t const *,struct reloc_tools_t *)" (?proc_convert_pic_got@proc_def_t@@UEAA_KPEBVsegment_t@@PEAUreloc_tools_t@@@Z)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual char const * __cdecl proc_def_t::proc_describe_flag_bit(unsigned int *)" (?proc_describe_flag_bit@proc_def_t@@UEAAPEBDPEAI@Z)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual bool __cdecl proc_def_t::proc_load_unknown_sec(struct Elf64_Shdr *,bool)" (?proc_load_unknown_sec@proc_def_t@@UEAA_NPEAUElf64_Shdr@@_N@Z)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual char const * __cdecl proc_def_t::proc_handle_dynamic_tag(struct Elf64_Dyn const *)" (?proc_handle_dynamic_tag@proc_def_t@@UEAAPEBDPEBUElf64_Dyn@@@Z)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual bool __cdecl proc_def_t::proc_is_acceptable_image_type(unsigned short)" (?proc_is_acceptable_image_type@proc_def_t@@UEAA_NG@Z)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual void __cdecl proc_def_t::proc_on_start_data_loading(struct elf_ehdr_t &)" (?proc_on_start_data_loading@proc_def_t@@UEAAXAEAUelf_ehdr_t@@@Z)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual bool __cdecl proc_def_t::proc_on_end_data_loading(void)" (?proc_on_end_data_loading@proc_def_t@@UEAA_NXZ)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual void __cdecl proc_def_t::proc_on_loading_symbols(void)" (?proc_on_loading_symbols@proc_def_t@@UEAAXXZ)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual bool __cdecl proc_def_t::proc_handle_symbol(struct sym_rel &,char const *)" (?proc_handle_symbol@proc_def_t@@UEAA_NAEAUsym_rel@@PEBD@Z)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual void __cdecl proc_def_t::proc_handle_dynsym(struct sym_rel const &,unsigned int,char const *)" (?proc_handle_dynsym@proc_def_t@@UEAAXAEBUsym_rel@@IPEBD@Z)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual int __cdecl proc_def_t::proc_handle_special_symbol(struct sym_rel *,char const *,unsigned short)" (?proc_handle_special_symbol@proc_def_t@@UEAAHPEAUsym_rel@@PEBDG@Z)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual bool __cdecl proc_def_t::proc_should_load_section(struct Elf64_Shdr const &,unsigned int,class _qstring<char> const &)" (?proc_should_load_section@proc_def_t@@UEAA_NAEBUElf64_Shdr@@IAEBV?$_qstring@D@@@Z)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual bool __cdecl proc_def_t::proc_on_create_section(struct Elf64_Shdr const &,class _qstring<char> const &,unsigned __int64 *)" (?proc_on_create_section@proc_def_t@@UEAA_NAEBUElf64_Shdr@@AEBV?$_qstring@D@@PEA_K@Z)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual char const * __cdecl proc_def_t::calc_procname(unsigned int *,char const *)" (?calc_procname@proc_def_t@@UEAAPEBDPEAIPEBD@Z)

1>reg.obj : error LNK2001: unresolved external symbol "public: virtual unsigned __int64 __cdecl proc_def_t::proc_adjust_entry(unsigned __int64)" (?proc_adjust_entry@proc_def_t@@UEAA_K_K@Z)

1>D:\ida75\procs\xxx64.dll : fatal error LNK1120: 21 unresolved externals

So I wrote plugin to handle ELF relocs for this new fashionable chinese processor.
Source

some description of relocs can be found here

ida pro plugin for unpacking lzma compressed linux kernel

UOS linux for mips64 contains strange linux kernel which cannot be unpacked with famous extract-vmlinux
Lets see what happens:

zimage_start = (unsigned long)(&__image_begin);
zimage_size = (unsigned long)(&__image_end) -
    (unsigned long)(&__image_begin);
...
/* Decompress the kernel with according algorithm */
__decompress((char *)zimage_start, zimage_size, 0, 0,
	   (void *)VMLINUX_LOAD_ADDRESS_ULL, 0, 0, error);

The problem is that System.map does not contain symbols __image_begin & __image_end. Investigation showed that compressed body of kernel located in .data section so the only unknown parameters for unpacking are start address and size of unpacked data. Fortunately used algo lzma puts size of unpacked data as last DWORD in data. And address you can extract from System.map for symbol _text

So logic of plugin is

• get filename of input file
• make right name for System.map from it
• read this System.map
• try to find xrefs in .data section - the only two will be __image_begin & __image_end
• unpack
• add new segment (and this was most terrible part of development - ida pro failed several times with memory dumps)
• put unpacked data to newly added segment
• profit

Link to github

poorgcc: IDA Pro plugin to fix poor gcc code on arm64

Lets see what generates gcc for arm64 - for example gcc7.5 and linux kernel
Function do_sysinstr:

ADRP            X0, #__func__.48604@PAGE ; "arm64_show_signal"

ADD             X0, X0, #__func__.48604@PAGEOFF

ADRP            X3, #ctr_read_handler@PAGE

ADD             X0, X0, #0x218

ADD             X3, X3, #ctr_read_handler@PAGEOFF

Wtf happened here? Instead of loading x0 with address of sys64_hooks we have two consecutive loads and no value x0 used between. You can peek some random functions - this is very common pattern, I personally think this is bug in gcc arm64 codegen. Anyway, it does not allow to see right xrefs so I wrote simple plugin for IDA Pro to fix this

Plugin just try to find instructions "add add reg, reg, imm" without data xref and backtrack if this register was loaded somewhere above - sure code is not sample of elegance. You can add to plugins.cfg string like this

process_all_poor_gcc_functions    poorgcc64     0      1

to process all functions

Some results - after applying plugin to function do_sysinstr code looks like:

ADRP            X0, #__func__.48604@PAGE ; "arm64_show_signal"

ADD             X0, X0, #__func__.48604@PAGEOFF

ADRP            X3, #ctr_read_handler@PAGE

ADD             X0, X0, #0x218 ; FFFFFFC010C116C8

ADD             X3, X3, #ctr_read_handler@PAGEOFF

FFFFFFC010C116C8 is address of sys64_hooks and now it has right xref

IDCFuncs in ida pro 7.x

Let's assume what we want to have some normal programming language inside ida pro (not strange looking pile of spaces). Or just to made RPC interface so you can use several instances of ida from external processeses. In previous versions (since 4.x - I can be wrong) we had IDCFuncs which I used for example to embed perl. But since 7.x this symbol is no longer exported (obviously to make users' lives even more unbearable). Sure this small problem can`t stop me. So there are at least two ways to find IDCFuncs in any ida pro 7.x

signature search

strictly speaking this method allows you to find IDCFuncs->funcs. Name of first function in this array of ext_idcfunc_t always is "____" (yes, some undocumented function with name of four underscores). So you first must search for it in .text section (in ida.dll/ida64.dll) and then find address in .data - this will be first ext_idcfunc_t:

struct ext_idcfunc_t

{  const char *name;             ///< Name of function  

   idc_func_t *fptr;             ///< Pointer to the Function

   const char *args;             ///< Type of arguments. Terminated with 0.        

   const idc_value_t *defvals;   ///< Default argument values.

   int ndefvals;                 ///< Number of default values.     

   int flags;                    ///< \ref EXTFUN_

};

some disasm magic

It`s very ironic that in the disassembler you have to use another disassembler to find what you want. Lets see which exported functions use IDCFuncs

IDA Pro plugin for arm64 switch tables processing

IDA Pro supports arm64 very poorly - it also cannot parse switch tables. Let`s see how they looks on arm64 - for example in function NtQueryInformationThread:
 CMP             W1, #0x2D           ; check index
 B.HI            loc_140673294
 ADR             X9, dword_14066E9EC ; switch tab address
 LDRSW           X8, [X9,W1,UXTW#2]  ; index in W1 << 2
 ADR             X9, loc_14066E358   ; base address
 ADD             X8, X9, X8,LSL#2    ; base address + offset << 2
 BR              X8
What happens here? first "ADR x9, addr" loads address of switch table
Next LDRSW is like "mov x8, [x9 + 4 * w1]" on Intel - load DWORD at x9 + index w1 left shifted by 2
Then second ADR loads address of base for this switch table
ADD x8, x9, x8 << 2 sets in x8 address of actual jumps
and finally BR go to this address

So I just wrote quick and dirty plugin arm64sw.p64 based on armpatched for switch tables processing

bug in ida pro arm64 module

Lets see in ida pro some arm64 windows kernel, for example good old function PspSetCreateThreadNotifyRoutine:
 ADRP            X8, #PspNotifyEnableMask@PAGE
 ADD             X11, X8, #PspNotifyEnableMask@PAGEOFF
 TBNZ            W20, #0, loc_140690960
 ADD             X10, X11, #0x33C

register x11 contains address of PspNotifyEnableMask - in my case this is 0x1408AE6B0 and then x10 loading address of PspNotifyEnableMask + 0x33c = 0x1408AE9EC - this is actually PspCreateThreadNotifyRoutineCount. And no - you cannot fix last instruction with pressing O or Ctrl + O
Given that cross-refs in arm64 is highly dependent from correct code analysis - this is very annoing
Tested in ida pro 6.9 and 7.2

kernel resource FUNCTIONEXTENTLIST

I commited today plugin for processing 64bit kernel resource with name "FUNCTIONEXTENTLIST" (located in RCDATA)

It seems that processing of this resource happens in huge unnamed sub called from famous KiFilterFiberContext, so this is apparently part of PatchGuard. Format of this resource relative simple.
At start we have signature CTXE for compressed data (LTXE for noncompressed but I have never seen this). Data unpacking with RtlDecompressBufferEx function. In packed data we have table with pair offsets, first to RUNTIME_FUNCTION recognised from IDA and second to some additional RUNTIME_FUNCTION (which usually skipped in IDA Pro for unknown reason)

And even after calling this plugin there are lots of some valid RUNTIME_FUNCTION in .pdata section - I don`t know why

etwex - ida plugin for Etw traces IIDs searching

For example you may need to find which Etw providers located in some module. There are lots of functions can be used to register provider and manual searching is very boring
So I commited today code for Ida Pro plugin for Etw traces IIDs searching. It currently supports only 32bit PE files (much better if you load appropriate PDB file) and processing following functions:

• TraceLoggingRegister
• TraceLoggingRegisterEx
• WPP_INIT_GUID_ARRAY
• EtwRegister from import
• EtwEventRegister from import
• EventRegister from import

Samples of using:

ida plugin for RFG fixups processing

I commited today code for Ida Pro plugin for RFG fixups processing - for both version 1 & 2

It seems that by default during automatic loading of pe files Ida don`t load .reloc section (where usually located RFG fixups). In such case I ask if you want to add new segment:

Sure it works only if original input file (you can extract it with get_input_file_path function) is still available. Also I used dirty hack - I am too lazy to parse PE file by hand, and it seems that node "$ PE header" keeps all sections (even not loaded in base !) in supvals

enjoy

Update: it seems that buggy ida sdk don`t contains doCode function and auto_mark_range actually does not take into account end argument, so body of prologs looks ugly

ntstatus.idc for WDK 10.0.14931.0

added 95 new NTSTATUS values

ida 6.95 has been released

changelog
useful changes:

• PE: added detection of entry point from incremental linking by Visual Studio 
• FLIRT: added signatures for Windows Driver Kits 7-10
• FLIRT: added detection of GsDriverEntry for Windows Drivers 

but still no support of apisetschema in PE imports, yeah

ntstatus.idc for WDK 10

added 69 new NTSTATUS values

WdfFunctions.idc for windows 10 Technical Preview 64bit

since w8.1 only pfnWdfDeviceStopIdleActual & pfnWdfDeviceResumeIdleActual was added

ida 6.5

changelog

PC: handle code sequences which load imagebase value into a temporary register (common in x64 Windows code)

yeah, finally I don`t need to recompile my plugin wpic64 for each new ida version

added win8_um.til and wdk8_km.til for Windows8 WDK (user and kernel mode headers)

he-he. How about WdfFunctions ?

ids files for MFC 12

I uploaded archive of IDS files for both 32 & 64bit MFC 12 dll modules
This archive also contains IDT files used for building

ntstatus.idc for WDK 8.1

Add 35 new NTSTATUS values

exref.pl

a very common problem in static code analysis is finding an exported functions that refers to some desired address. For example KseEngine has 21 references in windows kernel but only 5 of these functions are exported
So I wrote simple perl script for IDA Pro to automate this boring work. Sample of output for KseEngine:
_KseQueryDeviceFlags@12: 74A6C1 addr 74A6E2
_KseQueryDeviceData@20: 74A75B addr 74A77A
_KseQueryDeviceDataList@16: 7A5E74 addr 7A5E95
_KseSetDeviceFlags@16: 7A672D addr 7A6760
_KseUnregisterShim@12: 7A692B addr 7A698B


updated perl binding for IDA Pro

I add functions for accessing cmd structure
Now you can do things like this:

#!perl -w
use strict;
use warnings;
use IDA;

my $addr = ScreenEA();
my $href = ua_ana($addr);
my $str = GetDisasm($addr);
if ( defined($href) )
{
  my $iter;
  printf("real: %s, %s:\n", $str, get_mnem);
  foreach $iter ( keys %$href )
  {
    printf("%s: %X\n", $iter, $href->{$iter});
  }
  my $op_idx;
  for ( $op_idx = 0; $op_idx < 6; $op_idx++ )
  {
    my $op = get_op($op_idx);
    last if ( !defined $op );
    printf("operand %d:\n", $op_idx);
    foreach $iter ( keys %$op )
    {
      printf(" %s ", $iter);
      print $op->{$iter} . "\n";
    }
  }
}

WdfFunctions.idc patch for w8.1 preview

Some time ago I wrote simple script for finding _WDFFUNCTIONS in KMDF based drivers. It seems that Wdf01000.sys!_WDFFUNCTIONS from windows 8.1 preview has some additional fields, so I just added their to my script: