Related
I have been searching these forum for awhile on how to create a similar tool like "SbCalc". I'm from the microsoft kin forums on here and have just been trying to keep some kind of progress going as far as unlocking the phone. (That forum doesn't get a lot of attention so things have been slow for awhile.)
Anyways,the phone has a tegra 1 chip and is capable of running nvflash...but need to figure out the sbk to get into the partitions.This website goes into some detail about the SBK but not sure if it applies every phone including non android ones:
http://projects.pappkartong.se/a500/
To generate the SBK from the UID (assumign UID is a hexadecimal string)
Discard any leading 0x in the UID
Split the UID into four 4 character strings
For each part, take the ascii values and multiply with 100 raised to the position.
e.g. "89AB" => 56*100**3 + 57*100**2 + 65*100**2 + 66*100**0 = 56576566.
xor
If using a little-endian architecture, swap the byte order
Print the key
Would this be the right way to convert the key for nvflash? This phone doesnt haven a uid besides what i could find through QPST:
meid
esn 800CE99D
usb guid
s/n E00301720
s/n b37c03ac-0f16-47c2-a972-fcfe12a33080
meid dec
meid hex
Not really any 15-16 keys that i could find yet that would run in Sbcalc.Not really sure where to go from here and don't want this project to die out.Hopefully someone can help me out or maybe check out the kin forums and see if they can help.thanks
http://forum.xda-developers.com/forumdisplay.php?f=674
Things like this are very difficult when the manufacturer has completely given up on it and the user base is very small. Good luck!
I own an LG Optimus Elite phone, which is based around the qualcomm msm7k. This phone, like many other qualcomm devices, has a Download mode you can enter where you can send commands over USB and send commands to the phone for reading/writing RAM and ROM and stuff like this. After some messing around, I found the second stage bootloader (osbl.mbn) on the second partition of the phone. I reverse engineered some stuff and got the bootloader loaded up in ida and a good bit of it figured out, including where the implement the download mode.
I already wrote some code that can talk to the download mode, and I can send commands and receive the replies, and I have already made myself a list of all the supported commands and subcommands and started documenting what they do. I also found the implementation for some of their crypto stuff and some hardcoded keys/hashes. What I'm looking for now is some sort of documentation about the bootloader and/or the download mode. It would be really awesome if somebody could point me to some documentation about what sort of things you can do with this one, or similar bootloaders. Some of the commands look like they are for writing to the internal rom, and I would like to avoid messing with those that might brick my phone if used wrong. And any documentation about the logic for the booting process would really help. I see code here for booting secure elfs and stuff like that that will take a bit of effort to reverse.
gianptune said:
I own an LG Optimus Elite phone, which is based around the qualcomm msm7k. This phone, like many other qualcomm devices, has a Download mode you can enter where you can send commands over USB and send commands to the phone for reading/writing RAM and ROM and stuff like this. After some messing around, I found the second stage bootloader (osbl.mbn) on the second partition of the phone. I reverse engineered some stuff and got the bootloader loaded up in ida and a good bit of it figured out, including where the implement the download mode.
I already wrote some code that can talk to the download mode, and I can send commands and receive the replies, and I have already made myself a list of all the supported commands and subcommands and started documenting what they do. I also found the implementation for some of their crypto stuff and some hardcoded keys/hashes. What I'm looking for now is some sort of documentation about the bootloader and/or the download mode. It would be really awesome if somebody could point me to some documentation about what sort of things you can do with this one, or similar bootloaders. Some of the commands look like they are for writing to the internal rom, and I would like to avoid messing with those that might brick my phone if used wrong. And any documentation about the logic for the booting process would really help. I see code here for booting secure elfs and stuff like that that will take a bit of effort to reverse.
Click to expand...
Click to collapse
i am interested to in this subject
i am trying to do the same thing but i lack the experience.
i have a tablet that has an msm8255 which is made in china, in europe it is sold without the phone capabilities, in rusia there is the same tablet that has the phone capabilities, i flashed the firmware from the rusian tablet, but still, no phone function, so i think i need some ideas on how to download some stuff from the rusian model and flash`it on the european version.
i will do some reasearch at the uni because i have acces to more academical resources.
Are you the same guy from the Wii scene? Anyway I don't know much to help you myself, but you may want to check out revolutionary.io and unlimited.io. they have hacked bootloaders on phones
Latest Version 0.5.1 (beta)
What is CobaltDebugger? An ARM Processor Simulator/Emulator/Debugger. At its current state, it reads Android bootloader files, and runs them in a simulator, giving you control over which instructions execute and when. For optimal experience, use this in conjunction with IDA Pro.
Hint: Try setting the PC Register to an interesting address found in IDA.
https://youtu.be/cwvz8Cj70Ac <- newer but still old
https://youtu.be/L5NDob2rCmI <- even older
Unzip contents
Run CobaltDebugger.exe
Load up your aboot.mbn or sbl1.mbn
If you want to display referenced strings, open your binary in IDA, go to View > Subviews > Strings, then copy and paste the contents of the strings window into a new text file, then load that text file into CobaltDebugger.
Memory file will grow to 4GB
Click "Load Binary"
Then click "Step Into" or "Run"
You can
- Set breakpoints by address: use >, and < to define break-ranges
- Alter register values, condition flags, psr modes, instruction sets (ARM and Thumb)
Memory edits are not yet implemented but will most likely come as time permits
Page Up, Page Down, Up, and Down keys can be used to navigate the memory viewer - or you can type an address and click "Go" to go there - There's a bug in here somewhere - I'll get to it
The output from the bottom right window is saved as output.xxxxxx.txt, although the file may not get flushed until you click "Unload" or close the application.
All ARM and Thumb instructions were implemented in C# by hand by me. There may be bugs here and there as this is a work in progress and beta. Not all instructions have been implemented so you may encounter a message that states such and such instruction not implemented. If you see that, let me know which instruction and I will implement it as time permits, or you can wait until the next release. I plan on continuing this project until all instructions are implemented.
Originally built with the binaries from the AT&T Samsung Galaxy Note 3 (NC2) in mind, but focus switched to the Verizon Samsung Galaxy S4 (NK1), then back to Note 3 (OC1). This should work with other similar binaries as well.
I'm hoping this will help us discover new ways to unlock bootloaders. But at the very least it's fun to watch the files run.
Change Log 0.5.1
Added image verification steps thanks to Tal Aloni
Bug fixes
More instructions implemented
Slight redesign
Change Log 0.5
Bug fixes, UI improvements, a few more instructions implemented
Now the "Next" instruction is actually the Next instruction as opposed to the most recently executed instruction, so you can see the instruction highlighted BEFORE it executes.
Change Log 0.4.1
Fixed some bugs
Implemented some more instructions
AT&T Note 3 NC2 aboot runs to completion again, although you may find some instructions I've missed if you start jumping around editing the PC value.
Change Log 0.4
Complete refactor
Verizon S4 NK1 aboot runs to completion, although you may find some instructions I've missed if you start jumping around editing the PC value.
Broke some things with the Note 3 aboot instructions
Change Log v0.3:
set default breakpoint for Verizon S4 aboot - Either it's actually *supposed* to start executing code at 0x880C7000 after an MCR and BX instruction, or I may have mis-coded something, but it seems odd, so a breakpoint is set to 0x88E0E4BC until I can figure that one out.
Output to file - C:\temp\output.HHmmss.asm - Now you can review the log after the program has run.
Subscribed. This is going to be epic.
Taking the trash out then going to have some fun hopefully with this.
Next feature to add is the ability to load and run elf files like tz and sdi
v0.2
I Implemented the SP Minus Immediate instruction, which should resolve the NotImplemented exception reported by @dmt010 . I also implemented a bunch more instructions needed by the S4 aboot, although I'm still not done. I went ahead and uploaded an update anyway. This one doesn't blow up like the first version, but rather displays the missing instruction if it encounters one. To skip to a specific address and start executing code, you can modify the PC register and click Apply Edits, then step or run. Sometimes you have to do it twice for it to take, for some reason. If you want to play around with this with your own abootmbn or sbl1.mbn, feel free to post any Not Implemented messages here so I can add them, just make sure no one else has already posted it. Make sure you copy and paste the whole line including the instruction mnemonic and "Pattern" which will help me to identify the desired encoding.
Instruction [Thumb16,LDRB] not implemented. Pattern: [01111iiiiinnnttt]. Address: [0x88E1C470]
Cheers
I just uploaded v0.3. Now it runs the Verizon S4 aboot file without exception until it gets to a section where keeps incorrectly executing ANDEQ R0, R0, #0x3. I know that's not what it is supposed to do, and that it is a result of BX R14, when R14 is holding 0x880C7000, but 0x880C7000 has only zeros because the s4 aboot is running out of context, isolated. Maybe there is supposed to be code at 0x880C7000, ready and waiting to run. Or maybe there was a calculation error in my code and R14 should not have held the value 0x880C7000. I don't know. I will relook at the preceeding steps and make sure the calculations are correct. Might add a unit test or two. I may need to spend more time looking at the line before the branch (MCR p15, 0, R0,c1,c0, 0) MCR was one of the first instructions I implemented months ago. I may need to re-look at that logic and make sure I did it right...
Cobaltikus said:
I just uploaded v0.3. Now it runs the Verizon S4 aboot file without exception until it gets to a section where keeps incorrectly executing ANDEQ R0, R0, #0x3. I know that's not what it is supposed to do, and that it is a result of BX R14, when R14 is holding 0x880C7000, but 0x880C7000 has only zeros because the s4 aboot is running out of context, isolated. Maybe there is supposed to be code at 0x880C7000, ready and waiting to run. Or maybe there was a calculation error in my code and R14 should not have held the value 0x880C7000. I don't know. I will relook at the preceeding steps and make sure the calculations are correct. Might add a unit test or two. I may need to spend more time looking at the line before the branch (MCR p15, 0, R0,c1,c0, 0) MCR was one of the first instructions I implemented months ago. I may need to re-look at that logic and make sure I did it right...
Click to expand...
Click to collapse
What did I say? Glad I snagged the first post, I knew this project would take off.
It is possible that at some point I will consider sharing my source code to the public. But first I need to look into different licensing steps I should take to make sure that if I do release it, it will remain open source and not be stolen and licensed by someone else, forcing me to take my code down, or something else that could be bad for me. I want to make sure that if I do it, I do it right. Another issue for me is that I like to copy and paste the psuedocode from ARM directly into my code, commented, so I have it for reference. I'm fairly certain I would have to take that out before releasing, so I'm not infringing on ARM's copyright policies. But it would be nice to collaborate. Possibly. Maybe.
Cobaltikus said:
... (MCR p15, 0, R0,c1,c0, 0) MCR was one of the first instructions I implemented months ago. I may need to re-look at that logic and make sure I did it right...
Click to expand...
Click to collapse
Yep. I need to re-implement MCR. I wasn't doing all that needed to be done.
v0.4
v0.4 runs Verizon S4 NK1 aboot to completion, and you can view and modify the active Instruction Set (ARM vs Thumb).
v0.5
v0.5
I got a bit side tracked. Thanks to Tal Aloni, Cobalt Debugger now shows and validates the certificate chain and image signature, which started me down the rabbit hole of potentially cracking RSA. When I come back up for air I'll post my latest changes.
ive been trying to crack that thing for months now! haha join in the telegram again for info and we can collaborate live. from what i understand we're dealing with an RSA-SHA1 sig with PKCS#11 padding
Sorry to be somewhat off-topic, but RSA is a method of encryption. So Samsung/Verizon used this to encrypt the bootloader. So if we can crack it, we have access to the bootloader and can Loki it/ another exploit?
Oh yeah, I subbed. I'm teaching myself python and Java(was already on my to do list) to try and offer limited help.
XxD34THxX said:
Sorry to be somewhat off-topic, but RSA is a method of encryption. So Samsung/Verizon used this to encrypt the bootloader. So if we can crack it, we have access to the bootloader and can Loki it/ another exploit?
Oh yeah, I subbed. I'm teaching myself python and Java(was already on my to do list) to try and offer limited help.
Click to expand...
Click to collapse
can you do much with python on android?
What exactly does this thing do ? I"m a bit confused This is some kind of simulator so that you can see how it impacts memory during execution ? But then again, if it can't access hardware then what's the use ? What does it offer over IDA pro ? I'm confused
Not now. Still on the basics of python. I have python and ide on my pc waiting if you need me to test something.
kcarden said:
ive been trying to crack that thing for months now! haha join in the telegram again for info and we can collaborate live. from what i understand we're dealing with an RSA-SHA1 sig with PKCS#11 padding
Click to expand...
Click to collapse
Ah right, getting now what the use of this is As long as stuff is not done in hardware, which it most likely wont be anyway (cause kernel is not up lol) then this could function as a simulator to debug the bootloader. Makes sense
XxD34THxX said:
Sorry to be somewhat off-topic, but RSA is a method of encryption. So Samsung/Verizon used this to encrypt the bootloader. So if we can crack it, we have access to the bootloader and can Loki it/ another exploit?
Oh yeah, I subbed. I'm teaching myself python and Java(was already on my to do list) to try and offer limited help.
Click to expand...
Click to collapse
i've been looking a lot at recovery.img and the recovery partition. and what happens is the image is encrypted and then signed to be accepted by other software sig checks
.
This fix is for those who want to get rid of the annoying Red Corruption warning screen!!.
Disclaimer: You apply the fix at your own risk. I'm not responsible for any software or hardware damage it can lead. The only thing i can assure is that i've tested fix on my lg v20 F800s with DirtySanta Bootloader unlocked, and it work just fine.
Disclaimer 2: I don't provide any technical support for my fix through PM. So, please don't write PM about other devices. I share what i'm doing for myself .. and have no intention to do it to devices i don't have.
The trick:
This fix is not really fixes the problem, but it just replace the warning with the lg logo. so the boot time still higher as it is.
{
"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 raw_resources on our V20 is the equivalent partition to imgdata, but they use RLE images that has no header like BMP or JPEG, so we can't easily replace it like Nexus 5X ...
The trick that i use is changing the addresses of the warning images with the one of lg logo by patching raw_resources.bin file with Hex Workshop.
Here is a short description of steps to follow if you want to do the same for other devices:
1. download the KDZ firmware of your device.
2. extract the raw_resources.bin from it.
3. download and install Hex Workshop
3. open the raw_resources.bin with Hex Workshop
4. find the addresse of "lglogo_image" and copy it. (see the example image below)
5. find the 2 addresses of "verifiedboot_red_01" and "verifiedboot_red_02" and replace with the adrresse of "lglogo_image". ( respect the exact place!)
6. save your changes
7. put the raw_resources.bin incide the flash zip (you can use my attached flash zip).
8. flash the zip with TWRP.
9. reboot your device.
Attached: flash zip for my f800s OREO firmware
It looks like my 100$ refurbished ls997 has a f800s motherboard.
4shared said:
.
This fix is for those who want to get rid of the annoying Red Corruption warning screen!!.
Disclaimer: You apply the fix at your own risk. I'm not responsible for any software or hardware damage it can lead. The only thing i can assure is that i've tested fix on my lg v20 ls997 with DirtySanta Bootloader unlocked, and it work just fine.
Disclaimer 2: I don't provide any technical support for my fix through PM. So, please don't write PM about other devices. I share what i'm doing for myself .. and have no intention to do it to devices i don't have.
The trick:
This fix is not really fixes the problem, but it just replace the warning with the lg logo. so the boot time still higher as it is.
The raw_resources on our V20 is the equivalent partition to imgdata, but they use RLE images that has no header like BMP or JPEG, so we can't easily replace it like Nexus 5X ...
The trick that i use is changing the addresses of the warning images with the one of lg logo by patching raw_resources.bin file with Hex Workshop.
Here is a short description of steps to follow if you want to do the same for other devices:
1. download the KDZ firmware of your device.
2. extract the raw_resources.bin from it.
3. download and install Hex Workshop
3. open the raw_resources.bin with Hex Workshop
4. find the addresse of "lglogo_image" and copy it. (see the example image below)
5. find the 2 addresses of "verifiedboot_red_01" and "verifiedboot_red_02" and replace with the adrresse of "lglogo_image". ( respect the exact place!)
6. save your changes
7. put the raw_resources.bin incide the flash zip (you can use my attached flash zip).
8. flash the zip with TWRP.
9. reboot your device.
Attached: flash zip for my ls997 OREO firmware
Click to expand...
Click to collapse
Works on my H918 it does the warning but only in green text then shows lg logo
Speed gain ???
can we freely remove lines frome this file or the file size is important to the device to boot correctly, i guess by removing those lines we can disable this verification of aboot partition and gain a big boot speed ???
How are you on an Oreo firmware with a rooted ls997 when there are no roms that are Oreo for this model? Just wondering. I am stuck on Nougat and your rooted Oreo ls997 confuses me lol
Thanks @4shared for his great work.
Using his instructions I've patched the image for H990DS and F800K so far.
You can find the flashable zips here:
https://forum.xda-developers.com/v20/development/rom-h990ds-oreo-flashable-t3853735/post78503108
lingo2012 said:
Works on my H918 it does the warning but only in green text then shows lg logo
Click to expand...
Click to collapse
you can upload the flasheable zip? please
@4shared do you plan to share your Oreo rom for LS997?
He hasnt responded since he posted this.
Made one for the at&t H910 oreo not sure if it will work on nougat though. Works great on my H910 running alpha omega oreo. https://mega.nz/#!okADVKoB!N1W6kbYMbpXZpjuEgO1vIuELI_EV5ivUwQoM8gQM7_g
Thank you everyone,
I am glad that's my post is useful for someone .
--------------------
For rooting oreo I used a f800l kdz by using this method: Post
Again DO IT AT YOUR OWN RISK
-------------------
Currently i'm trying to port the H-ROM G7 PORT from g5 ...yes it boots but still not stable, still filled with BUGS
Edit:
Sorry guys, it looks like my 100$ refurbished ls997 has a f800s motherboard
4shared said:
Thank you everyone,
I am glad that's my post is useful for someone .
--------------------
For rooting oreo I used a f800l kdz by using this method: Post
Again DO IT AT YOUR OWN RISK
-------------------
Currently i'm trying to port the H-ROM G7 PORT from g5 ...yes it boots but still not stable, still filled with BUGS
Edit:
Sorry guys, it looks like my 100$ refurbished ls997 has a f800s motherboard
Click to expand...
Click to collapse
Was wondering how. Would have been epyk if on the real.
4shared said:
.
This fix is for those who want to get rid of the annoying Red Corruption warning screen!!.
Disclaimer: You apply the fix at your own risk. I'm not responsible for any software or hardware damage it can lead. The only thing i can assure is that i've tested fix on my lg v20 F800s with DirtySanta Bootloader unlocked, and it work just fine.
Disclaimer 2: I don't provide any technical support for my fix through PM. So, please don't write PM about other devices. I share what i'm doing for myself .. and have no intention to do it to devices i don't have.
The trick:
This fix is not really fixes the problem, but it just replace the warning with the lg logo. so the boot time still higher as it is.
View attachment 4667087
The raw_resources on our V20 is the equivalent partition to imgdata, but they use RLE images that has no header like BMP or JPEG, so we can't easily replace it like Nexus 5X ...
The trick that i use is changing the addresses of the warning images with the one of lg logo by patching raw_resources.bin file with Hex Workshop.
Here is a short description of steps to follow if you want to do the same for other devices:
1. download the KDZ firmware of your device.
2. extract the raw_resources.bin from it.
3. download and install Hex Workshop
3. open the raw_resources.bin with Hex Workshop
4. find the addresse of "lglogo_image" and copy it. (see the example image below)
5. find the 2 addresses of "verifiedboot_red_01" and "verifiedboot_red_02" and replace with the adrresse of "lglogo_image". ( respect the exact place!)
6. save your changes
7. put the raw_resources.bin incide the flash zip (you can use my attached flash zip).
8. flash the zip with TWRP.
9. reboot your device.
View attachment 4667088
Attached: flash zip for my f800s OREO firmware
It looks like my 100$ refurbished ls997 has a f800s motherboard.
Click to expand...
Click to collapse
Cold be useful https://github.com/ehem/lgetools/wiki/LG-V10
You've got an interesting experiment here. Problem is with things at this stage I see too much potential for malicious mischief, and insufficient gain to assist right now.
At the start of raw_resources is the string "BOOT_IMAGE_RLE". Almost certainly "RLE" stands for run-length encoding. Problem is, as mentioned in the Wikipedia article, there is lots of variation in what is called run-length encoding. If we could at least identify the start and end of some of the images we could think about doing something interesting.
The table of contents starts at 0x1000 (4KB or the second block). The end of the table is likely either indicated by the null entry or assumed to end at 0x2000 (8KB or the third block). In a handy example the longest entry title I found was "system_recovery_factoryreset_image" as this is 34 bytes, this means at least 36 bytes are reserved for the string, though 40 is more likely (there may be a requirement to have a null byte terminator) and there could be 28 bytes of data though 24 is a bit more likely.
24 bytes is a noticeable amount of data. That could be 6 32-bit numbers, or 3 64-bit numbers. At a minimum there would need to be a starting index, and either an end or a length. For "lglogo_image" I notice the first 4 bytes are "0x00 0x20 0x00 0x00". If this is little-endian (common for i386, AMD64 or ARM), then this would be "0x00002000" which looks suspiciously like the starting offset of the image data.
The issue then is what the other 20 bytes are? One of them is either an end offset or a length (note: a length might be encoded as a frame-count). One of them might well be a delay, in which case setting that one to zero would speed startup.
At offset 0x2000 of a handy raw_resources file the data starts with a few repeats of "0xFF 00 00 00". The byte sequence "0x00 00 00" could well be an encoding of black, in which case the 0xFF could be a count of 255 or 256 pixels. Looking through the file, I see a number of "0x01 xx xx xx" sequences, but no "0x00 xx xx xx" sequences. In which case it isn't likely that 1 is being added to the count, and those are 255 black pixels.
That is what I can come up with from looking at an example without spending a bunch more time analyzing the data. Alas I've got 15 things which need me to spend time on them. I'm curious as to what kind of startup animations are going to show up...
Okay, bit more analysis since I've actually kind of been wanting to be able to modify raw_resources (having my name/image on phone start would be kind of neat).
The initial header appears to have 5 fields:
Code:
struct rrheader {
char magic[16]="BOOT_IMAGE_RLE\x00\x00";
uint32_t entrycount;
uint32_t unknown;
char devicename[16];
uint32_t dataend;
};
The magic string is simply an identifier. Clearly suggestive of run-length encoding. The entrycount is the number of images stored in raw_resources. The unknown is a value which I don't know the meaning of, could instead be a pair of 16-bit numbers, but I suspect a single 32-bit little-endian is more likely. The devicename is something like "elsa_global_com". dataend identifies the complete length of all the data in raw_resources.
At offset 0x1000 (think LBA 1) the image headers start. The format is:
Code:
struct imageheader {
char name[40];
uint32_t dataoffset;
uint32_t expect;
uint32_t width;
uint32_t height;
char unknown[8];
}
Name is effectively a filename, such as "lglogo_image" or "verifiedboot_red_01". I'm pretty sure this string is what the code is searching for when trying to display an image. dataoffset is a byte offset from the begining of raw_resources. expect is a count of RLE entries worth of data, as such LGE/Qualcomm's software would multiply this by 4 and read that many bytes.
width and height are pretty obvious. The size of the image. I suspect the unknown is a pair of 4-byte integers, but I'm unsure of this. Presently I've got no idea of what it does. I'd love to have someone try modifying this value and see what it does.
5 images take roughly 250KB of space each: lglogo_image, verifiedboot_orange_01, verifiedboot_orange_02, verifiedboot_red_01, and verifiedboot_red_02. If you wanted to save space in raw_resources, you might merge verifiedboot_orange_01 with verifiedboot_orange_02, and similar for verifiedboot_red_0[12]. A number of the other images are also pairs which differ only by the unknown field, these pairs could be merged by setting their dataoffset values to the same value, thus freeing up more space.
My analysis in the previous post was on the money. The format is really dumb RLE. This is simple to encode, but doesn't offer very good compression ratios. These entries are 4-bytes long (expect counts these entries, not individual bytes). The first byte is a number value indicating a number of repeats, a 1 will result in 1 pixel of the color indicated by the next 3 bytes, a 2 will result in 2 pixels of the color, etc. The value 0 might well be untested, but it might cause 0 pixels of that color, 256 pixels of that color, 65536 pixels of that color, or perhaps a software crash.
The raw_resources sample I found had the color data in the order blue-green-red.
I'm attaching a simple Python 3 script which will decode a raw_resources image. Each portion will be dumped into a file matching the name in the image header. The format is "PPM" which is horribly inefficient, but easy to generate and modify by hand. Figure lglogo_image.ppm is 14MB for a 760x1544 image. The unknown in the image header will be emitted near the top of the PPM file (PPM is a text format, you can look at the raw data in a text editor). The data from the overall header including the raw unknown value will be emitted in a ".notes" text file matching the filename of the raw_resources image file.
Have fun with the knowledge.
Props to @4shared for the finding attached here you can find same fix for LS997 Sprint ZV7 Nougat. (warning image strings replaced with quick_lglogo_image)
Thanks.I have tried this on my vs995 and it works great. It should be OK on us996 because my raw img is from a us996 kdz
emdroidle said:
You've got an interesting experiment here. Problem is with things at this stage I see too much potential for malicious mischief, and insufficient gain to assist right now.
Click to expand...
Click to collapse
I'm still rather concerned about the potential to hide that the phone has been rooted/modified and then being sold as unmodified. I am though interested in the capability to replace the startup image with my own.
I suspect the unknown in the main raw_resources header may be some sort of version code. Alternatively it could be some magic values. Elsewhere I found a thread with a G4 raw_resources image. The first byte was 0x02, while the layout of the file pointed towards a 2KB block size. Add 9 and it could be interpreted as a shift value for the block size (2+9=11; 1<<11=2048), for the V20 that byte is 0x03 so 3+9=12, 1<<12=4096.
More of the image entry fields filled in:
Code:
struct imageheader {
char name[40];
uint32_t dataoffset;
uint32_t expect;
uint32_t width;
uint32_t height;
uint32_t unknown;
uint32_t screenoffset;
}
I'm quite sure "screenoffset" is a count of lines down from the top of screen specifying where the image should be placed. For the LG logo image in one version of raw_resources the value is decimal 160, which is specifying to place the image at the top of the main screen area and skipping the "second screen" (this is a crucial insight when interpretting the value).
I'm still unsure what the unknown is. I'll hazard a guess that it is some sort of flag value. The verified boot orange and red files have this set to 0x0064. The NT_TYPE_* files have 0x00E1. The most common value is 0x0000.
One other puzzle is left, how is the background color set? Several strategies come to mind. Reading a pixel in one of the corners and using that as background color is one. Another is to copy the whole border pattern outwards so everything ends up matching the border (this would explain why almost every image has at least 1 entire pixel of border).
I'm pretty sure the image rendering procedure is start on line $screenoffset, and dump the image into the center of the screen.
A fair bit of what I've seen in the data is rather odd. I'm left wondering whether LGE's tools for working with raw_resources are very primative, buggy or something else. Perhaps it is mostly being done by hand given some of the inconsistency. Is there a genuine need for borders (often wide) on all the images?
All the images start at multiples of 0x1000 (4096). This could be required by limitations of the bootloader environment, alternatively this could be LGE Engineering hasn't had time to correct this limitation. I'm a bit concerned violating this could have the potential to crash the bootloader...
There are a number of ways to free a great deal of space in raw_resources. Of note while they have different screenoffset values, the pair factory_reset_no_???_image and factory_reset_yes_???_image have identical payload data. Point them to the same address in raw_resources and you would free some space there. I also see how the factory_reset_???_line_image files could be merged, at which point the space used by factory_reset_1st_line_image could be freed. I don't know about some, but the battery_insert_nt_module_image is clearly for the G5 and not the V20 (reusing resources is one of the ways you save on your Engineering budget). Shrinking the large borders off various images would also save quite a bit of space.
I am interested in trying to produce my own version of raw_resources. Due to the ethics concern mentioned above, anything done by me will show overt indications of being in orange/red boot state.
I'm attaching an updated version of rrdecode I've been working on as part of the process of analyzing raw_resources. This includes 2 variants. The PPM variant outputs NetPBM format files, I'm a bit worried viewers for this format may be rare, but if you've got one it can be a handy format. The PNG variant will output PNG files once the Python Imaging Library is installed. This is a much more commonly used format so there are zillions of viewers out there.
MD5: 8616b271853fa974fec7f1d3ea838da6
SHA1: 78ebf2bb028d18bb571db92dc8af3d0bdd622bc0
SHA512: 07845b06d8cb9ab9be2de2caf380cae96772b81613e1dbd79e20f979c94c74ff96af33e1c41869226bbc54cf740354862c58bfd54cc4947c2ec4425641fa15da
does anyone have a description of how to repack the raw_resources.bin again
emdroidle said:
I'm still rather concerned about the potential to hide that the phone has been rooted/modified and then being sold as unmodified. I am though interested in the capability to replace the startup image with my own.
I suspect the unknown in the main raw_resources header may be some sort of version code. Alternatively it could be some magic values. Elsewhere I found a thread with a G4 raw_resources image. The first byte was 0x02, while the layout of the file pointed towards a 2KB block size. Add 9 and it could be interpreted as a shift value for the block size (2+9=11; 1<<11=2048), for the V20 that byte is 0x03 so 3+9=12, 1<<12=4096.
More of the image entry fields filled in:
Code:
struct imageheader {
char name[40];
uint32_t dataoffset;
uint32_t expect;
uint32_t width;
uint32_t height;
uint32_t unknown;
uint32_t screenoffset;
}
I'm quite sure "screenoffset" is a count of lines down from the top of screen specifying where the image should be placed. For the LG logo image in one version of raw_resources the value is decimal 160, which is specifying to place the image at the top of the main screen area and skipping the "second screen" (this is a crucial insight when interpretting the value).
I'm still unsure what the unknown is. I'll hazard a guess that it is some sort of flag value. The verified boot orange and red files have this set to 0x0064. The NT_TYPE_* files have 0x00E1. The most common value is 0x0000.
One other puzzle is left, how is the background color set? Several strategies come to mind. Reading a pixel in one of the corners and using that as background color is one. Another is to copy the whole border pattern outwards so everything ends up matching the border (this would explain why almost every image has at least 1 entire pixel of border).
I'm pretty sure the image rendering procedure is start on line $screenoffset, and dump the image into the center of the screen.
A fair bit of what I've seen in the data is rather odd. I'm left wondering whether LGE's tools for working with raw_resources are very primative, buggy or something else. Perhaps it is mostly being done by hand given some of the inconsistency. Is there a genuine need for borders (often wide) on all the images?
All the images start at multiples of 0x1000 (4096). This could be required by limitations of the bootloader environment, alternatively this could be LGE Engineering hasn't had time to correct this limitation. I'm a bit concerned violating this could have the potential to crash the bootloader...
There are a number of ways to free a great deal of space in raw_resources. Of note while they have different screenoffset values, the pair factory_reset_no_???_image and factory_reset_yes_???_image have identical payload data. Point them to the same address in raw_resources and you would free some space there. I also see how the factory_reset_???_line_image files could be merged, at which point the space used by factory_reset_1st_line_image could be freed. I don't know about some, but the battery_insert_nt_module_image is clearly for the G5 and not the V20 (reusing resources is one of the ways you save on your Engineering budget). Shrinking the large borders off various images would also save quite a bit of space.
I am interested in trying to produce my own version of raw_resources. Due to the ethics concern mentioned above, anything done by me will show overt indications of being in orange/red boot state.
I'm attaching an updated version of rrdecode I've been working on as part of the process of analyzing raw_resources. This includes 2 variants. The PPM variant outputs NetPBM format files, I'm a bit worried viewers for this format may be rare, but if you've got one it can be a handy format. The PNG variant will output PNG files once the Python Imaging Library is installed. This is a much more commonly used format so there are zillions of viewers out there.
MD5: 8616b271853fa974fec7f1d3ea838da6
SHA1: 78ebf2bb028d18bb571db92dc8af3d0bdd622bc0
SHA512: 07845b06d8cb9ab9be2de2caf380cae96772b81613e1dbd79e20f979c94c74ff96af33e1c41869226bbc54cf740354862c58bfd54cc4947c2ec4425641fa15da
Click to expand...
Click to collapse
Anything new? Did you manage to change the picture?
Also... I wonder if the crash possibility you're speaking about could lead to something more useful...
sexmaschine said:
does anyone have a description of how to repack the raw_resources.bin again
Click to expand...
Click to collapse
i didn't have to repack it after modifying it with a hex editor. i just modified an installation zip to install it.
Hi,
my name is Melanie, I'm part of an effort to root the Vector robot made by Anki.
Anki has recently gone into administration, with the IP of the company winding up as collateral for an emergency loan that was never paid back.
Vector is very much dependent on the "cloud", namely, Anki's servers running on AWS. The SSL certificate for these servers is due to expire in September. There is little chance of it being renewed since the company has no funds.
A group of tech-savvy owners have got together on Discord to discuss how to help Vector survive the coming demise of his servers. They had already collected a not insignificant amount of information in the form of datasheets and observations as well as images of the internals of the robot and images of jigs Anki used during development.
I'm bringing this project to this forum because, internally, Vector is really a phone without the GSM part.
He is powered by a Qualcomm APQ8009 (Snapdragon 212), which has been paired with a combination ram/flash chip by Kingston, 04EMCP04-NL3DM627. There is also a Wifi/BLE module and a screen and 4 microphones.
The Snapdragon runs an Android boot loader and Linux kerner version 3.18.66-perf.
This is where he becomes different from a phone in that he doesn't start Zygote, but rather runs a number of daemons from systemd.
As shipped, there is no user accessible wired IO.
There are a number of wirepads on the PCB, as well as unpopulated pads for a micro USB port. When I joined the project, the serial port was already known, but while it provides a boot log, there is no getty on it.
The USB port had to this point not been successfully activated.
Since I'm a hardware person, that is where i placed my lever. I populated the USB port and started digging. Finally I found a solder pad labeled F_USB which was not even close tot he USB port, but turned out to be a boot mode pin from the CPU. Pulling it to VCC made the USB port enumerate in EDL mode. Qualcomm call it QDL or QDLoader, but it basically an interface to the ROM in the CPU, just like phones have.
From this I managed to grab a CPU ID but not much more.
Meanwhile, we reverse-engineered the phone app that comes with it and are currently writing a general purpose library to talk to Vector over BLE.
At this point, I found that I was facing a thicket of software, mostly either cracked or containing malware, or both, but very little legit options.
I see a few options to go forward on this:
- Find a software that can talk to the Snapdragon 212 to extract the current image
- Desolder the flash to extract the image via a programmer
- Desolder the CPU to access the flash's data lines without having to heat the flash, which could corrupt it
The last two options are bound to be destructive and all us owners have found a connection to their robots and are loath to sacrifice them. Also, they require a bit of investment and are, because of that, no quick wins.
I'm hoping that someone here may have the missing pieces I need to get from QDL 9008 mode to an image of the flash on my disk. We believe we have another way to flash it, not needing the USB port, but we don't have an image to try it with and flashing something like all zeroes would needlessly destroy a robot.
- Melanie
PS: I would post links but I'm too young to do so. There is a google group called "Project Victor" that has the info we have so far called anki-vector-rooting, a.k.a. Project Victor.
https://groups.google.com/forum/m/#!forum/anki-vector-rooting
You are welcome to PM links to me and I will post them as a work around.
hope the best!
Link to Project Vector
http://projectvictor.my.to/
Sent from my ocean using XDA Labs