User Controls
What are you doing at the moment
-
2025-01-20 at 3:43 AM UTC
Originally posted by Landy Pamm we already had a conversation of the real capable guy who did that to me some 15 years ago or so.
knocked out power to the neighborhood. I would of written it off as just my computer fried by neighborhood surge on the electrical grid but he kept threatening me in real time then mocked me and bragged the next day and I didn't bother saying much to him for a few days. just another coincidence I guess
The moral of the story? Never mess with a genuine spook. -
2025-01-20 at 3:44 AM UTC
-
2025-01-20 at 3:49 AM UTC
-
2025-01-20 at 3:57 AM UTCIn computer security, a NOP slide, NOP sled or NOP ramp is a sequence of NOP (no-operation) instructions meant to "slide" the CPU's instruction execution flow to its final, desired destination whenever the program branches to a memory address anywhere on the slide.
The technique sees common usage in software exploits, where it is used to direct program execution when a branch instruction target is not known precisely. Other notable applications include defensive programming strategies such as EMC-aware programming.
While a NOP slide will function if it consists of a list of canonical NOP instructions, the presence of such code is suspicious and easy to automatically detect. For this reason, practical NOP slides are often composed of non-canonical NOP instructions (such as moving a register to itself or adding zero[1]), or of instructions that affect program state only inconsequentially, which makes them much more difficult to identify.
A NOP-sled is the oldest and most widely known technique for exploiting stack buffer overflows.[2] It solves the problem of finding the exact address of the buffer by effectively increasing the size of the target area. To do this, much larger sections of the stack are corrupted with the no-op machine instruction. At the end of the attacker-supplied data, after the no-op instructions, the attacker places an instruction to perform a relative jump to the top of the buffer where the shellcode is located. This collection of no-ops is referred to as the "NOP-sled" because if the return address is overwritten with any address within the no-op region of the buffer, the execution will "slide" down the no-ops until it is redirected to the actual malicious code by the jump at the end. -
2025-01-20 at 4 AM UTCThe following users say it would be alright if the author of this post didn't die in a fire!
-
2025-01-20 at 4:03 AM UTC
Originally posted by ⠀⠀⠀⠀⠀⠀ In computer security, a NOP slide, NOP sled or NOP ramp is a sequence of NOP (no-operation) instructions meant to "slide" the CPU's instruction execution flow to its final, desired destination whenever the program branches to a memory address anywhere on the slide.
The technique sees common usage in software exploits, where it is used to direct program execution when a branch instruction target is not known precisely. Other notable applications include defensive programming strategies such as EMC-aware programming.
While a NOP slide will function if it consists of a list of canonical NOP instructions, the presence of such code is suspicious and easy to automatically detect. For this reason, practical NOP slides are often composed of non-canonical NOP instructions (such as moving a register to itself or adding zero[1]), or of instructions that affect program state only inconsequentially, which makes them much more difficult to identify.
A NOP-sled is the oldest and most widely known technique for exploiting stack buffer overflows.[2] It solves the problem of finding the exact address of the buffer by effectively increasing the size of the target area. To do this, much larger sections of the stack are corrupted with the no-op machine instruction. At the end of the attacker-supplied data, after the no-op instructions, the attacker places an instruction to perform a relative jump to the top of the buffer where the shellcode is located. This collection of no-ops is referred to as the "NOP-sled" because if the return address is overwritten with any address within the no-op region of the buffer, the execution will "slide" down the no-ops until it is redirected to the actual malicious code by the jump at the end.
thanks wikipedia
how does this help defeat the nx-bit and/or memory protection
PS. nigger -
2025-01-20 at 4:08 AM UTC
-
2025-01-20 at 4:17 AM UTC
-
2025-01-20 at 4:23 AM UTCThe NX bit is a feature of the Memory Management Unit of some CPU (including recent enough x86). It allows to mark each memory page as being "allowed" or "disallowed" for code execution. The MMU is under control of the kernel; the kernel code decides which pages get the execution privilege and which do not. Therefore, whether the stack space is protected against execution depends on the OS. It also depends on a lot of other things:
Though the kernel may apply default values for the page properties, application can request changes. E.g. on Linux systems, the mprotect() system call can be used to enable or disable execution on any page that is under control of the calling process. In particular, any application which contains a JIT compiler (e.g. Web browsers, for efficient Javascript support) must play with mprotect(), because it must generate code (i.e. write bytes into some memory) and then execute the said code.
A mono-threaded application gets its stack in a dedicated area that the kernel knows of; in particular, the stack pages are automatically allocated upon first usage. In a multi-threaded application, things change: each thread has its own stack, which is, from the point of view of the kernel, heap-allocated. Depending on the OS, there may or may not be special support from the kernel for thread stacks.
GCC in particular supports a C language extension called nested functions. Because of the semantics of these functions, the compiled code for a nested function must dynamically produce some executable code on the stack; this is called a trampoline. See this page for some details. The bottom-line is that, for a trampoline to actually work, the stack (or at least the page in which the trampoline resides) must be marked executable.
It so happens that in the ELF file format, which is the format of executable files and DLL on Linux, there is a field which allows to specify whether the stack should be executable or not. When GCC compiles some code which contains a nested function, it sets this flag in the produced binary.
I have made some tests on a fairly recent Linux (Ubuntu 13.10, on 64-bit x86, with NX bit activated). Whether a given page is executable or not can be inferred from the contents of the special file /proc/$$/maps where $$ is the process ID. These tests have shown the following:
By default, the main stack is not executable. The NX bit is set for the stack pages.
If code contains a nested function, the executable is marked with the "executable stack" flag and, indeed, the main stack is now executable.
Thread stacks are created with the same "executable status" as the main stack.
If a "normal" executable, with its main stack non-executable, dynamically loads a DLL (with dlopen()) which contains code for a nested function, then the main stack is automatically switched to executable status.
If a normal multi-threaded executable, with its main stack and all its thread stacks non-executable, dynamically loads a DLL which contains code for the nested function, then the main stack and all the thread stacks are en masse promoted to executable status. Note that this implies that on this Linux system, "something" (probably the kernel, I have not checked) is aware of all the current thread stacks, and can change their mapping rights dynamically.
From all of this we conclude that on at least some recent versions of Linux, the stacks (main and threads) will usually be marked as non-executable (i.e. NX bit set). However, if the executable code of the application, or some executable code somewhere in a DLL loaded by the application, contains a nested function or otherwise advertises a need for an executable stack, then all stacks in the application will be marked as executable (i.e. NX bit not set). In other words, a single loadable plugin or extension for an application may deactivate NX stack protection for all threads of the applications, simply by using a rarely used but legitimate and documented feature of GCC.
There is no need to panic, though, because, as @tylerl points out, protection afforded by the NX bit is not that great. It will make some exploits more awkward for the least competent of attackers; but good attackers will not be impeded. Also, all this talk about NX is about trying to contain damage once a buffer overflow or use-after-free has occurred, and that's arguably a bit late to react. -
2025-01-20 at 4:31 AM UTC
Originally posted by ⠀⠀⠀⠀⠀⠀ The NX bit is a feature of the Memory Management Unit of some CPU (including recent enough x86). It allows to mark each memory page as being "allowed" or "disallowed" for code execution. The MMU is under control of the kernel; the kernel code decides which pages get the execution privilege and which do not. Therefore, whether the stack space is protected against execution depends on the OS. It also depends on a lot of other things:
Though the kernel may apply default values for the page properties, application can request changes. E.g. on Linux systems, the mprotect() system call can be used to enable or disable execution on any page that is under control of the calling process. In particular, any application which contains a JIT compiler (e.g. Web browsers, for efficient Javascript support) must play with mprotect(), because it must generate code (i.e. write bytes into some memory) and then execute the said code.
A mono-threaded application gets its stack in a dedicated area that the kernel knows of; in particular, the stack pages are automatically allocated upon first usage. In a multi-threaded application, things change: each thread has its own stack, which is, from the point of view of the kernel, heap-allocated. Depending on the OS, there may or may not be special support from the kernel for thread stacks.
GCC in particular supports a C language extension called nested functions. Because of the semantics of these functions, the compiled code for a nested function must dynamically produce some executable code on the stack; this is called a trampoline. See this page for some details. The bottom-line is that, for a trampoline to actually work, the stack (or at least the page in which the trampoline resides) must be marked executable.
It so happens that in the ELF file format, which is the format of executable files and DLL on Linux, there is a field which allows to specify whether the stack should be executable or not. When GCC compiles some code which contains a nested function, it sets this flag in the produced binary.
I have made some tests on a fairly recent Linux (Ubuntu 13.10, on 64-bit x86, with NX bit activated). Whether a given page is executable or not can be inferred from the contents of the special file /proc/$$/maps where $$ is the process ID. These tests have shown the following:
By default, the main stack is not executable. The NX bit is set for the stack pages.
If code contains a nested function, the executable is marked with the "executable stack" flag and, indeed, the main stack is now executable.
Thread stacks are created with the same "executable status" as the main stack.
If a "normal" executable, with its main stack non-executable, dynamically loads a DLL (with dlopen()) which contains code for a nested function, then the main stack is automatically switched to executable status.
If a normal multi-threaded executable, with its main stack and all its thread stacks non-executable, dynamically loads a DLL which contains code for the nested function, then the main stack and all the thread stacks are en masse promoted to executable status. Note that this implies that on this Linux system, "something" (probably the kernel, I have not checked) is aware of all the current thread stacks, and can change their mapping rights dynamically.
From all of this we conclude that on at least some recent versions of Linux, the stacks (main and threads) will usually be marked as non-executable (i.e. NX bit set). However, if the executable code of the application, or some executable code somewhere in a DLL loaded by the application, contains a nested function or otherwise advertises a need for an executable stack, then all stacks in the application will be marked as executable (i.e. NX bit not set). In other words, a single loadable plugin or extension for an application may deactivate NX stack protection for all threads of the applications, simply by using a rarely used but legitimate and documented feature of GCC.
There is no need to panic, though, because, as @tylerl points out, protection afforded by the NX bit is not that great. It will make some exploits more awkward for the least competent of attackers; but good attackers will not be impeded. Also, all this talk about NX is about trying to contain damage once a buffer overflow or use-after-free has occurred, and that's arguably a bit late to react. -
2025-01-20 at 4:40 AM UTCGod, speaking of which, these are some of the first yt Vida I remember wa
The following users say it would be alright if the author of this post didn't die in a fire! -
2025-01-20 at 4:40 AM UTC
Originally posted by Semiazas
the argument there is that that level of memory protection only stops you from putting executable shellcode in buffers and other places that aren't supposed to be executable, but that you can still use RTC/return code to point it back at the standard C calls that should be available in any regular lunix system.
then you have to worry about other things like address randomisation and non-kernel security measures, but it really has nothing to do with NOP sleds being particularly viable or relevant as they're just a way to pad the buffer with blank instructions so you can zero in on where you can actually inject code (ie. it doesn't matter because you can't really inject anything more than a jump to an existing system call) -
2025-01-20 at 4:43 AM UTChttps://en.wikipedia.org/wiki/Return-oriented_programming
With data execution prevention, an adversary cannot directly execute instructions written to a buffer because the buffer's memory section is marked as non-executable. To defeat this protection, a return-oriented programming attack does not inject malicious instructions, but rather uses instruction sequences already present in executable memory, called "gadgets", by manipulating return addresses. A typical data execution prevention implementation cannot defend against this attack because the adversary did not directly execute the malicious code, but rather combined sequences of "good" instructions by changing stored return addresses; therefore the code used would be marked as executable. -
2025-01-20 at 4:43 AM UTCok retard
-
2025-01-20 at 4:47 AM UTC
-
2025-01-20 at 5 AM UTC
Originally posted by ⠀⠀⠀⠀⠀⠀ Hey, be nice.
do you try an induce a stuxnet or how are you doing this?Most modern motherboards and CPUs are equipped with safety features designed to prevent overheating:
Thermal Protection: CPUs and GPUs have built-in thermal protection that will throttle performance or shut down the system if temperatures reach critical levels.
Fan Control Systems: Many systems have fail-safes that will engage if fans are not operating correctly, such as shutting down the computer before damage occurs. -
2025-01-20 at 5:11 AM UTC
-
2025-01-20 at 5:18 AM UTC
-
2025-01-20 at 5:29 AM UTCthis brings back a bad memory. pun intended or not.
so many files i had stored on two computers gone from that one incident.
I started smelling fried wires and smoke coming out of one tower and the lights went out. I said "That has to be a coincidence" but the entire neighborhood went dark
this dude was living in Massachusetts
Next morning just bragging about what he did. its one of many "Coincidences". -
2025-01-20 at 5:58 AM UTC
Originally posted by Landy Pamm do you have the original Sub7 laying around. flip my screen if you do but flip it back. lets see you do this. something simple
I not only have ALL versions of SubSeven, I have a modified version which is fully undetectable to all virus scanners, which can be binded to any other executable. It's also set with the "call home" feature enabled by default, so the IP of where it's loaded can go to any server of my choosing for pickup. I also have the master password, so even if the password is changed, I can override and get in. The older versions are best, because the file sizes are much smaller, so the memory lag when they load is much more unnoticeable.
