Resources for Samsung Galaxy TAB A 7.0 (2016) SM-T285

Search This thread

jedld

Senior Member
Oct 15, 2007
430
438
Bacoor
I've just got a new Samsung Galaxy TAB A 7.0 LTE SM-T285, For some reason I can't seem to find any resources for this hardware yet in this forum, anyone know where I could find one? I'll try to find out if the current methods (custom recovery and root) for other tab versions work on this.

CUSTOM ROMS
============

Android 5.1.1 Lollipop (Stock)


Tinker V5 Edition based on the Samsung Stock Rom SM-T280/T285


Android 6.0 Marshmallow

Cyanogenmod 13 for the SM-T285 Only
OMNIRom for the SM-T285 Only

Android 7.1 Nougat

Cyanogenmod 14.1 for the SM-T285 Only (Experimental, things are broken, depcrated in favor of LOS 14.1)
LineageOS 14.1 for the SM-T285 Only

Other Operating systems

Porting for Sailfish OS is currently in progress for the SM-T285, stay tuned

TWRP RECOVERY AND ROOT
=======================

TWRP is available for both the T280 and T285. You should find the relevant threads in this Galaxy Tab A forum.

If you want to root stock, easiest way is to install TWRP and go for SuperSU. Please see the TWRP threads for SM-T280/T285 on how to root after TWRP is installed.

KERNEL
======

Custom kernel with working sources for the SM-T285 can be found Here

DEVELOPMENT
============

If you want to build LineageOS 14.1 on your SM-T285 LTE device, you can use this manifest, not that this is still a work in progress:

https://github.com/jedld/android.git

UPDATE 10/06/2016
================

After a couple of weeks of trial and error and tinkering, I've been able to compile a kernel for the SM-T285 from source and so far it seems to work flawlessly!

Screenshot here: http://imgur.com/a/HRgsq

link to my kernel sources here: https://github.com/jedld/kernel_samsung_gtexslte.git

You can also thank samsung for giving us a "broken by default" kernel source. I had to mix and match defconfigs from their other kernel releases just to make this thing work. Download modified boot.img here:

http://forum.xda-developers.com/galaxy-tab-a/development/kernel-galaxy-tab-7-0-2016-lte-sm-t285-t3474967

UPDATE 09/20/2016
================

This device is now ROOTED!

http://forum.xda-developers.com/galaxy-tab-a/help/resources-samsung-galaxy-tab-7-0-2016-t3431022/post68777842#post68777842

Download Pre-rooted Tinker Edition V5 in this thread: Tinker Edition Thread

Post Root Post Mortem Analysis for the SM-T285 (09/21/2016)
=========================
Q: How were you able to find root? What did you do?
A: Surprisingly the SM-T285 bootloader isn't actually locked like we thought it was (Once you OEM unlock of course and disable FRP). The bottomline is that
we simply needed patches to mkbootimg to properly package a boot image for this device as there were additional fields and sections not found on a normal boot image. There were even minor breaking difference between the tab 4 and the boot image for this device.

Q: I thought the bootloader was locked?? Why did it take so long?
A: I blame it on the really vague errors the bootloader shows when loading an improperly packaged boot image. What helped was my faith to open up a hex editor when I needed to, and really look at the stock images and the images we were making. What really pushed me to investigate further was the fact that I was able to make a really small modification to the ramdisk and use the abootimg -u update function instead of the create options.

Q: So the bootloader doesn't really check the image?
A: Yup, The bootloader doesn't do any check. I haven't checked if that is the case for the recovery partition though. Even without the SELINUXENFORCE headers at the end it still continues like other samsung devices do.

Q: So the mkbootimg patches are all that we need?
A: Yup, if you have CM, AOSP build env ready you can simply add the modified mkbootimg to system/core:

https://github.com/jedld/degas-mkbootimg/commit/b63ae38e2ab7040cc7ddaef777652a56b2e48322

Sample usage below:

Code:
degas-mkbootimg -o boot.img --base 0 --pagesize 2048 \
  --kernel boot.img-zImage --cmdline "console=ttyS1,115200n8" --ramdisk boot_kitchen/boot.img-ramdisk-new.gz --dt boot.img-dt

Next challenge will be getting Cyanogenmod on this device as well as TWRP.
 
Last edited:

ashyx

Inactive Recognized Contributor
Oct 14, 2012
15,087
9,930
You won't because it has a locked bootloader, therefore not currently rootable and certainly no custom recovery.
 

ashyx

Inactive Recognized Contributor
Oct 14, 2012
15,087
9,930
Probably no hope for root. the PIT, boot and recovery are basically untouchable, selinux enforcing enabled also does not help. You can still debloat and customize the system partition though:

http://forum.xda-developers.com/android/development/guide-samsung-galaxy-tab-7-0-sm-t285-t3438296

I'm working on getting CM 12.1 to run on this device.
Yes at least the saving grace is that Samsung left Dm-verity off for this device.
If only they'd have left out the root restriction in the kernel too we'd have a rootable device.
I have an idea for this that I haven't tried yet.
Basically Samsung sends out security Policy updates via OTA, they recently released an SEPOLICY update to most devices breaking root. Chainfire patched this.
As this policy is stored in DATA and over rides the one in the boot.img it may be possible to use a patched SEPOLICY by creating a flashable DATA image with the patched SEPOLICY thereby removing the SElinux root restriction.

I ran it by Chainfire and he said in theory it should work except for that fact that the SEPOLICY in DATA is signed.

I have yet to try this out.

I think it would be difficult to get CM running as the kernel may need some patches and as we know that can't be touched.
 
Last edited:
  • Like
Reactions: Delgoth

jedld

Senior Member
Oct 15, 2007
430
438
Bacoor
Yes at least the saving grace is that Samsung left Dm-verity off for this device.
If only they'd have left out the root restriction in the kernel too we'd have a rootable device.
I have an idea for this that I haven't tried yet.
Basically Samsung sends out security Policy updates via OTA, they recently released an SEPOLICY update to most devices breaking root. Chainfire patched this.
As this policy is stored in DATA and over rides the one in the boot.img it may be possible to use a patched SEPOLICY by creating a flashable DATA image with the patched SEPOLICY thereby removing the SElinux root restriction.

I ran it by Chainfire and he said in theory it should work except for that fact that the SEPOLICY in DATA is signed.

I have yet to try this out.

I think it would be difficult to get CM running as the kernel may need some patches and as we know that can't be touched.
I ran it by Chainfire and he said in theory it should work except for that fact that the SEPOLICY in DATA is signed.

I have yet to try this out.

Would probably need to brush up on se policies in linux. If there are already files available that I just need to flash over to /data I can try it out and also a means to test it if it works.
 
  • Like
Reactions: Delgoth

jedld

Senior Member
Oct 15, 2007
430
438
Bacoor
As this policy is stored in DATA and over rides the one in the boot.img it may be possible to use a patched SEPOLICY by creating a flashable DATA image with the patched SEPOLICY thereby removing the SElinux root restriction.

I ran it by Chainfire and he said in theory it should work except for that fact that the SEPOLICY in DATA is signed.

I have yet to try this out.

I made an attempt to patch sepolicy using data however all I got in the logs was

Code:
E/SELinux (  733): Function: fileToArray, File Open Unsuccessful: 
E/SELinux (  733): Function: getVersionhash, signature is NULL
I/SELinux (  733): Function: selinux_init_verify_sepolicy, getVersionhash return false 
E/SELinux (  733): Function: VerifyPolicy , selinux_init_verify_sepolicy is failed

So far I have no indication that my patch worked

Code:
sepolicy-inject -s shell -t system -c file -p read -P sepolicy -o sepolicy

The error above only comes up if I place sepolicy in /data/security and sepolicy_version in /data/security/spota
sha256 hashes were also updated in the version file so I'm not sure what I'm missing.
If I could have a copy of a samsung ota that actually updates the policies I can probably have better direction
 

jedld

Senior Member
Oct 15, 2007
430
438
Bacoor
I made an attempt to patch sepolicy using data however all I got in the logs was

Code:
E/SELinux (  733): Function: fileToArray, File Open Unsuccessful: 
E/SELinux (  733): Function: getVersionhash, signature is NULL
I/SELinux (  733): Function: selinux_init_verify_sepolicy, getVersionhash return false 
E/SELinux (  733): Function: VerifyPolicy , selinux_init_verify_sepolicy is failed

So far I have no indication that my patch worked

Code:
sepolicy-inject -s shell -t system -c file -p read -P sepolicy -o sepolicy

The error above only comes up if I place sepolicy in /data/security and sepolicy_version in /data/security/spota
sha256 hashes were also updated in the version file so I'm not sure what I'm missing.
If I could have a copy of a samsung ota that actually updates the policies I can probably have better direction

Finally found a way to patch the kernel on this device. Stay tuned...
 

ashyx

Inactive Recognized Contributor
Oct 14, 2012
15,087
9,930
Turns out I was just able to modify files in the boot.img, though when I try to update the sepolicy itself, it won't boot.
Can you at least explain a bit further?
What modifications allow you to create a boot able image?
How have you overcome image signing?
Only way I can think of is hex editing the signature, however I was under the impression this was crc based.
 

jedld

Senior Member
Oct 15, 2007
430
438
Bacoor
Can you at least explain a bit further?
What modifications allow you to create a boot able image?
How have you overcome image signing?
Only way I can think of is hex editing the signature, however I was under the impression this was crc based.
Yeah I was able to flash a modified boot.img using heimdall, turns out that you just need to use abootimg -u boot.img -r yourmodifiedramdisk so that you don't overwrite the SELINUXENFORCE headers appended at the end of the boot.img file, it appears the bootloader only checks for the presence of those headers but does not actually compute the sig.

Modifying ramdisk works, haven't tried modifying the kernel itself.
 

jedld

Senior Member
Oct 15, 2007
430
438
Bacoor
I tried to modify the sepolicy files after using sepolicy-inject but it throws a KERNEL not SEnforced error. I am not certain if this is just a blanket error if the kernel doesn't boot due to modifying the policy files incorrectly or if there is legit checking going on. Nevertheless I am able to modify the init.rc files now.
 

jedld

Senior Member
Oct 15, 2007
430
438
Bacoor
I tried to modify the sepolicy files after using sepolicy-inject but it throws a KERNEL not SEnforced error. I am not certain if this is just a blanket error if the kernel doesn't boot due to modifying the policy files incorrectly or if there is legit checking going on. Nevertheless I am able to modify the init.rc files now.
Continued checking it out. So even though I can modify the ramdisk, I am unable to add more than 1000 - 2000 bytes before setting off the SEAndroid enforce error on bootup. Might be some headers on the boot.img that I fail to update when the ramdisk size gets bigger. Trying to modify the sepolicy in any way even if there is minimal change in size prevents it from booting. I have no idea what is checking it, I'll try to hexedit and see what happens.
 

jedld

Senior Member
Oct 15, 2007
430
438
Bacoor
Continued checking it out. So even though I can modify the ramdisk, I am unable to add more than 1000 - 2000 bytes before setting off the SEAndroid enforce error on bootup. Might be some headers on the boot.img that I fail to update when the ramdisk size gets bigger. Trying to modify the sepolicy in any way even if there is minimal change in size prevents it from booting. I have no idea what is checking it, I'll try to hexedit and see what happens.
So I used a hexedit on the sepolicy file and was able to modify one byte of it effectively changing its sha256sum... and it worked. So the sepolicy file CAN be changed, however current sepolicy-inject and supolicy tools does something to it that trips it, looks like samsung has again added a proprietary modification sepolicy format.
 

ashyx

Inactive Recognized Contributor
Oct 14, 2012
15,087
9,930
I've never known a kernel not boot due to the kernel not SEANDROID enforcing warning.
It's a meaningless warning and easily bypassed.

However this is on bootloader unlocked devices.

So just let me get this straight, you have been able to repack the boot.img with modifications to the ramdisk then force flash it via Heimdall and it still boots?
 

jedld

Senior Member
Oct 15, 2007
430
438
Bacoor
I've never known a kernel not boot due to the kernel not SEANDROID enforcing warning.
It's a meaningless warning and easily bypassed.

However this is on bootloader unlocked devices.

So just let me get this straight, you have been able to repack the boot.img with modifications to the ramdisk then force flash it via Heimdall and it still boots?
yup. that's correct. I'll post my modified boot.img in a while
 

jedld

Senior Member
Oct 15, 2007
430
438
Bacoor
yup. that's correct. I'll post my modified boot.img in a while
note that using the update only method of abootimg "abootimg -u boot.img -r xxxxxx " is the only one that works for repacking the ramdisk. Trying to build the boot.img from scratch using any other method has so far failed for me.
 

jedld

Senior Member
Oct 15, 2007
430
438
Bacoor
Here is a flashable boot.img for the SM-T285.

It contains the following modifications to the ramdisk:

a file at /this_device_is_owned
and a modified init.rc that creates a /tmp folder
 

Attachments

  • boot.img.gz
    7.4 MB · Views: 100

jedld

Senior Member
Oct 15, 2007
430
438
Bacoor
Here is a flashable boot.img for the SM-T285.

It contains the following modifications to the ramdisk:

a file at /this_device_is_owned
and a modified init.rc that creates a /tmp folder
now managed to patch sepolicy using chainfire's supolicy tool. needed to use a customized mkbootimg due to changes in the Tab A image format for this. now attempting to root the device... wish me luck
 

Top Liked Posts

  • There are no posts matching your filters.
  • 13
    I've just got a new Samsung Galaxy TAB A 7.0 LTE SM-T285, For some reason I can't seem to find any resources for this hardware yet in this forum, anyone know where I could find one? I'll try to find out if the current methods (custom recovery and root) for other tab versions work on this.

    CUSTOM ROMS
    ============

    Android 5.1.1 Lollipop (Stock)


    Tinker V5 Edition based on the Samsung Stock Rom SM-T280/T285


    Android 6.0 Marshmallow

    Cyanogenmod 13 for the SM-T285 Only
    OMNIRom for the SM-T285 Only

    Android 7.1 Nougat

    Cyanogenmod 14.1 for the SM-T285 Only (Experimental, things are broken, depcrated in favor of LOS 14.1)
    LineageOS 14.1 for the SM-T285 Only

    Other Operating systems

    Porting for Sailfish OS is currently in progress for the SM-T285, stay tuned

    TWRP RECOVERY AND ROOT
    =======================

    TWRP is available for both the T280 and T285. You should find the relevant threads in this Galaxy Tab A forum.

    If you want to root stock, easiest way is to install TWRP and go for SuperSU. Please see the TWRP threads for SM-T280/T285 on how to root after TWRP is installed.

    KERNEL
    ======

    Custom kernel with working sources for the SM-T285 can be found Here

    DEVELOPMENT
    ============

    If you want to build LineageOS 14.1 on your SM-T285 LTE device, you can use this manifest, not that this is still a work in progress:

    https://github.com/jedld/android.git

    UPDATE 10/06/2016
    ================

    After a couple of weeks of trial and error and tinkering, I've been able to compile a kernel for the SM-T285 from source and so far it seems to work flawlessly!

    Screenshot here: http://imgur.com/a/HRgsq

    link to my kernel sources here: https://github.com/jedld/kernel_samsung_gtexslte.git

    You can also thank samsung for giving us a "broken by default" kernel source. I had to mix and match defconfigs from their other kernel releases just to make this thing work. Download modified boot.img here:

    http://forum.xda-developers.com/galaxy-tab-a/development/kernel-galaxy-tab-7-0-2016-lte-sm-t285-t3474967

    UPDATE 09/20/2016
    ================

    This device is now ROOTED!

    http://forum.xda-developers.com/galaxy-tab-a/help/resources-samsung-galaxy-tab-7-0-2016-t3431022/post68777842#post68777842

    Download Pre-rooted Tinker Edition V5 in this thread: Tinker Edition Thread

    Post Root Post Mortem Analysis for the SM-T285 (09/21/2016)
    =========================
    Q: How were you able to find root? What did you do?
    A: Surprisingly the SM-T285 bootloader isn't actually locked like we thought it was (Once you OEM unlock of course and disable FRP). The bottomline is that
    we simply needed patches to mkbootimg to properly package a boot image for this device as there were additional fields and sections not found on a normal boot image. There were even minor breaking difference between the tab 4 and the boot image for this device.

    Q: I thought the bootloader was locked?? Why did it take so long?
    A: I blame it on the really vague errors the bootloader shows when loading an improperly packaged boot image. What helped was my faith to open up a hex editor when I needed to, and really look at the stock images and the images we were making. What really pushed me to investigate further was the fact that I was able to make a really small modification to the ramdisk and use the abootimg -u update function instead of the create options.

    Q: So the bootloader doesn't really check the image?
    A: Yup, The bootloader doesn't do any check. I haven't checked if that is the case for the recovery partition though. Even without the SELINUXENFORCE headers at the end it still continues like other samsung devices do.

    Q: So the mkbootimg patches are all that we need?
    A: Yup, if you have CM, AOSP build env ready you can simply add the modified mkbootimg to system/core:

    https://github.com/jedld/degas-mkbootimg/commit/b63ae38e2ab7040cc7ddaef777652a56b2e48322

    Sample usage below:

    Code:
    degas-mkbootimg -o boot.img --base 0 --pagesize 2048 \
      --kernel boot.img-zImage --cmdline "console=ttyS1,115200n8" --ramdisk boot_kitchen/boot.img-ramdisk-new.gz --dt boot.img-dt

    Next challenge will be getting Cyanogenmod on this device as well as TWRP.
    5
    rooted. The Galaxy Tab A 7" 2016 LTE (SM-T285) now joins the family of rooted devices. Now uploading the latest pre-rooted ROM. Will work on the SM-T280 next.

    uploaded the boot.img now. Sorry I have a slow net connection.

    Proof below for the unbelievers:

    http://imgur.com/a/7Bl8t
    4
    @ashyx - Reversed engineered the 280 header and came up with the following notes:

    The header is 512 bytes long.
    First 8 bytes consists of magic - 0x44 0x48 0x54 0x42 0x01 0x00 0x00 0x00 - DHTB
    This is followed by a sha256sum of the payload. Note that the "payload" starts with the start of the ANDROID header until the first 20 bytes of the SEANDROIDENFORCE header
    Followed by 4 bytes which I think is unused and then followed by a 32-bit unsigned integer consisting of the size of the payload.
    After that it is mostly empty bytes as far as i can tell.

    This is true for both boot and recovery headers.

    Below is the sample header of the DHTB header of the T280:

    < 00000000: 4448 5442 0100 0000 4b40 f348 e206 7672 [email protected]
    < 00000010: 8fe4 72c2 06ed 0fdd 9df7 16d7 80d0 fc64 ..r............d
    < 00000020: 17bd 6594 5881 07b2 0000 0000 0000 0000 ..e.X...........
    < 00000030: 1498 d600 0000 0000 0000 0000 0000 0000 ................


    We can see that payload is 14063636 long, original boot.img is 14064808 long, the seandroid header is 680 bytes long so we do the math
    14064808 - 512 (Size of the DHTB header) - 680 (seandroid header) - 20 (we include the SEANDROIDENFORCE magic string)
    =
    14063636 = 0x00d69814 , then swivel to account for endianess 0x1498d600

    afterwhich I computed the sha256sum of the 14063636 byte payload and got 4b40f348e20676728fe472c206ed0fdd9df716d780d0fc6417bd6594588107b2
    which matched the checksum value.

    Hope with this information, T280 users can get what they deserve so much :)

    Thanks, that was great info.
    I'd noticed the header magic was the same in the boot images and recovery after doing binary comparisons.

    I'd assumed that somewhere in the header would be the checksum and I'd already created a checksum from the payload and then tried to search for it in the header and footer, but came up with nothing. However I didn't include the SEANDROIDENFORCE magic string, which makes sense now as the rest is the signature. When you pointed that out I did it again and sure enough a match in both the header and footer.
    Good catch too with the bytes containing the payload size didn't notice that. Again found this in both header and footer.
    Looks like these are required mainly for ODIN to flash. If not there the bootloader rejects the flash which is why it was hanging on RQT CLOSE!

    I calculated the checksum and converted the payload size to HEX and patched the header and footer.

    Tested this out by modifying the stock recovery which wouldn't flash beforehand with the same mods. Bingo it flashed and didn't hang on RQT close! Still get the 'secure check fail' warning, but I guess that has something to do with the signature.

    Next I moved on to the custom kernel. I recompiled with some slight mods and did the procedure again with the stock recovery, replacing the stock kernel with the custom kernel.
    Flashed...and boom...successful flash again and booted.

    Next up was TWRP for the same treatment, did the whole procedure again and used my custom kernel. Flashed with ODIN and didn't hang this time. Booted to recovery and the result was...




    SUCCESS!
    TWRP now available for the T280.

    Still needs tweaking as the graphics aren't the right colour seems to be using the wrong pixel format and the FSTAB may need adjusting as the EFS is showing 0mb. All easily fixable.

    .
    3
    Alright, I got it all worked out; should be pretty robust now:
    https://github.com/osm0sis/dhtbsign

    :highfive::D

    I'll have support added for Android Image Kitchen v2.9. :cowboy::good:
    2
    Have added the flag for inverting the display. Compiled it with kernel built from latest sources. Kernel was a bit bigger which was slightly worrying.
    Display colours should also be correct.
    TWRP_3.0.2-1_SM-T285_23916

    .

    Thanks! Flashed it and twrp now works properly for me. The kernel I built was a bit bigger too. I'll try to go back to stock and try to re-root my ROM from there. Thanks again!