IERAE CTF had one of the coolest pwn challenges I've done in the while. It was written by hugeh0ge.
Here's the full source:
// gcc chal.c -fno-stack-protector -static -o chal
#include <stdio.h>
#include
IERAE CTF had one of the coolest pwn challenges I've done in the while. It was written by hugeh0ge.
Here's the full source:
// gcc chal.c -fno-stack-protector -static -o chal
#include <stdio.h>
#include
#!/bin/bash | |
# Run the lsregister command and store the output in a variable | |
output=$(/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump) | |
# Use awk to parse the relevant sections | |
echo "$output" | awk ' | |
# When "CFBundleDisplayName" is found, store the app name | |
/CFBundleDisplayName/ { | |
app_name = substr($0, index($0, "=") + 2) |
#include <stdint.h> | |
#include <stdio.h> | |
#include <stdlib.h> | |
#include <stdbool.h> | |
#include <windows.h> | |
#include "nt_crap.h" | |
#define ArrayCount(arr) (sizeof(arr)/sizeof(arr[0])) | |
#define assert(expr) if(!(expr)) { *(char*)0 = 0; } |
""" | |
31-round sha256 collision. | |
Not my research, just a PoC script I put together with numbers plugged in from the slide at | |
https://twitter.com/jedisct1/status/1772647350554464448 from FSE2024 | |
SHA256 impl follows FIPS 180-4 | |
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf | |
""" |
### Test on https://github.com/yousseb/meld/releases/tag/osx-20 | |
### OSX - 3.21.0 (r4) Sonoma | |
### !!! Note: You need put the Meld.app r4 build to the /Applications path first. | |
#!/bin/zsh | |
#Fix libpng16.16.dylib not found | |
install_name_tool -change /usr/local/opt/libpng/lib/libpng16.16.dylib @executable_path/../Frameworks/libpng16.16.dylib /Applications/Meld.app/Contents/Frameworks/libfreetype.6.20.0.dylib | |
#Fix libbrotlidec.1.dylib not found |
// Sometimes you have a large file on a small disk and would like to "transform" | |
// it in some way: for example, by decompressing it. However, you might not have | |
// enough space on disk to keep both the the compressed file and the | |
// decompressed results. If the process can be done in a streaming fashion, it | |
// would be nice if the file could be "drained"; that is, the file would be | |
// sequentially deleted as it is consumed. At the start you'd have 100% of the | |
// original file, somewhere in the middle you'd have about half of the original | |
// file and half of your output, and by the end the original file will be gone | |
// and you'll be left with just the results. If you do it this way, you might | |
// be able to do the entire operation without extra space! |
Official patch: https://chromium-review.googlesource.com/c/v8/v8/+/4584248
Patch come from KeyedStoreIC::StoreElementHandler(), it returns fast path code(Turbofan builtin) for keyed store depends on "receiver_map" and "store_mode". Based on the content of this function is all about element STORE, I personally believe that this is an OOB writes vulnerability.
If we divide the PoC exploration into two parts based on this func, they are: