Re: Looking for disassembler, decompiler, discompiler or whatever.

"MickaŽl Pointier" <mpointie@eden-studios.fr>
11 Sep 2001 23:12:39 -0400

          From comp.compilers

Related articles
Looking for disassembler, decompiler, discompiler or whatever. zuyihe@163.net (2001-09-03)
Re: Looking for disassembler, decompiler, discompiler or whatever. andyjnsn@ma.ultranet.com (2001-09-05)
Re: Looking for disassembler, decompiler, discompiler or whatever. vbdis@aol.com (2001-09-05)
Re: Looking for disassembler, decompiler, discompiler or whatever. zuyihe@163.net (2001-09-11)
Re: Looking for disassembler, decompiler, discompiler or whatever. mpointie@eden-studios.fr (MickaŽl Pointier) (2001-09-11)
Re: Looking for disassembler, decompiler, discompiler or whatever. joachim_d@gmx.de (Joachim Durchholz) (2001-09-11)
Re: Looking for disassembler, decompiler, discompiler or whatever. mpointie@eden-studios.fr (MickaŽl Pointier) (2001-09-11)
Re: Looking for disassembler, decompiler, discompiler or whatever. debray@CS.Arizona.EDU (2001-09-11)
Re: Looking for disassembler, decompiler, discompiler or whatever. eanders@argus.EECS.Berkeley.EDU (2001-09-11)
| List of all articles for this month |

From: "MickaŽl Pointier" <mpointie@eden-studios.fr>
Newsgroups: comp.compilers
Date: 11 Sep 2001 23:12:39 -0400
Organization: ImagiNET / Colt Internet
References: 01-09-011 01-09-021 01-09-029
Keywords: disassemble
Posted-Date: 11 Sep 2001 23:12:39 EDT

> My advisor wants me to modify an executable by inserting several
> instructions (to the text section). You are only given
> executable. Jesus, what can I do? Does it sound a reasonable task?
> Man, it could be a Ph.D. thesis. Any idea to hack this bullshit?
> Thanks.
>
> The platform is Linux on PowerPC or Solaris on Sun.
> [This is what's known as binary patching. Back in the Heroic Era of
> the 1950s and 1960s, any programmer could squint at a compiled program
> and patch in a few instructions, sticking in a few jumps if need be
> if there wasn't room. It's not THAT hard. -John]


I agree with that, it's not that hard.


First, you need to find a complete description of the binary
executable format. There are various format around, and I have no idea
on how it's in the unix world. Anyway you generaly have the TEXT, DATA
and BSS section, and eventually some relocation information. If your
format has relocation info, it's pretty easy to do the patching since
you know the adress of each adress reference into the program. In
this case all you have to do is to compute the size of your
"extension", and then "extend" the size of the TEXT section. You put
your code in the room you just manage to do between TEXT and DATA
section, and you use the relocation data to patch all the adresses
that refer to DATA and BSS locations (by the same amount you increase
the size of TEXT section).


Anyway, you can run into trouble with the short adressing modes. Some
processors have only long adressing mode, so in that case that's easy.
But if your executable is for a processor that support
short/average/long adressing mode, you risk to be obliged to change a
short access adress by a long one, and it became very annoying because
then you have to patch the instruction itself, and shift all the code
behind (because the adress field of the instruction is now longer than
originally), meaning that all other adresses into the code have to be
recomputed :))


Another way, is to consider that hand made assembly code can often be
made more compact than the code produced by a compiler. So you can try
to "recode" some non critical part of the executable to gain enough
room to insert your own code. This way the modification is only
local...


Another alternative, is to do what virii are doing. Instead of putting
the code into the text section, you can try to add it at the end of
the executable file, behind the data section. Then, you can add a
"jump" instruction at the begining of the program into your code. In
your code you start by allocating some memory (it could be into the
stack if it accept executable code), copy your code into this memory,
erase it to restore the integrity of the BSS section and patch the
code to jump into your own code (and eventually get back to the
original code). Of course it can fail if you cannot execute code into
allocated buffers on your operating system :)))


        Mickael Pointier


PS: I hope it was understandable...


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.