Home > Archive > A86 Assembler > April 2007 > Unwanted PRIVATE symbols in masm obj file
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Unwanted PRIVATE symbols in masm obj file
|
|
| spamtrap@crayne.org 2007-03-27, 6:58 pm |
| ..386
..model Flat, StdCall
option proc:private
..code
proc1 proc public ;public
ret
proc1 endp
proc2 proc private ;private
ret
proc2 endp
end
When assembled with "ML /coff /c test.asm" the output OBJ file
will contain references to both proc1 and proc2, but the proc2
should not be in ascii form mentioned in OBJ file.
The OPTION line has no effect.
The non-coff version "ML /c test.asm" will produce the correct
obj file (without references to proc2),but the non-coff format
is not suitable..(altough I don't know why, the linker will
complain about converting it to coff, but it still works, right?)
Any ideas? I've tried everything.. masm version 6.15.8803
Thanks
| |
| robertwessel2@yahoo.com 2007-03-27, 9:59 pm |
| On Mar 27, 4:18 am, spamt...@crayne.org wrote:
> .386
> .model Flat, StdCall
>
> option proc:private
>
> .code
>
> proc1 proc public ;public
> ret
> proc1 endp
>
> proc2 proc private ;private
> ret
> proc2 endp
>
> end
>
> When assembled with "ML /coff /c test.asm" the output OBJ file
> will contain references to both proc1 and proc2, but the proc2
> should not be in ascii form mentioned in OBJ file.
>
> The OPTION line has no effect.
>
> The non-coff version "ML /c test.asm" will produce the correct
> obj file (without references to proc2),but the non-coff format
> is not suitable..(altough I don't know why, the linker will
> complain about converting it to coff, but it still works, right?)
>
> Any ideas? I've tried everything.. masm version 6.15.8803
> Thanks
COFF can keep extra information, and MASM takes advantage of that. So
you see the symbol listed in the object file.
In any event, proc2 is not public, and you cannot reference it from
another module ("extern proc2:near"). IOW, you'll get an "unresolved"
error from the linker for the reference to proc2. You will, however
see it listed as a static symbol in the link map.
| |
| spamtrap@crayne.org 2007-03-29, 9:56 pm |
| Hi Robert,
This was sort of a security issue.
I needed to send an OBJ file to someone, but didn't want
him to see the names of ALL procedures, only the public ones.
The solution I came up with is:
first, assemble the file to OMF format, then give it to this BAT file:
lib %1.obj
lib /EXTRACT:%1.obj %1.lib
del %1.lib
This is, basically, OMF2COFF with the tools I have handy.
| |
| rhyde@cs.ucr.edu 2007-04-02, 6:57 pm |
| On Mar 29, 1:11 pm, spamt...@crayne.org wrote:
> Hi Robert,
>
> This was sort of a security issue.
>
> I needed to send an OBJ file to someone, but didn't want
> him to see the names of ALL procedures, only the public ones.
>
> The solution I came up with is:
>
> first, assemble the file to OMF format, then give it to this BAT file:
> lib %1.obj
> lib /EXTRACT:%1.obj %1.lib
> del %1.lib
>
> This is, basically, OMF2COFF with the tools I have handy.
Actually, MSLINK will automatically convert OMF files to COFF files
during the linking process, so you shouldn't need to do even this
(assuming you're using a reasonably recent version of the linker).
Do keep in mind, however, that if you're distributing .obj files,
security is almost a non-issue as they are *very* easy to disassemble.
If the particular name of the function is an issue, just use
conditional assembly in your source file to change the name for actual
release (e.g., use a textequ inside conditional assembly to change the
name of the procedure everywhere it appears in the program).
Cheers,
Randy Hyde
| |
|
|
|
|
|
|
|
|
|