Leaderboard

KRACK Detector is a Python script to detect possible KRACK attacks against client devices on your network. The script is meant to be run on the Access Point rather than the client devices. It listens on the Wi-Fi interface and waits for duplicate message 3 of the 4-way handshake. It then disconnects the suspected device, preventing it from sending any further sensitive data to the Access Point. KRACK Detector currently supports Linux Access Points with hostapd. It uses Python 2 for compatibility with older operating systems. No external Python packages are required. Usage: Run as root and pass the Wi-Fi interface as a single argument. It is important to use the actual Wi-Fi interface and not any bridge interface it connects to. python krack_detect.py wlan0 If you do not wish to disconnect suspected devices, use the -n flag python krack_detect.py -n wlan0 Known Issues Message 3 of the 4-way handshake might be retransmitted even if no attack is perfomed. In such a case the client device will be disconnected from the Wi-Fi network. Some client devices will take some time to re-authenticate themselves, losing the Wi-Fi connection for a few seconds. Download: krackdetector-master.zip Mirror: krack_detect.py Sources: https://krackattacks.securingsam.com https://github.com/securingsam/krackdetector

O lista cu câteva zeci de metode de bypass pentru AppLocker. Se actualizează constant. Link: https://github.com/api0cradle/UltimateAppLockerByPassList

WPSeku v0.2.1 - Wordpress Security Scanner WPSeku is a black box WordPress vulnerability scanner that can be used to scan remote WordPress installations to find security issues. Installation # git clone https://github.com/m4ll0k/WPSeku.git # cd WPSeku # pip install -r requirements.txt # python wpseku.py Usage: python --target http://youtargethere.com License WPSeku is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation version 3 of the License. WPSeku is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with WPSeku; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. WPSeku uses WPScan Vulnerability Database API (https://wpvulndb.com/api) Download: WPSeku-master.zip or git clone https://github.com/m4ll0k/WPSeku.git Source: https://github.com/m4ll0k/WPSeku

Those are the words uttered by Tommy, a childhood toy robot of mine. I've taken a look at his miniature vinyl record sound mechanism a few times before (#1, #2), in an attempt to recover the analog audio signal using only a digital camera. Results were noisy at best. The blog posts resurfaced in a recent IRC discussion which inspired me to try my luck with a slightly improved method. Source photo I'm using a photo of Tommy's internal miniature record I already had from previous adventures. This way, Tommy is spared from another invasive operation, though it also means I don't have control over the photographing environment. The picture was taken with a DSLR and it's an uncompressed 8-bit color photo measuring 3000 by 3000 pixels. There's a fair amount of focus blur, chromatic aberration and similar distortions. But at this resolution, a clear pattern can be seen when zooming into the grooves. This pattern superficially resembles a variable-area optical audio track seen in old film prints, and that's why I previously tried to decode it as such. But it didn't produce satisfactory results, and there is no physical reason it even should. In fact, I'm not even sure as to which physical parameter the audio is encoded in – does the needle move vertically or horizontally? How would this feature manifest itself in the photograph? Do the bright blobs represent crests in the groove, or just areas that happen to be oriented the right way in this particular lighting? Unwrapping To make the grooves a little easier to follow I first unwrapped the circular record into a linear image. I did this by remapping the image space from polar to 9000-wide Cartesian coordinates and then resampling it with a windowed sinc kernel: Mapping the groove path It's not easy to automatically follow the groove. As one would imagine, it's not a mathematically perfect spiral. Sometimes the groove disappears into darkness, or blurs into the adjacent track. But it wasn't overly tedious to draw a guiding path manually. Most of the work was just copy-pasting from a previous groove and making small adjustments. I opened the unwrapped image in Inkscape and drew a colored polyline over all obvious grooves. I tried to make sure a polyline at the left image border would neatly continue where the previous one ended on the right side. The grooves were alternatively labeled as 'a' and 'b', since I knew this record had two different sound effects on interleaved tracks. This polyline was then exported from Inkscape and loaded by a script that extracted a 3-7 pixel high column from the unwrapped original, centered around the groove, for further processing. Pixels to audio I had noticed another information-carrying feature besides just the transverse area of the groove: its displacement from center. The white blobs sometimes appear below or above the imaginary center line. I had my script calculate the brightness mass center (weighted y average) relative to the track polyline at all x positions along the groove. This position was then directly used as a PCM sample value, and the whole groove was written to a WAV file. A noise reduction algorithm was also applied, based on sample noise from the silent end of the groove. The results are much better than what I previously obtained (see video below, or mp3 here): Future ideas Several factors limit the fidelity and dynamic range obtained by this method. For one, the relationship between the white blobs and needle movement is not known. The results could possibly still benefit from more pixel resolution and color bit depth. The blob central displacement (insofar as it is the most useful feature) could also be more accurately obtained using a Gaussian fit or similar algorithm. The groove guide could be drawn more carefully, as some track slips can be heard in the recovered audio. Opening up the robot for another photograph would be risky, since I already broke a plastic tab before. But other ways to optically capture the signal would be using a USB microscope or a flatbed scanner. These methods would still be only slightly more complicated that just using a microphone! The linear light source of the scanner would possibly cause problems with the circular groove. I would imagine the problem of the disappearing grooves would still be there, unless some sort of carefully controlled lighting was used. Source: http://www.windytan.com/2017/07/gramophone-audio-from-photograph.html

webpack-dashboard A CLI dashboard for your webpack dev server What's this all about? When using webpack, especially for a dev server, you are probably used to seeing something like this: That's cool, but it's mostly noise and scrolly and not super helpful. This plugin changes that. Now when you run your dev server, you basically work at NASA: Install npm install webpack-dashboard --save-dev Use First, import the plugin and add it to your webpack config, or apply it to your compiler: // Import the plugin: var DashboardPlugin = require('webpack-dashboard/plugin'); // If you aren't using express, add it to your webpack configs plugins section: plugins: [ new DashboardPlugin() ] // If you are using an express based dev server, add it with compiler.apply compiler.apply(new DashboardPlugin()); If using a custom port, the port number must be included in the options object here, as well as passed using the -p flag in the call to webpack-dashboard. See how below: plugins: [ new DashboardPlugin({ port: 3001 }) ] In the latest version, you can either run your app, and run webpack-dashboard independently (by installing with npm install webpack-dashboard -g) or run webpack-dashboard from your package.json. So if your dev server start script previously looked like: "scripts": { "dev": "node index.js" } You would change that to: "scripts": { "dev": "webpack-dashboard -- node index.js" } Now you can just run your start script like normal, except now, you are awesome. Not that you weren't before. I'm just saying. More so. InspectPack and Node Environments Webpack Dashboard does additional analysis of individual module sizes, asset sizes, and any problems when your bundle is unminified and not in a production environment. The Webpack Plugin automatically adds pathinfo = true to your configuration’s output object. Environments are defined through the DefinePlugin with process.env["NODE_ENV"] being "production". Webpack Dashboard will produce a warning if a production configuration is run. Run it Finally, start your server using whatever command you have set up. Either you have npm run dev or npm start pointed at node devServer.js or something along those lines. Then, sit back and pretend you're an astronaut. Supported Operating Systems and Terminals macOS → Webpack Dashboard works in Terminal, iTerm 2, and Hyper. For mouse events, like scrolling, in Terminal you will need to ensure View → Enable Mouse Reporting is enabled. This is supported in macOS El Capitan, Sierra, and High Sierra. In iTerm 2, to select full rows of text hold the ⌥ Opt key. To select a block of text hold the ⌥ Opt + ⌘ Cmd key combination. Windows 10 → Webpack Dashboard works in Command Prompt, PowerShell, and Linux Subsystem for Windows. Mouse events are not supported at this time, as discussed further in the documentation of the underlying terminal library we use Blessed. The main log can be scrolled using the ↑, ↓, Page Up, and Page Down keys. Linux → Webpack Dashboard has been verified in the built-in terminal app for Debian-based Linux distributions such as Ubuntu or Mint. Mouse events and scrolling are supported automatically. To highlight or select lines hold the ⇧ Shift key. API webpack-dashboard (CLI) Options -c, --color [color] - Custom ANSI color for your dashboard -m, --minimal - Runs the dashboard in minimal mode -t, --title [title] - Set title of terminal window -p, --port [port] - Custom port for socket communication server Arguments [command] - The command you want to run, i.e. webpack-dashboard -- node index.js Webpack plugin Options host - Custom host for connection the socket client port - Custom port for connecting the socket client root - Custom full path to project root (where package.json + node_modules are if not in process.cwd()) handler - Plugin handler method, i.e. dashboard.setData Note: you can also just pass a function in as an argument, which then becomes the handler, i.e. new DashboardPlugin(dashboard.setData) Download: webpack-dashboard-master.zip or git clone https://github.com/FormidableLabs/webpack-dashboard.git Credits Module output deeply inspired by: https://github.com/robertknight/webpack-bundle-size-analyzer Error output deeply inspired by: https://github.com/facebookincubator/create-react-app Sources: https://medium.com/@wesharehoodies/webpack-dashboard-with-create-react-app-vue-cli-and-custom-configs-49166e1a69de https://github.com/FormidableLabs/webpack-dashboard

3dtoontubehd.com 4shared abbywinters.com account.norton.cm adf.ly alldebrid.com allelitepass.com Amaland amberlily.net AmourAngels anilios AOL api.steampowered.com atkpremium.com audience.nba.com auth.homeclips.com auth.livejasmin.com AVG backroomcastingcouch.com badongo Bangbros barelylegal.com bitshare.com bitshare blacksonblondes.com blacksonblondes brazzers Elite Brazzers_Mobil Brazzersmobile.com burningangel.com Can4 cams camwither collegerules cramit.in czechav.com dancingbear DebirdMax digitalplayground.com drop box.com easy-share.com edit.yahoo.com en.justin.tv + altele DOWNLOAD

http://recordit.co/GTIROeGtVr

L.E.: oarecum tangential...

O placa video ceva mai veche dar cu un raport calitate/pret foarte bun, mai ales daca ai un sistem fara pretentii foarte mari. Sapphire Radeon TOXIC R9 270X , 2GB - 300 Lei https://pricezone.ro/product/sapphire-radeon-toxic-r9-270x-2gb-gddr5-256-bit-hdmi-dvi-dp-11217-02-40g

I’ve been planning for some time to make a post about things you can do with virtual memory, so when @jimsagevid tweeted me about virtual memory in response to my last post, I felt the time was right. Virtual memory is funny. As programmers, we know that it’s there (on all modern CPUs and OSs), but we tend to forget about it, perhaps because it’s not directly exposed in our programming languages. Or, we just think of it as the thing that makes our software run really slow instead of crashing, when it runs out of physical RAM. But, it turns out, if you actually make use of what virtual memory can do, you can achieve some pretty cool things. Obscenely big array To recap — in my last post I faced the problem of wanting a big lookup table from object IDs to object pointers. Furthermore, I wanted this table to stay fixed in memory, so that writers could atomically replace pointers in the table without disturbing readers. This means that using something like a std::vector is not possible, since the underlying data will be reallocated when the vector grows. A fixed array works: object_o *objects[MAX_OBJECTS]. But what size should we use for the array? Pick a big size, and we’re wasting memory. Pick a small size, and we might run out of objects. In the article, I used a hierarchical approach, but as @jimsagevid pointed out, we could use virtual memory instead, and avoid the complexity of a hierarchical table layout. When we allocate memory through the virtual memory system we reserve address space for the pages we allocate immediately (no other code can allocate memory in that address range), but actual physical memory is not allocated until we actually touch the pages. So for this situation, we can just pick a comfortably large number for our array and virtually allocate it. Say 1 billion of objects, for example: #define MAX_OBJECTS 1000000000ULL object_o **objects = virtual_alloc(MAX_OBJECTS * sizeof(object_o *)); We’re using 8 GB of address space and virtual memory, but only as much physical memory as we actually need for our objects. A simple solution that only requires one line of code. Note: I’m using virtual_alloc() here as my OS agnostic virtual memory allocation call. On Windows you would actually call VirtualAlloc() and on Linux mmap(). Another note: Windows separates virtual memory allocation into separate MEM_RESERVE and MEM_COMMIT calls. MEM_RESERVE reserves address space and MEM_COMMIT commits it to physical memory. That does not mean that physical memory is actually allocated when you MEM_COMMIT, the physical memory is still not allocated until you actually touch the pages. But MEM_COMMIT reserves memory in the page file, and if you try to commit more memory than you have in your page file, MEM_COMMIT will fail. So on Windows, you probably don’t want to MEM_COMMIT the entire lookup table (because you only have a limited size page file). Instead you want to MEM_RESERVE the whole table in the beginning and then just MEM_COMMIT the range of the table that you actually use. In contrast, Linux allows overcommitting — i.e., you can commit more memory than the size of your page file. For this reason, Linux doesn’t need separate reserve/commit operations which makes the virtual memory a lot simpler to use. Is reserving 8 GB of virtual memory for the array a problem? Not really. There are two limits that concern us here. The first is address space. In a 64-bit application (which we assume), the address space is 264, a staggeringly large number with room for billions of gigabyte-sized arrays. The second limit is for virtual memory. The OS typically doesn’t let us allocate the whole possible address space as virtual memory. On 64-bit Windows, for example, we can only allocate 256 TB of virtual memory. Still, that’s room for 32 000 arrays of 8 GB each, so as long as we don’t go totally crazy, we’re fine. In fact, you could probably use this technique for all global or semi-global arrays in your application without any problems. Remember the old-school C way of writing games with static arrays for all objects: uint32_t num_tanks; tank_t tanks[MAX_TANKS]; uint32_t num_bullets; bullet_t bullets[MAX_BULLETS]; ... If you write code like this, you can be sure that someone will complain that it’s not “future-proof”, since you have caps on the number of objects. That is kind of ridiculous, but to satisfy the complaint in a simpler and more fun way than using a std::vector you can just get rid of the MAX_* defines and allocate 1 GB of virtual memory for each array: #define GB 1000000000 uint32_t num_tanks; tank_t *tanks = virtual_alloc(GB); uint32_t num_bullets; bullet_t *bullets = virtual_alloc(GB); Application wide unique IDs A lot of game engine systems need unique IDs to identify objects. Usually the code looks something like this: uint64_t allocate_id(system_t *sys) { return sys->next_free_id++; } But virtual memory gives us another option. Instead of using integers as identifiers, we could use addresses reserved from the virtual memory system. This allows us to create IDs that are unique, not just in the current system, but throughout the entire application. And since we never actually use the memory pointed to by these addresses, we won’t consume any physical memory. It might look something like this: system_id_t *allocate_id(system_t *sys) { if (!sys->id_block || sys->id_block_used == PAGE_SIZE) { sys->id_block = virtual_alloc(PAGE_SIZE); sys->id_block_used = 0; } return (system_id_t *)(sys->id_block + sys->id_block_used++); } Note that by using a pointer to an opaque struct for the ID we also get some type safety, that we didn’t have with the uint64_t approach. Memory overwrite detection One of the hardest bugs to fix is random memory overwrites, where some piece of code is writing to memory that it shouldn’t touch. Then, later, when some other piece of code tries to use that memory, it will read that trash data and (most likely) crash. The problem here is that while the crash itself is easy to find, it is tricky to know where the bad write that corrupted the data to begin with occurred. Luckily, virtual memory can help us here too. To see why, first note that the term random memory overwrite is actually a misnomer. Just like regular space, address space is mostly empty. With a 64 bit address space and an application size of say 2 GB, the address space is 99.999999988 % empty. This means that if the memory overwrites were truly random, most likely they would hit this empty space and cause a page fault/access violation. That would give us a crash at the point of the bad write, instead of the innocent read, which would make the bug much easier to find and fix. But of course, the writes are usually not truly random. Instead they typically fall in one of two categories: Writing to memory that has been freed. Writing beyond the allocated memory for an object. In both cases, it is pretty likely that the write will actually hit some other object, rather than empty space. In the first case, the memory will probably have been recycled for something else. In the second case, the write will probably hit a neighboring object, or allocation block headers. We can make these cases look more like the random case by replacing the standard system allocator with an end-of-page allocator. Such an allocator uses the virtual memory system to allocate each object on its own set of pages, and furthermore, it aligns the object so that the end of the object coincides with the end of the last page. End of page block placement. This accomplishes two things. First, when we free the pages, we free them in the virtual memory system. This means that attempting to write to the pages after they have been freed will result in an access violation. Note that this typically doesn’t happen with a regular memory allocator — it will save the freed memory in its freelists to be used for other allocations, instead of returning it to the OS. Second, as the end of the block coincides with the end of the page, writing beyond the end of the block will also cause an access violation. In other words, with this approach, our typical bad memory writes will crash at the point of the write and allow us to easily diagnose the problem. Since this allocator rounds up all allocations to the page size, it will waste a lot of memory for small allocations. It is probably not something that you want enabled all the time. What I typically do is work with the standard allocator. Then, if I suspect bad memory overwrites, I switch it out for the end-of-page allocator. Once I’ve fixed the problem, I switch back to the standard allocator. This of course requires you to have an architecture where you can easily change which allocator your system is using. Writing an end end-of-page allocator is not complicated at all. Here’s what malloc looks like: void *eop_malloc(uint64_t size) { uint64_t pages = (size + PAGE_SIZE - 1) / PAGE_SIZE; char *base = virtual_alloc(pages * PAGE_SIZE); uint64_t offset = pages * PAGE_SIZE - size; return base + offset; } Note: There’s still bad writes that could go undetected with this approach. For example, after we’ve freed the pages, a new page allocation could happen in the same memory range. Also, it is possible that another set of pages could be allocated directly after ours in memory, in which case we wouldn’t detect overwrites beyond the last page. Both these problems can be fixed. For the first issue, we can leave the pages reserved, but not committed. That way, the physical memory is freed and we will get page faults, but the addresses are reserved and cannot be used by other objects. For the second issue, we could reserve an extra page after our pages, but not commit that page. No other object could then claim those addresses and writing to them would still cause an access violation. (Note: This only works on Windows, where reserve and commit are separate operations.) In practice though, I’ve never needed to take these extra precautions. For me, the basic end-of-page allocator has always been enough to find and fix the bugs. Fragment free memory allocation On old console hardware, memory fragmentation could give programmers nightmares. But even on modern machines, memory fragmentation can be a big problem when trying to implement efficient memory allocators. A memory allocator works by requesting big chunks of memory from the system and chopping them up into smaller pieces on request of the user. Memory fragmentation occurs when only some of those objects are freed, leaving holes in the used memory block: Memory fragmentation. The problem here is that if the user requests a big chunk of memory, none of the “holes” may be big enough. This means we have to allocate it from the free memory block at the end — increasing the memory use of the application. In other words, we have a lot of wasted memory that we can’t really use. In the olden days, memory was a precious resource. Today, it’s less so, but we still don’t want to waste it. Memory fragmentation is a huge topic, but instead of diving too deep into it, I’m just going to look at it from the virtual memory perspective, which is pretty simple. When you are allocating from virtual memory, fragmentation is a non-issue. The reason is that when we are using virtual memory, each page in address space is individually mapped to a page in physical memory. So if we create “holes” in physical memory by allocating and freeing pages, it doesn’t matter, because those “holes” can later be used to allocate what to us seems like contiguous memory. Let me try to illustrate it with a picture: Physical memory can't be fragmented by virtual memory allocations. Here, we have first made the red allocations and freed some of them, leaving holes in address space and physical memory. However, this doesn’t prevent us from making the big purple allocation. Each page in the purple allocation can be mapped to one of the hole pages we created earlier, without the need for allocating any more physical memory. So nothing is lost to fragmentation. Note that we still have fragmentation in the address space. I.e. we can’t make a big contiguous allocation in the address space where the red allocations are. But we can’t have any fragmentation in physical memory. Fragmentation in address space doesn’t really worry us, because as I said before, address space is typically 99.999999988 % empty anyway, so we have no problem finding contiguous address blocks. (On 32 bit systems, it’s a different story.) The drawback compared to using an ordinary allocator is that we have to round up the allocations to the page size, which typically is 4 K on modern systems. This rounding up means we are not using all of the available memory, a problem which is somewhat confusingly referred to as internal fragmentation. There are lots of ways of dealing with this. For fixed size objects we can use object pools — allocate a page of memory and divide it into as many objects will fit on that page. For dynamically growing buffers, we can just make the buffer size match the page size. This is a simple but interesting technique that I haven’t seen mentioned a lot. Say that you have an array of objects that are 300 bytes big. The conventional setup is that as you need more entries you grow the array geometrically by say doubling it in size. So you go from 16 to 32 to 64 to 128 elements. Geometrical growth is important because it means you only pay an amortized constant cost for adding an element to the array. However, 16 * 300 = 4800. If you allocate that from virtual memory, you have to round it up to 8 K, wasting almost an entire page. But we can easily fix that. Instead of focusing on the number of elements, we just grow the buffer by multiples of the page size: 4 K, 8 K, 16 K, 32 K, … and then put as many elements as will fit in there (13, 27, 54, 109, …). This is still geometric growth, so the cost is still amortized constant, but now the internal fragmentation is just 150 bytes on average, instead of 2 K. I find it a bit surprising that standard memory allocators don’t take more advantage of virtual memory to avoid fragmentation. Most allocators I’ve looked at still work by obtaining large chunks from the OS and chopping them up, instead of working with page sized virtual memory allocations. Is getting larger chunks from the OS more efficient? I’m heading into territory where my knowledge is pretty sketchy here, but I don’t think so. Using a larger page size can be more efficient, because it means a smaller page table and better use of the TLB cache. But, given a fixed page size, I don’t think it matters if you have one big or many small virtual memory allocations, because the address resolve is done page-by-page anyway. And even if you allocate large chunks, consecutive virtual pages are often not consecutive in physical memory anyway. There is probably some memory overhead for the OS to keep track of a large number of individual memory allocations. Also we need system calls to allocate and release the pages which will consume a little time. Maybe that’s the reason. Or maybe it’s just that general allocators are written to run in a variety of environments — on 32 bit systems or systems with large page sizes — so they can’t take advantage of the fragment free allocations you can get with 64 bit address space and 4 K pages. Gapless ring buffer This is a trick I found out about from Fabian Giesen’s blog, but the idea seems to have been around for longer. A ring buffer is a very useful data structure for any situation where data is produced and consumed at different rates. For example, when reading from a socket, you may receive data in chunks that do not match your packet size, so you need to buffer it until you have received a full packet. A ring buffer stores the data in an array of fixed size that “wraps around”, i.e. once the array has been filled we start writing data to the beginning of the array again. In addition to the array we also need read and write pointers to know where in the buffer to read and write data. I like to use uint64_t counters for this, specifying the total number of data written and read, something like this: enum {BUFFER_SIZE = 8*1024}; struct ring_buffer_t { uint8_t data[BUFFER_SIZE]; uint64_t read; uint64_t written; }; Note that since the buffer wraps around, we cannot let the write pointer run too far ahead of the read pointer or it will start to trash data that hasn’t been read yet. Basically, the BUFFER_SIZE controls how far ahead the writer can get. If the buffer is full, the writer must stall and wait for the reader. If the buffer is empty, the reader must stall and wait for the writer. (The number of bytes available to the reader is written - read.) A really annoying part of ring buffers is that you need special code to handle the wraparound. If it weren’t for this, writing to the buffer would be a simple memcpy, but instead we have to be careful that we do the right thing when the write straddles the wraparound point: void write(ring_buffer_t *rb, uint8_t *p, uint64_t n) { uint64_t offset = rb->written % BUFFER_SIZE; uint64_t space = BUFFER_SIZE - offset; uint64_t first_write = n < space ? n : space; memcpy(rb->data + offset, p, first_write); memcpy(rb->data, p + first_write, n - first_write); rb->written += n; } As annoying as this is, reading is even worse. If it wasn’t for the wraparound, reading wouldn’t even require any copying at all — we could just use the data directly from the buffer — but with the wraparound, we need two memcpy() calls to move the data to a contiguous memory block for further processing. How can virtual memory help here? We could use the “huge array” technique and just reserve a huge array instead of the ring buffer, commit pages as the writer advanced and decommit them as the reader advanced. With this we wouldn’t even need to set a fixed size for the array — it would just use as much memory as needed. Pretty ingenious. But note that you might need a huge array. To buffer a 1 Gbps network stream with an uptime of a year you will need to reserve 4 PB (petabytes) of memory. Sadly, as we saw above, 64-bit windows caps the virtual memory at 256 TB. Also, those commit and decommit calls aren’t free. But we can fix this in another way, by taking advantage of the fact that multiple virtual pages can be setup to resolve to the same physical page. This is usually used to share memory between different processes, but we can also set it up in a single process. To use this for the ring buffer we set up a set of pages, immediately after the ring buffer that point to the same physical memory: Ring buffer with page mapping. The shaded block appears twice. As you can see, with this setup the virtual memory system takes care of the wraparound for us. In the address space we can always find a contiguous copy of the memory in the ring buffer, even though the buffer is split up physically. The read and write functions become simply: void write(ring_buffer_t *rb, uint8_t *p, uint64_t n) { memcpy(rb->data + (rb->written % BUFFER_SIZE), p, n); rb->written += n; } uint8_t *read(ring_buffer_t *rb, uint64_t n) { uint8_t *p = rb->data + (rb->read % BUFFER_SIZE); rb->read += n; return p; } A lot nicer, and we’re still using the same amount of (physical) memory. Note that setting up this memory layout can be a bit tricky. On Windows you have to create a file mapping into virtual memory with CreateFileMapping() — yes, even though no files on disk are involved we still need a “file mapping” because that’s how virtual memory is shared. Since we don’t need a file on disk we use INVALID_HANDLE_VALUE for the file handle which creates a mapping against the page file. Then we use MapViewOfFileEx() to map that file mapping into two consecutive memory regions. Unfortunately, there is no way of guaranteeing that the memory regions we pass are available. We can reserve them, and then free them just before calling MapViewOfFileEx() , but that still leaves a window of time where if we’re super unlucky, someone else could come and allocate something in that address area. We might have to retry the mapping a few times before it succeeds, but after that setup we can use the buffer without worrying about it. And that’s all from me Do you know of any neat virtual memory tricks not mentioned here. Tweet them to me at @niklasfrykholm. Source: ourmachinery.com

Multiple online user reports claim that the MantisTek GK2 mechanical keyboard's configuration software is sending data to an Alibaba server. One of the reports even includes an analysis of the software’s traffic, which seems to include typed keys. The MantisTek GK2 is a cheap RGB mechanical keyboard from China that costs half as much (or less) as the mechanical keyboards from better known companies. Multiple gadgets that come from China seem to have either poor security or privacy issues caused by collecting user data without consumers' explicit permission. The MantisTek GK2 seems to be one of those products. The main issue seems to be caused by the keyboard’s “Cloud Driver,” which sends information to IP addresses tied to Alibaba servers. Alibaba sells cloud services, so the data isn’t necessarily being sent to Alibaba, the company, but to someone else using an Alibaba server. The data being sent—in plaintext, no less—has been identified as key presses. This should worry people who bought this keyboard, because that could include email addresses, logins, and even passwords they may have typed at one point or another. How To Stop The Keylogger The first way to stop the keyboard from sending your key presses to the Alibaba server is to ensure the MantisTek Cloud Driver software isn’t running in the background. The second method to stop the data collection is to block the CMS.exe executable in your firewall. You could do this by adding a new firewall rule for the MantisTek Cloud Driver in the “Windows Defender Firewall With Advanced Security.” If you want a one-click method, you can also download the free GlassWire network monitoring tool. GlassWire will show you all the apps making connections to the internet in the “Alerts” tab and let you block those connections in the “Firewall” tab. It can also be used for other types of connections, such as all the connections Windows 10 makes to Microsoft’s servers even when you have most or all data tracking disabled. These days, most products are made in China, but usually some other local company acts as an intermediary to ensure that the product is developed to specification and without other "features" that shouldn't be there. However, this additional protection goes out of the window when people decide to purchase directly from Chinese manufacturers via Chinese marketplaces. Not all products are going to have privacy or security issues, but extra caution is warranted. Via tomshardware.com

limecv is a (Xe/Lua)LaTeX document class to write curriculum vitæ. It is designed to match the business card I designed and follows the same design rules: simple, elegant and clean. The design of this document class is discussed in a series of blog posts. This document class is available on CTAN, so installation is very straightforward. A minimal working example for XeLaTeX can be found here. The documentation describes all possible options and features. The final layout should similar to the images below. The image on the right is the project icon. Installation The package is available from CTAN, to install this document class using your favourite package manager. After installing this package, make sure you have the following fonts installed: FontAwesome Fira The following packages need to be installed on your system. They are all available on CTAN: kvoptions, ifxetex, ifluatex, xparse, calc, xcolor, tabularx, hyperref, url, parskip, xstring, xkeyval, tikz, graphicx, fontspec (XeLaTeX and LuaLaTeX only) and fontawesome. Documentation The class documentation can be found on CTAN. Alternatively, the documentation can also be created by running pdflatex limecv.dtx. Examples To compile the examples in /examples/, install the package from CTAN or compile from source by running: pdflatex limecv.ins and copy the resulting limecv.cls file to the /examples/ folder. Roadmap Below is a list of upcoming features and important to-do items. After these have been resolved, the first stable release will be released. Publish to CTAN. Initial release. LuaLaTeX support. LaTeX support. Cleaned code. .dtx source code format. Real testing by third party. Licence LPPL v1.3c See LICENSE file. Default profile picture courtesy of Twitter. © 2017 Olivier Pieters Download: limecv-master.zip or git clone https://github.com/opieters/limecv.git Sources: https://olivierpieters.be/projects/limecv https://github.com/opieters/limecv

Problema este in felul urmator: eu compun/re-scriu un articol in engleza de 600 cuvinte in minim 5 minute si maxim 10 minute cu tot cu formatare si punctuatie, indiferent de nisa si termeni (in acest timp am inclus si probabilitatea traducerii unor termeni) plus descrieri la poze daca este cazul, un articol de genul se citeste in minim 3 minute si maxim 5 minute conform wordcounttools.com, de aici socotim pentru 100 articole/zi ar veni cam 10 ore de lucru fara pauza. Eu te-as ajuta fara probleme dar la cantitatea de care aveti nevoie voi pe zi este cam greu, am fost contactat si de altcineva in privat si tot la fel doreste minim 100 art.zi/500 word's/en. Eu cer 5-10 lei pe 400 - 700 cuvinte En cand nu sunt presat de cantitate/timp si sursa este usor de inteles, fara cuvinte trends, ca sa iti faci o idee, dar se negociaza si asta daca ti se pare prea scump. Dupa cum ziceam problema nu este la pretul pe articol este la cele 10 ore minim de munca continua in cazul normei de 100articole/zi, zi de zi pe care nu o pot garanta 100%. Pana in 400 cuvinte e mai simplu sa faci o norma de 100/zi. Daca doresti mai putine de 100/zi contacteaza-ma prin mesaj privat, garantez pentru calitatea continutului. P.S: produc si prelucrez continut video daca te intereseaza ( fac pt. indieni rahaturi din alea cu free energy pt youtube...)

Awesome Hacking Resources A collection of hacking / penetration testing resources to make you better! Let's make it the biggest resource repository for our community. You are welcome to fork and contribute. We started a new tools list, come and contribute Table of Contents Learning the Skills YouTube Channels Companies Conferences NEWS Sharpening Your Skills Reverse Engineering, Buffer Overflow and Exploit Development Privilege Escalation Network Scanning / Reconnaissance Malware Analysis Vulnerable Web Application Vulnerable OS Exploits Forums Archived Security Conference Videos Online Communities Online News Sources Linux Penetration Testing OS Learning the Skills Free interactive labs with White Hat Academy Learning Exploitation with Offensive Computer Security 2.0 Cybrary OffensiveComputerSecurity CS 642: Intro to Computer Security Free cyber security training SecurityTube Seed Labs Hak5 OWASP top 10 web security risks MIT OCW 6.858 Computer Systems Security YouTube Channels OWASP Hak5 BlackHat Christiaan008 Companies 0patch by ACROS Security Detectify Kaspersky Lab Metasploit OpenNSM Rapid7 Securelist Segment Security SocialEngineerOrg Sonatype SophosLabs Sourcefire Station X Synack TippingPoint Zero Day Initiative Tripwire, Inc. Vincent Yiu nVisium ntop Conferences 44contv BruCON Security Conference BSides Manchester BSidesAugusta CarolinaCon Cort Johnson DevSecCon Garage4Hackers - Information Security HACKADAY Hack In The Box Security Conference Hack in Paris Hacklu Hacktivity Hardwear.io IEEE Symposium on Security and Privacy LASCON Marcus Niemietz Media.ccc.de NorthSec Pancake Nopcode Psiinon SJSU Infosec Secappdev.org Security Fest SecurityTubeCons ToorCon USENIX Enigma Conference NEWS Corey Nachreiner Error 404 Cyber News Latest Hacking News Pentester Academy TV SecureNinjaTV Troy Hunt Samy Kamkar's Applied Hacking danooct1 DedSec DEFCON Conference DemmSec Don Does 30 Geeks Fort - KIF iExplo1t HACKING TUTORIALS LiveOverflow Metasploitation NetSecNow Open SecurityTraining BalCCon - Balkan Computer Congress Penetration Testing in Linux rwbnetsec Security Weekly Seytonic Shozab Haxor SSTec Tutorials Waleed Jutt webpwnized JackkTutorials Zer0Mem0ry LionSec Adrian Crenshaw HackerSploit Derek Rook - CTF/Boot2root/wargames Walkthrough Sharpening Your Skills OWASP Security Shepherd CTFLearn CTFs write-ups CTF365 Pentestit Hacksplaining The cryptopals crypto challenges The enigma group Ringzer0 Team Hack The Box Over the wire Backdoor Vulnhub Hack.me Hack this site! Exploit exercises PentesterLab SmashTheStack Root-Me PicoCTF Shellter Labs Pentest Practice Pentest.training pwnable.kr pwnable.tw hackburger.ee http://noe.systems/ Hacker Gateway Solve Me Challenge Land Participating Challenge Sites Hacker test Crackmes.de Archive (2011-2015) ROP Emporium Google's XSS game Reverse Engineering, Buffer Overflow and Exploit Development Shell storm Buffer Overflow Exploitation Megaprimer for Linux Reverse Engineering Malware 101 Reverse Engineering Malware 102 Modern Binary Exploitation - CSCI 4968 Introductory Intel x86 Binary hacking Shellcode Injection Reverse Engineering for Beginners Exploit tutorials Exploit development Corelan tutorials Reverse engineering reading list Reverse Engineering challenges Reverse Engineering for beginners (GitHub project) reversing.kr challenges Analysis and exploitation (unprivileged) A Course on Intermediate Level Linux Exploitation Lena's Reversing for Newbies (Complete) Megabeets journey into Radare2 [Introduction to ARM Assembly Basics] ( https://azeria-labs.com/writing-arm-assembly-part-1/ ) Linux (x86) Exploit Development Series Privilege Escalation Reach the root Basic linux privilege escalation Windows Privilege Escalation Privilege escalation for Windows and Linux Windows Privilege Escalation Fundamentals RootHelper Windows exploits, mostly precompiled. Unix privesc checker Privilege escalation linux with live example Windows privilege escalation checker Linux Privilege Escalation Scripts AutoLocalPrivilegeEscalation Linux Privilege Escalation Check Script Local Linux Enumeration & Privilege Escalation Cheatsheet 4 Ways get linux privilege escalation Malware Analysis Malware traffic analysis Malware Analysis - CSCI 4976 Network Scanning / Reconnaissance Foot Printing with WhoIS/DNS records Google Dorks/Google Hacking Vulnerable Web Application OWASP Hackademic Challenges project bWAPP Damn Vulnerable Web Application (DVWA) Xtreme Vulnerable Web Application (XVWA) WebGoat: A deliberately insecure Web Application OWASP Mutillidae II OWASP Broken Web Applications Project Damn Small Vulnerable Web OWASP Juice Shop Google Gruyere Vulnerable OS Metasploitable2 (Linux) Metasploitable3 [Installation] Vulnhub General Test Environment Guidance Linux Penetration Testing OS BackBox BlackArch Kali LionSec Linux Parrot Bugtraq Exploits Exploit Database CXsecurity 0day.today Snyk Vulnerability DB Forums Greysec Hackforums 0x00sec Antichat EAST Exploit database Archived Security Conference Videos InfoCon.org Irongeek Online Communities Hack+ MPGH Hacktoday Online News Sources Recent Hash Leaks InfoSec Threatpost Security Intell The Hacker News Source: https://github.com/vitalysim/Awesome-Hacking-Resources

Avand in vedere ca se apropie, pinned!

Da-mi PM.

PHP Secure Configuration Checker Check current PHP configuration for potential security flaws. Simply access this file from your webserver or run on CLI. Author This software was written by Ben Fuhrmannek, SektionEins GmbH, in an effort to automate php.ini checks and spend more time on cheerful tasks. Link: https://github.com/sektioneins/pcc

DNA-ul isi cumpara all inclusive de la cellebrite http://www.grupul.ro/wp-content/uploads/2017/10/Caiet_sarcini_IT_softuri_DNA.pdf

Salutare, Sunt nikenzzza, sysadmin la o corporatie italiana, si sunt pasionat de development(php, bash) si cyber security. Sper sa gasesc informatii utilie pe acest blog si de ce nu, sa imi impartasesc si eu la randul meu, experienta personala. Numai bine!

Oo super metoda, dar in ce imprejurari ai putea sa o folosesti?

Click dreapta Delet