For those who are impatient and know how to patch their system.img with the SuperSu binaries:
Attached patched boot.img (has init.supersu.rc ready to run /system/xbin/daemonsu).
To build a boot.img for device you need a custom mkbootimg here:
Unpacking/packing the ramdisk is pretty standard. The mkbootimg is used like this:
degas-mkbootimg -o boot.img --signature seandroid.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
I've tested this so far only for my device. Feedback needed if boot.img flashes properly in other devices as well.
haven't tried if this technique works for recovery, but in theory it should. Now someone please get TWRP on this device
Flash boot.img using heimdall/odin as is. If everything works well the device should accept it like nothing
Okay I haven't read the rest of the thread yet. I found this post first. But I will read after I make this post before I forget what I was going to say.
If I read your post correctly, "the standard mkbootimg" program cannot actually unpack and repack the boot.img correctly. Which is an extremely common occurrence on Samsung Devices, even though the vast majority of those Samsung Devices use AOSP type boot.img's.
I am also surprised there is actually data on the kernel command line.
Does Your patched boot image just modify the ramdisk by simply inserting the init.supersu.rc and making sure it gets called?
I ask these kind of basic questions because I've had my tablet for a month, and it's a bit different in some areas than the Galaxy Mobile Phones. This is the first device I've had in awhile that allowed me All Possibilities without worrying about telephony services. So I've been slowly getting my environment back in order. So I can take some new details into my older projects.
This post is a little bit outdated now. But yeah the kernel command line doesn't really do anything, I've discovered that it is actually part of the dt image.
For a 5.1 device at launch, LineageOS 14.1 runs on this device if you want a measure on how hackable it is, you can check out the lineageos customrom thread for the T285. I've also included links to the kernel and LOS manifest if you want to build it for your device. I've gotten oreo partially to work, unfortunately it is not on a level that is usable at the moment.
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:
[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
Just use Magisk it comes with Xposed that can be used on any device.
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
@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