Hi everyone,
I'm looking for a little help modifying the ToyotaHMIMainSWUpdate.swf to skip the activation check when updating the maps.
So far I've managed to skip the screen where you enter the activation code and I'm able to select which maps I want and progress to the confirmation screen.
After pressing confirm I get the message saying "Radio will reset to complete the update" and then it either kicks me back to the previous screen or jumps back to the beginning with a message saying "I'm working on it...", any help is appreciated.
Here's a link to the unmodified file:
File on MEGA
mega.nz
Making modifications to the swdl and swdlInstall ISOs isn't an issue as I'm able to rebuild them with a valid signature.
It appears it's the nav-activation.lua and not the ToyotaHMIMainSWUpdate.swf file which needs to be modified. The swf must just act as a front end to the lua script.
After patching the activation check in the lua file and rebuilding the ISO I was able to sucessfully bypass the activation screen and the unit rebooted as it should after selecting which maps I wanted to install.
The problem I now have is that the ISO fails the secondary signature check when trying to validate against the embedded signature.
This is how the beginning of one of the ISOs looks.
The part marked in green is a digital signature created from a list of all the files and folders in the ISO file, along with some additional information about them.
The part in blue is a SHA-256 hash created by reading chunks of 32768 bytes.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
The part in green is verified by the following commands:
inject -e -i /fs/usb0/swdl.iso -f /tmp/isodigest.sha256 -o 0 -s 64
isodigest -df /tmp/iso.digest /fs/usb0/swdl.iso
openssl dgst -sha256 -verify /etc/keys/swdl.pub -signature /tmp/isodigest.sha256 /tmp/iso.digest
Click to expand...
Click to collapse
If successful, you will get "Verified OK"; otherwise, you will get "Verification Failure."
The part in blue has to match the output created by hashFile:
hashFile sha256 /fs/usb0/swdl.iso /tmp/tmp.digest 32768
Click to expand...
Click to collapse
I'm able to pass the verification checks for the parts in green and blue, but I can't seem to figure out how the part in red is generated, as the verification step then fails when verifyISO is run after the unit is reset before the updates are actually installed.
If we can figure out what the parts marked in red are, then we may be able to generate fully customizable updates.
It looks like the blue and red parts are base64 encoded and passed to com.harman.service.samSecurity as json in the following format:
{
"signType": "appUpdate",
"signature": "base64 encoded value"
}
Click to expand...
Click to collapse
The last character is also removed after it's been base64 encoded
Hi,
I'm trying the same.
Do you have any updates after the last message you send?
Can't we decode the activation code instead?
@willmav5000 Which system are you currently investigating?
Because I am looking for Toyota Touch & Go 2 system (MM17/MM19)
Do you find the ToyotaHMIMainSWUpdate.swf in the KWI update file?
I find a Russian website where KWI unpacker tool is available:
Курим KIWI
club-lexus.ru
Файловый архив
It seems to support KIWI 1.22 format, does it compliant with Toyota Touch & go 2 system?
Thanks.
lelapindelaforet said:
@willmav5000 Which system are you currently investigating?
Because I am looking for Toyota Touch & Go 2 system (MM17/MM19)
Do you find the ToyotaHMIMainSWUpdate.swf in the KWI update file?
Click to expand...
Click to collapse
I'm currently looking into the Toyota Touch & Go 2 MM16 system.
jobdbr said:
Hi,
I'm trying the same.
Do you have any updates after the last message you send?
Can't we decode the activation code instead?
Click to expand...
Click to collapse
No updates yet as I've been busy with other things. Being able to generate activation codes could be a possibility and if anyone is able to get an SPI dump that would also help out a little.
willmav5000 said:
Hi everyone,
I'm looking for a little help modifying the ToyotaHMIMainSWUpdate.swf to skip the activation check when updating the maps.
Click to expand...
Click to collapse
Hi! For what I've seen Toyota Touch & Go 2 seems to be sharing the QNX platform with Jeep (FCA) Uconnect. So this sounds very similar here where the 1st check happens "within the update image" itself as quick and simple validation for file/version origin and match to the head unit hardware. But then the second and slow image hash validation is done before flashing the data "on the head unit" - and inevitably fails... Unless you get full access to the head unit
willmav5000 said:
Making modifications to the swdl and swdlInstall ISOs isn't an issue as I'm able to rebuild them with a valid signature.
Click to expand...
Click to collapse
So yes, I believe you can fool the quick signature check, but no go with the full image sha256 hash verification. On the Uconnect the way to go is to exploit the head unit to gain root access and then to avoid the verification, but still modified Nav binary may be needed to skip map license check...
devmihkel said:
Hi! For what I've seen Toyota Touch & Go 2 seems to be sharing the QNX platform with Jeep (FCA) Uconnect. So this sounds very similar here where the 1st check happens "within the update image" itself as quick and simple validation for file/version origin and match to the head unit hardware. But then the second and slow image hash validation is done before flashing the data "on the head unit" - and inevitably fails... Unless you get full access to the head unit
So yes, I believe you can fool the quick signature check, but no go with the full image sha256 hash verification. On the Uconnect the way to go is to exploit the head unit to gain root access and then to avoid the verification, but still modified Nav binary may be needed to skip map license check...
Click to expand...
Click to collapse
Yeah the initial component in green is verified by one of the public keys, while the second part in blue is just a sha256 digest based on the remainder of ISO file. I am able to replicate both of those with some custom scripts I've written and fully alter the ISO how ever I want, I can still successfully pass the first stage of validation and initiate the update and/or execute custom scripts until the device restarts for the actual installation process. I still haven't been able to figure out how the third part in red is generated, but I do know that it also utilizes the sha256 digest in some way.
I have a dump of all the files from the head unit and have decoded all the Lua files. I've been looking over everything and discovered a few things of interest, but nothing solid yet.
Right, still sounds similar to the Jeep exploit, that by modifying the update image you can execute random code as root(?) on the head unit while triggering the update check? Could you then just copy and replace the updated map files into the storage?
willmav5000 said:
No updates yet as I've been busy with other things. Being able to generate activation codes could be a possibility and if anyone is able to get an SPI dump that would also help out a little.
Click to expand...
Click to collapse
Hi,
could it be helpful, if I send you original activation codes?
I have Toyota Touch 2 With Go (Toyota Auris 2018) software version 6.20.0SPWL (map version 2022 v2)
From 2019 until 2022 I have updated my system via MapCare, so I have 7 original activation codes for my device (and for 7 updates numbered from 6.13.0L to 6.19.0L)...
Together with my device ID you can perhaps figure out how activation codes are generated...
I could also help by sending you my activations codes and my device ID.
I have a 2017 Rav4
something new?
Nothing new, I've been unable to obtain any dumps and I've been away so this has been shelved for now.
Dear @willmav5000
You certainly hear about GreeLuigi1 and his hack of Hyundai system (https://programmingwithstyle.com/)
He successfully entered in the system and explain all the steps to do it.
He also published on GitHub the procedure to decrypt Hyundai firmware: https://github.com/greenluigi1/HyundaiFirmwareDecrypter
Could you please explain how you proceed to try to hack Toyota system?
You obtain SWF file I think for the Toyota update package (KWI file maybe?) but how?
If we cross our knowledge we should be able to progress further, I hope.
Regards
Related
A new approach!
Spoof the firmware version on the device, to trick Kies2.0.
But as you might understand, messing with system files is always dangerous and the possibility for a brick is always present. Hopefully this will not occur I'm doing my best to avoid that.
You should not use this app if you cannot get into Recovery and/or Download mode! (3 button combo) As always when you modifies system files!
Remember to disable any lagfix before updating!
For everyones safety I would recommend doing a manual backup of /system/build.prop and the complete /efs folder including nv_data.bin
The app does this automatically to the internal SDCARD, but just to be on the safe side I would recommend a manual backup to the computer aswell.
There is three steps where a reboot is required after step 2. The app will tell you what to do.
Step1.
Backup everything. If this fails, step2 is not available.
Step2.
Set the new ProductCode and PDA. Reboot!
Step3.
Set CSC and Phone. Do NOT reboot. Connect to Kies2.0 and update!
This setting is not permanent and will go back to previous setting after reboot.
Remember to disable any lagfix before updating!
Done!
-------------------------------------------------------------
How to Restore
Press restore in the menu. Reboot required.
If something fails, please send me your logcat.
So here it is: SpoofFw - requires ROOT and BusyBox
{
"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"
}
Online Market link
If you get problems to connect to Kies after you used this program, try remove the registry key "HKEY_CURRENT_USER\Software\Samsung\Kies\DeviceDB"
Please let me now if it works out for you.
If you like my work, please consider a small donation.
Thanks a lot for your patch
Hi,
I'm new to the forum and am very interested in your work, at the moment the file to "fool " Kies 2.0 has not worked for me. I have the version 2.2 of Android 9000XWJPB/I9000FOPJP3/I9000XXJPP/I9000XWJPB and product code FOP. Sorry for my english, i'm from Spain.
what is new in this ??
It does'nt entirely work. Tried and it shows me update available.
But when it supposed to start downloading new rom, it say that latest software is already installed in my phone.Then Kies resets and start over offering update again.
So, I guess it detects the real rom in the phone.
Nice patch, though. Maybe you can see what is the problem.
Thanks
Same here - I just posted in the "original" theme about kies registry patcher.
Kies finds update, and when i start upgrading, the phone disconnects, and then after 1s reconects back. I cannot upgrade.
oh crap. didnt try to actually download it. thought it would work. I'll have a look at it. sorry guys.
No panic
Obviously some can upgrade, some cannot. We are the first with this problem.
I have jpx. Could this cause problems?
Those of you who have tried the patch, can you please post your info from the registry and tell me if it worked or not. Include both product code, hidswver, softwarerevision and modelname.
For me, in the registry is still JPY everywhere, after apply patch.
PRODUCT code : GT-I9000HKDXEU
HIDSWVER: I9000XXJPY/I9000OXAJPY/I9000XXJPY/I9000XXJPY
Model Name:GT-I9000
Software Revision: I9000XXJPY/I9000OXAJPY/I9000XXJPY/I9000XXJPY
HTH....
Running Kies 2.0.0.11014_49
HIDSWVER I9000XXJPO/I9000OXAJPO/I9000XXJPP/I9000XXJPO
Product Code GT-I9000HKDTMU
Model Name GT-I9000
Doesn't work unfortunately - it offers me an upgrade, appears to download the file then gives the Disconnected error.
I've also tried manually editing the registry as per kies 1.5 but no more luck.
I've tried on 2 PCs too.
HIDSWVER: I9000BUJP7/I9000GVD2JP5/I9000BUJP5/I9000BUJP7 (SofwareRev is same)
FW: I9000BUJP7/I9000GVD2JP5(CSC)/I9000BUJP5(modem)
PCode: GT-I9000HKDVD2 (VD2)
Kies: v2.0.0.11014_49
OS: Win7 Ultimate 64bit
I checked my registry but to no avail. Also tried deleting DeviceDB key to force kies into reconstructing it. It doesn't offer the fw upgrade option at all.
At least it's good to know someone is trying to develop a way to spoof kies 2.0. Did the patch work with any previous versions of kies 2.0?
I just got some another idea: could we try to hack ProductCode on device instead of on Kies side?
AFAIU ProductCode == CSC. I've googled we can change CSC in following ways:
1) *#272*HHMM# on Android 2.1 and older
2) *#272*IMEI# on Android 2.2 and newer
3) Opening preconfing with ADB
4) Editing /efs/nv_data.bin
Would it make Kies detecting different ProductCode?
There is still one more thing we have to consider: what if Kies detects our changed ProductCode but also firmware versions that were never released for given ProductCode?
Zajec5 said:
I just got some another idea: could we try to hack ProductCode on device instead of on Kies side?
AFAIU ProductCode == CSC. I've googled we can change CSC in following ways:
1) *#272*HHMM# on Android 2.1 and older
2) *#272*IMEI# on Android 2.2 and newer
3) Opening preconfing with ADB
4) Editing /efs/nv_data.bin
Would it make Kies detecting different ProductCode?
There is still one more thing we have to consider: what if Kies detects our changed ProductCode but also firmware versions that were never released for given ProductCode?
Click to expand...
Click to collapse
I have thought about it too. But we still need to change the PDA and PHONE aswell. But I have not yet located where they are stored. My guess is it's hard coded somewhere. Still the drivers need to take it from somewhere, the question is where.
LuffarJoh said:
I have thought about it too. But we still need to change the PDA and PHONE aswell. But I have not yet located where they are stored. My guess is it's hard coded somewhere. Still the drivers need to take it from somewhere, the question is where.
Click to expand...
Click to collapse
There is something like
getBasebandVersion, but I can't track RILRequest, how is is reading RIL_REQUEST_BASEBAND_VERSION... That could show us some file with baseband version maybe.
I have had some progress.
I have managed to change all necessary codes in the phone to be able to spoof Kies. This time I passed the step that the patch didnt!
Unfortunately it's not that simple, it requires root and changes system properties. But it's all reversible. I think I'll try to make an app of it during next week. First is a final exam on Monday.
watch this space.
well, it's much more fun to develop android application then study for an exam
I have successfully switched from XEN to XEE and to DBT.
I'm almost done, just some more bug testing. I'll probably release it tonight
Good news, wait for your release tonight.
luffarjoh said:
well, it's much more fun to develop android application then study for an exam
i have successfully switched from xen to xee and to dbt.
I'm almost done, just some more bug testing. I'll probably release it tonight
Click to expand...
Click to collapse
great news!!!
I have to push the release until tomorrow, I still have some fine tuning to do! Overall is works very well
I know that this topic has already been discussed many times in many threads (most in MTCD - Verified Cross compatible MCUs).
I also know that there is a known solution to this problem.
However, there are users who report that they still have a problem with that.
I am writing a new thread to present (I hope) the final solution "Version unmatch"
Remember.
The solution presented in the MTCD - Verified Cross compatible MCUs thread still applies:
1. Before uploading new MCU (dmcu.bin), first export your settings to the dmcu.cfg file (FactorySettings, button Export)
2. After uploading new MCU, restore your dmcu.cfg (file dmcu.cfg on SD card, then MCU Update)
Below is the link to the application that unlocks the device from "Version unmatch"
Code:
https://www.sendspace.com/file/ijmf13
This is Android app so you must install it on your device.
After install and run you should see screen similar to that:
{
"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"
}
Press UNLOCK button. After you should see notifaction like below:
Reboot your unit.
After that, "Version unmatch" should gone
vote for sticky!
Works great!
thank you
Wadzio said:
I know that this topic has already been discussed many times in many threads (most in MTCD - Verified Cross compatible MCUs).
I also know that there is a known solution to this problem.
However, there are users who report that they still have a problem with that.
I am writing a new thread to present (I hope) the final solution "Version unmatch"
Remember.
The solution presented in the MTCD - Verified Cross compatible MCUs thread still applies:
1. Before uploading new MCU (dmcu.bin), first export your settings to the dmcu.cfg file (FactorySettings, button Export)
2. After uploading new MCU, restore your dmcu.cfg (file dmcu.cfg on SD card, then MCU Update)
Below is the link to the application that unlocks the device from "Version unmatch"
Code:
https://www.sendspace.com/file/ijmf13
This is Android app so you must install it on your device.
After install and run you should see screen similar to that:
Press UNLOCK button. After you should see notifaction like below:
Reboot your unit.
After that, "Version unmatch" should gone
Click to expand...
Click to collapse
Very good work, Thanks
how to restore dmcu.cfg?
I place in root of drive before upgrade but was ignored.
I changed from LM to HA and had to manually set display and touch key settings
I had this version unmatched problem and was solved with the tool. thanks
For me, the version unmatch tool crashes every single time. Anyone else experience this? What to do now?!?!
Heard of anyone having an issue with their unit crashing when trying to run the app? Mine does. I even reinstalled it several times and even after a full restore, it still crashes. I have an H201.
does this app requires root ? can you please elaborate a little as how this app works ? as the app is not working it asks for reboot and comes back to menu.
Try to manually reboot. Go to the factory settings menu and type hctreboot (step 10).
same for me, Android 10 ,it crash everytime , there is an update ?
same issue , on Android 10 it crashes everytime
laptopmd said:
same issue , on Android 10 it crashes everytime
Click to expand...
Click to collapse
Yes I think a number of people have reported that. Keen to figure it out?
I'm proud to announce that i've found a way to disable that "version unmatch" by modifying the dmcu.img file. It has worked 3 times with 3 different files so i can confirm it work.
Without boring you with the details, what i've done was :
1. decompress the img file with mtcdmcutool , you obtain a dmcu.bin file.
2. open and decompile the file with Ghidra (see screenshot)
3. here i've found where the software check if the version is "unmatch" (by searching the strings into the file).
4. just before you can see a check (cmp param1,#0x0) and a jump in case it doesn't match (beq , etc etc..) , those strange words is called "assembler language".
5. at the end, simply re-compress the files into a valid dmcu.img file, and update your mcu like always.
My simple solution was to force that parm1 value to 0 , to do that i've modified the code from CMP to MOV param1,0x0 and so the jump happen everytime and you don't get the annoying message and the continuous "beep" of the autoradio. I'm actually using my android radio without issues.
laptopmd said:
I'm proud to announce that i've found a way to disable that "version unmatch" by modifying the dmcu.img file. It has worked 3 times with 3 different files so i can confirm it work.
Without boring you with the details, what i've done was :
1. decompress the img file with mtcdmcutool , you obtain a dmcu.bin file.
2. open and decompile the file with Ghidra (see screenshot)
3. here i've found where the software check if the version is "unmatch" (by searching the strings into the file).
4. just before you can see a check (cmp param1,#0x0) and a jump in case it doesn't match (beq , etc etc..) , those strange words is called "assembler language".
5. at the end, simply re-compress the files into a valid dmcu.img file, and update your mcu like always.
My simple solution was to force that parm1 value to 0 , to do that i've modified the code from CMP to MOV param1,0x0 and so the jump happen everytime and you don't get the annoying message and the continuous "beep" of the autoradio. I'm actually using my android radio without issues.
Click to expand...
Click to collapse
Hey, can you upload mtcdmcutool somewhere?
I can't find it anywhere!
Fakken said:
Hey, can you upload mtcdmcutool somewhere?
I can't find it anywhere!
Click to expand...
Click to collapse
You didn't searched really... it is all on this forum
This is the thread : https://forum.xda-developers.com/an...dification-t3745838/post75471198#post75471198
Try to download the file there
Fakken said:
Try to download the file there
Click to expand...
Click to collapse
So use google, he answered with this link : http://www.tehnari.ru/f180/t266132/
It's in russian but you can see the file link, tried and it work.
I don't want to upload it here without the permission of the developer.
Thank you, i don't know if you believe me, but if searched alot to find the file. I even translated the 4pda.ru to search it.
Eh, thank you very much!
i got "error reading a file!" in mtcdmcutools while trying to convert it to .bin file.
how do i go from here? im using a stock dmcu.img file from xtrons.
In my case it says "illegal system!" additionally to the "Unmatch" Banner.
The Tool crashes right after it is opened, my touch screen only works on the upper slide part and there are no "Car Settings" in the Settings anymore..
Any idea what to do there?
I thought i would start this thread, separate to the Jeep one as the Jeep thread is for the 8.4" uConnect and uses some different files to the 6.5" version.
The aim of the thread is to be able to gain some sort of 'root' access to the file system to be able to update the maps on the system. So far I know cm0002 and Leighm0 have done some great work with the 8.4" - Most of which we can use on the 6.5".....once we have access to the file system.
The problem we seem to be facing is finding a swdl.iso that is old enough to be modified for our 6.5" units.
Mission Accomplished.... mostly
Disclaimer: I can not be held responsible for any damages to your uConnect, Car or your hair falling out from running this modification.
That being said, if you do have a problem please contact me and I will see if I can help you fix it.
For all those people still on v17.07.46 or older uConnect 6.5 firmware I offer you a “jailbreak”, you can now update your maps to the latest versions (currently offering EU 2018Q3 / NA 2018Q1 in my pack). I have to warn you though, the process can take a lot of time!
For those of you who have updated your 6.5 uConnect to v17.35.41 or v18, I am still working on how to update those, FCA / Alfa changed the locks with that update!
For a Full EU / NA update, if you follow my instructions fully, it will take approx. 4hours during which time your uConnect must remain powered on. This time can be greatly reduced by only updating the country or countries you need, or if you are feeling brave, skipping Step 1.
Files / Items needed:
uConnect 6.5 running v17 or older firmware -Supporting Alfa, Fiat and Jeeps too!
At least 8gb USB Drive ***preferably with a flashing led light so you can see file access***
Files from
https://mega.nz/#F!kURhTCbJ!uJhKPMyGiESbvQSDb33CvQ
Stage 1 – Backup your files
Download:
1 Magic -Alfa pre UPD.zip -For Alfa
1 Magic -Fiat & Jeep pre UPD.zip -For Fiat / Jeep
2 Backup.zip
Process:
1. Download and expand “1 Magic -XXX.zip” and “2 Backup.zip”
2. Copy the content onto the root of the USB drive
3. Start car and let uConnect boot up (wait approx 5min for full boot up)
4. Plug in and WAIT, the uConnect will not appear to be doing anything but if you are using a USB with a light you should be able to see it flashing with file activity
5. After some time, in my case it took 1h25 to complete this stage, it should popup a window about there is a update that you MUST answer NO to
6. Pull USB, and power cycle the uConnect*
After that you now have a backup of all the system and map files we are going to change on your uConnect.
KEEP THEM SAFE!
Either use a second USB for stage 2, save the backup folder to your computer or if your like me and use a 16gb USB stick you can leave it where it is.
I have now uploaded copies of the official EU Map Packs from (A) 2013, 2015 and 2017, NA Map Packs (B) 2013, and ROW Map Packs (C) WIP that will function as a backup or official upgrade for anybody needing them, restoring your uConnect back to stock.
***If you have a newer set of Original Map files please contact me, and I can add them to the drive for all to benefit from***
Stage 2 – Modify your uConnect
Download:
1 Magic.zip --You should already have this if you completed Stage 1
D EU Custom 2018 HNEU2018Q3v2.zip --Full EU
E NA Custom 2018 HNNA2018Q1.zip --Full North America
Or
D UK Custom 2018 HNUK2018Q3.zip --UK Only
D FR Custom 2018 HNFR2018Q3.zip --France Only
D DE Custom 2018 HNDE2018Q3.zip --Germany Only
D IT Custom 2018 HNIT2018Q3.zip --Italy Only
***There will be other country / State only update packs soon***
Or
A EU 2013 Original NQEU2012Q4.zip --Stock 2013 Maps, Original EU Release
A EU Update 2017 HMEU2015Q4.zip --Newest Original Map files released 2017
B NA 2013 Original NQNA2013Q4.zip --Stock 2013 Maps, Original NA Release
Process:
1. Download and expand “1 Magic.zip” and “D XX Custom 2018 HN….zip”
2. Copy the content onto the root of the USB drive
3. Start car and let uConnect boot up (wait approx. 5min for full boot up)
4. Plug in and WAIT, the uConnect will not appear to be doing anything but if you are using a USB with a light you should be able to see it flashing with file activity
5. After some time, depending on file used - If country / State only pack approx. 15min if full EU then approx. 2h, it should popup a window about there is a update that you MUST answer NO
6. Pull USB, and power cycle the uConnect*
If all gone well you will now have a uConnect 6.5 with updated maps!
As I am sure you can understand, there are still some little bugs to work out;
Problems:
UK postcodes > Only 5 digit search
Speedcams > Not working at all
Anything else… you tell me
Fixed:
UK TMC now working
France TMC working again
Italy TMC (paid version) working
There may be other little problems, but I am unable to test them, please let me know and I will look into them and try to fix!
*To Power cycle:
Either remove key, lock car, wait 10min, unlock and restart)
Or use engineers menu to reset the uConnect (Press Radio, More and Browse until menu pops up, scroll down to Reset Radio, answer YES)
I have uploaded some of the files, more to come.
The URL:
https://mega.nz/#F!kMYjlSKB!MCC6U1jclb0_aHc-NdocrA
If you have anything else to share please message me.
So I have found a uConnect 6.5 update file with version no 15.18.xx. Uploaded to the mega share - now to figure out how to modify it!
Jeep Renegade
Hi.
It is possible in jeep?
SquithyX said:
So I have found a uConnect 6.5 update file with version no 15.18.xx. Uploaded to the mega share - now to figure out how to modify it!
Click to expand...
Click to collapse
any news?
Update....
The 15.18.xx file is ROW and after modifying it to work for any model, I get a authentication error on inserting the USB!!!!
Hi SquithyX,
Any chance to get the link for "Updated EU Maps (2018q1) formatted for the 6.5"??
Many Thanks in advance!
Hi,
I have a working Alfa 6.5" headunit with 14.X.X sw still installed on it. Does anyone know if it is possible to extract fw directly through JTAG? What kind of harware is needed to do such operation?
Icaro03 said:
Hi SquithyX,
Any chance to get the link for "Updated EU Maps (2018q1) formatted for the 6.5"??
Many Thanks in advance!
Click to expand...
Click to collapse
I can upload for you if you want, however until I hack has been found to be able to modify the system, they will not work!
Sent from my CLT-L09 using Tapatalk
andri98 said:
Hi,
I have a working Alfa 6.5" headunit with 14.X.X sw still installed on it. Does anyone know if it is possible to extract fw directly through JTAG? What kind of harware is needed to do such operation?
Click to expand...
Click to collapse
Not sure on JTAG, but if it is a early uConnect (Alfa 940 unit with More button) then the NAND chip is on a separate daughter board, that can be removed from the system. If a interface could be made for that then full disk access could be got.
{
"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"
}
Sent from my CLT-L09 using Tapatalk
it would be great to see some development on this system
SquithyX said:
Not sure on JTAG, but if it is a early uConnect (Alfa 940 unit with More button) then the NAND chip is on a separate daughter board, that can be removed from the system. If a interface could be made for that then full disk access could be got. View attachment 4611300
Click to expand...
Click to collapse
I found a datasheet searching JY455
It seems to be an eMMC Memory from Micron (MTFC??GLGDM) with a build in MMC-Interface
Maybe it works like an MMC-Card.
If someone build an adapter for the white connector and USB, maybe we can read and write the flash like an MMC-Card on an USB reader.
for you may this works for really? have a look for "Alfa Romeo Giulietta UConnect Apple CarPlay & Android Auto retrofit Kit" in a search engine. it's very expensive but they say you can use touch screen as well to interaction when usually all the video interface i have found say not possbile, only video signal. what do you think about this?
So close, but broken lol
Success......kind of, I have managed to modify a swdl.iso to enable loading of different / modified files, on my Alfa 6.5 uConnect running 17.07.55.
The problem now is I seem to have completely broken navigation!!!!!!
I used the idea from post #216 in the Rooted Jeep Cherokee thread and modified the manifest.lua file in the swdl.iso (17.07.55) to load a script from usb before running the update.
Process goes power on uConnect > wait for it to boot up and display "Hands free ...." > insert USB and wait...it seems like its not doing anything but the script is running in the background > after some time the do you want to update question and answer No.
The fact that is has asked if you want to update is confirmation that the script has finished, however unfortunately there is no indication that the script is being run or how long it will take unless you have a usb with a flashing light, then it will show you something is happening at least! **my usb does not have a flashing light
I tested it with a splash screen update.... that worked perfectly, so no more boring Alfa Romeo logo on silver background for me at start up, I then pushed the modified NaviServer2, nav.sh and navRestart.sh files and rebooted.... new splash screen working perfectly but on pressing Nav button I just end up on a screen saying "Activating Navigation"
I am in the process of uploading the modified files to the mega share if anybody whats to have a look or are feeling brave
Navigation now fixed! working on making a 2018q2 map pack for it now.
SquithyX said:
Navigation now fixed! working on making a 2018q2 map pack for it now.
Click to expand...
Click to collapse
Really????' you are the MAN! could you please share everything you have used and step by step? do you think even with firmware 18 installed is possible updating maps?
thanks
Ok, here is a test image (working with v17 and earlier.... unknown for v18).
https://mega.nz/#!IUZDQATI!o1OBd8qbA...mQ5lunDb0opDvs
For anybody wanting to try it, and let me know the outcome.
The script I have included will:
Backup your MAPS license files to the USB
Backup your original Alfa Splash Screen to the USB
Copy a dbver file to the USB, that should contain information about your version of MAPS installed
Push the modified Splash screen and set its properties on the uConnect
Steps:
1. Download and expand
2. Copy onto USB drive (at least 4gb) ***preferably with a flashing led light so you can see file access***
3. Start car and let uConnect boot up (wait approx 5min for full boot up)
4. Plug in and hope
5. After some time it should popup a window about there is a update (with v17) that you answer NO to. With v18 i dont know what it will do, it may popup a window saying newer version installed, Error or maybe not do anything at all.
If that is the case use the led on the usb to make sure no file access is going on and then maybe wait 5 min extra, just to make sure.
6. Pull usb, and power cycle the uConnect - either power off the car (lock car, wait 5min, unlock and restart) or use engineers menu to reset the uConnect
7. Watch it boot....the boot image will be different if success!!!!! (there will also be some new files on the usb)
It is very important NOT to let it run the update, if it offers
I am in the process of uploading my work to my mega share,
I am currently running 2018Q3 UK maps in my Alfa with WORKING tmc. Still trying to sort the speedcams and full postcode search though - they dont work....yet!
SquithyX said:
I am in the process of uploading my work to my mega share,
I am currently running 2018Q3 UK maps in my Alfa with WORKING tmc. Still trying to sort the speedcams and full postcode search though - they dont work....yet!
Click to expand...
Click to collapse
did you modify the swdl.iso? or just the script.lua?
sofro1988 said:
did you modify the swdl.iso? or just the script.lua?
Click to expand...
Click to collapse
I have used a modified 17.07.55 swdl.iso with a script.lua - if you download the test above it contains some of the modified files. The rest are currently being uploaded / are already available online.
I have done a very quick video of progress with the uConnect here:
https://youtu.be/ed0O-xXNHdg
This is the support thread of PixelFlasher
(PixelFlasher is an open-source self contained GUI tool to facilitate Pixel phone device flashing/rooting/updating with extra features).
Note: This thread is meant for issues and problems faced in Google Pixel 6 Pro devices, generic issues that are device agnostic should be discussed in the main thread.
For full details on where to download / usage and feature set of the tool, visit the main thread at XDA or the project's Github page.
Troubleshooting:
If you need support or assistance, the best way to get is by generating a support file from within PixelFlasher.
You can hit that big Support button on the main screen, or select it from the Help menu.
The generated support.zip file is sanitized (redacted) to keep your sensitive information (username device id ...) private.
Placeholder
Placeholder
this is an interesting project.
can you add a way to flash all partition/boot slots easily for new users? I think that can resolve a ton of issues. (the flash tool doesn't do this, just reinstalls some of the images like bootloader and raidio).
Alekos said:
this is an interesting project.
can you add a way to flash all partition/boot slots easily for new users? I think that can resolve a ton of issues. (the flash tool doesn't do this, just reinstalls some of the images like bootloader and raidio).
Click to expand...
Click to collapse
There's some discussion ongoing in the main thread of PixelFlasher about advanced options.
Feel free to chime in there, as this point is not specific to Pixel 6 Pro and would help all devices if it is discussed in the main thread.
📳🔥 PixelFlasher, a GUI tool for flashing / updating / rooting / managing Pixel phones.
DESCRIPTION As the name suggests this is an application to flash (update) Pixel™ phones (possibly all Google™ made phones/tablets, YMMV.) PixelFlasher at its core is a UI layer (with bells and whistles) on top of adb / fastboot commands, hence...
forum.xda-developers.com
badabing2003 said:
There's some discussion ongoing in the main thread of PixelFlasher about advanced options.
Feel free to chime in there, as this point is not specific to Pixel 6 Pro and would help all devices if it is discussed in the main thread.
📳🔥 PixelFlasher, a GUI tool for flashing / updating / rooting / managing Pixel phones.
DESCRIPTION As the name suggests this is an application to flash (update) Pixel™ phones (possibly all Google™ made phones/tablets, YMMV.) PixelFlasher at its core is a UI layer (with bells and whistles) on top of adb / fastboot commands, hence...
forum.xda-developers.com
Click to expand...
Click to collapse
Done, check the new release.
New Release:
March 24, 2022 v1.2.0.1-alpha release.
Added Advanced Configuration menu which unlocks advanced features such as:
- Flashing to both slots
- Disabling Verity
- Disabling Verification
- (More features to come)
The UI will now display the chosen Android Platform Tool's version.
Added an option to toggle verbose console output (help troubleshooting, more verbosity to come).
Stability fixes.
New Release: (See full details here on xda or here at github)
April 03, 2022 v2.0.0.0-pre release.
Major refactoring
Added Advanced (Expert) mode UI.
Basic mode keeps UI simple and hides expert features.
Support for setting active slot.
Reboot options (recovery, system, bootloader)
Moved custom ROM options to expert mode.
Added custom flashing to expert mode, can now flash to live (temporary root), or custom flash any image to any partition.
Moved flashing to both slots, disabling verity / verification to expert mode.
Many other improvements, validations and checks.
Updated documentation.
Update:
Version 2.0.1 which includes a hotfix for issue reported here.
Flawless one click update. Thanks. This going to be my default update tool.
Just used it to flash April update on my 6 Pro. Worked like a charm. Thanks.
Also used this to get to April from February and it was one of the simplest things I've ever had to do. Excellent work on this.
It keeps saying magisk is not on my phone, but it is, and it's not hidden.
According to the logs it thinks my phone is not rooted, but it is.
Edit: Followed the instructions and it updated perfectly though, just weird it thinks my phone is not rooted. Awesome app my friend, will be using this as long as it works!
Zach Alt said:
It keeps saying magisk is not on my phone, but it is, and it's not hidden.
According to the logs it thinks my phone is not rooted, but it is.
Edit: Followed the instructions and it updated perfectly though, just weird it thinks my phone is not rooted. Awesome app my friend, will be using this as long as it works!
Click to expand...
Click to collapse
Thanks for bringing this up, I'll add it to the guide,
Shell would need root permission for it to be able to do detect and use magisk.
{
"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"
}
badabing2003 said:
Thanks for bringing this up, I'll add it to the guide,
Shell would need root permission for it to be able to do detect and use magisk.
View attachment 5581317
Click to expand...
Click to collapse
Awesome, I'll enable it for next month's update. Again, thanks for this software, it's awesome.
I toggled root access for shell and now my phone shows as rooted in Pixel Flasher.
New Release:
April 06, 2022 v2.1.0 release
Setup dedicated profile directory.
Put logs in the profile directory and maintain log history.
Plumbing for Linux support (just the flashing part is left to do).
Plumbing for new workflow.
Bugfix to handle name conflict in ROM filename.
Various minor improvements.
Update documentation.
Forgot to mention this but I was running this last night and did a dry run before the real thing, it progressed but my cable was apparently faulty so it lost connection mid way (good thing I did dry run and thank you for having it). Anyway, when it lost connection it caused the app to lock up. I closed it in task manager but the files were stuck in use and I had to find and kill the processes still open to free them up before I could start again.
Suggestion: add a check for and close of any existing processes related to the pixel flasher program if it gets reopened to avoid things being stuck in use. I work in IT so I was fine poking around to kill those processes but not everyone will be.
If you can't, maybe just add the list of processes to the OP so people can kill them on their own.
wgrant said:
Forgot to mention this but I was running this last night and did a dry run before the real thing, it progressed but my cable was apparently faulty so it lost connection mid way (good thing I did dry run and thank you for having it). Anyway, when it lost connection it caused the app to lock up. I closed it in task manager but the files were stuck in use and I had to find and kill the processes still open to free them up before I could start again.
Suggestion: add a check for and close of any existing processes related to the pixel flasher program if it gets reopened to avoid things being stuck in use. I work in IT so I was fine poking around to kill those processes but not everyone will be.
If you can't, maybe just add the list of processes to the OP so people can kill them on their own.
Click to expand...
Click to collapse
The reason that happened is because PixelFlasher is running flash-all equivalent script, which has fastboot commands in it, most fastboot commands (aside from informational ones) are blocking, i.e. it waits for device.
Because your cable was faulty and your device was not appearing connected, it got blocked waiting for it.
It's a good idea to display a message and the PID of the spawned process, the user can kill it if they wish.
I really don't want to intervene with that spawned process as it is the one flashing your phone, any glitch in there and it could mess up the phone.
badabing2003 said:
The reason that happened is because PixelFlasher is running flash-all equivalent script, which has fastboot commands in it, most fastboot commands (aside from informational ones) are blocking, i.e. it waits for device.
Because your cable was faulty and your device was not appearing connected, it got blocked waiting for it.
It's a good idea to display a message and the PID of the spawned process, the user can kill it if they wish.
I really don't want to intervene with that spawned process as it is the one flashing your phone, any glitch in there and it could mess up the phone.
Click to expand...
Click to collapse
That's a good idea as well, better to not force a closure of the process and instead inform then give the user the information necessary to close it themselves. It was definitely the fastboot process that was holding the files. Once I killed that it was fine for me to proceed. Providing a pop up with the PID or even just the process name (unless the PID is always the same) and instructions in that pop up would certainly help someone get out of a jam without needing to reboot the computer.
I've done some stuff like this project with batch but this blows that completely out of the water. Excellent work, you should be proud of what you've given to the community.
can I also root my Pixel with that?
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