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.
Related
Hi there!
As i said on a thread (bit long time ago), i had the intention of making an opensource file manager for the kin.
So i have been working on for two days, and i'm reserving this thread for its releases and descriptions.
It will be given as donationware, which means that you can take it for free and donate if you wish (or not to... )
SECURITY DISCLAIMER
- As you can imagine, by using this tool you have not guaranteed the operational state with your device and is provided "as is". You are the only responsable on the effects if could have on your device, even though i tested locally all the options for hours. Like you do for 3rd party non-certified software.
- DO NOT, i repeat DO NOT unplug the device nor close the program while writing or reading from the device. Errors states are unknown and you may scr3w up your flash memory.
{
"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"
}
- If during the usage, it takes long, WAIT for the transmission to end. Errors are handled by the program and in the last cases there are 2 to 3 levels of error treatment, notificating you in the info box and storing a brief description on the "error.log" file when it's ultra. (I'm still human, new errors can appear).
- IF during this usage the kin gets a "Connected" window and the program is clossed without closing that window, then it's the time where you can unplug and it will reset the device communication values, pluggin again. If you reach this state without doing magic, notify it to solve the bug.
Characteristics
- Libusb driver given for the kin (needs to remove the Zune one)
- Windows (XP,7) 32/64 bits. Linux (through Mono), Mac Osx(through Mono Framework) Compatibility
- Developed in pure c# (using libusbdotnet)
- Developped in layers:
----> Usb
----> Mtp Functions
----> Mtp<->Interface manager
----> Interface
Images V0.01
Requirements
- OS:
---> Windows
------->Net Framework 2.0
------->Libusb-win32 driver(provided below)
---> Linux
------->Root mode to access the devices.
------->Mono
------->Libusb 1-0 components
---> Mac OsX (Checked with Snow Leopard, PAIN IN THE ASS)
-------> Mono framework
-------> Libusb-1.0 source (sourceforge)
----------> Modern OSX compile for 64 bits. Mono needs 32 bits. Compile (as root) with:
Code:
sudo su
./configure CC="gcc -m32"
make CC="gcc -m32"
make CC="gcc -m32" install
*Note: it takes a looooooooooooooooooong time to load the first time. be patient
*Note2: if mono yells about needing X11 for Winforms, download Wireshark for OSX, which has X11 easy installation inside (needed for it).
Download links
Kin Driver (libusb-win32): (Create one with InfWizard for the kin PID and VID)
32 bit version: http://www.mediafire.com/?0nhrdn7f5je6dcx
64 bit version: (please use above version)
Source: ***Still needs a bit more documentation, cleaning and binary testing for errors ***
* Note that i DONT have a 64 bit hardware, so i based its compatibility on the failed running in my Windows 7 (aka "this is for other architecture error")
** Note that to use this driver you MUST remove the Zune driver. I recommend to test it on a clean virtual machine first
Functions
- TreeView Kin Storage explorer (Auto Resyncs after each operation)
---> Select one or multiple items with the checkboxes next to them.
- Batch upload to the kin (to the root of the tree)
---> Select one ore more files from the selection dialog and go go go. Any file, anytime
-------> **Danger** pressing twice will upload files twice, be patient.
- Multiple file download from the kin
----> Mark any file from the tree and press "Download". The file will be downloaded to a subfolder "Downloads" next to the exe, where the tree storage has been replicated.
-------> **Danger** Folder and Playlists and other files are just logical, and have no size, so program deals with them as folders (and are created emptied in the local system at the pc)
- Multiple file delete
-------> Mark any file from the tree and press "Delete". After confirmation, the files selected will be removed from the device.
-------> **Danger** Folders are not deleted. Infobox at the bottom will inform you if a file could not be deleted.
-------> **Danger** I trickied it so the storage root could not be deleted... ahhh smart little fellas.. you were already thinking in that huh! rofl.
Known issues
- During my random tests around, i found that sometimes (dunno why exactly), the kin <-> Kino communication skips a step, messing up the mtp communication schema. The solution i used in this release was to show the root storage without children nodes. As this case is an error, you should tell me if you know a repeatable way to get it so i can retest and solve it.
To keep going with the kin, close Kino, and unlock the Connected window (slide your finger over it) and unplug & plug the usb again.
F.A.Q.
- Q: No donation button in the end?
- A: Nope. Just when it proves to be useful .
- Q: This works with Kin One devices?
- A: No. I only have access to Two (bricked) and TwoM devices, so cannot test for the little round turtle.
- Q: Do you provide a driver for Kin?
- A: Yes. It is only a bridge from the programs to the libusb-win32 functions. Unfortunately, you would have to remove the zune driver (Hardware manager) before using this one.
- Q: This bricks kin devices?
- A: At all.
- Q: This can hack the device?
- A: No. This is only a tool to upload and download files to your kin. If later it's used to hack, good anyway
- Q: Can this upload *any* file to the kin storage?
- A: Yes, binary files like exe, cab,pdf, ... will be labeled as 0x3000 (undefined filetype) for the kin.
- Q: Can i take the code and make my version called OmgKinManager?
- A: Yup. It would be a nice detail to include a little text in "about..." regarding me though
kk, apart from the above, i'm a bit stuck on the uploading procedure, doing it dinamically, not with known filesizes like i tested before.
I will try to get it to work and allow multiselection file dialogs.
Later, downloading, which is easier, as i just request files. I will try to make the selectable tree work, so several files can be downloaded at a time.
Btw, the tree is not a demo, it's my real storage, being asked to the kin. It's a long process, as i ask for the id's and their values to the kin to create a Tree structure, later parsed by the interface.
Whenever that and deletion is done, i will upload both the driver and the program/source to the public.
For Zune's functionality lost scared people, i would suggest to try on a windows virtual machine first (which i will do to test for .net framework requirements and so)
Way cool imn glad to see some progress
Nice work! I spend a lot of time on this forum reading posts and 75% of the time it's your post. You've spent a lot of time working on this project and we all appreciate it. Expect a donation from me in the near future
I'm speechless.
Hey john, you have only gotten into the media section correct? What type of things have you gotten to do if i may ask. If you want, I can help get "into" the other parts of the phone. A.K.A contacts. That's my main concern right now. I could care less of customizing the OS (which I will get to if you care to lend a hand.) Since I don't want to Say anything just yet, send me an email to [email protected]. I would like to help. I'm on my phone at the moment but tomorow I'll post how i got the phone into a writeable state (which I don't know if it still work. I've only tested twice.) If it doesn't work tomorrow, I'll donate my time during the week helping you guys. I may need to get a new battery.
P.S. It's taking me awhile to do this becuase I dont want to brick my phone. Im definately not using my enV touch!
please, read the faq above. this is not a hacking thing, but a sync one.
to be honest, i dont care about contacts cause i dont use this phone to make calls and i just wanted it to be more open. pinned apps or phone settings storage would be my only interest apart storage folder.
also, i dont want to keep secrets or long term waiting things. post what you want or dont post, but dont make it a teaser of nothing. plus i dont wanna go emailing people.
Props to you. Great utility, if it were able to get deeper into the system. Then it would be golden.
Edited for many reason
As some other forumeer seems to have gotten into the phone system, imma halt this development till acess range is shown (filesystem / storage / settings), if any.
There's no need to redo all the required mtp subsystem if we can get there by other (easier) means. OS native explorer, for example.
just go ahead and work on it in case the other guy fails. ^.^
oaktree333 said:
just go ahead and work on it in case the other guy fails. ^.^
Click to expand...
Click to collapse
Nice future-sight on this post
I just tested the file upload in the command-line again with static (coded by hand) filesizes.
Here is a new vid (hahaha famous ultralowres) where a file is upload to a just-formatted kin (CB+power).
File: dstpa.mp4 (BEP- Don't stop the party), 33.1MB
Destination: Kin storage root
Playable after upload: yup!
Mp4 tags: At all .
Just a upload showcase, not just naming the procedure .
nice nice ^.^
more freedom in file management I like.
woot goodjob
I have to give you kudos for your dedication. You kept at it even after you bricked your first kin.
I patiently await a release.
I'm trying to get the alpha release up today (tonight here).
I was in the mood and moved my coding-ass. Solved most of the problems on-the-go, but downloading.
I'm trying to allow multidownload keeping same directories on the pc... just cause i wanted to... rofl.
Hummmmm,
EVERYDAYIAMSHUFFLIN
Mmm after discovering several things, and implementing a lot of bugfixes (didnt know some things about MTP), there it is.
here, and all the versions are updated and uploaded in the 1st post, among the driver for it.
As posted there, i suggest to use it on a virtual machine with .net framework 2.0 cause the removal of the zune's driver for the kin.
You can now take your kin and (if the driver & program behave correctly), upload the files you want to the Kin.
Any type of file, any time.
I'm pretty naughty telling this, but apart from uploading....... i don't check for the file contents... so if any of you want to turn a .exe into .mp4 to look for exploits i wouldnt blame you for testing....
Double naughty if i say that Zune doesnt load info from the files itself, but only what was transfered from MTP (.. poor fella)
You can check that, cause it will only load the filename and name of the mp3, ... cause i did that (before today, i just sent filename, which makes its name blank on zune, like you saw in my video from BEP).
Hope you all enjoy and no errors appear.. rofl.
Btw, there's no donate option, cause i think it's more fair to think about that when the program is known to work, and not just alpha releases .
It's 02:53 AM here, so i better go to bed, to work tomorrow and that things....
I just wish this thing could play games lol.
@Johnkussack
Wow. I have to say thank you for putting your time and effort into really hacking this phone. I can't wait to see someone get android or wp7 running on this thing (if it's even possible with the hack you have, I'm not sure). Ether way, thanks for everything.
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?
Introduction
Some of you will, remember lets save some bricks? Well, it's taken a long time to perfect this on the i9000, which is ironic because this is where it started, but we finally have a way! You can perform this mod on a bricked device and resurrect it, or you can apply it as a protective measure.
The way this works is we change the OM value in the processor by modifying an individual electronic binary signal. The signal we are interested in is xOM5. This line is normally grounded, causing the overall OM value to equal 0x9. When we bring this line high, the OM value becomes 0x29. This reverses the booting order and ensures you will always have boot from USB available before the device starts.
This is a better option than JTAG for resurrecting a device. How could it possibly be better then JTAG? Let's count the ways....
1. The only part required is a wire.
2. No shipping time.
3. No cost for a box to interface the computer.
4. Permanent.
5. Can be done as a preventive measure.
6. Gives the ability to test new Bootloaders temporarily.
7. Allows development of the entire system.
8. Removes worry about flashing and acts as a backup.
After performing this mod:
Remove the battery, replace the battery, plug in USB, your phone will connect to the computer via USB and await commands for 2 seconds. Otherwise it will pretty much act like a i9000. See the Special Instructions section.
Part 1: Hardware Modification
You will need:
1. Get someone who knows what they're doing with a soldering iron. If they don't know what flux is, then they don't know what they're doing.
2. soldering iron - make sure it's sharp, if it's not sharp, then sharpen it, flux it and retin it.
3. flux
4. solder
5. tweezers
6. A relay (for the wire contained within)
getting started:
You will need a very small peice of wire. Tear apart the relay unravel the coil within and grab about 5cm~ of wire. The fact that it comes from a relay is important because relays generally have very small wire which are individually treated with a non-conductive coating.
Take the 5cm~ wire from the relay and tin the very edge of it. No more then 1/32". If you tin more then 1mm, cut off the excess. It is desirable to have a slight bit of excess solder on the tip of this wire.
1. Tear apart your device. Remove battery cover, battery, 6 screws, the back case and 4 connectors from the board.
{
"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"
}
2. remove the EM shield from the board to expose the resistors
3. Replace the xOM5 resistor from the top to the bottom or remove the xOM5 resistor and connect either xOM5 center pad to either xOM3's or xOM0's center pads.
4. Reassemble the device
Special Instructions
This replaces the battery charging sequence for the first few seconds of being plugged in.
To turn on the device, and operate in normal mode, you must hold the power button for 5 seconds.
3 button Download mode works as usual, however you must not have the S5PC110 drivers installed on the computer. You can use your custom rom menu option, adb reboot download, or use a terminal to "reboot download". 301Kohm Factory Mode JIGs work as well, but you must press power to bypass the S5PC110 mode.
Part 2: Software Based Resurrection
Connexion2005 (Mobiltechvideos) perfomed the very first resurrection on this device based on a Google+ post I made with a picture of the xOM pins. Usually I post two separate posts, but since the software resurrection was already ready already, I decided to include it in this post. The tools used are the same as every other GalaxyS device. The resurrector must be run within 2 seconds of plugging in the USB cable. Thanks Connexion2005!
You Must have UnBrickable Mod applied to your device. If you're not sure, run this tool under Linux: http://forum.xda-developers.com/showthread.php?t=1257434
This currently only works for Linux based computers or Windows based computers with proper drivers installed, with a Linux Virtual Machine, Get Ubuntu here: http://www.ubuntu.com , Get Virtualbox Here: http://www.virtualbox.org/wiki/Downloads
You must have Java installed on your computer: http://www.java.com/en/download/
Unbricking:
1. Apply UnBrickable Mod to your device: see Hardware Modification section
2. Run ModeDetect and plug in your i9000. (Not a requirment, but helpful)
When you see this image you are in S5PC110 SEC SoC mode. When you see this mode you must proceed to step 3.
If it will only show this image, then you have not performed the modification correctly, or you have a hardware problem.
If it shows this, regardless of what's on your screen, you're in download mode:
3. Run UnBrickable Resurrector: Get it from the SVN repository here: http://code.google.com/p/hummingbird-hibl/downloads/list This will only work on linux. Install Linux or dual boot if you have windows.
On this device the resurrector must be run within 2 seconds of plugging in the device. So you must be quick. I find it's easiest to click Download Mode, type a password, plug in the device, then press enter.
4. Run Heimdall One-Click to flash firmware on your device. http://files.teamkomin.com/i9000SGS/i9000-XXJVT-One-Click.jar
5. repeat steps 2, 3 and 4 with bootloader flashing enabled (Heimdall One-Click has a safety mechanism which requires you to flash once before flashing bootloaders).
Conclusion
Congratulations. You now have a device which works like a KIT-S5PC110 with an OM Value of 29. Now get to developing some serious custom software.
reading material
Creating your own Samsung Bootloaders: http://forum.xda-developers.com/showthread.php?t=1233273
KIT-S5PC110 manual: http://www.mediafire.com/?94krzvvxksvmuxh
how to use DNW: http://tinyurl.com/dnw-how-to
Flash using openOCD and DNW: http://www.arm9board.net/wiki/index.php?title=Flash_using_OpenOCD_and_DNW
another DNW example: http://www.boardset.com/products/mv6410.php
ODroid dev center: http://dev.odroid.com/projects/uboot/wiki/#s-7.2
drivers and utilities
This will be an ever expanding list
Windows Drivers http://forum.xda-developers.com/attachment.php?attachmentid=678937&d=1312590673
Windows Download Tool DNW: http://forum.xda-developers.com/attachment.php?attachmentid=678938&d=1312590673
Windows Command Line tool: http://forum.xda-developers.com/showpost.php?p=17202523&postcount=27
Linux DNW Utility: http://dev.odroid.com/projects/uboot/wiki/#s-7.2
Linux ModeDetect tool: http://code.google.com/p/hummingbird-hibl/downloads/list
Linux Automated UnBricker:http://code.google.com/p/hummingbird-hibl/downloads/list
firmware
Bootloader Hello World by Rebellos http://forum.xda-developers.com/attachment.php?attachmentid=698077&d=1314105521
UnBrick tool http://forum.xda-developers.com/showthread.php?t=1242466
Such an important piece of information we have here!
Congrats Adam and all the team, will write about this!!
That's seems to be our alma mater of UB Mods. The first of whole family finally got UnBrickable.
Okay, so, what is Hummingbird Interceptor Boot Loader (HIBL)?
Basically: It allows to load any amount of data (limited by size of RAM block, the biggest one single block available is 256MB) through USB connection with PC under any specified address into memory and then execute it.
Technically: It does consist of 2 pieces fused together - BL1_stage1 and BL1_stage2.
Each stage starts from 16bytes (4 ARM WORDs) of secure boot header. In stage1 these are mandatory, in stage2 they can be random (nulled them in my code), so EntryPoint of each stage does start at its 0x10 offset.
BL1_stage1, loaded under 0xD0020000 address, is short code, digitally signed by Samsung. It has been released to break "Chain of Trust" and alter Secure Boot into Non-Secure Boot process. Literally stage1 just do some compare operations and then jumpout to BL1_stage2. (Yes, I also see no point of releasing hardware secured CPU version together with software which is bypassing it's security)
BL1_stage2, must be placed at 0xD0022000 address (it's fused together with stage1 into HIBL, so it's at 0x2000 offset of HIBL.bin) it is unsigned because Secure Boot Context, prepared by iROM (BL0) has been already ignored by stage1.
Its FASM_ARM sourcecode:
http://code.google.com/p/hummingbir...unk/HummingBirdInterceptorBootloader/HIBL.ASM
This is where the code start real work, it does begin with standard ARM core jump vector table (just to keep stick to standard, these aren't used anyway).
1. It does use I9000 BL1_stage2 functions (init_system) which I linked to it, these are used to init DMC controllers, as to this point code is executing in and working with very tiny, 96KB iRAM space, after calling this function it turns all 512MB of RAM available.
2. Make sure DMC is configured properly (write some value to address 0x40~~ memory space, then read it and compare with previously written)
3. Reinit iRAM heap to the BL0 initial state (to convince it USB dload mode haven't been called yet), by storing and restoring UART pointer only (to keep debug output flowing properly)
4. Call iROM usb_downloader function.
5. Read the address where downloaded data has been placed.
6. Jump into this address.
This, properly used provides similiar debug output (similiar, because its outdated testlog)
������������������������������������������������������������������������
Uart negotiation Error
----------------------------------------
Hummingbird Interceptor Boot Loader (HIBL) v1.0
Copyright (C) Rebellos 2011
----------------------------------------
Calling IBL Stage2
DONE!
Testing BL3 area
DONE!
iRAM reinit
DONE!
Please prepare USB dltool with BL3
Starting download...
0x00000000
Desired BL3 EP: 0x40244000
Download complete, hold download mode key combination.
Starting BL3...
//OUTPUT BELOW IS COMING FROM SBL
Set cpu clk. from 400MHz to 800MHz.
IROM e-fused - Non Secure Boot Version.
Click to expand...
Click to collapse
It opens infinite capabilities. Instead of SBL to unbrick, Uboot can be loaded, or any armlinux kernel. It's all up to you - XDA Developers.
is the start of porting another SO's to our i9000, like bada or wp?
Yeeee! Thank u very much Adam!
I hope i can get soon again another SGS!!
Inviato dal mio GT-I9100 usando Tapatalk
lpalvaro said:
is the start of porting another SO's to our i9000, like bada or wp?
Click to expand...
Click to collapse
I hope so, WP7.5 would be really fast running in a SGS!
Enviado desde mi GT-I9000 usando Tapatalk
lpalvaro said:
is the start of porting another SO's to our i9000, like bada or wp?
Click to expand...
Click to collapse
Noone will spend hundreds or even thousands of hours to port closed source system. So no. This is not start, this just opens such possibility.
Very impressive work, thanks a lot for this !
Rebellos said:
Noone will spend hundreds or even thousands of hours to port closed source system. So no. This is not start, this just opens such possibility.
Click to expand...
Click to collapse
That's true...but porting full Debian with LXDE and Kernel 3.1 would be good
Is one of my first project as soon as i get an unbrickable device...
Inviato dal mio GT-I9100 usando Tapatalk
The big brother has UBM! Yay
Sent from my SGH-I897 using xda premium
It's a Good mod, but I don't think I'll play with my phones hardware. It's unbrickable only when we don't play with bootloader and I don't.
Sent from my GT-I9000 using xda premium
simone201 said:
That's true...but porting full Debian with LXDE and Kernel 3.1 would be good
Is one of my first project as soon as i get an unbrickable device...
Inviato dal mio GT-I9100 usando Tapatalk
Click to expand...
Click to collapse
I sent you a PM yesterday. You never responded. You came in second in the Fascinate contest. Send me a PM and I'll do UBM for your device.
AdamOutler said:
I sent you a PM yesterday. You never responded. You came in second in the Fascinate contest. Send me a PM and I'll do UBM for your device.
Click to expand...
Click to collapse
Yeah sorry Adam, i haven't replied cuz i haven't got an SGS now (i have sold mine a month ago) so i cannot use your great offer now....
I am trying to search a bricked sgs to give it to you asap!
Thanks for all Adam!
Inviato dal mio GT-I9100 usando Tapatalk
Anyway, any idea if you can try to port the same mod to the SGS2 but it should be a completely different work....
It would be really good, as the work on I9100 is a lot!!
Inviato dal mio GT-I9100 usando Tapatalk
simone201 said:
Anyway, any idea if you can try to port the same mod to the SGS2 but it should be a completely different work....
It would be really good, as the work on I9100 is a lot!!
Inviato dal mio GT-I9100 usando Tapatalk
Click to expand...
Click to collapse
It would be a completely different task. Exynos Is a different processor. However, I know what needs to be done. I have the datasheets. Its a matter of locating the xOM pins, figuring out how they work, then rebellos can develop firmware and I can package a resurrector.
OMAP based devices like the Galaxy Nexus will be even easier.
There is no hope in sight for Qualcom devices like T-Mobile SGS2. All other SGS2 devices are ready. I just need one to work with.
AdamOutler said:
It would be a completely different task. Exynos Is a different processor. However, I know what needs to be done. I have the datasheets. Its a matter of locating the xOM pins, figuring out how they work, then rebellos can develop firmware and I can package a resurrector.
OMAP based devices like the Galaxy Nexus will be even easier.
There is no hope in sight for Qualcom devices like T-Mobile SGS2. All other SGS2 devices are ready. I just need one to work with.
Click to expand...
Click to collapse
Good to know!
I hope u can work on an I9100 soon as it would be much better to develop for a newer platform...
As soon as i brick my sgs2 i will give it to you! XD
As always, i really love your work Adam, i hope u can teach me something of ur knowledge! XD
Inviato dal mio GT-I9100 usando Tapatalk
thank you
This is one post i was waiting for for long time now,
thx Adam love your work
Wow... Great information! thank you!
Finally !
Adam, can this mod be performed by connecting the xOM pins only once and then flashing the HIBL ? I think we need to now develop something like MAGLDR for the SGS series. this will help greatly IMO. What do you think ??
Is it too difficult ? i wish i knew linux etc
EDIT: sorry my mistake I don't think it can be done
I go search a bricked sgs, this is just AWESOME FOR KERNEL developers.
Sent from my GT-I9100
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.
Edit-- after studying a couple days I understand why no modification to the images would work, which is due to AVB. I have a lot more studying to do and I will explain better. This thread is currently a mess of notes from a noob picking a kind lady's brain
Hello All~!
This is an effort to understand what exactly is going on with the files contained in the boot.img from our shield --edit to understand this on the shield, we must understand the other images as well (dtb, vbmeta. and the "staging blob" that comes with the shield)
ImgUtil
Miss @Renate has developed a wonderful tool to allow us to see the contents of our boot.img by placing her tool in the same folder as the boot.img and running this code:
Code:
imgutil.exe /v /l boot.img
Spoiler: SHOW
STOCK BOOT IMAGE:
{
"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"
}
DEV BOOT IMAGE:
IMAGES THAT COME WITH SHIELD
This was only possible Thanks to Renate.
AVB NOTES:
Finally figured out how to actually use the avb tool.. I feel stupid. Copy this script and make a new file called avbtool
Per this link I learned how to make an empty vbmeta with the tool, i had to add "python" to the front
Code:
python avbtool make_vbmeta_image --flags 2 --padding_size 4096 --output vbmeta_disabled.img
That allowed me to generate an empty vbmeta
The avbtool help menu:
View attachment 5792745
Signing boot images for Android Verified Boot (AVB) [v8]
Various Android devices support Android Verified Boot (AVB). A part of this is more commonly known as dm-verity, which verifies system (and vendor) partition integrity. AVB can however also verify boot images, and stock firmwares generally...
forum.xda-developers.com
super helpful
Boot Flow | Android Open Source Project
source.android.com
There can be image signing with vbmeta and/or AVB on the image itself.
Whether these are enforced is another question and can most easily be determined by experimenting.
Most people grab a boot image out of a partition. The whole partition.
In the days before AVB0 signing this meant you might copy a 64M partition and get 24M of actual image and 40M of zeroes.
In the days after AVB0 signing this meant you get 24M of actual image, 2k of signing, 40M of zeroes and an itty-bitty AVB0 footer.
That AVB0 footer is a pesky detail.
You can see it if you have the whole partition and use a hex editor at the very end (size-4096).
As Magisk deals with boot images I should double check what they do. I believe they don't modify the AVB0 footer at all.
Using my EDL client edl.exe there is the /t option to trim an image to the real ~24M live bit.
In imgutil.exe there is the /p option to strip padding.
If your fastboot works fine, you have a nice recovery and you feel confident you can experiment.
You can trim your stock boot image of its padding using imgutil.exe (which I believe leaves the AVB0 header intact), then:
Code:
fastboot erase boot
fastboot flash boot mytrimmedstock.img
You can even trim away the AVB0 header (using the address shown in imgutil.exe) and see if that works with erase, flash.
Then there is the vbmeta. That is a check on things too, whether enforced or not is also a question.
You can often replace it with an disabled vbmeta image.
Your dtb is in a separate partition.
On my main device it's on the kernel. I modify (in hex instead of dtc round-tripping) it to not verify /vendor.
@Renate Thank You, Seriously For Your Time. I was Just Looking at your EDL tool! I am going to play with all of this now. I cannot even begin to tell you how happy this has made me.
This is the link to her edl tool
EDL Utility
i deleted the vbmeta link that was originally listed here. ordinarily i would leave the comment up for knowledge, but I don't want anyone to get off the path. We need to learn the avb tools and generate our own, not use others due to the cryptographic hashes associated with each image that chains to the "staging" blob
Hi @Renate May I bother you again? I am stuck on two parts,
You mention editing the dtb to not verify /vendor could you help me to understand how to do that?
I threw my dtb.img into HXD and searched for "vendor" and it brought up this
Spoiler: SHOW
but I am unsure if this is what I need or what to change it to?
Also I wanted to try to do what you say here "You can even trim away the AVB0 header (using the address shown in imgutil.exe) and see if that works with erase, flash."
I took that to mean use imgutil.exe to /d the Header1 file? Is that wrong? I tried all these but I cannot figure out on my own how to do it
Spoiler: SHOW
>.> i at least figured out the padding part
No, I'm not saying that you have to change dtb.
In today's world you can "modify" things by using Magisk modules (and not modifying /system) or by burning your bridges and just modifying /system.
If you do that you'll have to get rid of all verification (and FEC if present) and you it make updates impossible without reverting back to stock.
Your choices are influenced by what the OEM offers for updates and how much you want to sink your teeth into swamp critters.
Looking at a dtb in raw hex will make you go blind.
You should use dtc to disassemble/assemble.
It's probably not on your device but it is in any Linux.
I use my own dtbview.exe (not ready for prime-time) to get a dump with addresses.
If you like (for learning) post your dtb.
@Renate this is the dtb image, and thank you for telling me about dtc LOL I will get that installed in my ubuntu VM.
Also @Renate is this the right tool?
Spoiler: SHOW
Yeah, that's the right tool.
I don't know if the mysterious new header on Android is part of Linux or not.
So your dtb partition is 2M
The end of actual data is 7c394, so basically 1/4 of the partition.
But it's also AVB signed, look at offset 7d000
And its silly footer at 1fffc0
Here's the listing for your edification
Spoiler: DTC FOR WINDOWS
I came across this dtc tool for windows made by amlogic, it was originally shared here, bundled with other things
How to Extract a Device Tree File from Android Firmware Files - CNX Software
Up to now, all our cheap Android devices were based on older Linux kernel (3.0.x, 3.4.x) that still used board files (arch/arm/board, but we've recently
www.cnx-software.com
Spoiler: SHOW
I extracted just it
dtc-tool.exe
drive.google.com
I checked it on virus total
VirusTotal
VirusTotal
www.virustotal.com
@Renate Hi, I'm going to probably bother you till you block me...
But could you explain to me how you were able to take that dtb image I shared with you to turn it into the text file? I tried to use the dtc tool in linux and on windows but I cannot figure out how to get the listing like you did.
Here's what I was trying
jenneh said:
Blob has incorrect magic number
Click to expand...
Click to collapse
Yeah, it does!
That's what I've been fighting about. They decided to add some header.
Some dtb's have multiple separate models built in. Why? I have no idea.
Instead of ye olde fashioned "a dtb is that period" they decided to put in a header.
I'm sure that's it's documented somewhere.
If you are just doing this for your own amusement, knock the first 128 bytes off the file and it can be disassembled.
@Renate I Really Am doing this for my own fun. But For A Total Noob, can you explain what this means? "knock the first 128 bytes off the file and it can be disassembled" I'm so very sorry. I have always been intrigued with disassembly but I do not know very much
Somebody at Android decided for whatever reason to extend the Linux DTB by putting another header before it.
Obviously Linux doesn't know or care what Android does.
If you look at offset 0x80 you'll see the normal signature of 0xd00feed (in bigend).
We can discuss whether that's politically questionable, but that's the way it is.
@Renate I guess what I am having trouble understanding, is where are these offsets that you are pointing me to with all this valuable information? Like you said here "If you look at offset 0x80 you'll see the normal signature of 0xd00feed (in bigend)."
When I look at the offsets in the text file I don't see anything called 0x80 it's the same trouble for me to fully understand what you were telling me earlier
Spoiler: SHOW
"But it's also AVB signed, look at offset 7d000
And its silly footer at 1fffc0"
How do I see these offsets that you so awesomely took the time to point out?
jenneh said:
When I look at the offsets in the text file I don't see anything called 0x80...
Click to expand...
Click to collapse
When you look at something like this you're looking at a raw chunk of memory.
As such, every bit of it, err, every byte of it has an address.
The first byte is zero and it goes up from there.
"0x80" is hex 80, (i.e. 128 bytes) into the file.
Renate said:
When you look at something like this you're looking at a raw chunk of memory.
As such, every bit of it, err, every byte of it has an address.
The first byte is zero and it goes up from there.
"0x80" is hex 80, (i.e. 128 bytes) into the file.
Click to expand...
Click to collapse
Does that mean these first 8 lines of offsets are the the first bytes? Is this what I would want to blank out to remove the header?
So, look at the line with 00000080: d0 0d fe ed, "doodfeed"!
It's not a question of "blanking" it's a question of "skipping".
Although I don't o-fish-ally release it, here is modfile.exe: modfile
Code:
C:\>copy dtb dtb-short
C:\>modfile dtb-short /s 80
Renate said:
So, look at the line with 00000080: d0 0d fe ed, "doodfeed"!
Click to expand...
Click to collapse
Gosh, Thank You. "d0 0d fe ed, "doodfeed"!" This, this did it for me to Understand. Haha. Thank You for the modfile tool as [email protected]@!
I got to get some sleep, but rest assured I will be back tomorrow to bother you even more!
@Renate Good Morning!! THANK YOU for helping me to learn how to "Skip" the erroneous header! This is something I Literally would never have learned Without You! Your modfile tool is so Neat! Also appreciate the Semantics!!
FIRST QUESTION! How do I produce a text output file similar to the one you shared with me? As in one that has all the offsets at the beginning of the line?
I ran this command after the skip (It finally worked yay!! No magic number problem!!):
Code:
dtc-tool.exe -I dtb -o dtb.txt dtb.img
I got this output text, which is noticeably missing the offsets that your copy provided.
Spoiler: SHOW
Spoiler: DTC MANUAL
Here is the manual for other people learning:
manual.txt « Documentation - dtc/dtc.git - The Device Tree Compiler
git.kernel.org
Spoiler: I SAW BOOTLOADER.
SECOND QUESTION! Theoretically, if I wanted to add a new Bootloader to be able to run windows, Would that be done in here? Or more specifically, somewhere in the DTS? We don't have to go into technical specifics yet... unless you want to but is it possible?
THIRD QUESTION! When I was learning how to flash the images onto the Shield, Nvidia made mentions to use this command to flash the "staging blob" I have always wondered Why and What is this, is it needed do you know?
Spoiler: SHOW
Thank you as always for your time