Essentially, how I bypassed was check first 7-8 bytes for ANDROID! - in
java: byte androidMagic[] = {0x41, 0x4E, 0x44, 0x52, 0x4F, 0x49, 0x44,
0x21}; //ANDROID!If that isn't found, skip 256 bytes and check again. With the signed boot.img files, boot_signed.img, HTC has been using on newer devices such as the HTC Sensation, EVO 3D and I think also the Thunderbolt, they all follow this pattern. After 256 bytes the Android magic is located and the first 256 bytes can be dropped. Once a user has root access and disables the memory write protection, they don't need a correct 256 byte prefix on their boot.img to load. For what it is worth, I couldn't find any other application which took this issue into account and properly handled, other than dsixda kitchen. Hope that helps! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/881977 Title: Not able to process "signed" Android boot.img To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/abootimg/+bug/881977/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
