| Welcome, Guest |
You have to register before you can post on our site.
|
| Online Users |
There are currently 84 online users. » 0 Member(s) | 81 Guest(s) Applebot, Baidu, Forum Biopsy Bot [Anti-Spam]
|
| Latest Threads |
@pump_upp - best crypto p...
by torla 04-16-2026, 01:23 PM
|
datebest.net - visit webs...
by torla 04-10-2026, 01:11 PM
|
Girls In Your Town - No S...
by torla 04-06-2026, 06:39 PM
|
Girls In Your Town - No V...
by torla 04-04-2026, 11:52 PM
|
New DarkSword Kernel Expl...
by GeoSn0w 03-24-2026, 10:49 PM
|
iPhone 15 - iPhone 11 Cor...
by pliku 03-15-2026, 01:17 PM
|
Great iOS Jailbreak NEWS:...
by pliku 03-15-2026, 12:56 PM
|
Great JAILBREAK News: Mas...
by GeoSn0w 02-04-2026, 05:46 AM
|
Receive a $500,500.99 Gif...
by udede 01-22-2026, 05:19 PM
|
iOS 12 - 18.6.2 / iOS 26:...
by GeoSn0w 01-09-2026, 10:56 PM
|
|
|
| Checkra1n and Apple |
|
Posted by: spwo - 10-25-2019, 10:45 PM - Forum: Jailbreak Help
- Replies (1)
|
 |
I know it sounds like Conspiracy theory but could it be possible that Apple paid money to the checkra1n team so they don’t publish the jailbreak?
|
|
|
| Can I jailbreak A12 ios 12.1 |
|
Posted by: jimmynguyen - 10-25-2019, 10:47 AM - Forum: Jailbreak Help
- Replies (4)
|
 |
As my thread. I wonder if I can jailbreak my device iphone Xs ios 12.1 by Uncover. I’m on chimera now but when I update packages from sileo my device turn into black screen and shutdown 2 times in several hours
|
|
|
iOS 13.1.3 / 13.0 / 12.4.1 JAILBREAK Status (Including A12 / A13 Devices) |
|
Posted by: GeoSn0w - 10-25-2019, 03:54 AM - Forum: Jailbreak News
- Replies (1)
|
 |
In today's video, we're discussing the current status of the iOS 13.0, #iOS 13.1.2, iOS 13.1.3 and also iOS 12.4.1 #Jailbreak, for all the devices including A12 devices and A13 devices. As you probably know, A12 devices are the iPhone XS, iPhone XS Max, and iPhone XR, and A13 devices are the iPhone 11 variants released this year. In the video we're discussing the current iOS kernel exploits available, which ones work on which types of devices and what are the best iOS versions to stay on if you wanna jailbreak your device as soon as possible.
We're also discussing about CheckM8 and its compatible devices, as well as what should people who don't have a device compatible with #CheckM8 / CheckRa1n should do. For those devices, such as the #A12 and A13 ones, #tfp0 kernel exploits are still vital for a successful jailbreak and people should still choose the versions they update to wisely.
For the devices compatible with CheckM8, which are the iPhone X all the way down to iPhone 4S, the iOS version they stay on is completely irrelevant because the exploit is not patchable and thus we can use it to jailbreak iOS 13, iOS 12 and any other iOS version, past present or future.
|
|
|
| device not supported |
|
Posted by: Fockerwolf - 10-24-2019, 11:03 AM - Forum: Jailbreak Help
- Replies (1)
|
 |
Hello guys when I try to use checkm8 exploit, terminal says that device is not supported , I tried latest iOS of iPhone 6 , and iOS 13.1.3 on iPhone SE , any ideas?
|
|
|
| tsschecker won't compile |
|
Posted by: suzughia - 10-23-2019, 10:29 PM - Forum: Jailbreak Help
- No Replies
|
 |
Hello everyone,
I'm trying to compile the last build of tsschecker released by s0uthwes and tihmstar
https://twitter.com/s0uthwes/status/1183418585932279814
https://github.com/tihmstar/tsschecker
I get the following error when trying to compile it.
the configure part is ok:
Code:
________________________________________________________________________________
| /Volumes/TJD128GB/iPhone-src/tsschecker-13-10-2019 @ MacBook Pro (suzughia)
| => ./autogen.sh --prefix=/Volumes/TJD128GB/iPhone-src/tsschecker-bin/
glibtoolize: putting auxiliary files in '.'.
glibtoolize: linking file './ltmain.sh'
glibtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
glibtoolize: linking file 'm4/libtool.m4'
glibtoolize: linking file 'm4/ltoptions.m4'
glibtoolize: linking file 'm4/ltsugar.m4'
glibtoolize: linking file 'm4/ltversion.m4'
glibtoolize: linking file 'm4/lt~obsolete.m4'
configure.ac:10: installing './compile'
configure.ac:5: installing './missing'
tsschecker/Makefile.am:6: warning: source file '$(top_srcdir)/external/jssy/jssy/jssy.c' is in a subdirectory,
tsschecker/Makefile.am:6: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled. For now, the corresponding output
automake: object file(s) will be placed in the top-level directory. However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
tsschecker/Makefile.am: installing './depcomp'
checking for a BSD-compatible install... /usr/local/bin/ginstall -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of gcc... gcc3
checking build system type... x86_64-apple-darwin18.7.0
checking host system type... x86_64-apple-darwin18.7.0
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
checking if the linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 196608
checking how to convert x86_64-apple-darwin18.7.0 file names to x86_64-apple-darwin18.7.0 format... func_convert_file_noop
checking how to convert x86_64-apple-darwin18.7.0 file names to toolchain format... func_convert_file_noop
checking for /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... no
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking for -force_load linker flag... yes
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin18.7.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for pkg-config... /usr/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for libplist >= 1.0... yes
checking for libcurl >= 1.0... yes
checking for libfragmentzip >= 1.0... yes
checking for libirecovery >= 0.2.0... yes
checking getopt.h usability... yes
checking getopt.h presence... yes
checking for getopt.h... yes
checking stddef.h usability... yes
checking stddef.h presence... yes
checking for stddef.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking stdio.h usability... yes
checking stdio.h presence... yes
checking for stdio.h... yes
checking for unistd.h... (cached) yes
checking for int32_t... yes
checking for int64_t... yes
checking for size_t... yes
checking for uint32_t... yes
checking for uint64_t... yes
checking for uint8_t... yes
checking for error_at_line... no
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible realloc... yes
checking for memset... yes
checking for mkdir... yes
checking for pow... yes
checking for strchr... yes
checking for strdup... yes
checking for strstr... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating tsschecker/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
config.status: executing libtool commands
________________________________________________________________________________
| /Volumes/TJD128GB/iPhone-src/tsschecker-13-10-2019 @ MacBook Pro (suzughia)
| =>
but when I try to compile it... it suddenly fails.
Code:
________________________________________________________________________________
| /Volumes/TJD128GB/iPhone-src/tsschecker-13-10-2019 @ MacBook Pro (suzughia)
| => make
/Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive
Making all in tsschecker
/bin/sh ../libtool --tag=CC --mode=link gcc -I/usr/local/Cellar/libplist/2.0.0_1/include -I/usr/local/Cellar/libfragmentzip/46/include -I/usr/local/Cellar/libzip/1.5.2/include -I/usr/local/Cellar/libirecovery/git0/include -I../external/jssy/jssy/ -g -O2 -std=c11 -D TSSCHECKER_VERSION_COUNT=\"294\" -D TSSCHECKER_VERSION_SHA=\"04c4044893513248c46a45ef250de544856d9a9e\" -L/usr/local/Cellar/libplist/2.0.0_1/lib -lplist -L/usr/local/Cellar/libfragmentzip/46/lib -L/usr/local/Cellar/libzip/1.5.2/lib -lfragmentzip -lzip -lcurl -lz -lcurl -L/usr/local/Cellar/libirecovery/git0/lib -lirecovery -lm -o tsschecker tsschecker-tsschecker.o tsschecker-tss.o tsschecker-download.o tsschecker-main.o -L/usr/local/Cellar/libplist/2.0.0_1/lib -lplist -L/usr/local/Cellar/libfragmentzip/46/lib -L/usr/local/Cellar/libzip/1.5.2/lib -lfragmentzip -lzip -lcurl -lz -lcurl -L/usr/local/Cellar/libirecovery/git0/lib -lirecovery -lm libjssy.a
libtool: link: gcc -I/usr/local/Cellar/libplist/2.0.0_1/include -I/usr/local/Cellar/libfragmentzip/46/include -I/usr/local/Cellar/libzip/1.5.2/include -I/usr/local/Cellar/libirecovery/git0/include -I../external/jssy/jssy/ -g -O2 -std=c11 -D TSSCHECKER_VERSION_COUNT=\"294\" -D TSSCHECKER_VERSION_SHA=\"04c4044893513248c46a45ef250de544856d9a9e\" -o tsschecker tsschecker-tsschecker.o tsschecker-tss.o tsschecker-download.o tsschecker-main.o -L/usr/local/Cellar/libplist/2.0.0_1/lib -L/usr/local/Cellar/libfragmentzip/46/lib -L/usr/local/Cellar/libzip/1.5.2/lib -L/usr/local/Cellar/libirecovery/git0/lib -lplist -lfragmentzip -lzip -lz -lcurl -lirecovery -lm libjssy.a
Undefined symbols for architecture x86_64:
"__plist_dict_get_bool", referenced from:
_tss_request_add_ap_tags in tsschecker-tss.o
_tss_request_add_rose_tags in tsschecker-tss.o
_tss_request_add_veridian_tags in tsschecker-tss.o
"__plist_dict_get_uint", referenced from:
_tss_request_add_baseband_tags in tsschecker-tss.o
_tss_request_add_rose_tags in tsschecker-tss.o
_tss_request_add_veridian_tags in tsschecker-tss.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [tsschecker] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
________________________________________________________________________________
| /Volumes/TJD128GB/iPhone-src/tsschecker-13-10-2019 @ MacBook Pro (suzughia)
| =>
there is an issue just posted here on GitHub
https://github.com/tihmstar/tsschecker/issues/144
and it has a dirty workaround but I can't use it for fixing the error.
Any one that would or could help me?
Thanks!
|
|
|
iOS 13.1.3 / 13 / 12 CFW Creation: How To Extract Keys And Decrypt IPSW |
|
Posted by: GeoSn0w - 10-23-2019, 09:30 AM - Forum: iCloud Bypass Research
- Replies (2)
|
 |
In this video, we're going to start the process of CFW creation for iOS 13.1.3, #iOS 13.0, iOS 12.4.1 or even iOS 11 (any iOS version that works with CheckM8 compatible devices). And as we start, the first logical step is to be able to extract the decryption keys for iBEC, iBSS, and iBoot which need patching for a CFW to work. These files are packed inside an IM4P container which also contains the decryption key and IV, but these keys are encrypted themselves in a KBAG which can only be decrypted by the device's chip. While we cannot get access to the GID key, we can use CheckM8 exploit by @axi0mX to decrypt these.
This step is crucial in the process of CFW creation on iOS because if you cannot decrypt the files, you cannot patch them. The CheckM8 exploit released by @axi0mX is compatible with iPhone 4S all the way up to iPhone X on all iOS versions compatible with these devices, past present or future. So you can do this procedure on any supported iOS version. Keep in mind that the keys you obtain using #CheckM8 are usable for your iPhone model. For example, if you have an iPhone X and you extract the keys for iOS 13.1.3 iBoot, the keys will work on all iPhone X devices on that version. The GID key changes per CPU not per individual device.
|
|
|
How to Decrypt iOS (iBoot, iBEC, iBSS, Ramdisk, etc) on iOS 13 / iOS 12 With CheckM8 |
|
Posted by: GeoSn0w - 10-21-2019, 09:16 PM - Forum: iCloud Bypass Research
- Replies (71)
|
 |
In this post, I am going to show you how to decrypt the iOS Boot Chain components such as iBEC, iBSS, iBoot, the Restore Ramdisk and so on by derivating their keys using the CheckM8 SecureROM (BootROM) exploit. We're going to do this for iOS 13.x but you could use literally any version on the supported devices. The supported devices are the iPhone 4S all the way up to iPhone X and everything in between.
For the sake of this post, I will use an iPod Touch 2019 (iPod Touch 7) which has the A10 Chip (compatible with CheckM8). I am also using the latest version of the CheckM8 exploit which is part of the ipwndfu repo on @axi0mX's GitHub.
Now, as you probably know, if you wanna build an iOS CFW you need to patch iBEC, iBSS, iBoot, the Ramdisk and so on. These are part of an IMG4 / IM4P container on 64-Bit iOS devices, and IMG3 containers on 32-Bit devices like iPhone 5, iPhone 5C and 4S. The container is encrypted. The key used to decrypt it is only available on the device's silicon and it cannot be extracted and used outside. However, using CheckM8, we can get access to the AES engine and ask it to derivate the decryption KEY and IV for us by feeding it the KBAG from the firmware component. Of course, normally, iOS turns this engine off ass soon as iBoot finishes doing its job at boot-time, but using this exploit we can just use it how much we want.
Keep in mind that each iOS device has a different key, so the decryption keys for iBEC for example from my iPod 7 will not work on the same iBEC from the same iOS version your iPhone 5S (for example). Each device model has a different GID key. Brute-forcing the key is useless. There way too many possible keys it would take billions of years to brute-force if even possible. While the GID key remains tightly encapsulated and protected, we can still take advantage of it if the iOS device is pwned at iBoot or SecureROM level.
Important note: The Key and IV used to decrypt the iOS components are actually stored inside each component as part of their IMG4 container inside the KBAG. However, the KEY + IV pair is also encrypted with another unique key called a GID key. This is the key we can never extract. Using the open window checkM8 brings to this key through the AES engine, we can decrypt the KBAG which will render the unencrypted plain-text Key and IV used to decrypt the actual data.
1.0 Gathering your tools:
For this operation, you will need a couple of tools. They are all listed here, available for you to download.
Please do keep in mind that at the time I am writing this write-up, you can only do this on a macOS machine. Either virtual or physical.
> ipwndfu: https://github.com/axi0mX/ipwndfu
> IMG4TOOL: https://github.com/tihmstar/img4tool
> IMG4: https://mega.nz/#!kh9HwALK!z65nLcHWj_Ivu...q3XHe97_Vg
2.0 Obtaining the right iPSW file for your iOS version and device.
Of course, if you wanna decrypt the iOS for your device, you need the proper IPSW you wanna convert into a CFW. I recommend using ipsw.me to get the iPSW file for your iOS version and your device. Once you have it, rename it from ".ipsw" to ".zip" so that you can extract it. Double-click on the archive to extract it and wait until the extraction is complete.
Inside the iPSW you can see that there is a specific directory structure. Inside the DFU folder, you can find the iBEC and iBSS. Apple combines nowadays the firmware for multiple devices with the same screen size into the same IPSW, so make sure you get the files for your model. Usually, they are named after the device identifier.
For the sake of this write-up, I will extract the iBoot and the iBSS for my iPod and place them on my Desktop.
3.0 Obtaining the KBAG from the IM4P / IMG4 firmware component.
As I said, the decryption keys for each component are stored inside the component itself, but they're encrypted. The encrypted chunk is called a KBAG. We can use IMG4TOOL by @tihmstar to extract the KBAG.
In Terminal run the following commands:
Code: chmod 775 /path/to/your/compiled/IMG4TOOL
./img4tool -a /path/to/encrypted/file
Then press Return (Enter).
In my case, it looks like this:
![[Image: 1.png]](https://i.ibb.co/WfXkCRX/1.png)
As you can see, the program yields two different KBAGs, num 1 and num 2. You're interested in num 1 because that one is for RELEASE fused devices. The other one is for DEVELOPMENT devices which they use internally at the factory.
You need to copy the long alphanumeric string after num: 1. That is your KBAG.
So in my case, the KBAG is:
Code: 493d1322792f9688c135567ee1c30e388ef162b030d229a986f8fded4b0a45d2cb1971400fb93cf6b884bf223b11944d
4.0 Decrypting the KBAG with CheckM8 and a compatible pwned device.
As you can see, we got the KBAG, but it's completely useless. We cannot use it to decrypt the data because the KBAG is an encrypted pair of KEY + IV. We need to pwn the matching device with checkm8 in DFU mode, and then use the AES engine to decrypt the KBAG.
Follow these steps to get your device in PWNED DFU MODE with CheckM8.
1) Plug the device to the computer using a USB cable.
2) Press and hold POWER + either HOME if you have an iPhone 6S Plus or older, or Volume DOWN until the phone goes dark.
3) Wait 5 seconds while holding both after the screen goes black.
4) Release the Power button but keep holding HOME or Volume Down depending on the device, for 14 more seconds.
5) Release the HOME / Volume Down button.
6) Now run the ipwndfu in terminal.
The command should look like this, assuming you extracted the GitHub repo for ipwndfu in a folder on Desktop:
Code: cd /Users/geosn0w/Desktop/ipwndfu-master
./ipwndfu -p
You may need to run the ./ipwndfu -p more than once if it fails. Once it succeeds it should look like mine:
![[Image: 2.png]](https://i.ibb.co/frvhF1P/2.png)
Now that the device is pwned, we can abuse its AES engine to decrypt our KEY + IV.
To decrypt the KBAG, we need to run "./ipwndfu --decrypt-gid=YOUR KBAG" in Terminal. It should look like this once done:
![[Image: 3.png]](https://i.ibb.co/qpRMhVQ/3.png)
As you can see, the decryption was successful and we obtained yet another confusing string. Fear not, this is the actual KEY and IV, but they are concatenated.
5.0 Extracting the KEY + IV for your component
That long string is basically the KEY and the IV, you just don't know how much of it is the key and how much of it is the IV. The first 64 characters are the KEY and the rest 32 are the IV.
So in this case, the KEY is:
570c42b1ae1af1ab9639b5b4b1983938b52b19662dabd101d74ca0529aa914e5
And the IV is:
3080bfc320a827ac89d3106831a06166
6.0 Using the KEY + IV to decrypt the firmware component
Now we can use the KEY + IV and the tool called IMG4 to actually decrypt iBSS / iBoot etc.
To do that, we need to run the following commands:
Code: chmod 775 /Users/geosn0w/Desktop/img4
/Users/geosn0w/Desktop/img4 -image /Users/geosn0w/Desktop/iBoot.n112.RELEASE.im4p iBoot-Decrypted-AF 570c42b1ae1af1ab9639b5b4b1983938b52b19662dabd101d74ca0529aa914e53080bfc320a827ac89d3106831a06166
Of course, adapt the paths for your computer/locations.
Once we press enter, we should get only one word: the type of the file. In this case "ibot" means iBoot file. This means that the decryption was successful. You can see that by the fact that a new file was created with the second file name you specified (iBoot-Decrypted-AF) and when you open that file in a HEX editor, it should look like this.
![[Image: 22.png]](https://i.ibb.co/T1Y9sc6/22.png)
And that's all :-) You can now patch, reverse engineer or do whatever to the decrypted file.
~GeoSn0w (@FCE365)
NOTE: This forum is not endorsed in any way by Apple Inc. iPhone and iOS are trademarks of Apple Inc. All the info provided here is strictly for educational purposes. You are the only one responsible for how you use this information.
|
|
|
| screen time , encrypt |
|
Posted by: Fockerwolf - 10-21-2019, 11:47 AM - Forum: iCloud Bypass Questions
- Replies (1)
|
 |
Hello guys I am new here, I wonder if it is possible to find out screen time passcode on latest iOS without erasing device? , while phone is encrypted and? I used Pinfinder for older versions , but now I cannot find the location of this passcode in backups , can anyone help?
|
|
|
|