Dealing with illegal instruction

[Just another C hacker]

Hello friends,

I'm writing a program in C with some bits in inline asm for efficiency.
I'd like to be able to handle illegal instructions from within asm.

Here's an example of a standalone asm program,

..data

..text

..globl _start
_start:

..byte 0xff
..byte 0xff
..byte 0xff

movl $1,%eax
movl $0,%ebx
int $0x80

This generates an illegal instruction but I'd like to be able to ignore
that.

Thanks.

 

[jacob navia]

Hello friends,

I'm writing a program in C with some bits in inline asm for efficiency.
I'd like to be able to handle illegal instructions from within asm.

Here's an example of a standalone asm program,

.data

.text

.globl _start
_start:

.byte 0xff
.byte 0xff
.byte 0xff

movl $1,%eax
movl $0,%ebx
int $0x80

This generates an illegal instruction but I'd like to be able to ignore
that.

Thanks.

Whan I assemble your program with lcc-win I get
Section Hex Dumps
section 00 (.text) size: 00016 file offs: 00140
[0000000] ff (bad)
[0000001] ff (bad)
[0000002] ff (bad)
[0000003] b801000000 mov $0x1,%eax
[0000008] bb00000000 mov $0x0,%ebx
[0000013] cd80 int $0x80
[0000015] 90 nop

You have 3 illegal instructions, not one.
And why you add them in the first place?

Wouldn't it be better to delete the 3
..byte ff
???????

Anyway this is quite off topic here, we deal with C.
You should go to the group

comp.lang.asm.x86

 

[Antoninus Twink]

Hello friends,

I'm writing a program in C with some bits in inline asm for efficiency.
I'd like to be able to handle illegal instructions from within asm. [snip]
This generates an illegal instruction but I'd like to be able to ignore
that.

You have 3 illegal instructions, not one.
And why you add them in the first place?

Wouldn't it be better to delete the 3
.byte ff
???????

Jacob is right that what you're asking doesn't seem to make much sense -
maybe if you explain what you're ultimately trying to achieve then that
would help.

If you just want to catch illegal instructions, then you can use the C
signal function to install a handler for SIGILL (which has numerical
value 4).

 

[Just another C hacker]

Look I don't think it's any of your business what I'm doing, either
answer the question or don't bother.

Yeah signal is ok, but it doesn't let me know which was the address of
the illegal operation that was attempted.

Hello friends,

I'm writing a program in C with some bits in inline asm for efficiency.
I'd like to be able to handle illegal instructions from within asm.

[snip]

This generates an illegal instruction but I'd like to be able to ignore
that.

You have 3 illegal instructions, not one.
And why you add them in the first place?

Wouldn't it be better to delete the 3
.byte ff
???????

Jacob is right that what you're asking doesn't seem to make much sense -
maybe if you explain what you're ultimately trying to achieve then that
would help.

If you just want to catch illegal instructions, then you can use the C
signal function to install a handler for SIGILL (which has numerical
value 4).

 

[jacob navia]

Look I don't think it's any of your business what I'm doing, either
answer the question or don't bother.

Look Mr "hacker"
You add illegal instructions and then you want to ignore it...
Fine, you want to screw some program, build some virus,
crash some stuff.

OK.

But do not expect help from me in this forum.

 

[jacob navia]

What's in it for us?

-- Richard

Well, if the virus works you will get one!



The only thing we gain here is YASV!
YET ANOTHER STUPID VIRUS!

 

[Richard Tobin]

Look I don't think it's any of your business what I'm doing, either
answer the question or don't bother.

What's in it for us?

-- Richard

 

[Antoninus Twink]

Yeah signal is ok, but it doesn't let me know which was the address of
the illegal operation that was attempted.

If you're using assembler, why not just navigate back up the call stack
to the frame before the handler was called?

 

[Richard Tobin]

Richard Tobin wrote:

Well, if the virus works you will get one!

Ah yes, that does look quite possible. If he wants help writing
viruses, my rates are double, plus indemnity.

-- Richard

 

[jacob navia]

If you're using assembler, why not just navigate back up the call stack
to the frame before the handler was called?

He needs to add 3 illegal instructions to find out the portion
of the code where the call was done. The 3 illegal instructions
are a *marker* for later reference.

This looks like a highly suspect operation. I know what he
should do (it is *obvious* if you know assembler) but I will
not tell him.

1) Anonymous post
2) Highly suspect operations
3) Secrecy paranoia ("None of your business")

I am not for flaming people here that ask legitimate questions
but this one is a virus writer, sorry.

 

[Keith Thompson]

If you just want to catch illegal instructions, then you can use the C
signal function to install a handler for SIGILL (which has numerical
value 4).

There is no reason to assume that SIGILL is 4, no benefit in doing so
(the macro exists precisely so you don't have to assume a particular
value), and no guarantee that the system will raise the signal under
any circumstances other than an explicit call to raise().

 

[Antoninus Twink]

There is no reason to assume that SIGILL is 4, no benefit in doing so
(the macro exists precisely so you don't have to assume a particular
value),

In C, it's certainly preferable to #include <signal.h> and use the
symbolic constant. However, the context was that the OP was using
assembler, so he'd have to specify the int argument to signal() as an
explicit integer pushed onto the stack before calling the function.

and no guarantee that the system will raise the signal under
any circumstances other than an explicit call to raise().

I believe POSIX guarantees the signal will be raised upon detection of
an invalid or illegal hardware instruction.

 

[Walter Roberson]

In C, it's certainly preferable to #include <signal.h> and use the
symbolic constant. However, the context was that the OP was using
assembler, so he'd have to specify the int argument to signal() as an
explicit integer pushed onto the stack before calling the function.

POSIX.1 guarantees only that the signal numbers are distinct
positive integers; their numeric values are unspecified by POSIX.1
and can vary from system to system.

I believe POSIX guarantees the signal will be raised upon detection of
an invalid or illegal hardware instruction.

"detection" is a key word here: the implementation need not be able
to "detect" the problem in a manner that can allow it to generate
a signal.

SIGILL is a "required" POSIX.1 signal, but the POSIX.1-1989 wording
is not clear as to whether that means that a compliant system -must-
raise the signal under those circumstances, or whether it just means
that SIGILL must be in its signals.h header in case kill() or raise()
specifying SIGILL get called.

POSIX.1-1989 says that the behaviour upon return from a signal handler
for SIGILL is unspecified -- e.g., there are no POSIX.1 mechanisms to say
"leave signal-handler status and pick up execution at instruction
address P."

 

[Antoninus Twink]

SIGILL is a "required" POSIX.1 signal, but the POSIX.1-1989 wording
is not clear as to whether that means that a compliant system -must-
raise the signal under those circumstances, or whether it just means
that SIGILL must be in its signals.h header in case kill() or raise()
specifying SIGILL get called.

POSIX.1-1989 says that the behaviour upon return from a signal handler
for SIGILL is unspecified -- e.g., there are no POSIX.1 mechanisms to say
"leave signal-handler status and pick up execution at instruction
address P."

I am not a language lawyer, but I think it's clear from the context (the
OP was writing asm and trying to use a specially-placed illegal
instruction as some sort of marker, for an unknown reason, possibly
nefarious) that the OP was happy to rely on system-specific behavior for
POSIX signal-handling functions.

As it happens, in this particular case every sane implementation will
produce a SIGILL for an illegal operation, and by playing with the stack
pointer it will be possible to resume from near the illegal operation.
Probably the regulars here will worry about their
strictly-POSIX-compliant Deathstations, but as so often that will be of
precisely zero help to the OP.

 

[Kenny McCormack]

There is no reason to assume that SIGILL is 4, no benefit in doing so
(the macro exists precisely so you don't have to assume a particular
value), and no guarantee that the system will raise the signal under
any circumstances other than an explicit call to raise().

Does this mean that Keith really doesn't have A.T. kf'd, after all?
Or has his notoriously well kept killfile sprung a leak?

P.S. It looks like Roberson has slipped as well.

 

[jacob navia]

I am not a language lawyer, but I think it's clear from the context (the
OP was writing asm and trying to use a specially-placed illegal
instruction as some sort of marker, for an unknown reason, possibly
nefarious) that the OP was happy to rely on system-specific behavior for
POSIX signal-handling functions.

As it happens, in this particular case every sane implementation will
produce a SIGILL for an illegal operation, and by playing with the stack
pointer it will be possible to resume from near the illegal operation.
Probably the regulars here will worry about their
strictly-POSIX-compliant Deathstations, but as so often that will be of
precisely zero help to the OP.

I think your answer was technically correct and the regulars are wrong
by trying to put forward C portability assumptions for an assembler
program (!!!!!!!)

You did the right thing. What make me more suspicious was his reaction
"none of your business"...

 

[Flash Gordon]

jacob navia wrote, On 11/04/08 19:08:

I think your answer was technically correct and the regulars are wrong
by trying to put forward C portability assumptions for an assembler
program (!!!!!!!)

Well, the OP did not specify POSIX so it could be a virus for Windows or
even a DOS virus! Maybe it is for an embedded x86 system and there is no OS!

You did the right thing.

Actually, you did the right thing on your earlier response where you
redirected the poster to comp.lang.asm.x86 and that should have been the
end of the thread.

What make me more suspicious was his reaction
"none of your business"...

Oh indeed.

 

[Bartc]

....

Please do not top-post. Your answer belongs after (or intermixed
with) the quoted material to which you reply, after snipping all
irrelevant material. See the following links:

You make it sound like Just's reply would have been been perfectly
acceptable otherwise.

Sometimes it's necessary to ask additional questions of posters and a rebuke
like the above would put some people off.

Or are your posts generated automatically so that the actual content you
reply to is irrelevant?