Raedwulf, I don't remember anything of this anymore, perhaps my code was just to verify that get_dword_value doesn't corrupts anything?

Umm but you did say

So it does suggest that that was the fix .

I actually might just use the Elf from scratch method and wait for Tomasz to get round to making a nicer format specification. I finally got round to testing the fasm code and it work with my new patched version but when I tried to convert the libc version of FASM, the program would just not run ^^ .

Disadvantage of people that doesn't speak English natively

I was wondering if this is good idea after all. On Windows it is OK to import DLLs directly without linker, but on Linux, when you link to a shared library using linker, sometimes you also add some extra code to your executable (for example linking against C library).

So, skipping the linker will be reliable or we gonna just abuse of the fact that the current implementation of a certain library can work anyway?

You have a point there... I don't know for sure but I think its pretty portable provided that the *.so name is the same and all the supported symbols are present.

So basically if the *.so is not present by that name you will have to reassemble. However if you use C/C++ you will also have to relink/recompile. So I don't think there's too much of a difference.

saya dari Malaysia . Negeri Sabah. Saya pasti awak pernah dengar mengenainya sebab Sabah sangat dekat dengan Brunei.

In Windows, linker also add codes to our executable.. otherwise we cannot get those arguments to main.. the same thing goes for linux.. the extra codes are there to support all the C stuff.

the problem here is when building a dll (dynamically shared object) in linux, because afaik every linker available use section header to get info from our object, but the dynamic linker don't need it. perhaps somebody can hack gnu linker here?

<Ok removed personal stuff into PM>

Maybe add the normal section info -> because I'm guessing we're skipping all the sections using this method?