Original source: https://github.com/0xced/iOS-Artwork-Extractor/wiki/Extracting-more-artwork
You can extract even more artwork if you decrypt and mount an iOS firmware (.ipsw file).
- ipsw_decrypt.py
- Python 3.2 (required by ipsw_decrypt.py)
ACTION | |
AD_HOC_CODE_SIGNING_ALLOWED | |
ALTERNATE_GROUP | |
ALTERNATE_MODE | |
ALTERNATE_OWNER | |
ALWAYS_SEARCH_USER_PATHS | |
ALWAYS_USE_SEPARATE_HEADERMAPS | |
APPLE_INTERNAL_DEVELOPER_DIR | |
APPLE_INTERNAL_DIR | |
APPLE_INTERNAL_DOCUMENTATION_DIR |
Original source: https://github.com/0xced/iOS-Artwork-Extractor/wiki/Extracting-more-artwork
You can extract even more artwork if you decrypt and mount an iOS firmware (.ipsw file).
#!/usr/bin/python | |
# usage python unwxapkg.py filename | |
import sys,os | |
import struct | |
class WxapkgFile: | |
nameLen = 0 | |
name = "" |
Idea: See if a board/software under 10.euros, can be made for low cost commercially available FPGAS or CPLDs using as a base, the already known hacks done with FPGAs that allow to reuse LCDs that compply to the MIPI industry Standart.
MOVED HERE: | |
https://gist.github.com/naveenkrdy/26760ac5135deed6d0bb8902f6ceb6bd |
This is a kernel exploit targeting iOS 12.0-12.2 and 12.4. It exploits a dangling kernel pointer to craft a fake task port corresponding to the kernel task and gets a send right to it.
This code is not readily compilable — some common sense is a prerequisite. If you do get it going though, it is extremely reliable on any device with more than a gigabyte of RAM. Interested readers may want to investigate how reallocations can be prevented -- this might improve reliability even more.
This bug was also called moonshine in the beginning | |
Basically the following bug is present in all bootroms I have looked at: | |
1. When usb is started to get an image over dfu, dfu registers an interface to handle all the commands and allocates a buffer for input and output | |
2. if you send data to dfu the setup packet is handled by the main code which then calls out to the interface code | |
3. the interface code verifies that wLength is shorter than the input output buffer length and if that's the case it updates a pointer passed as an argument with a pointer to the input output buffer | |
4. it then returns wLength which is the length it wants to recieve into the buffer | |
5. the usb main code then updates a global var with the length and gets ready to recieve the data packages | |
6. if a data package is recieved it gets written to the input output buffer via the pointer which was passed as an argument and another global variable is used to keep track of how many bytes were recieved already | |
7. if all the data was recieved th |
#!/bin/bash | |
set -v | |
set -euo pipefail | |
trap "echo 'error: Script failed: see failed command above'" ERR | |
# Disable many keybindings that manage windows to free them up for VSCode, | |
# except for a few ones I also had on macOS | |
dconf write /org/gnome/desktop/wm/keybindings/maximize "['disabled']" | |
dconf write /org/gnome/desktop/wm/keybindings/move-to-monitor-down "['disabled']" |
import sys | |
import json | |
import re | |
kslide = 0x0 | |
if len(sys.argv) < 2: | |
print("Usage: PanicParser.py [file path]") | |
exit() |
// | |
// patchfinder64.c | |
// extra_recipe | |
// | |
// Created by xerub on 06/06/2017. | |
// Copyright © 2017 xerub. All rights reserved. | |
// | |
#include <assert.h> | |
#include <stdint.h> |