Index
> Main > Alignment and paddingGoto page Previous 1, 2 |
| Author |
|
|
system error 04 May 2017, 10:08
revolution wrote:
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. |
|||
04 May 2017, 10:08 |
|
|
revolution 04 May 2017, 10:19
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.
|
|||
|
04 May 2017, 10:19 |
|
|
Furs 04 May 2017, 20:08
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? 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. |
|||
|
04 May 2017, 20:08 |
|
|
system error 07 May 2017, 17:39
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. |
|||
|
07 May 2017, 17:39 |
|
|
system error 07 May 2017, 17:50
Quote:
Tell that to debugger writers / developers. |
|||
|
07 May 2017, 17:50 |
|
|
Furs 07 May 2017, 20:31
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! 
Just don't use nops. |
|||
|
07 May 2017, 20:31 |
|
|
system error 07 May 2017, 21:59
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. |
|||
|
07 May 2017, 21:59 |
|
|
VEG 08 May 2017, 05:05
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. |
|||
|
08 May 2017, 05:05 |
|
|
Furs 08 May 2017, 11:13
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). 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. |
|||
|
08 May 2017, 11:13 |
|
|
system error 08 May 2017, 11:33
VEG wrote:
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. |
|||
|
08 May 2017, 11:33 |
|
|
system error 08 May 2017, 11:36
Furs wrote:
I don't quite understand what you're trying to convey here. Seems like you're supporting my statements. |
|||
|
08 May 2017, 11:36 |
|
|
Furs 08 May 2017, 12:49
Here's a snippet from the assembler source generated by GCC:
Code: .balign 16,0xCC function_name: # blah... 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++ 
Yeah btw you can write the above directly in assembler (GNU AS syntax so beware), and it will compile just fine. No C++ required. |
|||
|
08 May 2017, 12:49 |
|
|
system error 15 May 2017, 18:21
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  |
|||
|
15 May 2017, 18:21 |
|
|
Furs 15 May 2017, 19:56
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
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. |
|||
|
15 May 2017, 19:56 |
|
| Goto page Previous 1, 2 < Last Thread | Next Thread > |
Forum Rules:
|