Related
I made a kitchen that creates ROMs in both XPR and LZX compressions.
I'm also trying to port it to the Artemis, the Trinity, and the Hermes.
The way the kitchen work is:
Run "RunMe.bat"
Choose compression algorithm. (XPR or LZX)
Follow the normal Bepe's kitchen process.
Wait as the kitchen creates the ROM (like Bepe's kitchen, but with whatever compression you chose.)
The kitchen will automatically open up the imgfs.bin in a hex editor and automatically adjust it for the wanted compression before it builds the ROM.
It automatically inserts the proper XIP drivers.
It will automatically set the Pagepool to 4MB but give you the option to change it to something else as it does.
It then automatically creates the NBH and then finally launches whatever flasher (CustomerRUU, FlashCenter, or whatever your devices use) to flash the ROM.
For those who don't know what LZX compression is:
It's a compression algorithm that, although slower (by 1-4% in real life use) gives a good amount of free storage space. In some case (like in the Herald) it makes the ROM so small that it has to be flashed through an SD card due to the Herald's flashing size requirements. On an average 50mb ROM, it takes off about 10mb. The actual cooking itself does take a LOT more CPU and RAM to do in your PC, though. Especially the RAM. (It's because the tools that actually do the compression weren't really optimized for the job.)
Anyhow, let me know if you want it.
I would love to use it if you're willing to share. I really want to get into cooking. I just don't have time these days.
Here is a bit that one of my buddies wrote on compression, for those interested. He's actually discussing LZMA (which is what 7zip uses by default), which is similar to the LZ1 dictionary (the same dictionary used in LZX compression algorithms). This should help people to understand what settings to use depending on the situation.
Hehe. I've long been fascinated by compression algorithms ever since studying the original Lempel-Ziv algorithm some years ago.
The key here is the dictionary, which, in a simplified nutshell, stores patterns that have been encountered. You encounter pattern A, compress/encode it, and then the next time you see pattern A, since it's already in the dictionary, you can just use that. With a small dictionary, what happens is that you'll encounter pattern A, then pattern B, C, D, etc., and by the time you encounter pattern A again, it's been pushed out of the dictionary so that you can't re-use it, and thus you take a hit on your size. All compression algorithms basically work on eliminating repetition and patterns, so being able to recognize them is vital, and for dictionary-based algorithms (which comprise most mainstream general-purpose algorithms), a small dictionary forces you to forget what you saw earlier, thus hurting your ability to recognize those patterns and repetitions; small dictionary == amnesia.
Solid compression is also important because without it, you are using a separate dictionary for every file. Compress file 1, reset dictionary, compress file 2, reset dictionary, etc. In other words, regular non-solid compression == amnesia. With solid compression, you treat all the files as one big file and never reset your dictionary. The downside is that it's harder to get to a file in the middle or end of the archive, as it means that you must decompress everything before it to reconstruct the dictionary, and it also means that any damage to the archive will affect every file beyond the point of damage. The first problem is not an issue if you are extracting the whole archive anyway, and the second issue is really only a problem if you are using it for archival backup and can be mitigated with Reed-Solomon (WinRAR's recovery data, or something external, like PAR2 files). Solid archiving is very, very important if you have lots of files that are similar, as is the case for DirectX runtimes (since you have a dozen or so versions of what is basically the same DLL). For example, when I was compressing a few versions of a DVD drive's firmware some years ago, the first file in the archive was compressed to about 40% or so of the original size, but every subsequent file was compressed to less than 0.1% of their original size, since they were virtually duplicates of the first file (with only some minor differences). Of course, with a bunch of diverse files, solid archiving won't help as much; the more similar the files are, the more important solid archiving becomes.
The dictionary is what really makes 7-Zip's LZMA so powerful. DEFLATE (used for Zip) uses a 32KB dictionary, and coupled with the lack of solid archiving, Zip has the compression equivalent of Alzheimer's. WinRAR's maximum dictionary size is 4MB. LZMA's maximum dictionary size is 4GB (though in practice, anything beyond 128MB is pretty unwieldy and 64MB is the most you can select from the GUI; plus, it doesn't make sense to use a dictionary larger than the size of your uncompressed data, and 7-Zip will automatically adjust the dictionary size down if the uncompressed data isn't that big). Take away the dictionary size and the solid compression, and LZMA loses a lot of its edge.
In the case of the DirectX runtimes, because of their repetitive nature and the large size of the uncompressed data, a large dictionary and solid compression really shines here, much more so than it would in other scenarios. My command line parameters set the main stream dictionary to 128MB, and the other much smaller streams to 16MB. For the 32-bit runtimes, where the total uncompressed size is less than 64MB, this isn't any different than the Ultra setting in the GUI, and 7-Zip will even reduce the dictionary down to 64MB. For the 64-bit runtimes, the extra dictionary size has only a modest effect because 64MB is already pretty big, and also because the data with the most similarity are already placed close to each other (by the ordering of the files). The other parameters (fast bytes and search cycles) basically makes the CPU work harder and look more closely when searching for patterns, but their effect is also somewhat limited. In all, these particular parameters are only slightly better than Ultra from the GUI, but I much rather prefer running a script than having to wade through a GUI (just as I prefer unattended installs over wading through installs manually).
Oh, and another caveat: Ultra from the GUI will apply the BCJ2 filter to anything that it thinks is an executable. This command line will apply it to everything. Which means that this command line should not be used if you are doing an archive with lots of non-executable code (in this case, the only non-executable is a tiny INF file, so it's okay). This also means that this command line will perform much better with files that don't get auto-detected (for example, *.ax files are executable, but are not recognized as such by 7-Zip, so an archive with a bunch of .ax files will do noticeably better with these parameters than with GUI-Ultra). If you want to use a 7z CLI for unattended compression but would prefer that 7-Zip auto-select BCJ2 for appropriate files, use -m0=LZMA:d27:fb=128:mc=256 (which is also much shorter than that big long line; for files that do get BCJ2'ed, it will just use the default settings for the minor streams).
dumpydooby said:
I would love to use it if you're willing to share. I really want to get into cooking. I just don't have time these days.
Here is a bit that one of my buddies wrote on compression, for those interested. He's actually discussing LZMA (which is what 7zip uses by default), which is similar to the LZ1 dictionary (the same dictionary used in LZX compression algorithms). This should help people to understand what settings to use depending on the situation.
Hehe. I've long been fascinated by compression algorithms ever since studying the original Lempel-Ziv algorithm some years ago.
The key here is the dictionary, which, in a simplified nutshell, stores patterns that have been encountered. You encounter pattern A, compress/encode it, and then the next time you see pattern A, since it's already in the dictionary, you can just use that. With a small dictionary, what happens is that you'll encounter pattern A, then pattern B, C, D, etc., and by the time you encounter pattern A again, it's been pushed out of the dictionary so that you can't re-use it, and thus you take a hit on your size. All compression algorithms basically work on eliminating repetition and patterns, so being able to recognize them is vital, and for dictionary-based algorithms (which comprise most mainstream general-purpose algorithms), a small dictionary forces you to forget what you saw earlier, thus hurting your ability to recognize those patterns and repetitions; small dictionary == amnesia.
Solid compression is also important because without it, you are using a separate dictionary for every file. Compress file 1, reset dictionary, compress file 2, reset dictionary, etc. In other words, regular non-solid compression == amnesia. With solid compression, you treat all the files as one big file and never reset your dictionary. The downside is that it's harder to get to a file in the middle or end of the archive, as it means that you must decompress everything before it to reconstruct the dictionary, and it also means that any damage to the archive will affect every file beyond the point of damage. The first problem is not an issue if you are extracting the whole archive anyway, and the second issue is really only a problem if you are using it for archival backup and can be mitigated with Reed-Solomon (WinRAR's recovery data, or something external, like PAR2 files). Solid archiving is very, very important if you have lots of files that are similar, as is the case for DirectX runtimes (since you have a dozen or so versions of what is basically the same DLL). For example, when I was compressing a few versions of a DVD drive's firmware some years ago, the first file in the archive was compressed to about 40% or so of the original size, but every subsequent file was compressed to less than 0.1% of their original size, since they were virtually duplicates of the first file (with only some minor differences). Of course, with a bunch of diverse files, solid archiving won't help as much; the more similar the files are, the more important solid archiving becomes.
The dictionary is what really makes 7-Zip's LZMA so powerful. DEFLATE (used for Zip) uses a 32KB dictionary, and coupled with the lack of solid archiving, Zip has the compression equivalent of Alzheimer's. WinRAR's maximum dictionary size is 4MB. LZMA's maximum dictionary size is 4GB (though in practice, anything beyond 128MB is pretty unwieldy and 64MB is the most you can select from the GUI; plus, it doesn't make sense to use a dictionary larger than the size of your uncompressed data, and 7-Zip will automatically adjust the dictionary size down if the uncompressed data isn't that big). Take away the dictionary size and the solid compression, and LZMA loses a lot of its edge.
In the case of the DirectX runtimes, because of their repetitive nature and the large size of the uncompressed data, a large dictionary and solid compression really shines here, much more so than it would in other scenarios. My command line parameters set the main stream dictionary to 128MB, and the other much smaller streams to 16MB. For the 32-bit runtimes, where the total uncompressed size is less than 64MB, this isn't any different than the Ultra setting in the GUI, and 7-Zip will even reduce the dictionary down to 64MB. For the 64-bit runtimes, the extra dictionary size has only a modest effect because 64MB is already pretty big, and also because the data with the most similarity are already placed close to each other (by the ordering of the files). The other parameters (fast bytes and search cycles) basically makes the CPU work harder and look more closely when searching for patterns, but their effect is also somewhat limited. In all, these particular parameters are only slightly better than Ultra from the GUI, but I much rather prefer running a script than having to wade through a GUI (just as I prefer unattended installs over wading through installs manually).
Oh, and another caveat: Ultra from the GUI will apply the BCJ2 filter to anything that it thinks is an executable. This command line will apply it to everything. Which means that this command line should not be used if you are doing an archive with lots of non-executable code (in this case, the only non-executable is a tiny INF file, so it's okay). This also means that this command line will perform much better with files that don't get auto-detected (for example, *.ax files are executable, but are not recognized as such by 7-Zip, so an archive with a bunch of .ax files will do noticeably better with these parameters than with GUI-Ultra). If you want to use a 7z CLI for unattended compression but would prefer that 7-Zip auto-select BCJ2 for appropriate files, use -m0=LZMA:d27:fb=128:mc=256 (which is also much shorter than that big long line; for files that do get BCJ2'ed, it will just use the default settings for the minor streams).
Click to expand...
Click to collapse
You have no idea how much the geek in me loved this post. ^_^ I have a thing about compression, too, but I'm just not very well versed in it. I only know the basic details of compression.
Answered 2 of my questions I tried finding out the other day. Thank you guys. I learn so much here.
While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....
erasmux said:
While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....
Click to expand...
Click to collapse
Huh. I've been wondering if this was possible. I haven't tried this yet but if it works, nicely done! I think that this would be a huge improvement and addition to the themeporter programs that are out there. There is a high demand for this in that area and in the area of HDPI>MDPI/MDPI>HDPI conversion. I'm certainly bookmarking this!
Awesome, just checked out ur source, so simple but effective
Anyway wanted to ask if ur ok with me incorporating it into theme-porter ? Link
Wht im thinking is perhaps when "Hdpi to mdpi" is on, it would resize the .9.pngs by 66%, after which it would transfer the .9 data using this program so (9-patch) code is preserved.
Let me know. Thnx
FYI : Just gave it a whirl, works perfectly.
Daneshm90 said:
Awesome, just checked out ur source, so simple but effective
Anyway wanted to ask if ur ok with me incorporating it into theme-porter ? Link
Wht im thinking is perhaps when "Hdpi to mdpi" is on, it would resize the .9.pngs by 66%, after which it would transfer the .9 data using this program so (9-patch) code is preserved.
Let me know. Thnx
FYI : Just gave it a whirl, works perfectly.
Click to expand...
Click to collapse
Maybe my original post wasn't blunt enough, my code is just "proof of concept" because I am bit lazy in this department (themeing tools) - I'd rather spend my time compiling kernels (go figure ).
So my main goal for this post is for developers of apk managing tools and etc. to pick up the ball and go forward with this
And to be even clearer:
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
(am also adding this to the main post)
Regarding your actual resizing idea, you might want to resize it with the 9-patch "codes" (in the 1-pixel border) because you want the codes from your original HDMI files just resized. This should work, just be careful with resizing algorithms which average pixels and such. If I understand correctly the edge pixels should be either white or black (defining stretchable and context areas). Need to play around with this until it works well.
Let me know if I can be of any further assistance.
erasmux said:
Maybe my original post wasn't blunt enough, my code is just "proof of concept" because I am bit lazy in this department (themeing tools) - I'd rather spend my time compiling kernels (go figure ).
So my main goal for this post is for developers of apk managing tools and etc. to pick up the ball and go forward with this
And to be even clearer:
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
(am also adding this to the main post)
Regarding your actual resizing idea, you might want to resize it with the 9-patch "codes" (in the 1-pixel border) because you want the codes from your original HDMI files just resized. This should work, just be careful with resizing algorithms which average pixels and such. If I understand correctly the edge pixels should be either white or black (defining stretchable and context areas). Need to play around with this until it works well.
Let me know if I can be of any further assistance.
Click to expand...
Click to collapse
Hmm k i'll spend more time with it, perhaps the resizing program im using causes mishaps. Currently when i resize it completely messes stuff up even though the resolution corresponds to a mdpi device.
I'll do the good ol' trial/error n let u know. Thanks for the (proof of concept)
Edit :
Ok so upon using ur code for transferring images of diff sizes u can obviously tell whts up
So one improvement im thinking off, is if the images differ in size, it could draw the border and eliminate anything outside it. Ugh gotta brush up on my java though :S
bump
10 del al char har
bump
I tested it out and it works great! Thanks!
I really hope someone takes this idea and runs with it! If I knew how to code, I would certainly look into this. Maybe I can get one of the Vibrant Devs to look at this....
erasmux said:
While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....
Click to expand...
Click to collapse
Can U just tell how to use this code for bulk images?????
pratyush.creed said:
Can U just tell how to use this code for bulk images?????
Click to expand...
Click to collapse
Hmm, haven't used this for a very long time and don't really remember whats going on here.
Still attached is the version which I have on my HD, and it does support bulk images if all the images are in a folder.
If I remember correctly (mostly going by the help that is displayed by running the program without argument):
Code:
fixResPngs drawable-mdpi drawable-mdpi.org
Will go over all drawable-mdpi/*.png files (possibly also sub dirs?! I really have no idea, sorry), and "fix" each such file. If I am not mistaken it needs a "reference" file only for 9 patch files which are identified by their ".9.png" suffix (regular pngs I think are just rewritten without any change which I found improves compatibility). In case of a 9 patch file, the original file with exactly the same name should be found under the directory given in the second argument. For example: If drawable-mdpi/aaa.9.png is processed the 9-patch data will be copied from drawable-mdpi.org/aaa.9.png.
Obviously it also still works on single files. It does *not* work on lists of files or lists of directories.
If anyone is interested in the code, I am sure I have it somewhere (I hope)....
erasmux said:
Hmm, haven't used this for a very long time and don't really remember whats going on here.
Still attached is the version which I have on my HD, and it does support bulk images if all the images are in a folder.
If I remember correctly (mostly going by the help that is displayed by running the program without argument):
Code:
fixResPngs drawable-mdpi drawable-mdpi.org
Will go over all drawable-mdpi/*.png files (possibly also sub dirs?! I really have no idea, sorry), and "fix" each such file. If I am not mistaken it needs a "reference" file only for 9 patch files which are identified by their ".9.png" suffix (regular pngs I think are just rewritten without any change which I found improves compatibility). In case of a 9 patch file, the original file with exactly the same name should be found under the directory given in the second argument. For example: If drawable-mdpi/aaa.9.png is processed the 9-patch data will be copied from drawable-mdpi.org/aaa.9.png.
Obviously it also still works on single files. It does *not* work on lists of files or lists of directories.
If anyone is interested in the code, I am sure I have it somewhere (I hope)....
Click to expand...
Click to collapse
Gr8 work...u made themin a kid's job
Sent from my GT-S5670 using XDA Premium App
???
does the original still work cause im on windows 7 64 bit and i was able to copy the changes to original but not it makes no changes at all, so the original file doesnt get the changes...
please help!!
In order to develop an app remote desktop WP7, I started to with a desktop simple viewer and it works
but the problem that not show all actions that I do in Server side, that's video in YouTube can show you my problem
"watch?v=3q-FumfYsPQ&feature=youtu.be" (add it after /)
I use socket connection and I decode and encode my data (images).
this my code in WP7 client side
void Conncet(string IP_Address) {
client_socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
SocketAsyncEventArgs socketEventArg = new SocketAsyncEventArgs()
{
RemoteEndPoint = new IPEndPoint(IPAddress.Parse(IP_Address), 4532)
};
socketEventArg.Completed += OnConncetCompleted;
client_socket.ConnectAsync(socketEventArg);
}
void StartReceiving()
{
byte[] response = new byte[131072];
SocketAsyncEventArgs socketEventArg = new SocketAsyncEventArgs();
socketEventArg.Completed += OnReceiveCompleted;
socketEventArg.SetBuffer(response, 0, response.Length);
client_socket.ReceiveAsync(socketEventArg);
}
private void ViewReceivedImage(byte[] buffer)
{ try { MemoryStream ms = new MemoryStream(buffer);
BitmapImage bi = new BitmapImage();
bi.SetSource(ms); MyImage.Source = bi;
ms.Close();
}
catch (Exception) { }
finally { StartReceiving();
} }
this my code in Server side (PC) sending images
void StartSending() { while (!stop)
try
{
Image oldimage = scr.Get_Resized_Image(wToCompare, hToCompare, scr.GetDesktopBitmapBytes());
//Thread.Sleep(1);
Image newimage = scr.Get_Resized_Image(wToCompare, hToCompare, scr.GetDesktopBitmapBytes());
byte[] buffer = scr.GetDesktop_ResizedBytes(wToSend, hToSend);
float difference = scr.difference(newimage, oldimage);
if (difference >= 1)
{
SenderSocket.Send(buffer);
}
}
catch (Exception) { }
}
My question is how can I make the send and receive fast to show the PC screen in WP7 in +/- real time.
The short answer is, you can't. Even if you compress the screen images first, which I note you're not doing, the amount of data is just too great. An uncompressed 800x480x32-bit image (such as WP7's screen can display) is 1.5MB. That's each frame. You can halve that by using 16-bit color, of course; now it's .75MB per frame. If you want even 20 frames per second - which is slower than TV or almost any video camera, but is moderately smooth for most things - that's 15 MB/sec, which is 120Mbps (about twice the speed of most WiFi, faster even than most wired networks).
With some simple image compression combined with clever data differencing (sending only the parts of the image that change), you could probably reduce that data load by at least a factor of 10. That's still too high for most Internet connections (even if your phone can download 12 Mbps, your PC probably can't upload it) but it might be usable over WiFi (802.11n probably, 802.11a or g maybe). You'd have to make your code quite a bit more complicated, of course. Additionally, the phone's processor would have to work a lot harder, since it would be decompressing the data and applying it to the changed part of the frame, instead of just dumping netowrk packets into an image buffer.
The real solution, of course, is to use one of the several programs and protocols that already exist and have the intended purpose of doing exactly what you're trying to do. The most common on Windows is called Terminal Services or Remote Desktop (Remote Desktop Protocol). Nearly all versions of Windows come with the client, and the better editions come with the server. On WP7, there are already some client apps available; the one I use is called "RemoteDesktop" (no space). Note that, in addition to having a well-optimized algorithm for screen updates (but it's *still* not going to be smooth for things like movies or games), Remote Desktop Protocol lets you control the PC directly as well.
Thanks
I look that's apps in marketplace and it looks very difficult to me, but I develop simple viewer and next time I will develop the code that can remote the PC.
the idea about send only that pixels that changed between the old image and the new image is really good, but how I ca send only that pixel and they're position in the image, that's a question.
And about compression, how I can do that with images?
Well, just compressing the full screen to .PNG or .JPG and sending it would shrink things considerably. There are .NET libraries available (there might even be one in the core library) for image compression. Alternatively, there are some excellent C/C++ libraries available, if you can code native interop. I know the phone has built-in capability to handle JPG, not sure about PNG though.
However, once the data is compressed it's hard to extract a part of it and send just that part. What I suggest you do instead is identify the portion of the image that changed. For example, if all the changed pixels fall within one rectangle, use that. Send the coordinates of the rectangle (its origin and either the opposite corner or the length/width), followed by the updated data. On the phone, listen for the rectangle to update, then write the updated data into those coordinates on the display.
Note that you may want to send multiple rectangles - for example, if the top left nd bottom right pixels change, but nothing else does, a single rectangle that encompasses both of them would have to be the entire image. Instead, send two tiny rectangles - one for each corner - and you can massively reduce the data needed. However, the process of quickly detecting a good way to break up an image into the parts that are and are not moving is tricky. You're essentially trying to create a video compression algorithm here, and although I know a little of the theory, it's totally not my area and I don't know much more than what I've told you so far.
Thanks again
I found something similare to know the pixel that chaged
Image Comparison using C#
http://www.c-sharpcorner.com/uploadfile/prathore/image-comparison-using-C-Sharp/
I will try to study it and get information how to set the coordinates, but the problem that stay is how I send it to the right position in image in client side
juste_3al_faza said:
I look that's apps in marketplace and it looks very difficult to me
Click to expand...
Click to collapse
I don't understand that. What is "difficult"? Enable RDP access on desktop? Or add your desktop ip address to the WP7 app? Take a look to the RemoteDesktop app by Topperware: it's fast, professionally designed and easy to use but of course not a free (however $4.99 is not much!)
As for me, it looks like you are trying to "invent a bicycle" but without basic knowledge how the remote access protocols should work. It's not that easy like just a transfer bitmap images via sockets...
I mind I don't need to use it, I want to develop a simple apps because its my project and I will get a note and pass my last year in school
juste_3al_faza said:
I mind I don't need to use it, I want to develop a simple apps because its my project and I will get a note and pass my last year in school
Click to expand...
Click to collapse
Now I understand OK, I can recommend you to dig in MJPEG. There are few Silverlight classes available on the web (you may google em); they may simplify your job. The picture quality isn't good or sharp enough but should be good for the student project.
you talk about compression images to mpeg????????????
have you an idea when I zoom In image in WP7, most image be clear to see, how I can do it?
Edit (After see the article about MJPEG silverlight)
It use the HTTP connexion and I use socket, It can work together?
If yes how I can combine with it (plz a sample code can help )
No, I'm talking about M(otion)JPEG over HTTP, easiest possible video streaming implementation. For the solution, you need to implement your own M-JPEG HTTP server application, and on WP7 you may use (it's already exists, google for MJPEG MediaStreamSource) MediaElement. And I don't understand your second question.
I already edit my previous post
and about the 2nd question, I mean when to pinch in WP7 screen, is the image will be clear or not.
I don't have time to write an example for you; however it's your project or homework , I just give you a direction.
As for seconds question (as far as I understand): it's depends from the image dimensions and JPEG compression level. If you resize 1920x1080 image to 800x480 with 50% quality, resulting image will looks not so good.
P.S. Check this project: http://mjpeg.codeplex.com/ To estimate output quality on Wp7, you may use any MJPEG desktop streaming solution (vlc, for example).
Thanks a lot
I finished my app and it work good, see the video
http://www.youtube.com/watch?v=cCwsuj7Hcno
Cool. Looks like you get about a frame per second, which won't work for showing a video but is fine for a Powerpoint or something, and a decent proof of concept.
I'm not sure I'd recommend demoing using a video showing a commercial movie with a clearly visible "Uploaded by..." comment, at least in the USA schools tend to frown on open displays of media piracy. Otherwise, well done.
Ok next time I will use PowerPoint to use my app show
I implemented a browser based encryption solution which runs on Windows RT (and many other Windows computers). All I wrote was the HTML page, I am leveraging Crypto.JS javascript library for encryption algorithm. I am using the HTML 5 File API implementation which Microsoft provides for reading and writing files.
I make no claim on this but seems to work good for me. Feel free to feedback if you have any suggestions. The crypto.js library supports many different algorithms and configuration so feel free to modify it to your own purposes.
You can download the zip file to your surface, extract it and load the TridentEncode.htm file into Internet Explorer.
If you want to save to custom directory you probably need to load it from the Desktop IE instead of metro IE (to get the file save dialog). I usually drag and drop the file onto desktop IE and from there I can make favorite. This should work in all IE 11 and probably IE 10 browsers... if you use other browsers you may need to copy paste into the fields since the File API implementation seems rather browser specific. Running the html page from the local filesystem means that there is no man-in-the-middle which helps eliminate some of the vulnerabilities of using a javascript crypto implementation. You could also copy the attached zip file to your skydrive to decrypt your files from other computers.
Skydrive files in theory are secure (unless they are shared to public) so this might be useful for adding another layer of protection to certain info.
Again, use at your own risk, but feel free to play around and test it, and offer any suggestions or critiques of its soundness, or just use it as a template for your own apps.
Ok... this is really cool! Nice idea, and a good first implementation.
With that said, I have a few comments (from a security perspective). As an aside, minimized JS is the devil and should be annihilated with extreme prejudice (where not actually being used in a bandwidth-sensitive context). Reviewing this thing took way too long...
1) Your random number generation is extremely weak. Math.random() in JS (or any other language I'm aware of, for that matter) is not suitable for use in cryptographic operations. I recommend reading http://stackoverflow.com/questions/4083204/secure-random-numbers-in-javascript for suggestions. The answer by user ZeroG (bottom one, with three votes, as of this writing) gets my recommendation. Unfortunately, the only really good options require IE11 (or a recent, non-IE browser) so RT8.0 users are SOL.
NOTE: For the particular case in question here (where the only place I can see that random numbers are needed is the salt for the key derivation), a weak PRNG is not a critical failing so long as the attacker does not know, before the attack, what time the function is called at. If they do know, they can pre-compute the likely keys and possibly succeed in a dictionary attack faster than if they were able to generate every key only after accessing the encrypted file.
2) Similarly, I really recommend not using a third-party crypto lib, if possible; window.crypto (or window.msCrypto, for IE11) will provide operations that are both faster and *much* better reviewed. In theory, using a JS library means anybody who wants to can review the code; in practice, the vast majority of people are unqualified to either write or review crypto implementations, and it's very easy for weaknesses to creep in through subtle errors.
3) The default key derivation function (as used for CryptoJS.AES.encrypt({string}, {string})) is a single iteration of MD5 with a 64-bit salt. This is very fast, but that is actually a downside here; an attacker can extremely quickly derive different keys to attempt a dictionary attack (a type of brute-force attack where commonly used passwords are attempted; in practice, people choose fairly predictable passwords so such attacks often succeed quickly). Dictionary attacks can be made vastly more difficult if the key derivation process is made more computationally expensive. While this may not matter so much for large files (where the time to perform the decryption will dominate the total time required for the attack), it could matter very much for small ones. The typical approach here is to use a function such as PBKDF2 (Password-Based Key Derivation Function) with a large number of iterations (in native code, values of 20000-50000 are not uncommon; tune this value to avoid an undesirably long delay) although other "slow" KDFs exist.
4) There's no mechanism in place to determine whether or not the file was tampered with. It is often possible to modify encrypted data, without knowing the exact contents, in such a way that the data decrypts "successfully" but to the wrong output. In some cases, an attacker can even control enough of the output to achieve some goal, such as compromising a program that parses the file. While the use of PKCS7 padding usually makes naïve tampering detectable (because the padding bytes will be incorrect), it is not a safe guarantee. For example, a message of 7 bytes (or 15 or 23 or 31 or any other multiple of 8 + 7) will have only 1 byte of padding; thus there is about a 0.4% (1 / 256) chance that even a random change to the ciphertext will produce a valid padding. To combat this, use an HMAC (Hash-based Message Authentication Code) and verify it before attempting decryption. Without knowing the key, the attacker will be unable to correct the HMAC after modifying the ciphertext. See http://en.wikipedia.org/wiki/HMAC
5) The same problem as 4, but from a different angle: there's no way to be sure that the correct key was entered. In the case of an incorrect key, the plaintext will almost certainly be wrong... but it is possible that the padding byte(s) will be correct anyhow. With a binary file, it may not be possible to distinguish a correct decryption from an incorrect one. The solution (an HMAC) is the same, as the odds of an HMAC collision (especially if a good hash function is used) are infinitesimal.
6) Passwords are relatively weak and often easily guessed. Keyfiles (binary keys generated from cryptographically strong random number generators and stored in a file - possibly on a flashdrive - rather than in your head) are more secure, assuming you can generate them. It is even possible to encrypt the keyfile itself with a password, which is a form of two-factor authentication: to decrypt the data that an attacker wants to get at, they need the keyfile (a thing you have) and its password (a thing you know). Adding support for loading and using keyfiles, and possibly generating them too, would be a good feature.
The solutions to 3-5 will break backward compatibility, and will also break compatibility with the default parameters for openssl's "enc" operation. This is not a bad thing; backward compatibility can be maintained by either keeping the old version around or adding a decrypt-version selector, and openssl's defaults for many things are bad (it is possible, and wise, to override the defaults with more secure options). For forward compatibility, some version metadata could be prepended to the ciphertext (or appended to the file name, perhaps as an additional extension) to allow you to make changes in the future, and allow the encryption software to select the correct algorithms and parameters for a given file automatically.
Wow thanks GDTD that's great feedback
Not sure about his minified sources, the unminified aes.js in components is smaller than the minified version (which I am using) in rollups. I'll have to look into what his process for 'rollup' is to see if I can derive a functional set of non-minified script includes. If I can do that it would be easier to replace (what I would guess is) his reliance on Math.random.
His source here mirrors the unminified files in components folder : https://code.google.com/p/crypto-js/source/browse/tags/3.1.2/src
msCrypto that would be great, I had no idea that was in there. I found a few (Microsoft) samples so I will have to test them out and see if I can completely substitute that for crypto.js. Would be more keeping in line with the name I came up with.
Currently this version only works for text files, I am using the FileAPI method reader.readAsText(). I have been trying to devise a solution for binary files utilizing reader.readAsArrayBuffer but as yet I haven't been able to convert or pass this to crypto.js. I will need to experiment more with base64 or other interim buffer formats (which Crypto.js or msCrypto can work with) until I can get a better understanding of it.
Metadata is a great idea, maybe i can accommodate that with a hex encoded interim format.
You seem extremely knowledgeable in the area of encryption, hopefully i can refine the approach to address some of the issues you raised by setting up proper key, salt, and IV configuration... I'm sure I will understand more of your post as i progress (and after reading it about 20 times more as a reference).
Too bad we don't a web server for RT, that would at least open up localStorage for json serialization (mostly for other apps I had in mind). I guess they might not allow that in app store though. Could probably run one of a developers license though (renewed every 1-2 months)?
nazoraios said:
Too bad we don't a web server for RT, that would at least open up localStorage for json serialization (mostly for other apps I had in mind). I guess they might not allow that in app store though. Could probably run one of a developers license though (renewed every 1-2 months)?
Click to expand...
Click to collapse
I cant comment too much on the encryption, GoodDayToDie has covered anything I could contribute and more. But there is a functioning web server on RT. Apache 2.0 was ported: http://forum.xda-developers.com/showthread.php?t=2408106 I dont know if everything is working on it, I dont own an RT device and last time I tried I couldnt get apache to run on 64 bit windows 8 anyway (needed it at uni, spent hours going through troubleshooting guides and it never worked on my laptop, gave up and ran it under linux in virtualbox where it took 2 minutes to have functioning the way I needed it to).
Curious about the performance. Speaking of encryption, 7-Zip has it built-in, and from the discuss in StackExchange, it seems pretty good.
One of the neat things about this thing (local web app? Pseudo-HTA (HTml Application)? Not sure if there's a proper name for such things) is that it runs just fine even on non-jailbroken devices. That's a significant advantage, at least for now.
Running a web server should be easy enough. I wrote one for WP8 (which has a subset of the allowed APIs for WinRT) and while the app *I* use it in won't be allowed in the store, other developers have taken the HTTP server component (I open-sourced it) and packaged it in other apps which have been allowed just fine. With that said, there are of course already file crypto utilities in the store anyhow... but they're "Modern" apps so you might want to develop such a server anyhow so you can use it from a desktop web browser instead.
Web cryptography (window.crypto / window.msCrypto) is brand new; it's not even close to standardization yet. I'm actually kind of shocked MS implemented it already, even if they put it in a different name. It's pretty great, though; for a long time, things like secure random numbers have required plugins (Flash/Java/Silverlight/whatever). Still, bear in mind that (as it's still far from standardized), the API might change over time.
Yep, I think of them as Trident apps since trident is what Microsoft calls their IE rendering engine, but I guess they are sort of offline web apps (which come from null domain). Being from null domain you are not allowed to use localstorage which is domain specific. You also are not allowed to make ajax requests. You just have file api and json object serialization to make do with I/O.
Another app I am working on is a kind of Fiddler app similar to http://jsfiddle.net/ where you can sandbox some simple script programs.
Kind of turning an RT device into a modern/retro version of a commodore 64 or other on-device development environments. Instead of basic interpreter you've got your html markup and script.
I have an attached demo version which makes available jquery, jquery-ui, alertify javascript libraries in a sandbox environment that you can save as .prg files.
I put a few sample programs in the samples subfolder. Some of the animation samples (like solar system) set up timers which may persist even after cleared so you might need to reload the page to clear those.
It takes a while to extract (lots of little files for all the libraries) but once it extracts you can run the html page and I included a sample program 'Demo Fiddle.prg' you can load and run to get an idea.
I added syntax highlighting editors (EditArea) which seems to work ok and let's you zoom each editor full screen.
The idea would be to take the best third party javascript libraries and make them available and even make shortcuts or minimal API for making it easier to use them. Common global variable, global helper methods, ide manipulation. I'd like to include jqplot for charting graphs, maybe for mathematical programs and provide api for user to do their own I/O within the environment.
These are just rough initial demos, and obviously open source so if anyone wants to take the ideas and run with them i'd be interested in seeing what others do. Otherwise I will slowly evolve the demos and release when there are significant changes.
.
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.