flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Main > Alignment and padding

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15319
Location: Bigweld Industries

system error wrote:
... you should not be fooled into believing that 0xCC can be handled like a breeze ...

I wasn't fooled. I written these sorts of handlers before. And I said I don't care if it takes one million cycles. Anyhow, it is not about how long it takes to execute, that is a distraction, it the fact that it immediately signals that something went wrong before anything else can errantly do any damage.

BTW: Did you know that most programs already generate thousands of exceptions in rapid succession? Whenever you hit the guard page on the stack. Whenever you allocate memory. Whenever the OS swaps your state to the pagefile. Regularly for each clock tick. Each time you move the mouse. Each time you press a key. Each time an Internet packet arrives. Each time you read/write date from/to the disk. etc. etc. etc.
Post 04 May 2017, 04:53
View user's profile Send private message Visit poster's website Reply with quote
system error



Joined: 01 Sep 2013
Posts: 673

revolution wrote:

system error wrote:
... you should not be fooled into believing that 0xCC can be handled like a breeze ...

I wasn't fooled. I written these sorts of handlers before. And I said I don't care if it takes one million cycles. Anyhow, it is not about how long it takes to execute, that is a distraction, it the fact that it immediately signals that something went wrong before anything else can errantly do any damage.

BTW: Did you know that most programs already generate thousands of exceptions in rapid succession? Whenever you hit the guard page on the stack. Whenever you allocate memory. Whenever the OS swaps your state to the pagefile. Regularly for each clock tick. Each time you move the mouse. Each time you press a key. Each time an Internet packet arrives. Each time you read/write date from/to the disk. etc. etc. etc.



Show me your or your friend's code / handler specifically designed to handle application's 0xCC padding then. Because from the sound of it, you are trying to convince me that such program is normal and too common, a.k.a tough talk.
Post 04 May 2017, 10:08
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15319
Location: Bigweld Industries
No, you missed the point. The exception is to indicate that something went wrong. We are not supposed to continue execution from that point. The app should terminate, or the OS should terminate it. That's why it makes no difference if in3 takes even a billion cycles to complete because we never intend return, ever. It should die.
Post 04 May 2017, 10:19
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 894

system error wrote:
You mean, just because someone overrun the buffer by one byte, he has to deal with this 1-byte "convenience", invoking Trap Gate, Task Gate, setting up IVT, entering etc etc?

No man. You don't have to do anything, that's the whole point.

When an illegal instruction (unprivileged, etc) is executed, the CPU signals interrupt and then the OS (Windows, or Linux in case of Wine which is what I mostly run) raises the exception. It's very simple, this happens instantly without you writing a single line of code.

If your application registers an exception callback (via the eh frame table in x64, or via pushing it in x86 SEH), then the OS will call your function here, to handle the exception. At no point do you deal with interrupt handlers, you deal with the Operating System's exception mechanism. The interrupt handlers are NOT available to usercode hijacking. You simply tell Windows "hey stupid OS, I want you to call this function when you encounter an exception, got it?". The interrupt handling is handled by the OS itself.

Handling the exception is beside the point, you don't need to handle it or even register a handler. If there's no handler, Windows will gracefully exit the app with a "crash dump" (register values when exception was raised). That is good.

It's like in movies: a fatal leak of a hazardous experimental material or whatever was found, so best thing to do is emergency seal (i.e. crash) instead of continuing.

However you can handle the exception, but you cannot if it's nop. It will silently run possibly bad code.

Handling the exception is absolutely nothing special, it's standard exception handling mechanism. Obviously, if you don't know how to do exception handling, that's a completely unrelated issue. (I mean in general, "you" = generic person, but yes I've done it). There's nothing "extra" or "special" you have to do.

If your app uses exception handling (for many other reasons), then it WILL receive the callback, so it's a matter of you doing a test for the 0xCC (you can simply inspect the instruction pointer's data and see if it's 0xCC, but first make sure it's within valid bounds so you don't trigger a page fault when "reading" it -- that's easy though, since you know the bounds of your program, you can use linker symbols or FASM etc... I'm experienced with GNU ld scripts so it's no issue for me)

Just an example of a very unorthodox use of exceptions, I've written exception handlers for things like detecting if a program is ran under Linux (via Wine or something else), by calling Linux syscalls from within a "Windows app". On Windows, this would likely generated an exception, so that's how I detect it (amongst other things like checking if return data from uname is 'Linux' and so on). Without an exception handler, the program will instantly crash on Windows, which is obviously not what I want. In this way, I can use Linux kernel syscalls along with Windows API (from Wine).

Exceptions aren't as esoteric as you think.
Post 04 May 2017, 20:08
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 673
So, it's not about how YOU handle 0xCC then, because you DO NOT KNOW how to deal with int3 yourselves. It's about the OS doing it for you in C++. To let the C++ program catch the exceptions and deal with it for your own 'safety'.

That redundant irony of the so-called 'machine' programmers.
Post 07 May 2017, 17:39
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 673

Quote:

The interrupt handlers are NOT available to usercode hijacking. You simply tell Windows "hey stupid OS, I want you to call this function when you encounter an exception, got it?". The interrupt handling is handled by the OS itself.



Tell that to debugger writers / developers.
Post 07 May 2017, 17:50
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 894
What? You can register your own callback that the OS will call, you don't have to rely on "C++". Obviously, unless the exception happens from within a C++ function, but in that case it's not your code anyway (that function I mean) unless you're the one who coded it in C++.

Btw, SEH (Windows exceptions) has nothing to do with C++ exceptions. SEH can be used from C or asm or whatever else, you just need to register your handlers or make the appropriate eh table.

Now, don't debuggers step in only when the application doesn't handle the exception? If you don't handle the exception, then why do you even care what happens after?

Or you can just handle it and call ExitProcess instantly if you really hate crash dumps so much, it's still much safer than with nop.

if you are really paranoid, just use hlt which is 0xF4 instead of 0xCC, it even makes sense. You know ALT+F4 shortcut? Now 0xF4 to crash your program! Razz

Just don't use nops.
Post 07 May 2017, 20:31
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 673

Furs wrote:
What? You can register your own callback that the OS will call, you don't have to rely on "C++". Obviously, unless the exception happens from within a C++ function, but in that case it's not your code anyway (that function I mean) unless you're the one who coded it in C++.



Well, Windows wasn't developed using Java anyway. Try to apply some common sense when discussing. Does Windows internal debugger looks like a Java product to you? Most Windows library components were written in C++/C, that includes writing the security cookies (your favorite 0xCC 'paddings' you see from the debugger output, embedded into the codes at runtime).

You people are dissapointing. I got more useful techincal information about this from C++ forum than from the so-called machine programmers.
Post 07 May 2017, 21:59
View user's profile Send private message Reply with quote
VEG



Joined: 06 Feb 2013
Posts: 70
Location: Minsk, Belarus

Quote:
Most Windows library components were written in C++/C, that includes writing the security cookies (your favorite 0xCC 'paddings' you see from the debugger output, embedded into the codes at runtime).


I've provided you examples that at least LLVM/Clang/LLD and modern Visual C++ use 0xCC for paddings between procedures in executable files. And we are speaking not about security cookies, but about padding between procedures. The same thing between a security cookie and padding between procedures is that these bytes have not to be executed. But these things are different. And 0xCC is often used for padding between procedures in the machine code of a program. And it is used for the reason. Just because it is much more better than 0x90. 0xСС has the trait which is required for bytes which have not to be executed, it prevents further execution, this is why it is a better decision and this is why compilers use it for paddings between procedures. That's it.
Post 08 May 2017, 05:05
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 894

system error wrote:
Well, Windows wasn't developed using Java anyway. Try to apply some common sense when discussing. Does Windows internal debugger looks like a Java product to you? Most Windows library components were written in C++/C, that includes writing the security cookies (your favorite 0xCC 'paddings' you see from the debugger output, embedded into the codes at runtime).

You people are dissapointing. I got more useful techincal information about this from C++ forum than from the so-called machine programmers.

I have no idea what you're talking about. Who mentioned Java?

Padding is inserted by the back-end assembler, C++ has nothing to do with it.

For example, GCC's process goes like so:

* Language parser (C++)
* GENERIC (language-independent already! all languages arrive at this form or GIMPLE directly)
* GIMPLE
* RTL
* Assembly

0xCC or nops are not present even in the assembly source at the last stage. It simply has "align" directives. It's the assembler after that which inserts nops or 0xCC depending how many it has to insert. Needless to say, the original "C++" language is long gone in this process, it's gone after the first stage!

And I wouldn't be surprised if you got shit wrong answers from a C++ forum, wouldn't be surpised if they don't even know what a byte is.
Post 08 May 2017, 11:13
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 673

VEG wrote:

Quote:
Most Windows library components were written in C++/C, that includes writing the security cookies (your favorite 0xCC 'paddings' you see from the debugger output, embedded into the codes at runtime).


I've provided you examples that at least LLVM/Clang/LLD and modern Visual C++ use 0xCC for paddings between procedures in executable files. And we are speaking not about security cookies, but about padding between procedures. The same thing between a security cookie and padding between procedures is that these bytes have not to be executed. But these things are different. And 0xCC is often used for padding between procedures in the machine code of a program. And it is used for the reason. Just because it is much more better than 0x90. 0xСС has the trait which is required for bytes which have not to be executed, it prevents further execution, this is why it is a better decision and this is why compilers use it for paddings between procedures. That's it.



You still don't get it. It's calculated and inserted at runtime., They're not always end / start at natural boundaries. Some landed at the odd addresses, some in the middle. What kind of padding that stops at the odd addresses for example byte 5 and 9?

Secondly what you're suggesting is MS or Windows own internal affairs which has close support by their own internal debugger and kernel resources to handle such exceptions. It has nothing to do with your code even if you'd like to think so. There's no VC++ direct support of INT3 statement or instructions ever suggested by MS to peasant programmers like you and me.

You feel comfortable and confident using 0XCC padding on Windows because your version of O.S has internal debugger support / installed. Not every OS / versions supports such idea.

The principle is simpe: Software faults must be handled by software means. Invoking int3 is an overkill. This semantics is handled beautifully by C++ and Java via that try...catch exception handlers as an example. I believe ASM programmers can do the same.
Post 08 May 2017, 11:33
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 673

Furs wrote:

system error wrote:
Well, Windows wasn't developed using Java anyway. Try to apply some common sense when discussing. Does Windows internal debugger looks like a Java product to you? Most Windows library components were written in C++/C, that includes writing the security cookies (your favorite 0xCC 'paddings' you see from the debugger output, embedded into the codes at runtime).

You people are dissapointing. I got more useful techincal information about this from C++ forum than from the so-called machine programmers.

I have no idea what you're talking about. Who mentioned Java?

Padding is inserted by the back-end assembler, C++ has nothing to do with it.

For example, GCC's process goes like so:

* Language parser (C++)
* GENERIC (language-independent already! all languages arrive at this form or GIMPLE directly)
* GIMPLE
* RTL
* Assembly

0xCC or nops are not present even in the assembly source at the last stage. It simply has "align" directives. It's the assembler after that which inserts nops or 0xCC depending how many it has to insert. Needless to say, the original "C++" language is long gone in this process, it's gone after the first stage!

And I wouldn't be surprised if you got shit wrong answers from a C++ forum, wouldn't be surpised if they don't even know what a byte is.



I don't quite understand what you're trying to convey here. Seems like you're supporting my statements.
Post 08 May 2017, 11:36
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 894
Here's a snippet from the assembler source generated by GCC:


Code:
.balign 16,0xCC
function_name:
blah...

Do you see any Java or C++ or debugger?

The first line is literally what will automatically insert 0xCC padding if it's required (if it's already aligned to 16 bytes, then it won't). You can also change the 16 of course -- either with command line to GCC or by parsing the asm yourself after before assembly (in the makefile so it's fully automatic).

Of course you can do the same with a FASM macro, but you mentioned all these other languages so I had to give you an example of a compiler that supports both Java and C++ Wink

Yeah btw you can write the above directly in assembler (GNU AS syntax so beware), and it will compile just fine. No C++ required.
Post 08 May 2017, 12:49
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 673
So, where's your 0xCC handler? Let me see how you handle it once it hits the 0xCC.

Or yet again, we have to rely on 3rd party debugger to handle it for you?

For extra info, you can use EDB, evan's debugger for handling it for you on Linux. It was written in C++, with QT as its backend.

C++ programmers are always dependable to handle ASM programmer's faulty software Very Happy
Post 15 May 2017, 18:21
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 894
You don't need a 0xCC handler. You need an exception handler.

You know, an exception handler is typically made to handle all sorts of exceptions (I even gave you an example earlier of one I personally used to detect if the program is ran under a Linux Kernel, even if it's a Windows application!), but most "exceptions" in Windows userland are from software, not hardware (throw). To be honest, personally I only find hardware exceptions valuable, since you can't emulate them in code or software.

I mean, you're asking now how to do exception handling or what? Try to Google a bit "Structured Exception Handling" (note: x64 is completely different than x86 SEH, so make sure you read the right one that you want)

But there's one thing in common. When you receive an exception callback (you basically register a "callback" that Windows will use to call it, whether actively register it (x86), or in a read-only table section (x64)), you receive a pointer to a struct that contains all the state of the processor's registers at the point the exception was triggered.

This is what you see in "crash dumps" when exceptions are "unhandled" (unhandled simply means you return from the callback telling Windows you didn't handle it, or there's no callback in the first place).

Of course you can just call ExitProcess() if you want to instantly quit with no crash dumps since you are anti-debugging information it seems Razz

Or you can do elaborate checks to see what happened; where was exception triggered, by what action, etc. You can even recover from it if you want, or set the instruction pointer to point anywhere by changing it in the struct (you won't want to recover from a 0xCC though, since it means code is messed up already; at best just collect information to diagnose the problem, and then quit).

A simple way to check for 0xCC is to simply inspect what RIP/EIP (in the struct provided by Windows) points to. But first make sure it is within valid bounds (check it against your code section's bounds!!), else you run the risk of another access violation from within an exception handler, which will instantly kill the application. If it's within valid bounds you are free to dereference it, so you can see if it's 0xCC that it landed on or not.
Post 15 May 2017, 19:56
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.