Opening 0x07/0x08 "unbreakable" in radare2

[pitust]

trafficstars

How? I modified it to hang for a second at the end, so i have time to quickly ^Z it away, and:

sudo gdb
attach <process>

That got gdb attached (with debug symbols & everything) Then, i used vmmap to get its mappings and found that the layout is something like this:

<asdf+0> (one page)
nothing (one page)
<asdf+0> (one page)
<asdf+0x1000> (one page)

So i used nasm to get an object that looks ok similar:

incbin "asdf"
resb 1024
incbin "asdf"
incbin "asdf"

And ran: nasm embed.s -felf64 -o asdf-fake.o To my surpries, asdf-fake.o was good enough for radare and i was able to open it. But there were no symbols (they were left alone in the cold with gdb). After analyzing it i did s <TAB> <TAB> and found some functions radare2 found:

[0x08000180]> s 
rax                 rbx                 rcx                 rdx                 rsi                 rdi                 r8                  
r9                  r10                 r11                 r12                 r13                 r14                 r15                 
rflags              rbp                 rsp                 section.            segment.ehdr        section..text       sym..text           
rip                 fcn.08000718        fcn.08000740        fcn.08000750        fcn.08000760        fcn.08000770        fcn.08000780        
fcn.080007c0        fcn.08000861        fcn.08000890        fcn.0800089a        fcn.08002c08        fcn.08002c30        fcn.08002c40        
fcn.08002c50        fcn.08002c60        fcn.08002c70        fcn.08002cb0        fcn.08002d51        fcn.08002d80        fcn.08002d8a        
fcn.08004cf8        fcn.08004d20        fcn.08004d30        fcn.08004d40        fcn.08004d50        fcn.08004d60        fcn.08004da0        
fcn.08004e41        fcn.08004e70        fcn.08004e7a        section..shstrtab   section..symtab     section..strtab  

So i had a look at the first function, fcn.08000718. It was a small leaf function which looked very much like PLT handler. It had a code XREF from fcn.0800089a What is that? main. So that wasn't too hard...

[pitust]

(i know this wasn't unbreakable)

[pitust]

And gdb attach isn't even required. You can just use objdump and manually add symbols i guess.

[pitust]

(which gives you symbols too)

[pitust]

(except objdump sometimes fails...)

[pitust]

(looking at what it says, it claims that there is 648588715588852480 program headers... unless i screwed up ELF parsing.)

[pitust]

of course. Linux doesn't care about that. it uses sections not program headers...

[pitust]

Oh i screwed up endianness... So i used big-endian for x86-64 which is little endian.. going back to parsing it

[pitust]

And entry point is at: 0x4004d0

[pitust]

I parsed out section headers... there is one useful and a ton of (fuzzed in?) garbage.

[pitust]

or maybe not fuzzed in. i screwed up elf parsing again (ELFs are hard, ok?)

[pitust]

It claims there are 9 headers:

Program headers (9 of them)
 Section header #0
  Type: 6(PT_PHDR)
 Section header #1
  Type: 3(PT_INTERP)
 Section header #2
  Type: 1(PT_LOAD)
 Section header #3
  Type: 1(PT_LOAD)
 Section header #4
  Type: 2(PT_DYNAMIC)
 Section header #5
  Type: 4(PT_NOTE)
 Section header #6
  Type: 1685382480(undefined)
 Section header #7
  Type: 1685382481(undefined)
 Section header #8
  Type: 1685382482(undefined)

I looked at the original and it seems to be the same. These 3 super-high section types are withing the "OS Specific" range. So maybe some linux specific stuff?

[pitust]

here is the elf header: [i cut it out after realizing i screwed it up]

[pitust]

(i am writing tools to do this so i can do this in superior typescript)

[pitust]

BUT it has nice types (it took me ages to get it to work)

[LiveOverflow]

I appreciate the shared investigation and experiments for people to discover here. But please don't write single sentence responses. This is not a chat 😅

[pitust]

Okay, so as it turns out this only works in older versions of radare, my radare that i got off master few days ago reads it fine. But my (older) gdb as well as all of binutils+llvm-binutils don't like it. The error is even more apparent when you try to llvm-objcopy it:

$ llvm-objcopy ./license_2_fuzz ./license_2_fuzz 
llvm-objcopy: error: invalid sh_type for string table section [index 27]: expected SHT_STRTAB, but got SHT_NULL