[EXPERIMENTAL][i9505] Possibility to Downgrade to an old Bootloader!

Status
Not open for further replies.
Search This thread

Kaito95

Senior Member
Sep 11, 2012
87
211
Düsseldorf
before you read -> please use at your own risk!! I am not responsible for any damage!! Use it only if you have a jtag or a riffbox

Hello dear Developer,

I offer you modified files which may possible to Downgrade to an old Bootloader. Every file has the new Samsung Certificate from Android 4.3 Bootloader (XXUEMK8).
This Bootloader is based on Android 4.2.2 firmware (XXUBMGA).

My presumption is that the new Bootloader has something to do with the new Samsung Certificate inside the new Knox enabled Bootloader.
If we flash a newer firmware it will fail because the KNOX bootloader checks the certificate while we flash an older/newer bootloader.
We know that is not possible to Downgrade to an old Bootloader if it has not the same certificate.


aboot.mbn -> https://www.dropbox.com/s/isb22plz7kvnve8/aboot.mbn
rpm.mbn -> https://www.dropbox.com/s/sng6w4lyc6p8w22/rpm.mbn
sbl2.mbn -> https://www.dropbox.com/s/x8hh3livuqh6xku/sbl2.mbn
sbl3.mbn -> https://www.dropbox.com/s/inzx4396x4zdcj1/sbl3.mbn
tz.mbn -> https://www.dropbox.com/s/973ue0rdp80qgbn/tz.mbn

I'll attach you five modified files (aboot.mbn, tz.mbn, sbl2.mbn, sbl3.mbn and rpm.mbn). It's from the XXUBMGA files which has the new certificates from XXUEMK8.

I edited the old Bootloader and I replace the old certificate with the new one from Android 4.3 Bootloader. There are a few differences between the both certificates.

That means:
Updating from MJX to a newer version -> possible
Downgrading from 4.3 to 4.2.2 -> not possible -> Certificates doesn't match with the new one or with the current one
Updating the same firmware (e.g. 4.3 XXUEMK8 -> XXUEMK8) --> also possible

Older firmware like XXUEMJ5 (older than XXUEMK8) is not possible unless we include the modified files to a odin flashable firmware. If we get newer firmwares with new bootloader (certificates) we will not able to flash my modified bootloader.



UPDATE:
Now with Odin flashable tar.md5 file. Big thanks to @mike_galaxy_s
Download
FLASH IT AT YOUR OWN RISK!


Some useful information concerning the Mount Points from GT-i9505 from Android 4.3 XXUEMKE
root@jflte:/ # ls -al /dev/block/platform/msm_sdcc.1/by-name/
lrwxrwxrwx root root aboot -> /dev/block/mmcblk0p6
lrwxrwxrwx root root apnhlos -> /dev/block/mmcblk0p1
lrwxrwxrwx root root backup -> /dev/block/mmcblk0p23
lrwxrwxrwx root root boot -> /dev/block/mmcblk0p20
lrwxrwxrwx root root cache -> /dev/block/mmcblk0p18
lrwxrwxrwx root root carrier -> /dev/block/mmcblk0p28
lrwxrwxrwx root root efs -> /dev/block/mmcblk0p10
lrwxrwxrwx root root fota -> /dev/block/mmcblk0p22
lrwxrwxrwx root root fsg -> /dev/block/mmcblk0p24
lrwxrwxrwx root root hidden -> /dev/block/mmcblk0p27
lrwxrwxrwx root root m9kefs1 -> /dev/block/mmcblk0p13
lrwxrwxrwx root root m9kefs2 -> /dev/block/mmcblk0p14
lrwxrwxrwx root root m9kefs3 -> /dev/block/mmcblk0p15
lrwxrwxrwx root root mdm -> /dev/block/mmcblk0p2
lrwxrwxrwx root root modemst1 -> /dev/block/mmcblk0p11
lrwxrwxrwx root root modemst2 -> /dev/block/mmcblk0p12
lrwxrwxrwx root root pad -> /dev/block/mmcblk0p9
lrwxrwxrwx root root param -> /dev/block/mmcblk0p19
lrwxrwxrwx root root persdata -> /dev/block/mmcblk0p26
lrwxrwxrwx root root persist -> /dev/block/mmcblk0p17
lrwxrwxrwx root root recovery -> /dev/block/mmcblk0p21
lrwxrwxrwx root root rpm -> /dev/block/mmcblk0p7
lrwxrwxrwx root root sbl1 -> /dev/block/mmcblk0p3
lrwxrwxrwx root root sbl2 -> /dev/block/mmcblk0p4
lrwxrwxrwx root root sbl3 -> /dev/block/mmcblk0p5
lrwxrwxrwx root root ssd -> /dev/block/mmcblk0p25
lrwxrwxrwx root root system -> /dev/block/mmcblk0p16
lrwxrwxrwx root root tz -> /dev/block/mmcblk0p8
lrwxrwxrwx root root userdata -> /dev/block/mmcblk0p29

root@jflte:/ # cat /proc/mounts
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,seclabel,relatime,mode=600 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,seclabel,relatime 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
/sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/secure tmpfs rw,seclabel,relatime,mode=700 0 0
tmpfs /mnt/asec tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
/dev/block/dm-0 /mnt/asec/com.picsart.studio-2 ext4 ro,dirsync,seclabel,nosuid,nodev,noatime,errors=continue 0 0
tmpfs /mnt/obb tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,seclabel,relatime,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,errors=panic,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/apnhlos /firmware vfat ro,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=lower,errors=remount-ro 0 0
/dev/block/platform/msm_sdcc.1/by-name/mdm /firmware-mdm vfat ro,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=lower,errors=remount-ro 0 0
/dev/block/platform/msm_sdcc.1/by-name/efs /efs ext4 rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,errors=panic,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/persdata /persdata/absolute ext4 rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0
/data/container /mnt/shell/container sdcardfs rw,nosuid,nodev,relatime,uid=1000,gid=1000 0 0
/data/media /mnt/shell/emulated sdcardfs rw,nosuid,nodev,relatime,uid=1023,gid=1023 0 0
tmpfs /storage/emulated tmpfs rw,seclabel,nosuid,nodev,relatime,mode=050,gid=1028 0 0
/dev/block/vold/179:33 /storage/extSdCard exfat rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1023,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=utf8,namecase=0,errors=remount-ro 0 0
tmpfs /storage/extSdCard/.android_secure tmpfs ro,seclabel,relatime,size=0k,mode=000 0 0
/data/media /storage/emulated/0 sdcardfs rw,nosuid,nodev,relatime,uid=1023,gid=1023 0 0
/data/media /storage/emulated/0/Android/obb sdcardfs rw,nosuid,nodev,relatime,uid=1023,gid=1023 0 0
/data/media /storage/emulated/legacy sdcardfs rw,nosuid,nodev,relatime,uid=1023,gid=1023 0 0
/data/media /storage/emulated/legacy/Android/obb sdcardfs rw,nosuid,nodev,relatime,uid=1023,gid=1023 0 0

root@jflte:/ # cat /proc/partitions
major minor #blocks name

7 0 17703 loop0
253 0 512000 zram0
179 0 15388672 mmcblk0
179 1 12772 mmcblk0p1
179 2 52764 mmcblk0p2
179 3 128 mmcblk0p3
179 4 256 mmcblk0p4
179 5 512 mmcblk0p5
179 6 2048 mmcblk0p6
179 7 512 mmcblk0p7
179 8 512 mmcblk0p8
179 9 16896 mmcblk0p9
179 10 13952 mmcblk0p10
179 11 3072 mmcblk0p11
179 12 3072 mmcblk0p12
179 13 780 mmcblk0p13
179 14 780 mmcblk0p14
179 15 780 mmcblk0p15
179 16 2826240 mmcblk0p16
179 17 8192 mmcblk0p17
179 18 2119680 mmcblk0p18
179 19 6144 mmcblk0p19
179 20 10240 mmcblk0p20
179 21 10240 mmcblk0p21
179 22 10240 mmcblk0p22
179 23 6144 mmcblk0p23
179 24 3072 mmcblk0p24
179 25 8 mmcblk0p25
179 26 9216 mmcblk0p26
179 27 512000 mmcblk0p27
179 28 20480 mmcblk0p28
179 29 9728000 mmcblk0p29
179 32 30657536 mmcblk1
179 33 30656512 mmcblk1p1
254 0 17703 dm-0


best regards,
Kaito95
 
Last edited:

Easton999GS

Senior Member
Aug 31, 2010
368
103
what about devices with a locked bootloader, Ex. Verizon and AT&T Galaxy S4 ? would this be possible to flash the modified bootloader on those phones?
This probably wont work in general because you completely forgot to take Qfuses into consideration. You cant downgrade after one of the Qfuses is blown, period. Certificates/downgrading would only work if that didn't exist.
 
Last edited:

Kaito95

Senior Member
Sep 11, 2012
87
211
Düsseldorf
what about devices with a locked bootloader, Ex. Verizon and AT&T Galaxy S4 ? would this be possible to flash the modified bootloader on those phones?
This probably wont work in general because you completely forgot to take Qfuses into consideration. You cant downgrade after one of the Qfuses is blown, period. Certificates/downgrading would only work if that didn't exist.

Sorry, i don't know how about devices with a locked bootloader :/

It's only my presumption. I think there are more things that I look for a success flash. I must find the location of files which depends while flashing an old Bootloader :)


If someone find more information, you can post it here. I'll look it :) i would be glad if someone make an odin flashable tar file.


Gesendet von meinem GT-I9505 mit Tapatalk 2
 

joiN85

Senior Member
May 3, 2011
158
146
Italy
This is sbl1.mbn from OLD mga bootloader,
please change certifiate from sbl1 mk8 bootloader!
 

Attachments

  • sbl1.rar
    38.6 KB · Views: 833

dpeddi

Senior Member
Mar 10, 2007
206
133
Are your sure of what you have done? To sign a file you need the private key... if you copied the signature from another file it shouldn't be valid.

Inviato dal mio GT-I9505 utilizzando Tapatalk
 

Kaito95

Senior Member
Sep 11, 2012
87
211
Düsseldorf
Are your sure of what you have done? To sign a file you need the private key... if you copied the signature from another file it shouldn't be valid.

Inviato dal mio GT-I9505 utilizzando Tapatalk

Yes, I'm very sure :) the certificates between the old Bootloader and the new Bootloader are different and at least they've the same bytes at the end. I'll post screenshots later ;) you can see how many differences they are. I don't change anything on the Bootloader except the certificates :)

If you found anything which is useful for me please let me know ;)


Gesendet von meinem GT-I9505 mit Tapatalk 2
 

Kaito95

Senior Member
Sep 11, 2012
87
211
Düsseldorf
Kaito95:

Phone:
Samsung Galaxy S4 GT-i9505
ROM:Stock Firmware XXUEMJ5 Germany DBT
Kernel:Stock Kernel
Recovery:PhilZ Touch v5.18.9
System Status: Official :cowboy:
Binary Status: Samsung Official :cowboy:


How'd you do that? recovery Philz did not you stay in 0x1? Mirroring works? you have root?



I have the new Bootloader unfortunately and the knox flag stay on 0x1 but i could make binary and system status official with mobile odin and wanam xposed. On old Bootloader it stays to custom if I flash a recovery through mobile odin however. I can't test the screen mirroring functionality yet.



Gesendet von meinem GT-I9505 mit Tapatalk 2
 

dpeddi

Senior Member
Mar 10, 2007
206
133
Please explain me how you add the signature... i suspect you copied and paste from another file. This isn't the right way. The signature is related to the signed file. You method can work only if the samsung bootloader is bugged like some motorola bootloaders.

Inviato dal mio GT-I9505 utilizzando Tapatalk
 

Kaito95

Senior Member
Sep 11, 2012
87
211
Düsseldorf
Please explain me how you add the signature... i suspect you copied and paste from another file. This isn't the right way. The signature is related to the signed file. You method can work only if the samsung bootloader is bugged like some motorola bootloaders.

Inviato dal mio GT-I9505 utilizzando Tapatalk


I add the new signatures with a hex editor (UltraEdit) . I have looked for the precise locations where a certificate is present and changed it. The sizes of both files are identical and i don't overwrite anything except the signatures at the end. After that I compared it (UltraCompare) and thats it.

Look here:
-> rpm.mbn
-> aboot.mbn → (1) (2) (3)
-> sbl2.mbn ' sbl3.mbn ' tz.mbn (same as rpm.mbn -> layout)

↓ detailed ↓

ABOOT.mbn (XXUBMGA) Samsungs Zertifikate
Begin Header: --> 00119090h (-> 4A C7 9C 08 F6 A5 B9 BD ED DC .....)

ABOOT.mbn (XXUEMK8) Samsungs NEUE Zertifikate
Begin Header: --> 001326b0h ( [c column] -> 98 27 6D 40)


tz.mbn (XXUBMGA)
Begin Header: 000309b0h ([c column] -> 8D ED 48 79 ... )

tz.mbn (XXUEMK8)
Begin Header: 000309b0h ([c column] -> 42 F6 55 68 ... )


sbl2.mbn (XXUBMGA)
Begin Header: 00022060h (8th column] -> 69 1D D5 EB .... )

sbl2.mbn (XXUEMK8)
Begin Header: 00022060h ([8th column] -> 1C 02 01 EA .... )


sbl3.mbn (XXUBMGA)
Begin Header:0003ef10h ([c column] -> 94 00 F0 8F .... )

sbl3.mbn (XXUEMK8)
Begin Header: 0003ef20h ([c column] -> 94 00 F0 8F .... )


rpm.mbn (XXUBMGA)
Begin Header: 00022500h ([8th column] -> 0E 48 00 B5 00 68 9D B0)

rpm.mbn (XXUEMK8)
Begin Header: 00022500h ([8th column] -> 0E 48 00 B5 00 68 9D B0)
 

k1mu

Senior Member
Apr 11, 2011
1,945
1,620
Virginia
I add the new signatures with a hex editor (UltraEdit) . I have looked for the precise locations where a certificate is present and changed it. The sizes of both files are identical and i don't overwrite anything except the signatures at the end. After that I compared it (UltraCompare) and thats it.

Apparently you have no idea how digital signatures work.

The signature uses the input data, hashes it, then signs it with the private key. The public key, which is distributed with the certificate, is used to verify the signature. If you don't have the private key, you can't make a valid signature from new input. Copying certificates around won't help you unless you have the private key that corresponds to the certificates that you're playing with.
 

Kaito95

Senior Member
Sep 11, 2012
87
211
Düsseldorf
Apparently you have no idea how digital signatures work.

The signature uses the input data, hashes it, then signs it with the private key. The public key, which is distributed with the certificate, is used to verify the signature. If you don't have the private key, you can't make a valid signature from new input. Copying certificates around won't help you unless you have the private key that corresponds to the certificates that you're playing with.

Could be ;)

I thought that the private keys are inside the certificate. While I editing the files, I saw lines that redirect to a http website. As I already have said, there are more things that we must change!



Gesendet von meinem GT-I9505 mit Tapatalk 2
 

k1mu

Senior Member
Apr 11, 2011
1,945
1,620
Virginia
Could be ;)

I thought that the private keys are inside the certificate. While I editing the files, I saw lines that redirect to a http website. As I already have said, there are more things that we must change!

Nope. The public key is in the certificate. The only way you're going to get the private key is via a leak.
The URLs in the certificate are most likely CDPs (certificate revocation list distribution point) or OCSP (Online certificate status protocol) addresses. Those permit the certificate issuer to invalidate it if it becomes compromised.
 

Kaito95

Senior Member
Sep 11, 2012
87
211
Düsseldorf
Nope. The public key is in the certificate. The only way you're going to get the private key is via a leak.
The URLs in the certificate are most likely CDPs (certificate revocation list distribution point) or OCSP (Online certificate status protocol) addresses. Those permit the certificate issuer to invalidate it if it becomes compromised.



Damn... :)

Do you think that we could get the private key through an OTA Update inside the update-zip?? If yes, we could integrate the old Bootloader inside the update-zip... :confused: ?


Gesendet von meinem GT-I9505 mit Tapatalk 2
 

tech_head

Senior Member
Damn... :)

Do you think that we could get the private key through an OTA Update inside the update-zip?? If yes, we could integrate the old Bootloader inside the update-zip... :confused: ?


Gesendet von meinem GT-I9505 mit Tapatalk 2

Private key is just that.
It's locked in a vault somewhere. Unless it gets leaked, forget about it.
Keys have been leaked before, but you aren't going to get the keys through brute force or any other computerized method.

To sign the boot loader, you need the key *AND* the hash.
 

Adnan73

Member
Nov 22, 2013
30
5
@Kaito95

Do you know that modem.bin contains sbl and rpm
(there are many other things related to Knox bootloader and downgrade)
 
Last edited:
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 12
    before you read -> please use at your own risk!! I am not responsible for any damage!! Use it only if you have a jtag or a riffbox

    Hello dear Developer,

    I offer you modified files which may possible to Downgrade to an old Bootloader. Every file has the new Samsung Certificate from Android 4.3 Bootloader (XXUEMK8).
    This Bootloader is based on Android 4.2.2 firmware (XXUBMGA).

    My presumption is that the new Bootloader has something to do with the new Samsung Certificate inside the new Knox enabled Bootloader.
    If we flash a newer firmware it will fail because the KNOX bootloader checks the certificate while we flash an older/newer bootloader.
    We know that is not possible to Downgrade to an old Bootloader if it has not the same certificate.


    aboot.mbn -> https://www.dropbox.com/s/isb22plz7kvnve8/aboot.mbn
    rpm.mbn -> https://www.dropbox.com/s/sng6w4lyc6p8w22/rpm.mbn
    sbl2.mbn -> https://www.dropbox.com/s/x8hh3livuqh6xku/sbl2.mbn
    sbl3.mbn -> https://www.dropbox.com/s/inzx4396x4zdcj1/sbl3.mbn
    tz.mbn -> https://www.dropbox.com/s/973ue0rdp80qgbn/tz.mbn

    I'll attach you five modified files (aboot.mbn, tz.mbn, sbl2.mbn, sbl3.mbn and rpm.mbn). It's from the XXUBMGA files which has the new certificates from XXUEMK8.

    I edited the old Bootloader and I replace the old certificate with the new one from Android 4.3 Bootloader. There are a few differences between the both certificates.

    That means:
    Updating from MJX to a newer version -> possible
    Downgrading from 4.3 to 4.2.2 -> not possible -> Certificates doesn't match with the new one or with the current one
    Updating the same firmware (e.g. 4.3 XXUEMK8 -> XXUEMK8) --> also possible

    Older firmware like XXUEMJ5 (older than XXUEMK8) is not possible unless we include the modified files to a odin flashable firmware. If we get newer firmwares with new bootloader (certificates) we will not able to flash my modified bootloader.



    UPDATE:
    Now with Odin flashable tar.md5 file. Big thanks to @mike_galaxy_s
    Download
    FLASH IT AT YOUR OWN RISK!


    Some useful information concerning the Mount Points from GT-i9505 from Android 4.3 XXUEMKE
    root@jflte:/ # ls -al /dev/block/platform/msm_sdcc.1/by-name/
    lrwxrwxrwx root root aboot -> /dev/block/mmcblk0p6
    lrwxrwxrwx root root apnhlos -> /dev/block/mmcblk0p1
    lrwxrwxrwx root root backup -> /dev/block/mmcblk0p23
    lrwxrwxrwx root root boot -> /dev/block/mmcblk0p20
    lrwxrwxrwx root root cache -> /dev/block/mmcblk0p18
    lrwxrwxrwx root root carrier -> /dev/block/mmcblk0p28
    lrwxrwxrwx root root efs -> /dev/block/mmcblk0p10
    lrwxrwxrwx root root fota -> /dev/block/mmcblk0p22
    lrwxrwxrwx root root fsg -> /dev/block/mmcblk0p24
    lrwxrwxrwx root root hidden -> /dev/block/mmcblk0p27
    lrwxrwxrwx root root m9kefs1 -> /dev/block/mmcblk0p13
    lrwxrwxrwx root root m9kefs2 -> /dev/block/mmcblk0p14
    lrwxrwxrwx root root m9kefs3 -> /dev/block/mmcblk0p15
    lrwxrwxrwx root root mdm -> /dev/block/mmcblk0p2
    lrwxrwxrwx root root modemst1 -> /dev/block/mmcblk0p11
    lrwxrwxrwx root root modemst2 -> /dev/block/mmcblk0p12
    lrwxrwxrwx root root pad -> /dev/block/mmcblk0p9
    lrwxrwxrwx root root param -> /dev/block/mmcblk0p19
    lrwxrwxrwx root root persdata -> /dev/block/mmcblk0p26
    lrwxrwxrwx root root persist -> /dev/block/mmcblk0p17
    lrwxrwxrwx root root recovery -> /dev/block/mmcblk0p21
    lrwxrwxrwx root root rpm -> /dev/block/mmcblk0p7
    lrwxrwxrwx root root sbl1 -> /dev/block/mmcblk0p3
    lrwxrwxrwx root root sbl2 -> /dev/block/mmcblk0p4
    lrwxrwxrwx root root sbl3 -> /dev/block/mmcblk0p5
    lrwxrwxrwx root root ssd -> /dev/block/mmcblk0p25
    lrwxrwxrwx root root system -> /dev/block/mmcblk0p16
    lrwxrwxrwx root root tz -> /dev/block/mmcblk0p8
    lrwxrwxrwx root root userdata -> /dev/block/mmcblk0p29

    root@jflte:/ # cat /proc/mounts
    rootfs / rootfs ro,relatime 0 0
    tmpfs /dev tmpfs rw,seclabel,nosuid,relatime,mode=755 0 0
    devpts /dev/pts devpts rw,seclabel,relatime,mode=600 0 0
    none /dev/cpuctl cgroup rw,relatime,cpu 0 0
    proc /proc proc rw,relatime 0 0
    sysfs /sys sysfs rw,seclabel,relatime 0 0
    selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
    /sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0
    none /acct cgroup rw,relatime,cpuacct 0 0
    tmpfs /mnt/secure tmpfs rw,seclabel,relatime,mode=700 0 0
    tmpfs /mnt/asec tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
    /dev/block/dm-0 /mnt/asec/com.picsart.studio-2 ext4 ro,dirsync,seclabel,nosuid,nodev,noatime,errors=continue 0 0
    tmpfs /mnt/obb tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
    /dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,seclabel,relatime,data=ordered 0 0
    /dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,data=ordered 0 0
    /dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,errors=panic,data=ordered 0 0
    /dev/block/platform/msm_sdcc.1/by-name/apnhlos /firmware vfat ro,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=lower,errors=remount-ro 0 0
    /dev/block/platform/msm_sdcc.1/by-name/mdm /firmware-mdm vfat ro,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=lower,errors=remount-ro 0 0
    /dev/block/platform/msm_sdcc.1/by-name/efs /efs ext4 rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,errors=panic,data=ordered 0 0
    /dev/block/platform/msm_sdcc.1/by-name/persdata /persdata/absolute ext4 rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0
    /data/container /mnt/shell/container sdcardfs rw,nosuid,nodev,relatime,uid=1000,gid=1000 0 0
    /data/media /mnt/shell/emulated sdcardfs rw,nosuid,nodev,relatime,uid=1023,gid=1023 0 0
    tmpfs /storage/emulated tmpfs rw,seclabel,nosuid,nodev,relatime,mode=050,gid=1028 0 0
    /dev/block/vold/179:33 /storage/extSdCard exfat rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1023,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=utf8,namecase=0,errors=remount-ro 0 0
    tmpfs /storage/extSdCard/.android_secure tmpfs ro,seclabel,relatime,size=0k,mode=000 0 0
    /data/media /storage/emulated/0 sdcardfs rw,nosuid,nodev,relatime,uid=1023,gid=1023 0 0
    /data/media /storage/emulated/0/Android/obb sdcardfs rw,nosuid,nodev,relatime,uid=1023,gid=1023 0 0
    /data/media /storage/emulated/legacy sdcardfs rw,nosuid,nodev,relatime,uid=1023,gid=1023 0 0
    /data/media /storage/emulated/legacy/Android/obb sdcardfs rw,nosuid,nodev,relatime,uid=1023,gid=1023 0 0

    root@jflte:/ # cat /proc/partitions
    major minor #blocks name

    7 0 17703 loop0
    253 0 512000 zram0
    179 0 15388672 mmcblk0
    179 1 12772 mmcblk0p1
    179 2 52764 mmcblk0p2
    179 3 128 mmcblk0p3
    179 4 256 mmcblk0p4
    179 5 512 mmcblk0p5
    179 6 2048 mmcblk0p6
    179 7 512 mmcblk0p7
    179 8 512 mmcblk0p8
    179 9 16896 mmcblk0p9
    179 10 13952 mmcblk0p10
    179 11 3072 mmcblk0p11
    179 12 3072 mmcblk0p12
    179 13 780 mmcblk0p13
    179 14 780 mmcblk0p14
    179 15 780 mmcblk0p15
    179 16 2826240 mmcblk0p16
    179 17 8192 mmcblk0p17
    179 18 2119680 mmcblk0p18
    179 19 6144 mmcblk0p19
    179 20 10240 mmcblk0p20
    179 21 10240 mmcblk0p21
    179 22 10240 mmcblk0p22
    179 23 6144 mmcblk0p23
    179 24 3072 mmcblk0p24
    179 25 8 mmcblk0p25
    179 26 9216 mmcblk0p26
    179 27 512000 mmcblk0p27
    179 28 20480 mmcblk0p28
    179 29 9728000 mmcblk0p29
    179 32 30657536 mmcblk1
    179 33 30656512 mmcblk1p1
    254 0 17703 dm-0


    best regards,
    Kaito95
    4
    Old devices like SGS3 and N2 have been developed when KNOX wasn't exist. So, these devices may have not enough protection against rolling back from KNOX infected bootloaders.
    SGS4 was developed together with KNOX (but not enabled at launch day), SGS4 has hardware protection against writes to boot block. Only bootloader itself can write at the early stage of booting. Once bootloader switch write protection flag on, you can't reset it till physical reboot or power cycle.

    So basically, the only way to re-write the bootloader is by hardbricking the device and using the QHSUSB drivers to recover and re-flash the software? That is what we had to do with the EVO3D....hmmm...food for thought...

    but, I think the reason the MC2 back to stock works on the note2 is because there is a script to bypass mmcblk0 when it reboots into a temporary cache partition, i might be wrong, and I probably am, but if it is possible to bypass aboot or mmcblk0boot0 into a temporary partition like fota, like samsung uses, then it may be possible to write over these partitions from the temporary, like chainfire's triangle away does to change the flash count back to zero....off topic, just for laughs I sent an email to Samsung's tech support explaining how my phone was infected by a terrible virus that has taken control of everything and won't let me do anything, and asked them if they could point me in the direction of an anti-virus that could get rid of the Knox virus
    3
    I add the new signatures with a hex editor (UltraEdit) . I have looked for the precise locations where a certificate is present and changed it. The sizes of both files are identical and i don't overwrite anything except the signatures at the end. After that I compared it (UltraCompare) and thats it.

    Apparently you have no idea how digital signatures work.

    The signature uses the input data, hashes it, then signs it with the private key. The public key, which is distributed with the certificate, is used to verify the signature. If you don't have the private key, you can't make a valid signature from new input. Copying certificates around won't help you unless you have the private key that corresponds to the certificates that you're playing with.
    2
    Could be ;)

    I thought that the private keys are inside the certificate. While I editing the files, I saw lines that redirect to a http website. As I already have said, there are more things that we must change!

    Nope. The public key is in the certificate. The only way you're going to get the private key is via a leak.
    The URLs in the certificate are most likely CDPs (certificate revocation list distribution point) or OCSP (Online certificate status protocol) addresses. Those permit the certificate issuer to invalidate it if it becomes compromised.
    1
    Is it possible to reverse engineer the signing process that Samsung uses? Perhaps via setting up a large amount of computers to break whatever encryption their using....? I would be willing to put all 5 of my computers into working on this.

    Sent from my SM-P600 using xda app-developers app

    To be blunt, AES encryption will take a lot more than your 5 computers to even put a dent in it via brute force.

    Folks:
    No disrespect intended but I'm tempted to close this thread as it seems to be another wild goose chase thread.
    While I'm in support of people trying to find a way around that, recent conversation doesn't seem headed that way.
    Please keep the discussion relevant or move on to other things.