RUN_ELF Format: RUN_ELF [GUARD] [] RUN_ELF [GUARD] PATCH Template: FILE,GUARD/S,PATCH/S,ARGS/F: Purpose: To load "big endian" ix86 ELF binaries. Specification: RUN_ELF is a small tool for Amithlon that loads and executes a "big endian" ix86 ELF binary. For more information about such binaries, please visit . There are two ways to use the RUN_ELF. If PATCH is not specified, RUN_ELF expects a ELF program (with or without arguments) as argument. RUN_ELF will load and execute the program. Another way of using RUN_ELF is to specify the PATCH switch. In this case, RUN_ELF will patch various OS functions so "big endian" ix86 ELF binaries are handled transparently. ELF programs, libraries, datatypes etc. can then be used as if they were normal Amiga HUNK binaries. In both modes of operations, the GUARD switch enables limited "Enforcer"-like memory protection. Currently, this only involves read- and write-protection of page zero (the first 4096 bytes of the address space). When in PATCH mode, this protection can be enabled by pressing CTRL-E and disabled by pressing CTRL-F. Hits will be reported by the standard KPrintF() debug function, which normally sends the output to the serial port. A tool like SUSHI can be used to redirect this output to a file or a console window. Example 1: 1> RUN_ELF hello loads and executes the big endian ix86 ELF program "hello". Example 2: 1> RUN_ELF PATCH installs the OS patches. In a second shell, it is now possible to execute "hello" as if it was a normal m68k HUNK program: 2> hello Example 3: 1> RUN_ELF PATCH GUARD installs the OS patches and activates the "Enforcer" clone. int main( void ) { *(long*) 4 = 0xabadc0de; return 0; } The code above is compiled to a normal m68k HUNK binary and executed. Without the protection, this would instantly crash the OS. In this case, however, the memory write is intercepted and reported: ILLEGAL M68K WRITE to 00000004 near 040C7F74 (TCB: 040CBBD0) SR:0000 Data: 00000000 00003FD0 FFFFFFFF FFFFFFFF FFFFFFBB FFFFFFA7 01033495 040C7E94 Addr: 040EABBC 040EABB8 03F1218C 03F121A0 041326A8 04132690 00C00C7C 04132688 Stck: 00C00C7C 00000000 03F122E8 040C7EFC 00000001 03E9B8A4 00000000 00FA06D6 00020000 040CC73C DBDBDBDB DBDBDBDB DBDBDBDB DBDBDBDB DBDBDBDB DBDBDBDB 040C7F74: 21fc abad c0de movel #-1414676258,0x4 0004 040C7F7C: 7032 moveq #50,%d0 040C7F7E: 2b40 fffc movel %d0,%fp@(-4) 040C7F82: 2c79 03f1 2204 moveal 0x3f12204,%a6 ----> 040C7F74 - "m68k-hit" Hunk 0000 Offset 000000DC Name: "Shell Process" CLI: "m68k-hit" Hunk 0000 Offset 000000DC On the first line, the address the program tried to write to is displayed. It is also reported, as accurate as possible, where the m68k instruction that cased the hit is located. Note that due to the JIT compiler, the address may not be correct. TCB is the task control block or simply the process identifier. SR is the status register. The next two lines show the content of the CPU registers. "Stck" is a stack dump, starting at the location specified by the "A7" register (16 longwords). The last four lines show an m68k disassembly of the code that triggered the hit, starting at the address specified by the "PC" register (which may not be entirely correct if Amithlon's JIT compilation is enabled). Example 4: 1> RUN_ELF PATCH GUARD installs the OS patches and activates the "Enforcer" clone. If the same program as used in example 3 is compiled to big endian ix86 code, the hit will look something like this: ILLEGAL IX86 WRITE to 00000004 at 040E6B52 (TCB: 040CBBD0) EFLAGS: 00013206 EAX EBX ECX EDX ESI EDI ESP EBP Regs: 00000001 040E6350 00000000 FFFFFFFF 041325C0 040E67C4 04132584 0413258C Stck: 00000000 00000000 D8251304 040E693D 01000000 3CFCF003 00000000 00001000 00000000 010399EF 040E690E C48E0C04 FFFFFFFF 00C00C7C 040E681A 50630E04 Stck: 00000000 00000000 041325D8 3D690E04 00000001 03F0FC3C 00000000 00100000 [BE] 00000000 EF990301 0E690E04 040C8EC4 FFFFFFFF 7C0CC000 1A680E04 040E6350 040E6B52: c7 05 04 00 00 movl $0xdec0adab,0x4 00 ab ad c0 de 040E6B5C: 83 ec 40 subl $0x40,%esp 040E6B5F: c7 44 24 04 32 movl $0x32,0x4(%esp,1) 00 00 00 040E6B67: a1 98 8c 0c 04 movl 0x40c8c98,%eax Name: "Shell Process" CLI: "ix86-hit" Again, the first line displays information about the hit. In this case, the address is always correct. The next line displays the content of the CPU registers. EFLAGS is the processor's status flags. "Stck" is a stack dump, starting at the location specified by the "ESP" register (16 longwords). Note that this is the real contents of the stack, in little endian format. The next two lines, "Stck [BE]", show the stack again, but this time byte-swapped to big endian format. The last four lines show an ix86 disassembly of the code that triggered the hit, starting at the address specified by the "EIP" register.