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

Search This thread

gian20

Senior Member
Apr 19, 2013
91
7
Manila
the build you suggested, the Alarm Clock problem persists.whenever I try to set the alarm clock the device will reboot and reboot and reboot ........ Still trying to find more bugs. I am attempting to try the 'Encrypt Phone" functionality.
 
Last edited:

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
15,016
34,059
Halifax
GT-i9250
Google Nexus 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 :)

@jedld @ashyx Is anything at all actually required in the DHTB header? Lineage's repo seems to suggest otherwise: https://github.com/samsung-sc8830/lineage_device_samsung_gtexswifi/tree/cm-13.0/boot
 

jedld

Senior Member
Oct 15, 2007
430
438
Bacoor
@jedld @ashyx Is anything at all actually required in the DHTB header? Lineage's repo seems to suggest otherwise: https://github.com/samsung-sc8830/lineage_device_samsung_gtexswifi/tree/cm-13.0/boot

I don't have the SM-T280 so most of my knowledge comes from results obtained by other developers, if I remember another developer @_mone (who managed to build twrp for this device btw) might have said that the actual content of the DHTB header may not matter as long as it exists. Though a properly formed DHTB header prevents various flashing errors from showing up as tested by @ashyx. The SM-T285 which I have uses a pretty standard boot.img format and does not require a DHTB header.
 
  • Like
Reactions: osm0sis

ashyx

Inactive Recognized Contributor
Oct 14, 2012
15,087
9,928
@[email protected] Is anything at all actually required in the DHTB header? Lineage's repo seems to suggest otherwise: https://github.com/samsung-sc8830/lineage_device_samsung_gtexswifi/tree/cm-13.0/boot
I'm a bit sketchy on the procedure now, memory not what it used to be, but IIRC to flash the boot.img with ODIN the DHTB header is needed plus padding and the sha256 checksum created from the boot.img +SEandroid enforcing header. Also the size of the boot.img is included in the header.

For flashing via any other means, DD, TWRP etc., I think it was just the DHTB header required.

I would need to consult my notes to confirm, however I've just moved home and haven't got a working PC at the mo, so can't check the procedure.

However I can test an image built by your excellent AIK kitchen, assuming that's what the info is for?

Just for info though, custom kernels won't boot stock TouchWiz as yet. Still working on that one.
 
Last edited:
  • Like
Reactions: osm0sis

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
15,016
34,059
Halifax
GT-i9250
Google Nexus 4
I'm a bit sketchy on the procedure now, memory not what it used to be, but IIRC to flash the boot.img with ODIN the DHTB header is needed plus padding and the sha256 checksum created from the boot.img +SEandroid enforcing header. Also the size of the boot.img is included in the header.

For flashing via any other means, DD, TWRP etc., I think it was just the DHTB header required.

I would need to consult my notes to confirm, however I've just moved home and haven't got a working PC at the mo, so can't check the procedure.

However I can test an image built by your excellent AIK kitchen, assuming that's what the info is for?

Just for info though, custom kernels won't boot stock TouchWiz as yet. Still working on that one.

Yup, hoping to add repack support for DHTB headered images to AIK. :)

Considering you guys have basically reverse engineered everything for it already, would one of you be able to write a proper standalone tool to create the header?
 
Last edited:

jedld

Senior Member
Oct 15, 2007
430
438
Bacoor

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
15,016
34,059
Halifax
GT-i9250
Google Nexus 4

IngolfN

Member
Jul 7, 2017
23
0
Update LineageOS ?

Hello!
Nice work!
I have a question: If I have installed the inofficial LineageOS on my SM-T285, how I can update it to a newer (inofficial) version without losing my data? Booting in Download-Mode and reinstalling the new version via Odin/Heimdall without flashing before?

Best regards!
 

jedld

Senior Member
Oct 15, 2007
430
438
Bacoor
Hello!
Nice work!
I have a question: If I have installed the inofficial LineageOS on my SM-T285, how I can update it to a newer (inofficial) version without losing my data? Booting in Download-Mode and reinstalling the new version via Odin/Heimdall without flashing before?

Best regards!

You can flash over the boot.img and system.img and leave your data partition intact. You might also need to reflash your gapps or other mods if you did those. Do note that my LineageOS builds are still alpha and I do not test upgrade scenarios. Make sure you backup your data and have a copy of the previous images just in case things goes sideways.
 
  • Like
Reactions: IngolfN

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
15,016
34,059
Halifax
GT-i9250
Google Nexus 4
Last edited:

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
15,016
34,059
Halifax
GT-i9250
Google Nexus 4
Alright - I pushed the utility to my fork (minimal error checking). feel free to modify/whatever - it's mostly @jedld/@ashyx/@_mone's work :)

Awesome work! Since it's still part of mkbootimg my plan will be to turn it into a standalone utility, like I did with mkmtkhdr for MTK zImage/ramdisk signing. :)

Edit: Oh wait, you did do it separately. Nice! :D

Edit 2: Okay, I think I know why it's not booting for you. The sha256sum needs to be generated from everything ANDROID! to SEANDROIDENFORCE + trailing 0xFFFFFFFF, without the trailing FFFFFFFF the sha256sum doesn't match the original.
 
Last edited:

chiefwigms

Senior Member
Jul 31, 2010
63
18
Awesome work! Since it's still part of mkbootimg my plan will be to turn it into a standalone utility, like I did with mkmtkhdr for MTK zImage/ramdisk signing. :)

Edit: Oh wait, you did do it separately. Nice! :D

Edit 2: Okay, I think I know why it's not booting for you. The sha256sum needs to be generated from everything ANDROID! to SEANDROIDENFORCE + trailing 0xFFFFFFFF, without the trailing FFFFFFFF the sha256sum doesn't match the original.

Hmm - it matched my original boot.img (from Samsung's AQA4 factory firmware). When I branched, I had to recompile unpack/mkbootimg, otherwise it gave me bad results:

Code:
[email protected]:/gtaba/degas-mkbootimg/boot# ../tools/degas-unpackbootimg -i boot.img
Android magic found at: 512
BOARD_KERNEL_CMDLINE console=ttyS1,115200n8
BOARD_KERNEL_BASE 00000000
BOARD_RAMDISK_OFFSET 01000000
BOARD_SECOND_OFFSET 00f00000
BOARD_TAGS_OFFSET 00000000
BOARD_PAGE_SIZE 2048
BOARD_SECOND_SIZE 0
BOARD_DT_SIZE 380928
Before read
After read
Total Read: 14064384
[email protected]:/gtaba/degas-mkbootimg/boot# ../tools/degas-mkbootimg -o boot_new.img --signature ../tools/seandroid_t280.img --base 0 --pagesize 2048 --kernel boot.img-zImage --cmdline "console=ttyS1,115200n8" --ramdisk boot.img-ramdisk.gz --dt boot.img-dt
[email protected]:/gtaba/degas-mkbootimg/boot# ../tools/mkT280bootimg -i boot_new.img -o boot_t280.img
[email protected]:/gtaba/degas-mkbootimg/boot# diff boot.img boot_t280.img
 
Last edited:

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
15,016
34,059
Halifax
GT-i9250
Google Nexus 4
Hmm - it matched my original boot.img (from Samsung's AQA4 factory firmware). When I branched, I had to recompile unpack/mkbootimg, otherwise it gave me bad results:

Code:
[email protected]:/gtaba/degas-mkbootimg/boot# ../tools/degas-unpackbootimg -i boot.img
Android magic found at: 512
BOARD_KERNEL_CMDLINE console=ttyS1,115200n8
BOARD_KERNEL_BASE 00000000
BOARD_RAMDISK_OFFSET 01000000
BOARD_SECOND_OFFSET 00f00000
BOARD_TAGS_OFFSET 00000000
BOARD_PAGE_SIZE 2048
BOARD_SECOND_SIZE 0
BOARD_DT_SIZE 380928
Before read
After read
Total Read: 14064384
[email protected]:/gtaba/degas-mkbootimg/boot# ../tools/degas-mkbootimg -o boot_new.img --signature ../tools/seandroid_t280.img --base 0 --pagesize 2048 --kernel boot.img-zImage --cmdline "console=ttyS1,115200n8" --ramdisk boot.img-ramdisk.gz --dt boot.img-dt
[email protected]:/gtaba/degas-mkbootimg/boot# ../tools/mkT280bootimg -i boot_new.img -o boot_t280.img
[email protected]:/gtaba/degas-mkbootimg/boot# diff boot.img boot_t280.img

Figured out the issue, mkT280bootimg expects the full signature to be there (per your "Assumption" note in the code), otherwise it doesn't hash correctly, even though only up to the FF FF FF FF is needed. Must be counting/subtracting from the end?

I was thinking something like this:
check for input file
- usage if not found

check for DHTB magic
- abort if found

check for ANDROID! magic
- abort if not found

check for SEANDROIDENFORCE
- add if not present

check for 0xFFFFFFFF
- add if not present

calculate sha256sum and size from full payload

write file with added header and additional 12 bytes 00 padding to trailing 0xFFFFFFFF​

I'll mess around and see what I can work out. :)
 
Last edited:

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!