Re: Patchless modification of Lua source code

[Sean Conner <sean@...>]

It was thus said that the Great Viacheslav Usov once stated:
> On Sat, Nov 24, 2018 at 11:23 PM Sean Conner <sean@conman.org> wrote:
> 
> >  No, the output I saw under Linux was consistent with Solaris, NOT
> Windows.
> 
> Since you did not say that in the original message that had only the output
> on Solaris, I could not not assume that.

  I did say that.   Twice.  Granted, they were in parentheticals but they
are there.  And the reason I reported the Solaris results is that you
explicitely called out the GNU tools as a possible reason, and I wanted to
get a counter to that.

  I could have probably been clearer on that point though.

> Instead, I relied on the message from Philippe Verdy which had this output:
> 
> Hello from main
>     Hello from func1
>         Hello from func2 (sic!)
>     Back to func1
> Back to main
>     Hello from myfun2 (sic!)
> Back to main
> 
> His message did not say that it was done on Linux, that was my guess. And
> it did not show the command line options he used to get the result, nor did
> it specify the details of the toolchain.
>
> ELF shared libraries allow for symbol interposition, so that a shared
> library may end up calling a function defined elsewhere even if it is also
> defined in the shared library. This is I think what your results
> demonstrate. However, that is both inefficient and questionable from the
> security standpoint so there are ways controlled by a bunch of different
> options to suppress this behaviour. Even default behaviour in this respect
> may have changed over the years and tool versions, so it is not completely
> surprising that you and Philippe got different results.
> 
> On the other hand, I do not think such behaviour is available with PE DLLs.

  Ivan Krylov did the experiment under Windows (gave the commands, etc).  He
was able to replicate my results with static compilation (with separate
translation units in the library), but the DLL version behaved differently
than Solaris/Linux.

> I am not sure about MacOS.

  I am not sure either.

> I'd say all this demonstrates "undefined behaviour" quite convincingly.

  True.  But I did find this, written by Microsoft, about the Microsoft LINK
program (about statically linking):

	For example, imagine that a C programmer has written two versions of
	a function named _myfunc()_ that is called by the program MYPROG.C. 
	One version of _myfunc()_ is for debugging; its object module is
	found in MYFUNC.OBJ.  The other is a production version whose object
	module resides in MYLIB.LIB.  Under normal circumstances, the
	programmer links the production version of _myfunc()_ by using
	MYLIB.LIB.  To use the debugging version of _myfunc()_, the
	programmer explicitly includes its object module (MYFUNC.OBJ) when
	LINK is executed.  This causes LINK to build the debugging version
	of _myfunc()_ into the executable file because it encounters the
	debugging version in MYFUNC.OBJ before it finds the other version in
	MYLIB.LIB.

	To exploit the order in which LINK resolves external references, it
	is important to know LINK's library search strategy: Each individual
	library is search repeatedly (from first library to last, in the
	sequence in which they are input to LINK) until no further external
	references can be resolved.

					_The MS-DOS Encyclopedia_

  Given Microsoft's history of backwards compatability, I'm sure this is
still true to this day.

  -spc