Develop Bugs

[NOTICE] ATTENTION ALL ROM/KERNEL DEVELOPERS - Firmware Packages!

The Heimdall Suite 1.3 release includes a major overhaul of Heimdall Frontend. The most important feature is that Heimdall Frontend now provides a means for you to easily package your firmware/ROMs/kernels in a "Heimdall Firmware Package".
Heimdall Firmware Packages contain any files users will need to flash as well as additional information including supported devices, developer names, homepage and donate URLs etc.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Heimdall Firmware Packages can be customised by users or flashed directly as provided by firmware developers. Generally users won't want or need to customise the firmware so flashing your firmware becomes as simple as loading the firmware package and pressing the "Start" button.
Distributing your firmware via Heimdall Firmware Packages should simplify the flashing process for end users and decrease the number of bricks that occur as a result of users flashing incorrect firmware.
Heimdall 1.3.0 has officially been released and can be download from the Heimdall product page.
Feedback is very welcome! As always donations are also very much appreciated.

The following information/tutorial is included in the official README for all platforms but is reprinted here so developers can gain an understanding of the process before downloading Heimdall Frontend.
How to Create a Heimdall Firmware Package:
Firstly, Heimdall's firmware package format is just a regular TAR archive
compressed with gzip. The only two real requirements are that a valid
firmware.xml must be included (refer to Appendix A) and you can only
include files (no directories, links etc.) As such if you'd like there is
nothing preventing you creating Heimdall packages manually. Of course
Heimdall Frontend provides a simple user interface that takes care of all
the hard work for you.
There are two ways in which you can create a firmware package. You can
create a package from scratch, or you can load an existing package, apply
modifications and then save the package. Creating a package from scratch
is the preferred approach, by taking this approach you're far less likely
to run into file name length limitations, these are not Heimdall's own
limitation but rather a limitation of the TAR archive format.
Before you can access Heimdall Frontend's firmware creation functionality
(available from the "Create Package" tab) you must first specify which
files will be included in your package as well as a few flashing options
i.e. Whether or not users should repartition when flashing. This
information must be filled out from the "Flash" tab in exactly the same
fashion you would provide information to flash your device (see "Performing
a Custom Flash with Heimdall Frontend"). As mentioned above, it's not the
preferred means, but you're able to load an existing package as a starting
point for this information.
Once you've specified the files/partitions you wish to include in your
firmware package the "Create Package" tab will become available. Clicking
this tab will display additional information that you can include in your
package. In order to continue you must fill out all sections except for the
URLs section, which is optional. The following is break-down of what all
these options mean.
- General Firmware Information: -
Firmware Name - This is the name of your particular firmware. An
example would be "Cyanogenmod".
Firmware Version - This is the particular version identifier for your
package. Any valid string will be accepted although a the inclusion
of decimal point version number is preferred releases i.e. "7.1".
If it makes sense then feel free to append a text string like "RC1"
or "Beta 1" to the decimal point version.
Platform Name - This is the name of platform (or operating system) that
your firmware is based on. In most cases this will simply be
"Android".
Platform Version - This is the operating system version that your
firmware is based on. Again decimal point version numbers are
preferred over text, i.e. "2.3.4" is preferred over "Gingerbread".​
- Developers -
URLs (Optional):
Homepage - Here you can enter your personal URL or a URL particularly
pertaining to the firmware being packaged. The URL must be well
formed for it to work. An example of a well formed URL is
"http://www.glassechidna.com.au/products/heimdall/". It is
important to include "http://" in order to specify the protocol as
other protocols such as "ftp://" are equally valid although
unlikely to be used.
Donate - Here you can enter a URL that will link users to a page to
make donations for the effort you've put into developing your
firmware. Once again the URL must be well formed but there is no
requirement on how your donation page should work. For instance
both "http://www.glassechidna.com.au/donate/" and
"http://forum.xda-developers.com/donatetome.php?u=2710388" are
equally valid.​
Developer Info:
Name - Here you can enter in the name of individual team members or a
team name. Click "Add" and the developer will be added to the list
on the right. If you make a mistake you can select a developer from
the list and click "Remove". You can list as many developers as you
like however size constraints of the "Load Package" means only a
few will be visible. Where possible you may want to opt for team
names over listing individual team members.​
- Supported Devices -
This section allows you to create a list of devices that are supported by
your particular firmware. Although Heimdall isn't capable of enforcing this
we strongly recommend you take this section seriously. If filled out
correctly you could help save a number of accidental bricks!
Device Info:
Manufacturer - This is where you can enter the name of the manufacturer
for a particular device. For now this will most likely be
"Samsung".
Name - This is the human readable name for a particular device.
"Galaxy S", "Galaxy S II", "Droid Charge", "Vibrant" and
"Galaxy S (Telstra)" are all valid names. There are a lot of
possible variations here so be as specific as you think is
necessary.
Product Code - This is by far the most important bit of device
information. Device names tend to be region specific and further
subject to the whims of telecommunication companies and resellers.
Product Codes (or product IDs) are designated by manufacturers and
are generally the definitive means of referring to a particular
device. Examples are "GT-I9000", "GT-I9100" and "SCH-I897". If
you're unsure of a particular product code then Google and
GSMArena are your friends!​
After filling out all the necessary information the "Build" button will be
enabled. If it's still disabled then you know you're missing some required
information. In particular you must specify at least one developer and at
least one supported device. Pressing the "Build" button will bring up a
save dialogue where you must chose a file name for your particular package.
Don't worry about specifying the ".tar.gz" extension Heimdall Frontend will
take care of this automatically.
Once you've chosen a file name Heimdall Frontend will begin the process of
building the firmware package. In doing so a valid firmware.xml file will
be generated from the information entered, all files will be archived in a
single TAR file then the TAR archive will be compressed via gzip
compression. Compression will take a little while but you will see progress
bars so you know the application hasn't hung. When the progress bars
disappear you're finished making your package.
Congratulations! You're now ready to redistribute your firmware package
online or by any means you see fit.​
Appendix A - firmware.xml
The following details a part of the Heimdall Firmware Package format. This
is only relevant to developers or advanced users who wish to create Heimdall
Firmware Packages outside of Heimdall Frontend or in some way integrate support
for the format in their own software.
All Heimdall Firmware Packages must contain a file called firmware.xml. This
file stores information stores meta-data for the package as well as information
about other files contained in the package that indicates how they should be
flashed.
The format is fairly straight-forward so it won't be explained in great detail,
nonetheless the following is an example of a valid firmware.xml file.
Code:
<?xml version="1.0" encoding="UTF-8"?>
<firmware version="1">
<name>Test Firmware</name>
<version>1.1</version>
<platform>
<name>Android</name>
<version>2.3.4</version>
</platform>
<developers>
<name>Benjamin Dobell</name>
<name>Hedonism Bot</name>
</developers>
<url>http://www.glassechidna.com.au/</url>
<donateurl>http://www.glassechidna.com.au/donate/</donateurl>
<devices>
<device>
<manufacturer>Samsung</manufacturer>
<product>GT-I9000</product>
<name>Galaxy S</name>
</device>
<device>
<manufacturer>Samsung</manufacturer>
<product>GT-I9000T</product>
<name>Galaxy S (Telstra)</name>
</device>
<device>
<manufacturer>Samsung</manufacturer>
<product>GT-I9000M</product>
<name>Vibrant</name>
</device>
</devices>
<pit>Nl3276-I9000 s1_odin_20100512.pit</pit>
<repartition>0</repartition>
<noreboot>0</noreboot>
<files>
<file>
<id>0</id>
<filename>gq3276-boot.bin</filename>
</file>
<file>
<id>24</id>
<filename>Uh3276-cache.rfs</filename>
</file>
<file>
<id>22</id>
<filename>em3276-factoryfs.rfs</filename>
</file>
<file>
<id>11</id>
<filename>fl3276-modem.bin</filename>
</file>
<file>
<id>21</id>
<filename>Xd3276-param.lfs</filename>
</file>
<file>
<id>3</id>
<filename>if3276-Sbl.bin</filename>
</file>
<file>
<id>6</id>
<filename>cr3276-zImage</filename>
</file>
</files>
</firmware>
New lines need not be included and the order in which elements are specified
does not need to match that of the above example.
One and only one <firmware> element must be included. The <firmware> element
must also have a version attribute specified. The version must be parsable as
an integer and indicates what version of the Heimdall Firmware Package
specification the package adheres to.
All data is stored as strings, however a <file>'s <id> element must be parsable
as an integer. The <id> value represents the partition ID (according to the
specified PIT file) that the file should be flashed to.
A <firmware>'s <repartition> and <noreboot> elements must also be parsable as
an integer. However, as they represent boolean values, a value of zero ("0")
means false (or disabled) where as a non-zero value (typically "1") means true
(or enabled).
File names are specified relative to the TAR archive in which firmware.xml and
all other files are to be stored. Heimdall Firmware Packages do not support
directories or links, as such file names should only be a name and not a path.
<url> and <donateurl> are the only optional elements, all other elements must
be included.

This is AWESOME! Hope people adopt this fast!

Thanks a lot for this. I was waiting for such a tool since long long time
Now I can make my development even more faster.

I'm really thankful for your shared knowledge and your hard work.

Darkyy said:
I'm really thankful for your shared knowledge and your hard work.
Click to expand...
Click to collapse
+1
in case you havent noticed theres a thx button fo rthat you might go ahead and click it

i9100 support?

uppon2 said:
i9100 support?
Click to expand...
Click to collapse
Yeah, all Galaxy S devices, well except maybe the Droid Charge which we've had problems flashing with Heimdall.
The firmware package format itself isn't tied to any particular device.

DAGr8 said:
+1
in case you havent noticed theres a thx button fo rthat you might go ahead and click it
Click to expand...
Click to collapse
I did
You know, sometimes a sentence says more than thousand clicks

Alright, let's see what this can do. Many thanks for this project!

I am trying to put together a package for the Vibrant's original firmware, JFD. The one clarifying question that I have is: Is IBF/PBF the same as the primary boot loader? That is, should I set that partition (0) to boot.bin?
Thank you for the hard work!

ginzberg said:
I am trying to put together a package for the Vibrant's original firmware, JFD. The one clarifying question that I have is: Is IBF/PBF the same as the primary boot loader? That is, should I set that partition (0) to boot.bin?
Thank you for the hard work!
Click to expand...
Click to collapse
Instead of "IBF/PBF" I think it might be something like "IBL+PBL". But yeah, primary bootloader (boot.bin) == initial bootloader + primitive bootloader.

Wow, yeah.. you're right. I sent my message without proofing. "Thanks" sent.
Great... now that I've built this thing... do I dare try it? I will report back with my findings when I get up the guts (i.e. have a windows machine around to bail me out if I need it), and then post the package for other Vibrant users.

ginzberg said:
Wow, yeah.. you're right. I sent my message without proofing. "Thanks" sent.
Great... now that I've built this thing... do I dare try it? I will report back with my findings when I get up the guts (i.e. have a windows machine around to bail me out if I need it), and then post the package for other Vibrant users.
Click to expand...
Click to collapse
Haha, you'll be right. Heimdall has been pretty heavily tested these days. Adam Outler recently made a video of Heimdall performing 200 flashes in a row without a single failure It's MUCH more reliably than Odin.

I thought it's probably worth mentioning the Heimdall 1.3.0 has officially been released. On top of the functionality provided in the betas there's also a few extra bits of functionality provided by the new Utilities tab.
The new Utilities tab should make the creation of Heimdall Firmware Packages a bit easier for developers as you're now able to connect your device to your PC and download the PIT that's on the device straight to your PC. As such you no longer need to worry about trying to recall exactly which PIT file you're using or where you got it from.

Benjamin Dobell said:
I thought it's probably worth mentioning the Heimdall 1.3.0 has officially been released. On top of the functionality provided in the betas there's also a few extra bits of functionality provided by the new Utilities tab.
The new Utilities tab should make the creation of Heimdall Firmware Packages a bit easier for developers as you're now able to connect your device to your PC and download the PIT that's on the device straight to your PC. As such you no longer need to worry about trying to recall exactly which PIT file you're using or where you got it from.
Click to expand...
Click to collapse
Awesome, thanks for the heads up. The new firmware package feature seems really cool... but I haven't seen anyone using it yet. What's the deal!? Do you have any samples for stock ROMs we can try?

aorth said:
Awesome, thanks for the heads up. The new firmware package feature seems really cool... but I haven't seen anyone using it yet. What's the deal!? Do you have any samples for stock ROMs we can try?
Click to expand...
Click to collapse
Well the official release of Heimdall 1.3.0 was only made a couple of days ago. So I figured some developers were waiting for that (over the beta release). However, now I'm not so sure that's the reason. I can understand if developers only release their firmware for ROM Manager. However, I see zero reason to continue releasing firmware as several TAR archives for Odin.
Heimdall Firmware Packages are much more straight-forward to use for end-users as there's only one file to select (and no settings need to be changed). As Heimdall Frontend takes care of building the packages it's probably also easier for developers, plus developers are able to include additional information about themselves and the package. On top of that these packages will work flawlessly on Linux, OS X and Windows with no additional work required.
EDIT: It's probably also worth noting that the format isn't just for full firmware packages. It works quite nicely as a way of distributing modems and kernels as well. This is particularly useful for custom kernel developers.

Benjamin Dobell said:
Well the official release of Heimdall 1.3.0 was only made a couple of days ago. So I figured some developers were waiting for that (over the beta release). However, now I'm not so sure that's the reason. I can understand if developers only release their firmware for ROM Manager. However, I see zero reason to continue releasing firmware as several TAR archives for Odin.
Heimdall Firmware Packages are much more straight-forward to use for end-users as there's only one file to select (and no settings need to be changed). As Heimdall Frontend takes care of building the packages it's probably also easier for developers, plus developers are able to include additional information about themselves and the package. On top of that these packages will work flawlessly on Linux, OS X and Windows with no additional work required.
EDIT: It's probably also worth noting that the format isn't just for full firmware packages. It works quite nicely as a way of distributing modems and kernels as well. This is particularly useful for custom kernel developers.
Click to expand...
Click to collapse
Yeah, the way I see it, it's a bit like VMware or whoever else offering pre-built appliances for various functions. Download this VM, press play, and you've got a fully-functional Redmine server, for example.
I'll keep my eye out for some firmware packages... I'll be keen to try one.

aorth said:
Yeah, the way I see it, it's a bit like VMware or whoever else offering pre-built appliances for various functions. Download this VM, press play, and you've got a fully-functional Redmine server, for example.
I'll keep my eye out for some firmware packages... I'll be keen to try one.
Click to expand...
Click to collapse
Ok, I just decided to make my own. Since it worked, I'll share... here's a Heimdall-1.3-flashable firmware package for stock XXJVQ:
http://www.multiupload.com/W4IGGFZU6F
It's stock. It's odexed. It's stock! It will repartition. It includes bootloaders. Did I mention it's COMPLETELY stock?
Great job on Heimdall 1.3, Ben. I used to write shell scripts to do my flashing, but I'd love it if people started releasing Heimdall-flashable tar files. Hopefully this gets the ball rolling for people to create their own firmware packages (hopefully for more-interesting firmwares than a stock XXJVQ!).

Hi, sorry if I'm been thick but where can I find heimdall packages for the galaxy s2? I have tried downloading the firmware but cannot see where to load all the files once the tar has been extracted. The only tutorials I have seen have the boxes labelled pda etc. The latest version I have downloaded doesn't as far as I can see, V1.3.1. Packages sound much easier than me mucking up the file uploads but I can't find any?

Create your own I9000/S8500 (& all S5PC110 based devices) bootloader&ultimate unbrick

Create your own I9000/S8500 (& all S5PC110 based devices) bootloader&ultimate unbrick
Preamble
I present you the results of hours of many people research.
Special thanks to:
AdamOutler
mijoma
TheBeano
midas5
Leave me a message if I forgot to mention someone.
I, nor anybody except you take no responsibility for the things you do to your PC, phone, family, neighbours, dog, cat or fish in the result of reading this and/or using any materials linked and included from here.
What is it?
Info how to bypass secure booting mechanism built in S5PC110 CPU's iROM on lowest level and create code loadable even with totally damaged bootloader, without use of JTAG.
Okay, how useful is it?
I've got no clue, it all depends on you.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Our main target, which is almost done, is ability to revive any hard-bricked hardware built on S5PC110 without use of JTAG (for eg. when JTAG pads had been damaged)
Some additional info and history
S5PC110 - the powerful CPU, heart and brain of many great handsets (like Samsung I9000, S8500, S8530, SGH-897, Google Nexus S, Odroid T, while last one is hard to be called HANDset, nvm) has got few booting levels before loading operating system:
-BL0/iROM, non-writable (not-brickable), written during CPU production process, execution starts here on every machine start, executed straight in iROM, using iRAM(iRAM is 96KB big, there is a spelling error in CPU manual), it does select booting source depending on xOM CPU pins (different types of flash memory/UART/USB), loads BL1 from it and validate its integrity using electronic sign attached to BL1 (iROM doesn't check BL1 integrity if CPU's SECKEY registers are null, there was some misunderstanding of these, but as far it appear that most or all S5PC110 units has got SECKEY not-null, and its always equal in Samsung's phones)
Execution begins from 0xD0000000
-BL1/IBL, writable (brickable), executed in iRAM, it does memory controllers setup, loads BL2 and, depending from info in BL1 electronic sign, it does or does not check BL2 integrity, BL1 is usually splitted to 2 stages, separated in iRAM by few KB of 0x00
Entrypoint of stage 1 = 0xD0020010 (while it should be loaded under 0xD0020000, as it does have 16 bytes of header)
Entrypoint of stage 2 during normal oneNAND boot = 0xD0020800 (this is already platform-dependant but doesn't seems to vary between mainboards)
Entrypoint of stage 2 during external usb/uart boot = 0xD0022010 (here we insert our custom code, sticked to the end of stage1, it must have dummy header)
-BL2/PBL, writable (brickable), executed in RAM (external DRAM or SRAM), it isn't in fact unneeded, God one knows why Samsung's developers decided to add one additional stage
Entrypoint = platform&version-dependant, it's usually 0x40204000 on I9000
-BL3/SBL, writable (brickable), executed in RAM, it does platform init, support LCD output, download mode and usually few additional functions, it does load OS image into RAM, prepare hardware to execute it and jumps into OS entrypoint
Entrypoint = platform&version-dependant, it's usually 0x40244000 on I9000
for more info about booting sequence and OM pins please reffer to section 02, chapter 6 of S5PC110_EVT1_UM.pdf in [6]
//editnote: This is my own interpretation of bootloaders levels splitting, it haven't been clearly stated in CPU user manual, but it can be also said that IBL is in one part, and PBL is splitted into 2 stages, one executed in iRAM and second executed in DRAM, that's the matter of thinking. Odroid developers seems to use terminology of the second possiblity.
//editnote2: Confirmed from SGS/Captivate boot.bin reversing - Samsung is dividing and calling bootloaders as I wrote in previous points (2nd stage of IBL, which could be aswell 1st stage of 2-stage PBL does contain "IBL" string) Uboot devs got different calling convention. Well... who cares.
After many (even more than many) research [1] we found out that there is no ther way to change iROM primarey booting source than changing OM pins setup, which are hardware soldered through pullup and pulldown resistors to give 5b'001001 (0x9) which means that primary booting source is OnenandMux(Audi) using X-TAL(USB) oscillator (to be honest I still don't hell get what does it means )
AdamOutler sacrificed Captivate mainboard to locate the pullup and pulldown resistors [2], and in result he modified board to have xOM5=1 instead of 0 which enables UART/USB as primary booting source. This booting method is normally tried only when IBL on oneNAND has been damaged, usually bricked is PBL or SBL, and iROM successfully completes its task, but phone hangs somewhere in the middle.
This enabled Adam to load various data through iROM download mode straight into iRAM. And here comes disappointment - all data we tried to load were validated by iROM code against SECKEY and rejected with "Secure Fail Error", BL1 code loaded by iROM must contain 512 bytes of e-sign, consist of 2 public rsa keys and few sha-1 hashes.
Here comes again days and night of deep code analyze, we found BL1_stage1 in Odroid T U-Boot [4] sourcecode signed by Samsung with stage2 security turned off.
That means any BL1_stage2 can be created and joined to BL1_stage1 in proper way, it will pass all integrity tests and be executed - bingo!
Base code
I've created kind of S5PC110 IBL dev kit. It's attached to the post. All you need to build it is FASMARM (downloadable from [5], its really everything except package in attachement) and you can compile any code basing on s5pc110_example.
There you will find Hello World but it does NOT produce this output to screen nor widely used UART hidden in Micro-Usb slot. It does produce output to UART2 channel, which is hidden in JTAG pads in SGS/Captivate mainboard and it has got special pads under battery in S8500/S8530. BUT if you really are determined to run it, by doing OM pulldown->pullup MOD, and feel like you must immediately see it working, it's about 20lines of ASM code which will blink SGS keypad LED and about 10, by calling iROM functions to get other UART port working.
If you want some reference, follow [3] and [7] (also in previous revisions), there you can find alot of FASMARM code written for S5PC110 (S8500/S8530 to be precise).
How to run it?
Here goes the problem, it is unable to run if you have no IBL brick or no OM5 modification (again, reffer to [2]), there you will also find more instructions. It is also able to run by JTAG. Theoretically produced code should be possible to flash and then run as normal IBL, but that's not really good thing to try without JTAG/OM5 mod to resurrect it.
Postamble
If you want to write something bigger, I'd recommend switching from FASMARM to Codesourcery ARM Crosscompiling environment - everything for S5PC110 is already in Odroid's U-Boot and many Android kernel sources (I9000 for example), ready to compile under Codesourcery. I used FASMARM because it's tiny and simple to create small ASM codes, but doesn't support many functions which are speeding up creating larger code.
We will soon release ultimate unbricking method for SGS/Captivate/Wave without use of JTAG, altough this will require high soldering skills or maybe steady hand, while that second is untested and may burn out something onboard, I'm about to test it in few days on my bricked S8530.
Further reading
[1] Where it all has began - Lets save some bricks
[2] First practical results - The Captivate Development Platform
[3] First S8500/S8530 BL3 hacking - FOTA development thread
[4] What has been used here, and what can be easily ported to any S5PC110 device - Odroid's U-Boot
[5] FASMARM homepage
[6] Samsung Galaxy S (and many similiar devices) Hack Pack by Adam Outler
[7] Badadroid FOTA source tree
[8] Walking in Memphis
Note: I wasn't sure which board should I choose to post it. If any mod/admin find better place for this thread (please note it doesn't reffer to SGS or Captivate only, that's the problem) please move it.
Note2: Post above may change if I decide to better explain something.
Note3: Please post any questions and mistakes you found. I'll be happy to answer it if it helps anybody.

Good job. A flow chart made with OpenOffice.org or something to understand the booting process would make things even clearer.
Does your comment about O-Droid's U-Boot mean even non-Samsung devices that utilize this chip verify the digital signature of BL1/the first stage bootloader?

Master Melab said:
Good job. A flow chart made with OpenOffice.org or something to understand the booting process would make things even clearer.
Does your comment about O-Droid's U-Boot mean even non-Samsung devices that utilize this chip verify the digital signature of BL1/the first stage bootloader?
Click to expand...
Click to collapse
Will think about chart later. Thanks for suggestion.
Also, sorry for leading you into mistake before. Even Odroids does verify BL1 signature, and they verify it against the same SECKEY as SGS, Wave and so on does (BL1 from one fits to all above), also all S5PC110 looks to be EVT1_SEC versions, but Secure Boot Context is usually dropped at IBL level and it does continue non-secure boot.

I am not exactly sure what you mean when you say "Secure Boot Context is usually dropped at IBL level and it does continue non-secure boot.". Does that mean after attempting to boot from oneNAND, UART/USB, and the SD card, it try to boot from oneNAND again without checking the digital signature?

No, I mean that iROM (BL0) requires IBL (BL1) to be signed (most likely always), that allows secure boot without unauthorized boot change possibility. But to make boot fully secure, BL1 should require signed BL2, BL2 should require signed BL3 and BL3 should require signed OS image. In case of most (or even all) SGS handsets, BL1 or BL2 doesn't follow secure booting process and doesn't require signed next level of bootloader.

Great work! Maybe you can add links to compilers and some instructions on how to compile?

AdamOutler said:
Great work! Maybe you can add links to compilers and some instructions on how to compile?
Click to expand...
Click to collapse
Rebellos said:
I've created kind of S5PC110 IBL dev kit. It's attached to the post. All you need is FASMARM (downloaded from [5]) and you can compile any code basing on s5pc110_example.
Click to expand...
Click to collapse
There is nothing more simple - open .ASM file using FASMWARM editor and hit F9 or choose Compile from menu.

Rebellos said:
No, I mean that iROM (BL0) requires IBL (BL1) to be signed (most likely always), that allows secure boot without unauthorized boot change possibility. But to make boot fully secure, BL1 should require signed BL2, BL2 should require signed BL3 and BL3 should require signed OS image. In case of most (or even all) SGS handsets, BL1 or BL2 doesn't follow secure booting process and doesn't require signed next level of bootloader.
Click to expand...
Click to collapse
Ahh. I was thinking of an older thread in which someone stated something about it trying to boot from oneNAND a second time without signature checks, if it and booting from USB and the SD card failed. I hate signature checks.

Master Melab said:
Ahh. I was thinking of an older thread in which someone stated something about it trying to boot from oneNAND a second time without signature checks, if it and booting from USB and the SD card failed. I hate signature checks.
Click to expand...
Click to collapse
It was me. Thats the separate thing. However it was only assumption that second boot is without security check, now I'm nearly sure every booting try is signature checked if SECKEY is not null.
Sorry for misleading again.

Its okay. Maybe we can order S5PC110's from Samsung. If anyone has the soldering skills.

This hardware/software mod should apply to more then just the following devices:
Apple iPhone4, Samsung I9000, S8500, S8530, SGH-897, SGH-i896, SGH-i997, T959, SGH-T849, GT-P1000, GT-i9010, GT-i8350, GT-I917, Google Nexus S, Odroid T, and a few Samsung WP7s..
There's so many it's hard to identify them all.

Master Melab said:
Its okay. Maybe we can order S5PC110's from Samsung. If anyone has the soldering skills.
Click to expand...
Click to collapse
Odroid's team is probably one of few Samsung's customers who buys S5PC110, but I guess they won't sell them in less amount than ~1000.
AdamOutler said:
This hardware/software mod should apply to more then just the following devices:
Apple iPhone4, Samsung I9000, S8500, S8530, SGH-897, SGH-i896, SGH-i997, T959, SGH-T849, GT-P1000, GT-i9010, GT-i8350, GT-I917, Google Nexus S, Odroid T, and a few Samsung WP7s..
There's so many it's hard to identify them all.
Click to expand...
Click to collapse
Odroid T has got jumpers to setup OM pins. ;P

AdamOutler said:
This hardware/software mod should apply to more then just the following devices:
Apple iPhone4, Samsung I9000, S8500, S8530, SGH-897, SGH-i896, SGH-i997, T959, SGH-T849, GT-P1000, GT-i9010, GT-i8350, GT-I917, Google Nexus S, Odroid T, and a few Samsung WP7s..
There's so many it's hard to identify them all.
Click to expand...
Click to collapse
I don't think applies to the iPhone 4. Keep in mind that Apple had a major hand in designing the A4 processor and they like to do things their way.

Master Melab said:
I don't think applies to the iPhone 4. Keep in mind that Apple had a major hand in designing the A4 processor and they like to do things their way.
Click to expand...
Click to collapse
If you look at the a4 processor xrays and board layouts, you will see the same structures. Even the xOM resistors. The board is different, but that's because someone else did the layout. The processor is basically the same and the xOM pins provide debugging capabilities. They are ARM cortex a9 processors otherwise.

Great work so far (especially since you don't have a device), and nice tutorial.
I really hope that this gets a portal spot, and maybe even bigger. This info really needs to get out there and worked on, especially with the possibility of this for so many devices. Good luck to you all.

I think the phone hacking community needs more hardware hacks.

Master Melab said:
I don't think applies to the iPhone 4. Keep in mind that Apple had a major hand in designing the A4 processor and they like to do things their way.
Click to expand...
Click to collapse
A4 processor is slighty modified S5PC110 with different, but in fact similiar model name.
AdamOutler said:
They are ARM cortex a9 processors otherwise.
Click to expand...
Click to collapse
It's Cortex A8*.

I've been following the Captivate UnBrickable Mod thread, this thread, and I'm thoroughly impressed by the work you two (and many others) have done. I've taken an interest in poking around inside my Infuse (see pictures).
My questions are these:
1a. If someone were to successfully create a custom IBL/PBL that boots on the S5PC110, or even go so far as to load U-Boot or similar, would it be possible to flash this modified code onto the oneNAND, overwriting the existing IBL and (if needed) PBL?
1b. Supposedly, the IBL+PBL is "locked" on the Infuse, but gtg465x and I were able to successfully write the IBL+PBL+SBL on my first Infuse, inevitably hard-bricking the device (it's since been warranty replaced, so don't bother asking for my dead/bricked device - sorry!). If I had some way of unbricking my new device conveniently (JTAG for example), I would re-try the method gtg465x used, just to watch UART output and see what was going on behind the dark screen of a bricked Infuse.
1c. Regardless, it seems it would be possible to write anything to any part of the oneNAND if one had the proper tools (JTAG, which I am actually considering purchasing a JTAG device for several reasons!). Correct me if this is not the case.
2a. Has anyone tried intentionally corrupting the IBL? Has anyone tried to reproduce this state to confirm that this enables UART/USB as the primary booting source?
2b. If I had a way to recover my device (JTAG, again), I would like to test this myself.
3a. What cable/device/attachment is needed for the CPU to be able to attempt to boot from UART/USB (given xOM5=1, for example)?
3b. Is this just the standard USB OTG cable, or are you communicating to the device over TTL UART?
3c. What is the CPU physically looking for, exactly, when booting this way?
I suppose my goals are these:
1. I would first like to be able to JTAG my Infuse, as a means to recover from the stupid s*** I would like to do to it.
2. I would like to retry gtg465x's method of writing bootloaders, and confirm that this is possible by using nothing but software on the device itself (i.e. no JTAG), given the device is still operational and rooted.
3. I would like to intentionally corrupt the IBL, theoretically turning the device into a KIT-S5PC110 development board. From here, I could work as a tester on your team, and try loading whatever-code-you-come-up-with on the Infuse and hand you results.
4. Once a working/useful IBL+PBL has been created/ported (such as u-boot), I would like to attempt flashing this onto the oneNAND and be able to boot from this without the need of tethering the device to a PC. Further, this would theoretically allow booting from any device (emmc, for example), which would open the door to many, many possibilities.
5. I'd like to see a Dev take the work from goals #3 & #4 and create a script/package/etc that recreates these two steps. I would be happy to test such a script/package/etc.
6. Once goal #5 is complete, Devs could easily start working on porting alternative operating systems to our devices, without substantial fear of bricking their device (e.g. boot iOS or WP7 from emmc, screw around with that, and then boot back into Android from their NAND when they are done for the day).
Thanks for your time reading through my wall-o-text.

Stupid Request...
Is it possible to access iROM via JTAG?
Please, maybe someone can explain how to do this with RIFF Box...
My device is S8500...
Thanx in advance.
Best Regards

adfree said:
Stupid Request...
Is it possible to access iROM via JTAG?
Please, maybe someone can explain how to do this with RIFF Box...
My device is S8500...
Thanx in advance.
Best Regards
Click to expand...
Click to collapse
I think it's no problem to access iROM via JTAG.
You'll find whole iROM under 0xD0000000 RAM address (don't confuse with oneNAND), it's size is 0x10000 (64KB) (so it's 0xD0000000-0xD000FFFF area)
It is also possible to call iROM functions (code tested by nbates66 confirmed that it's possible to call iROM functions from FOTA, which is BL3 level)
Also you will find iRAM under 0xD0020000, its size is 0x15000 (96KB, there is an error in user manual, or I'm too dumb to access the remaining 32KB)
Please post your results somewhere if you decide to test it.
PS: iRAM is probably cleaned somewhere on PBL (BL2) level (couldn't find anything there from FOTA), so if you want to find some interesting info there, try to set JTAG HW breakpoint on 0xD0020010 execution address (entry point of IBL) and then dump iRAM.

[Q] Modify Samsung Galaxy Note 2 Boot Logo

THE SKINNY
I want to modify boot logo on my awesome Note 2, but cant find anywhere on how to do it. The following is an excerpt from what I did, these are my stories (ding ding).
Indepth
Hello everybody, I was wanting to max-mod my phone and came across a post on the Samsung Galaxy Tab 2 forums that allows you to modify the boot logo (not to be confused with the bootanimation) on the Tab 2.
I want this on my phone.
So, I went ahead and did the things they say to do here http://forum.xda-developers.com/showthread.php?t=1898377, only not using a Tab 2
Things I learned: the script that ketut.kumajaya (op) for the process of extracting and injecting the JPG's is very specialized for the Tab 2. I feel like I'd be stupid-bricking my phone just to try it. At least for injecting the pics back in.
I did cat as per instructions (using room toolbox terminal emulator),
Code:
su
cat /dev/block/mmcblk0p4 > /sdcard/mmcblk0p4.lfs
and extracted them on my ubuntu machine
Code:
../extract-jpg.sh ../mmcblk0p4.lfs
but nothing came of it. So, I decided to dump and extract all of the block devices (in /dev/block).
In sequence, only /dev/block/mmcblk0p7 is the only one that yielded results for me, but I feel like it's incomplete.
Of the 31 images that got extracted, 2 are corrupt (?) and not view-able or editable. And I'm sure on of those two is the file I seek to modify.
(see screenshot)
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I'll also upload all of the files in a zip.
The Juice
I'm just not too comfortable writing bash or modifying ketut.kumajaya's script. This is the part where I ask for help.
I narrowed down where the files "are", but can't confirm until I can actually confirm. I bet 13.jpg is the file to change to get a modded boot logo splash image. But 17.jpg could be as well.
mmcblk0p10, mmcblk0p11, mmcblk0p12, mmcblk0p13 get progressively larger, so I stopped at 13, since it exceeded 1.5gigs.
I'm sure mmcblk0p7 is the .lfs file we need to modify, I just don't know how. (I'm relatively new to linux and even newer to android)
Thanks for taking the time to read my bizarre fidings and for helping in any way, shape or form.
ps: the beginning sentence is a Law and Order joke. Sorry, it just felt so right at the time.

UPDATE: I managed to get the files. Instead of using the script in http://forum.xda-developers.com/showthread.php?t=1898377, I was able to simply extract the archive and get everything out.
Here's the original .lfs file (renamed with a .zip instead)
This "solves" one issue, but I'm still lost as to how to re-incorporate a modification into the device again.
PS: One of the pics is very funny, check it out
(see attached)
Verizon? I have an SGH-T889! Not an SCH-i605. My mind is in shambles!

Please read forum rules before posting
Questions and help issues go in Q&A and help section
Thread moved
Thank you for your cooperation
Friendly Neighborhood Moderator

sorry and bump

vebulous said:
sorry and bump
Click to expand...
Click to collapse
Sorry for the bump guys, but I'm very curious about this. And since I've never done this before on the note 2, I'm afraid I'm going to brique my phone.
Of course this serves as a warning too: please don't brick your phone just to help me. That would be bad.

bump?

current boot splash screen for samsung galaxy note 2 GT-N7100 and variants (SGH-T889, SCH-i605, etc)
also, bump

vebulous said:
current boot splash screen for samsung galaxy note 2 GT-N7100 and variants (SGH-T889, SCH-i605, etc)
also, bump
Click to expand...
Click to collapse
Do you have the image that says 'GT-N7100'? I need it for a boot animation.

ByPrin The
I am surprised there isn't more activity or interest in this thread. I am certainly interested in how to accomplish this as well. Then again I am fairly new to modding phones. It's possible that this is just something too in depth to explain and no one has the time or may just not be possible. I would think that logo must be stored somewhere deep within inner workings but should be able to be reflashed in some way or another. Then again maybe there are some limitations I am ignorant of. Can someone out there help shed some light on this for us? Are we simply chasing a ghost?

vantt1 said:
Do you have the image that says 'GT-N7100'? I need it for a boot animation.
Click to expand...
Click to collapse
No, I don't, but I'm sure you can extract it from your device if you have the N7100. See my original post, there's links and such that go in very good detail of how to do it.
I happen to have the SGH-T889 (T-Mobile US) variant of the device.
And I too started looking for this info just so I can make a cool bootanimation for myself.

TheRedlines said:
I am surprised there isn't more activity or interest in this thread. I am certainly interested in how to accomplish this as well. Then again I am fairly new to modding phones. It's possible that this is just something too in depth to explain and no one has the time or may just not be possible. I would think that logo must be stored somewhere deep within inner workings but should be able to be reflashed in some way or another. Then again maybe there are some limitations I am ignorant of. Can someone out there help shed some light on this for us? Are we simply chasing a ghost?
Click to expand...
Click to collapse
Well, I can say this about me not being interested...
I would rather not mess around with these partitions. One little mistake and you can say goodbye to your device.
To the OP.... I will say this, EVERY single android device I have ever bricked (only one) or seen get bricked was during a process that was writing to the boot partition or NAND internal mem.
Be careful. In my opinion it isn't worth it. But good luck! :good:

Close enough.

Admiral Sir Manley Power said:
Well, I can say this about me not being interested...
I would rather not mess around with these partitions. One little mistake and you can say goodbye to your device.
To the OP.... I will say this, EVERY single android device I have ever bricked (only one) or seen get bricked was during a process that was writing to the boot partition or NAND internal mem.
Be careful. In my opinion it isn't worth it. But good luck! :good:
Click to expand...
Click to collapse
I'm fully aware of the consequences, thats why I didn't do my usual "leap of faith" and hope everything works out for the best.
What I will do is scour the web to see what other devices have done this (including the note 1 guide) and see what issues people have ran into (if there are any).
In the worst possible case, I'll just close my eyes and quench my breath and if I happen to fail, I'll try this restoration procedure here.
Thanks for the warning though. I know I need tread lightly.

vantt1 said:
Close enough.
Click to expand...
Click to collapse
Nice. Looks legit to me.
If anyone is interested in the bootanimation I created, I'll link you here
part 0 plays once and proceeds
part 1 plays once and proceeds
part 2 loops until fully booted
here's a preview:

Mine is the same as yours; what you're seeing is part 1. Part 0 is the logo (which nearly seamlessly transitions from the kernel boot splash one, but I may have accidentally compressed the image by saving it in JPG during the creation process so it isn't seamless) and part 2 is the looping flower thing.
EDIT: I got rid of part 0 because having it is pointless. Now it's quite seamless! (if you ignore the delay from the boot logo to the animation itself)

And here's the ZIP for my custom boot animation. There are a few blank frames before the actual animation though. I guess it's the delay between the transitions. It might appear frozen at the very end because it's my very first boot animation.

vantt1 said:
Mine is the same as yours; what you're seeing is part 1. Part 0 is the logo (which nearly seamlessly transitions from the kernel boot splash one, but I may have accidentally compressed the image by saving it in JPG during the creation process so it isn't seamless) and part 2 is the looping flower thing.
EDIT: I got rid of part 0 because having it is pointless. Now it's quite seamless! (if you ignore the delay from the boot logo to the animation itself)
Click to expand...
Click to collapse
yeah, png's are superior to jpg in terms of quality and "features" (rgba as opposed to rgb). As for size and compression, jpg is better (but looks bad).
ANYWAY, looks like no one wants to pitch in on how to change that boot splash. On my next day off, this will become my weekend project.
Hopefully I don't brik my phone in the process....anyone have a spare note 2 laying around?

Personally, I'm OK with the existing stock boot splash image that my Note 2 has. This topic kinda veered from boot splash to boot animation though...
If it doesn't require too much risky modding, I'd also be interested in changing the boot splash. But by the looks of it, you'll need to modify the kernel.
Even if I could, I wouldn't know what to change it to.

vantt1 said:
Personally, I'm OK with the existing stock boot splash image that my Note 2 has. This topic kinda veered from boot splash to boot animation though...
If it doesn't require too much risky modding, I'd also be interested in changing the boot splash. But by the looks of it, you'll need to modify the kernel.
Even if I could, I wouldn't know what to change it to.
Click to expand...
Click to collapse
it's not the kernel that needs to be modded; it's a partition block that's either a part of the bootloader, or like a stage 1.5 kind of thing (I think).
In either case, I just need to dedicate a weekend to it. Fortunately, I've been working for 9 days straight now...yippi

Okay, LFS files are tar archives.
However, there is some data at the end of the file. I don't know if this is important or not, but in the interest of not bricking the device it's best to leave it intact.
The reason the extract script is failing is that the boot logo has jpg thumbnails embedded in the EXIF data for the image.
The file offset for the logo jpg is 0x6C000 (442368) and the JPG end of file (FF D9) for the WHOLE file is at 0x77D82, this means the block from 0x6C000 to 0x77D84 is the file. The TAR record block is stretches to 0x77E00 so the total file size available is 48640 bytes.
Used archivemount to add a new logo.jpg to the tar file, and overwrote the data block in the original with the one from the new tar file.
Going to flash it to my Note 2, cross your fingers.
Oh, the size is offset 0x6BE80 and it's an ascii string of the octal representation of the file size... 0136604 in this case. Alter it to the size of your jpg. Just put in the size in bytes into google and add "in octal" to the end, then remove the lowercase o.
EDIT: changing the file size seems like a bad idea now, it makes the archive fail to parse.

Kingrow K1 eInk (8.1, MediaTek Helio P23 (MT6763))

Just learned about GIS. Still using a Galaxy S4 w/Lineage, but am a huge fan of eink everything and impulse pre-ordered this new black and white phone from new and unknown Chinese vendor. Alleged to ship in August.
Assumed I was just going to use it off line as an ebook reader (to replace my kobo mini), but GIS has given me hope that there is a chance for a (relatively) safe/unbloated life for this device beyond that.
I’m sure there will be some eink optimization in the official ROM, but am less concerned about that than I am mysterious Chinese software.
Would love to hear anyone’s thoughts. I am more than happy to contribute to the cost of a Getting a test device in capable hands if necessary.
As a privacy enthusiast would also appreciate thoughts on hardware security on random Chinese phone as well. This is the first time I’ve ever gone out on such a limb.
Kingrow K1 Specs
5.17-inch E Ink Carta display (1280 x 720 with 283 ppi).
Frontlight.
2.0GHz MediaTek Helio P23 (MT6763) octa-core processor.
16GB of storage space.
2GB of RAM.
MicroSD card slot with support up to 64GB.
3100 mAh battery.
8MP rear camera with LED flash and auto-focus.
Android 8.1 Oreo operating system.
Dual SIM.
USB-C port.
Dual speakers.
138 x 72 x 8.5mm.
Thanks in advance.

Just realized one particular hardware issue may be the front light (since screen is not backlit like an LCD) and the controls may not be identical to backlight controls. I hope it treats the screen brightness identically and that it won’t be an issue.

Bump. For this type of preocessor I’ve only seen one example of getting stock android running relatively easily, anybody have any insight on what I can expect in the attempt?

I waited with backing this project on Indiegogo, because of the lack of GMS. I hope that could be fixed through another rom. But I doubt there will be a big developer crowd for this device. Nevertheless its nice to see it here on XDA. Followed!

Hi, I just got my Kingrow K1 in the mail today. I've always wanted an e-ink smartphone for longer battery life + less distraction, so I'm pretty excited about this. Unfortunately, the preinstalled software looks rather clunky and, as you mention, it might include random Chinese bloat/spyware. I'm hoping somebody can root this thing and we can get a developer scene going for it.
Some of the work done for Barnes & Noble Nook devices might be relevant, as those are also e-ink devices running Android.
For future reference, here's a list of everything installed on the stock ROM. I'm still trying to sort out what it all is, I think all the MTK* stuff are alternatives to missing Google packages provided by MediaTek.
$ pm list packages -f
package:/system/priv-app/FMRadio/FMRadio.apk=com.android.fmradio
package:/system/app/Gba/Gba.apk=com.mediatek.gba
package:/system/priv-app/ImsService/ImsService.apk=com.mediatek.ims
package:/system/plugin/PrivacyProtectionLock/PrivacyProtectionLock.apk=com.mediatek.ppl
package:/system/priv-app/CtsShimPrivPrebuilt/CtsShimPrivPrebuilt.apk=com.android.cts.priv.ctsshim
package:/system/app/Uicc2Terminal/Uicc2Terminal.apk=org.simalliance.openmobileapi.uicc2terminal
package:/system/priv-app/MtkTelephonyProvider/MtkTelephonyProvider.apk=com.android.providers.telephony
package:/system/app/Camera/Camera.apk=com.mediatek.camera
package:/system/priv-app/MtkCalendarProvider/MtkCalendarProvider.apk=com.android.providers.calendar
package:/system/priv-app/MtkMediaProvider/MtkMediaProvider.apk=com.android.providers.media
package:/vendor/app/LPPeService/LPPeService.apk=com.mediatek.location.lppe.main
package:/system/priv-app/WallpaperCropper/WallpaperCropper.apk=com.android.wallpapercropper
package:/vendor/app/SchedulePowerOnOff/SchedulePowerOnOff.apk=com.mediatek.schpwronoff
package:/system/app/Protips/Protips.apk=com.android.protips
package:/system/app/SmartcardService/SmartcardService.apk=org.simalliance.openmobileapi.service
package:/system/priv-app/MtkDocumentsUI/MtkDocumentsUI.apk=com.android.documentsui
package:/vendor/overlay/framework-res__auto_generated_rro.apk=android.auto_generated_rro__
package:/system/priv-app/ExternalStorageProvider/ExternalStorageProvider.apk=com.android.externalstorage
package:/system/app/YGPS/YGPS.apk=com.mediatek.ygps
package:/system/priv-app/MtkSimProcessor/MtkSimProcessor.apk=com.mediatek.simprocessor
package:/system/app/HTMLViewer/HTMLViewer.apk=com.android.htmlviewer
package:/system/app/CompanionDeviceManager/CompanionDeviceManager.apk=com.android.companiondevicemanager
package:/system/app/QuickSearchBox/QuickSearchBox.apk=com.android.quicksearchbox
package:/system/priv-app/MtkMmsService/MtkMmsService.apk=com.android.mms.service
package:/system/priv-app/MtkDownloadProvider/MtkDownloadProvider.apk=com.android.providers.downloads
package:/system/app/EngineerMode/EngineerMode.apk=com.mediatek.engineermode
package:/system/priv-app/xxLauncher/xxLauncher.apk=com.android.xx.launcherink
package:/system/app/Omacp/Omacp.apk=com.mediatek.omacp
package:/system/app/MtkBrowser/MtkBrowser.apk=com.android.browser
package:/system/app/OP01SoundRecorder/OP01SoundRecorder.apk=com.android.soundrecorder
package:/system/priv-app/WfoService/WfoService.apk=com.mediatek.wfo.impl
package:/system/priv-app/DefaultContainerService/DefaultContainerService.apk=com.android.defcontainer
package:/system/app/RedStoneOta/RedStoneOta.apk=com.redstone.ota.ui
package:/system/app/MtkDownloadProviderUi/MtkDownloadProviderUi.apk=com.android.providers.downloads.ui
package:/system/app/PacProcessor/PacProcessor.apk=com.android.pacprocessor
package:/system/app/CertInstaller/CertInstaller.apk=com.android.certinstaller
package:/system/priv-app/MtkCarrierConfig/MtkCarrierConfig.apk=com.android.carrierconfig
package:/system/framework/framework-res.apk=android
package:/system/priv-app/MtkContacts/MtkContacts.apk=com.android.contacts
package:/vendor/app/EmCamera/EmCamera.apk=com.mediatek.emcamera
package:/system/app/EasterEgg/EasterEgg.apk=com.android.egg
package:/system/priv-app/MtkMms/MtkMms.apk=com.android.mms
package:/system/priv-app/MtpDocumentsProvider/MtpDocumentsProvider.apk=com.android.mtp
package:/system/app/NfcNci/NfcNci.apk=com.android.nfc
package:/system/priv-app/Stk1/Stk1.apk=com.android.stk
package:/system/priv-app/BackupRestoreConfirmation/BackupRestoreConfirmation.apk=com.android.backupconfirm
package:/system/plugin/PermissionControl/PermissionControl.apk=com.mediatek.security
package:/system/app/BtTool/BtTool.apk=com.mediatek.bluetooth.dtt
package:/system/priv-app/Provision/Provision.apk=com.android.provision
package:/system/priv-app/StatementService/StatementService.apk=com.android.statementservice
package:/system/app/MDMLSample/MDMLSample.apk=com.mediatek.mdmlsample
package:/system/app/MtkCalendar/MtkCalendar.apk=com.android.calendar
package:/system/app/DrmProvider/DrmProvider.apk=com.mediatek.providers.drm
package:/vendor/overlay/SysuiDarkTheme/SysuiDarkThemeOverlay.apk=com.android.systemui.theme.dark
package:/system/priv-app/MtkSettingsProvider/MtkSettingsProvider.apk=com.android.providers.settings
package:/system/priv-app/SharedStorageBackup/SharedStorageBackup.apk=com.android.sharedstoragebackup
package:/system/app/PrintSpooler/PrintSpooler.apk=com.android.printspooler
package:/system/app/Uicc1Terminal/Uicc1Terminal.apk=org.simalliance.openmobileapi.uicc1terminal
package:/system/app/BasicDreams/BasicDreams.apk=com.android.dreams.basic
package:/system/app/webview/webview.apk=com.android.webview
package:/system/priv-app/InputDevices/InputDevices.apk=com.android.inputdevices
package:/system/app/BuiltInPrintService/BuiltInPrintService.apk=com.android.bips
package:/system/framework/mediatek-res/mediatek-res.apk=com.mediatek
package:/vendor/app/AutoDialer/AutoDialer.apk=com.example
package:/system/priv-app/DuraSpeed/DuraSpeed.apk=com.mediatek.duraspeed
package:/system/priv-app/MusicFX/MusicFX.apk=com.android.musicfx
package:/system/app/ExtShared/ExtShared.apk=android.ext.shared
package:/system/priv-app/OneTimeInitializer/OneTimeInitializer.apk=com.android.onetimeinitializer
package:/vendor/app/NlpService/NlpService.apk=com.mediatek.nlpservice
package:/system/priv-app/MtkTelecom/MtkTelecom.apk=com.android.server.telecom
package:/system/app/KeyChain/KeyChain.apk=com.android.keychain
package:/system/app/PrintRecommendationService/PrintRecommendationService.apk=com.android.printservice.recommendation
package:/system/priv-app/MtkDialer/MtkDialer.apk=com.android.dialer
package:/system/app/MtkGallery2/MtkGallery2.apk=com.android.gallery3d
package:/system/app/GoogleTTS/GoogleTTS.apk=com.google.android.tts
package:/system/priv-app/ExtServices/ExtServices.apk=android.ext.services
package:/system/priv-app/CallLogBackup/CallLogBackup.apk=com.android.calllogbackup
package:/system/priv-app/MtkPackageInstaller/MtkPackageInstaller.apk=com.android.packageinstaller
package:/system/priv-app/ProxyHandler/ProxyHandler.apk=com.android.proxyhandler
package:/system/app/MtkLatinIME/MtkLatinIME.apk=com.android.inputmethod.latin
package:/system/priv-app/ManagedProvisioning/ManagedProvisioning.apk=com.android.managedprovisioning
package:/system/app/CalendarImporter/CalendarImporter.apk=com.mediatek.calendarimporter
package:/vendor/app/MTKThermalManager/MTKThermalManager.apk=com.mediatek.thermalmanager
package:/system/priv-app/CallRecorderService/CallRecorderService.apk=com.mediatek.callrecorder
package:/system/app/MtkWebView/MtkWebView.apk=com.mediatek.webview
package:/system/app/WAPPushManager/WAPPushManager.apk=com.android.smspush
package:/vendor/app/SimRecoveryTestTool/SimRecoveryTestTool.apk=com.mtk.telephony
package:/system/priv-app/Baidu_Location/Baidu_Location.apk=com.baidu.map.location
package:/system/priv-app/StorageManager/StorageManager.apk=com.android.storagemanager
package:/system/app/OpenWnn/OpenWnn.apk=jp.co.omronsoft.openwnn
package:/system/app/BookmarkProvider/BookmarkProvider.apk=com.android.bookmarkprovider
package:/system/priv-app/MtkSettings/MtkSettings.apk=com.android.settings
package:/system/app/MDMConfig/MDMConfig.apk=com.mediatek.mdmconfig
package:/system/app/ExactCalculator/ExactCalculator.apk=com.android.calculator2
package:/vendor/app/LocationEM2/LocationEM2.apk=com.mediatek.lbs.em2.ui
package:/system/app/CtsShimPrebuilt/CtsShimPrebuilt.apk=com.android.cts.ctsshim
package:/system/priv-app/VpnDialogs/VpnDialogs.apk=com.android.vpndialogs
package:/system/app/MtkEmail/MtkEmail.apk=com.android.email
package:/vendor/app/MusicBspPlus/MusicBspPlus.apk=com.android.music
package:/system/priv-app/MtkTeleService/MtkTeleService.apk=com.android.phone
package:/system/priv-app/Shell/Shell.apk=com.android.shell
package:/system/app/WallpaperBackup/WallpaperBackup.apk=com.android.wallpaperbackup
package:/system/priv-app/BlockedNumberProvider/BlockedNumberProvider.apk=com.android.providers.blockednumber
package:/system/app/UserDictionaryProvider/UserDictionaryProvider.apk=com.android.providers.userdictionary
package:/system/priv-app/MtkEmergencyInfo/MtkEmergencyInfo.apk=com.android.emergency
package:/system/priv-app/FusedLocation/FusedLocation.apk=com.android.location.fused
package:/system/app/FactoryTest/FactoryTest.apk=com.xthink.factorytest
package:/system/app/MtkDeskClock/MtkDeskClock.apk=com.android.deskclock
package:/system/priv-app/MtkSystemUI/MtkSystemUI.apk=com.android.systemui
package:/system/app/Exchange2/Exchange2.apk=com.android.exchange
package:/system/app/BluetoothMidiService/BluetoothMidiService.apk=com.android.bluetoothmidiservice
package:/system/app/MtkNlp/MtkNlp.apk=com.mediatek.location.mtknlp
package:/system/app/FileManager/FileManager.apk=com.mediatek.filemanager
package:/system/app/MTKLogger/MTKLogger.apk=com.mediatek.mtklogger
package:/system/app/SensorHub/SensorHub.apk=com.mediatek.sensorhub.ui
package:/system/app/MtkBluetooth/MtkBluetooth.apk=com.android.bluetooth
package:/system/app/MtkWallpaperPicker/MtkWallpaperPicker.apk=com.android.wallpaperpicker
package:/system/priv-app/MtkContactsProvider/MtkContactsProvider.apk=com.android.providers.contacts
package:/system/app/CaptivePortalLogin/CaptivePortalLogin.apk=com.android.captiveportallogin
package:/system/plugin/DataProtection/DataProtection.apk=com.mediatek.dataprotection
package:/vendor/app/WapiCertManager/WapiCertManager.apk=com.wapi.wapicertmanager
package:/system/app/kindlefc/kindlefc.apk=com.amazon.kindle
Click to expand...
Click to collapse

I've managed to get the device into fastboot mode. I'd like to flash a custom recovery like TWRP, but I don't know which one is compatible with this device. Any suggestions?

Bunyip123 said:
I've managed to get the device into fastboot mode. I'd like to flash a custom recovery like TWRP, but I don't know which one is compatible with this device. Any suggestions?
Click to expand...
Click to collapse
do you happen to have the stock firmware with the boot.IMG. i want to look at it and see if its similar to my device. i have a umidigi one max and it has the same chipset and it looks like alot of the same apps

th3d3ck3r said:
do you happen to have the stock firmware with the boot.IMG.
Click to expand...
Click to collapse
No, I don't have the stock firmware. If you can point me to some instructions, I'm happy to try to extract a copy of it and post it here.

Kingrow K1 doesn't let me log in to google services
Hi,
I'm not a developer, sorry for my lack of knowledgle, however I'm desparate to find a sollution, maybe you can help me here.
I've bought the Kingrow K1 only to find there's no way of signing in to google accounts, contacts, callendar etc. $%^&*()!~
I hope it's just a question of installing and configuring the missing pieces.
Can you please help me out?
Tom

Maybe flashing Gapps like on AOSP? ?

You could try flashing a gapps package like https://opengapps.org/ but I don't know if it will work without root.

Bunyip123 said:
You could try flashing a gapps package but I don't know if it will work without root.
Click to expand...
Click to collapse
Without TWRP
We even have no stock firmware. I see it's a first step to acquire it.

sandworm88 said:
Without TWRP
We even have no stock firmware. I see it's a first step to acquire it.
Click to expand...
Click to collapse
is it of any help the url that get called when a k1 fails to find a new OTA firmware?
It's using a server called
fota.redstone.net.cn
on the port 6100
and it's asking for service/request

_jet said:
is it of any help the url that get called when a k1 fails to find a new OTA firmware?
It's using a server called
fota.redstone.net.cn
on the port 6100
and it's asking for service/request
Click to expand...
Click to collapse
...i'm just asking, i don't know anything about how to retrieve (and keep) a firmware copy

Any updates on this? someone in Kingrow K1 eReader/Phone User Group on FB claims they got root:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

Hello, I've worked on a MT6763 device before. You may be in luck because MTK devices have built-in flash mode you can access. This would mean you can dump partitions provided you locate their offsets (if you can get hands on a scatter file, that would help a lot). The flash mode also allows you to bypass any locked bootloader (though, you don't seem to face such issue, but nice to know it's possible) restrictions. You may also be able to dd the blocks and create a stock firmware dump for backup. A good chance TWRP can be ported without kernel sources by using a very similar device's port as a base and dropping your current recovery image's kernel and fstab values in it.
I do not own this device myself, but I am interested in any findings regarding this topic. Good luck.
EDIT:
_jet said:
...i'm just asking, i don't know anything about how to retrieve (and keep) a firmware copy
Click to expand...
Click to collapse
Can you tell me how your /dev/block structure looks like, (use ls). If you navigate deep enough, you will see "by-name" folder, you can then dd the "boot" partition as a boot.img file.
EDIT2:
Actually, I suggest just dd'ing your system partition to your PC. You can also flash GSIs using fastboot. By dd'ing your system partition, you essentially make a fallback in case the image fails.

Cernodile said:
Hello, I've worked on a MT6763 device before. You may be in luck because MTK devices have built-in flash mode you can access. This would mean you can dump partitions provided you locate their offsets (if you can get hands on a scatter file, that would help a lot). The flash mode also allows you to bypass any locked bootloader (though, you don't seem to face such issue, but nice to know it's possible) restrictions. You may also be able to dd the blocks and create a stock firmware dump for backup. A good chance TWRP can be ported without kernel sources by using a very similar device's port as a base and dropping your current recovery image's kernel and fstab values in it.
I do not own this device myself, but I am interested in any findings regarding this topic. Good luck.
EDIT:
Can you tell me how your /dev/block structure looks like, (use ls). If you navigate deep enough, you will see "by-name" folder, you can then dd the "boot" partition as a boot.img file.
EDIT2:
Actually, I suggest just dd'ing your system partition to your PC. You can also flash GSIs using fastboot. By dd'ing your system partition, you essentially make a fallback in case the image fails.
Click to expand...
Click to collapse
Thanks for you answer @Cernodile. I'm the guy Ti He who posted in the FB group.
I'm currently trying to port a TWRP to our device. First I did a full read with Miracle Box, so in case something goes wrong I can restore my device. I used a TWRP from Cubot King Kong 3 because it has the same SoC and GPU. I unpacked my stock recovery and the Cubot recovery and replaced files like recovery.img-kernel
recovery.img-kernel_offset
ramdisk/prop.default
ramdisk/init files
ramdisk/ueventd.rc
ramdisk/ect/recovery.fstab
I flashed the repacked recovery through fastboot and booted into TWRP. I assume that TWRP would have been booted, because I can do adb devices and see my phone in recovery. But the display only shows some black lines, so there must be something wrong. Do you have any idea where to look at? See attached the log from /cache/recovery/.
Regards - Timo

helnorsksvartmetall said:
Thanks for you answer @Cernodile
I'm currently trying to port a TWRP to our device. First I did a full read with Miracle Box, so in case something goes wrong I can restore my device. I used a TWRP from Cubot King Kong 3 because it has the same SoC and GPU. I unpacked my stock recovery and the Cubot recovery and replaced files like recovery.img-kernel
recovery.img-kernel_offset
ramdisk/prop.default
ramdisk/init files
ramdisk/ueventd.rc
ramdisk/ect/recovery.fstab
I flashed to repacked recovery through fastboot and booted into TWRP. I assume that TWRP would have been booted, because I can do adb devices and see my phone in recovery. But the display only shows some black lines, so there must be something wrong. Do you have any idea where to look at? See attached to log from /cache/recovery/.
Regards - Timo
Click to expand...
Click to collapse
That seems already quite promising! It seems like your device is trying to render some TWRP elements, perhaps you have wrong resolution set as suggested by "framebuffer: 3 (344 x 725)". What would assist me here greatly would be .prop files from stock and your TWRP port such as default.prop.

I also attached the Scatter file from my device on my last post.
See below the prop files from stock and port (Cubot King Row 3).
(I also tried with port TWRP from Umidigi One Max but with the same result)

helnorsksvartmetall said:
I also attached the Scatter file from my device on my last post.
See below the prop files from stock and port (Cubot King Row 3).
(I also tried with port TWRP from Umidigi One May but with the same result)
Click to expand...
Click to collapse
First inconsistencies I see:
This is in your stock, but not port.
Code:
ro.product.cpu.abi=arm64-v8a
ro.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi
ro.product.cpu.abilist32=armeabi-v7a,armeabi
ro.product.cpu.abilist64=arm64-v8a
dalvik.vm.isa.arm64.variant=cortex-a53
dalvik.vm.isa.arm64.features=default
dalvik.vm.isa.arm.variant=cortex-a53
Although, I don't think that is the cause. I'd keep looking for a device that has e ink patches for TWRP, you can use that as base, rebuild the similar device's TWRP and then do same port method.

Toyota Map Update Hacking Help

Hi everyone,
I'm looking for a little help modifying the ToyotaHMIMainSWUpdate.swf to skip the activation check when updating the maps.
So far I've managed to skip the screen where you enter the activation code and I'm able to select which maps I want and progress to the confirmation screen.
After pressing confirm I get the message saying "Radio will reset to complete the update" and then it either kicks me back to the previous screen or jumps back to the beginning with a message saying "I'm working on it...", any help is appreciated.
Here's a link to the unmodified file:
File on MEGA
mega.nz
Making modifications to the swdl and swdlInstall ISOs isn't an issue as I'm able to rebuild them with a valid signature.

It appears it's the nav-activation.lua and not the ToyotaHMIMainSWUpdate.swf file which needs to be modified. The swf must just act as a front end to the lua script.
After patching the activation check in the lua file and rebuilding the ISO I was able to sucessfully bypass the activation screen and the unit rebooted as it should after selecting which maps I wanted to install.
The problem I now have is that the ISO fails the secondary signature check when trying to validate against the embedded signature.

This is how the beginning of one of the ISOs looks.
The part marked in green is a digital signature created from a list of all the files and folders in the ISO file, along with some additional information about them.
The part in blue is a SHA-256 hash created by reading chunks of 32768 bytes.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
The part in green is verified by the following commands:
inject -e -i /fs/usb0/swdl.iso -f /tmp/isodigest.sha256 -o 0 -s 64
isodigest -df /tmp/iso.digest /fs/usb0/swdl.iso
openssl dgst -sha256 -verify /etc/keys/swdl.pub -signature /tmp/isodigest.sha256 /tmp/iso.digest
Click to expand...
Click to collapse
If successful, you will get "Verified OK"; otherwise, you will get "Verification Failure."
The part in blue has to match the output created by hashFile:
hashFile sha256 /fs/usb0/swdl.iso /tmp/tmp.digest 32768
Click to expand...
Click to collapse
I'm able to pass the verification checks for the parts in green and blue, but I can't seem to figure out how the part in red is generated, as the verification step then fails when verifyISO is run after the unit is reset before the updates are actually installed.
If we can figure out what the parts marked in red are, then we may be able to generate fully customizable updates.

It looks like the blue and red parts are base64 encoded and passed to com.harman.service.samSecurity as json in the following format:
{
"signType": "appUpdate",
"signature": "base64 encoded value"
}
Click to expand...
Click to collapse
The last character is also removed after it's been base64 encoded

Hi,
I'm trying the same.
Do you have any updates after the last message you send?
Can't we decode the activation code instead?

@willmav5000 Which system are you currently investigating?
Because I am looking for Toyota Touch & Go 2 system (MM17/MM19)
Do you find the ToyotaHMIMainSWUpdate.swf in the KWI update file?

I find a Russian website where KWI unpacker tool is available:
Курим KIWI
club-lexus.ru
Файловый архив
It seems to support KIWI 1.22 format, does it compliant with Toyota Touch & go 2 system?
Thanks.

lelapindelaforet said:
@willmav5000 Which system are you currently investigating?
Because I am looking for Toyota Touch & Go 2 system (MM17/MM19)
Do you find the ToyotaHMIMainSWUpdate.swf in the KWI update file?
Click to expand...
Click to collapse
I'm currently looking into the Toyota Touch & Go 2 MM16 system.

jobdbr said:
Hi,
I'm trying the same.
Do you have any updates after the last message you send?
Can't we decode the activation code instead?
Click to expand...
Click to collapse
No updates yet as I've been busy with other things. Being able to generate activation codes could be a possibility and if anyone is able to get an SPI dump that would also help out a little.

willmav5000 said:
Hi everyone,
I'm looking for a little help modifying the ToyotaHMIMainSWUpdate.swf to skip the activation check when updating the maps.
Click to expand...
Click to collapse
Hi! For what I've seen Toyota Touch & Go 2 seems to be sharing the QNX platform with Jeep (FCA) Uconnect. So this sounds very similar here where the 1st check happens "within the update image" itself as quick and simple validation for file/version origin and match to the head unit hardware. But then the second and slow image hash validation is done before flashing the data "on the head unit" - and inevitably fails... Unless you get full access to the head unit
willmav5000 said:
Making modifications to the swdl and swdlInstall ISOs isn't an issue as I'm able to rebuild them with a valid signature.
Click to expand...
Click to collapse
So yes, I believe you can fool the quick signature check, but no go with the full image sha256 hash verification. On the Uconnect the way to go is to exploit the head unit to gain root access and then to avoid the verification, but still modified Nav binary may be needed to skip map license check...

devmihkel said:
Hi! For what I've seen Toyota Touch & Go 2 seems to be sharing the QNX platform with Jeep (FCA) Uconnect. So this sounds very similar here where the 1st check happens "within the update image" itself as quick and simple validation for file/version origin and match to the head unit hardware. But then the second and slow image hash validation is done before flashing the data "on the head unit" - and inevitably fails... Unless you get full access to the head unit
So yes, I believe you can fool the quick signature check, but no go with the full image sha256 hash verification. On the Uconnect the way to go is to exploit the head unit to gain root access and then to avoid the verification, but still modified Nav binary may be needed to skip map license check...
Click to expand...
Click to collapse
Yeah the initial component in green is verified by one of the public keys, while the second part in blue is just a sha256 digest based on the remainder of ISO file. I am able to replicate both of those with some custom scripts I've written and fully alter the ISO how ever I want, I can still successfully pass the first stage of validation and initiate the update and/or execute custom scripts until the device restarts for the actual installation process. I still haven't been able to figure out how the third part in red is generated, but I do know that it also utilizes the sha256 digest in some way.
I have a dump of all the files from the head unit and have decoded all the Lua files. I've been looking over everything and discovered a few things of interest, but nothing solid yet.

Right, still sounds similar to the Jeep exploit, that by modifying the update image you can execute random code as root(?) on the head unit while triggering the update check? Could you then just copy and replace the updated map files into the storage?

willmav5000 said:
No updates yet as I've been busy with other things. Being able to generate activation codes could be a possibility and if anyone is able to get an SPI dump that would also help out a little.
Click to expand...
Click to collapse
Hi,
could it be helpful, if I send you original activation codes?
I have Toyota Touch 2 With Go (Toyota Auris 2018) software version 6.20.0SPWL (map version 2022 v2)
From 2019 until 2022 I have updated my system via MapCare, so I have 7 original activation codes for my device (and for 7 updates numbered from 6.13.0L to 6.19.0L)...
Together with my device ID you can perhaps figure out how activation codes are generated...

I could also help by sending you my activations codes and my device ID.
I have a 2017 Rav4

something new?

Nothing new, I've been unable to obtain any dumps and I've been away so this has been shelved for now.

Dear @willmav5000
You certainly hear about GreeLuigi1 and his hack of Hyundai system (https://programmingwithstyle.com/)
He successfully entered in the system and explain all the steps to do it.
He also published on GitHub the procedure to decrypt Hyundai firmware: https://github.com/greenluigi1/HyundaiFirmwareDecrypter
Could you please explain how you proceed to try to hack Toyota system?
You obtain SWF file I think for the Toyota update package (KWI file maybe?) but how?
If we cross our knowledge we should be able to progress further, I hope.
Regards