This thread is for FlashCast image developers ONLY. If you are not developing a FlashCast image, please do not post here. Post in the main thread instead.
Hello developers! I hope that this thread can serve as a place for you to ask any questions you may have about FlashCast development or internals, make feature requests, and report issues you're having. I will edit this post with FAQs as they come up. Until then, take a look at my documentation on GitHub, which contains documentation and sample code to help you create FlashCast mods.
tchebb said:
This thread is for FlashCast image developers ONLY. If you are not developing a FlashCast image, please do not post here. Post in the main thread instead.
Hello developers! I hope that this thread can serve as a place for you to ask any questions you may have about FlashCast development or internals, make feature requests, and report issues you're having. I will edit this post with FAQs as they come up. Until then, take a look at my flashcast-samples repository on GitHub, which contains documentation and sample code to help you create FlashCast mods.
Click to expand...
Click to collapse
So far its working great! Plan on releasing a rooted 13300 system image with this soon, but I was wondering, is there a possibility you could create a partition backup option? so like
Code:
backup_mtd_partition 'rootfs' 'system.img'
Where it will make a folder called backup on the jump drive, and store the rootfs file system with the name of system.img? also a md5 for each file would be nice. I know I could just have a script dd the mount point, but would be nice to see a function to call.
ddggttff3 said:
So far its working great! Plan on releasing a rooted 13300 system image with this soon, but I was wondering, is there a possibility you could create a partition backup option? so like
Code:
backup_mtd_partition 'rootfs' 'system.img'
Where it will make a folder called backup on the SD card, and store the rootfs file system with the name of system.img? also a md5 for each file would be nice. I know I could just have a script dd the mount point, but would be nice to see a function to call.
Click to expand...
Click to collapse
This would definitely be a useful feature. I can see a few implementation details that would need to be worked out in a non-obvious fashion, though:
There is currently no way for a imager script to directly access the root of the user partition. This is intended to prevent multiple scripts from having access to the same filesystem and possibly overwriting each others' files. Instead, scripts are executed in a temporary directory whose contents are discarded on device shutdown. It seems like the solution to this would be to create numbered backup directories, like there are numbered logs now, for mods to place their backups in.
It wouldn't be desirable for a mod to take a backup every time it was flashed, as not everyone cares about backups and they take up lots of space. There would need to be some way for the user to decide whether or not they wanted backups. Maybe another flag file?
Finally, taking a backup of an MTD partition using nanddump (dd should not be used to image NAND partitions, since it is not bad-block aware) images the entire partition, when (in the case of squashfs) only a small part actually has a filesystem on it. This means that a single rootfs backup will take up 400MB on the USB drive. I would want to implement something which can back up only the part of a partition which squashfs is using before I release backup functionality.
Obviously, this is a prime candidate for a new helper function, because of these non-trivial complications. I'll see if I can make the necessary changes to FlashCast and release backup functionality as part of v1.1. Thanks for the suggestion!
One more suggestion, if you do not mind.
How about the ability to flash multiple zips at once? So, if I have 2 files I want to flash, first one will stay eureka_image.zip, and then the next one would be eureka_image1.zip, or some similar process to allow multiple zips.
The issue here would be a naming scheme that would be easy for users to use and understand. so maybe if you flash a single file, just use eureka_image.zip, and if multiple, each would have a number added, starting from 1 and counting up in the order you want them flashed?
ddggttff3 said:
One more suggestion, if you do not mind.
How about the ability to flash multiple zips at once? So, if I have 2 files I want to flash, first one will stay eureka_image.zip, and then the next one would be eureka_image1.zip, or some similar process to allow multiple zips.
The issue here would be a naming scheme that would be easy for users to use and understand. so maybe if you flash a single file, just use eureka_image.zip, and if multiple, each would have a number added, starting from 1 and counting up in the order you want them flashed?
Click to expand...
Click to collapse
This is something I intend to implement. My current plan is to support a eureka_images directory, which can contain any combination of zipped and unzipped mods which will be flashed in alphabetical order. Mod authors can distribute their mods with a prefixed number, so, for example, you could distribute 00_13300_rooted.zip and 59_unlocator_dns.zip. I'll write a standard for how to determine the numbers (e.g. full system images get 00-09, major/minor filesystem changes get 40-49/50-59 respectively depending on how many files they affect, etc). It's not perfect and there can still be conflicts, but it should allow most mods to be flashed in a mostly sane order. I'm open to any suggestions or improvements you might have.
tchebb said:
This is something I intend to implement. My current plan is to support a eureka_images directory, which can contain any combination of zipped and unzipped mods which will be flashed in alphabetical order. Mod authors can distribute their mods with a prefixed number, so, for example, you could distribute 00_13300_rooted.zip and 59_unlocator_dns.zip. I'll write a standard for how to determine the numbers (e.g. full system images get 00-09, major/minor filesystem changes get 40-49/50-59 respectively depending on how many files they affect, etc). It's not perfect and there can still be conflicts, but it should allow most mods to be flashed in a mostly sane order. I'm open to any suggestions or improvements you might have.
Click to expand...
Click to collapse
Sounds great to me! Only other suggestion I have is to add another flag file which would allow Flashcast to continue flashing the multiple zips, even if one errors out.
So, by default if multiple zips are going to be flashed, and it errors on the first, it would stop, get a red LED, and then reboot.
with a flag file present, maybe ignore_errors, even if it errors out on the first zip, it would continue down the chain of zips until it finishes all of them.
Anyone got any idea how to get started with some themes for the chromecast? Will be more than happy to help, as soon i know where to start.
bormeth said:
Anyone got any idea how to get started with some themes for the chromecast? Will be more than happy to help, as soon i know where to start.
Click to expand...
Click to collapse
Most of the resources seem to be kept in the .pak files contained in /chrome. The first step to theming would be figuring out what format those are in and how to unpack and repack them. You might want to start by taking a look at the content_shell source code, as it might have some documentation or scripts for working with .pak files.
tchebb said:
Most of the resources seem to be kept in the .pak files contained in /chrome. The first step to theming would be figuring out what format those are in and how to unpack and repack them. You might want to start by taking a look at the content_shell source code, as it might have some documentation or scripts for working with .pak files.
Click to expand...
Click to collapse
Im gonna dive into it
Have a little bug report.
If a person has more then 85~MB in their eureka_image folder, and then they start a SquashFS File system edit, flashcast will report an error saying out of space. Now, here is the error part. Even though it failed to mount with an error, the imager.sh file will continue to run, and will then attempt to flash back a corrupt file, causing a non-bootable chromecast until the system partition is re-flashed.
bormeth said:
Anyone got any idea how to get started with some themes for the chromecast? Will be more than happy to help, as soon i know where to start.
Click to expand...
Click to collapse
The first script on THIS SITE will unpack the .PAK files, although it unpacks everything as a .png as it was made for a different Chromium device. So you would have to manually go rename all the files to their correct extension for the files, but because it expects everything to be a .png it won't pack back properly. The second script, technically should unpack/pack as proper file extensions, but I never got it to work right as I have little to no knowledge of Python.
The chromium source has a script,data_pack.py (which I can't link to since I'm a new user ATM) which can be used to pack and unpack .PAK files. The script posted above seems to be lifted from this source and modified to detect a few filetypes and write the unpacked files. But if you want to modify or add images and need to repack them, this script will help you figure it out. I'll work on adding and making some changes to the theme and give some instructions.
how to mount usb drive
Haven't used linux in years. Thanks!
Hey, want to do some poking around in the flashcast .bin file...how do I go about doing that? What is the file format, and is the image mountable in linux? Even better might be to extract files/folders from the image...what tool can I use to do that?
Ok, so I'm doing some dinking around...I've looked into buildroot, and I think for the most part I understand what is going on. I also tried building from source, and it appears to have worked. So, from this poking around I have a few assumptions I've made and a few questions. Correct me if I'm wrong anywhere but.......
Basically, you've built a generic bootloader for the device using buildroot. This is not related at all to the stock CC bootloader (although maybe you borrowed a few drivers, etc). I would guess that the buildroot bootloader has just what you need to display a picture on the TV and do some basic file system operations, and I would also guess that the buildroot bootloader is missing a few features that the stock bootloader has - therefore, it wouldn't be possible to run a full-fledged ROM off of this bootloader. Am I right so far? If so, what is missing from the buildroot bootloader? Libraries? Binaries? No idea?
Also, to access something like USB storage, the buildroot bootloader is able to include the required /dev devices, whereas it wouldn't be possible to include this on CC's stock bootloader without the source. So, doing something like accessing a ROM from an external flash drive isn't feasible because of these limitations? Basically, all that is possible with the current bootloader (of course, the insecure one which allows for unsigned code to run) is to add a few binaries to the stock CC ROM (things like adb, dropbear, etc), maybe add some access to those binaries through Web GUI, etc.
Am I on the right track? Is there anything you would add/correct? Thanks for the help. I'm trying to understand
tomg09 said:
Ok, so I'm doing some dinking around...I've looked into buildroot, and I think for the most part I understand what is going on. I also tried building from source, and it appears to have worked. So, from this poking around I have a few assumptions I've made and a few questions. Correct me if I'm wrong anywhere but.......
Basically, you've built a generic bootloader for the device using buildroot. This is not related at all to the stock CC bootloader (although maybe you borrowed a few drivers, etc). I would guess that the buildroot bootloader has just what you need to display a picture on the TV and do some basic file system operations, and I would also guess that the buildroot bootloader is missing a few features that the stock bootloader has - therefore, it wouldn't be possible to run a full-fledged ROM off of this bootloader. Am I right so far? If so, what is missing from the buildroot bootloader? Libraries? Binaries? No idea?
Also, to access something like USB storage, the buildroot bootloader is able to include the required /dev devices, whereas it wouldn't be possible to include this on CC's stock bootloader without the source. So, doing something like accessing a ROM from an external flash drive isn't feasible because of these limitations? Basically, all that is possible with the current bootloader (of course, the insecure one which allows for unsigned code to run) is to add a few binaries to the stock CC ROM (things like adb, dropbear, etc), maybe add some access to those binaries through Web GUI, etc.
Am I on the right track? Is there anything you would add/correct? Thanks for the help. I'm trying to understand
Click to expand...
Click to collapse
Buildroot does not let us build a bootloader, it lets us build a custom linux distribution that runs on the chromecast. The reason it is unable to do anything "graphical" minus the static image is due to licensing of the marvell GPU driver the chromecast uses. It is currently closed source, so it is unable to be compiled. We can use the blob from the stock OS, but ATM there is no need, and this can cause licensing issues.
Also, you can still access /dev and such on the stock OS. The big thing is the stock OS has usb input disabled at a kernel level, so it doesn't mount or detect any devices plugged in when the OS is running. This is circumvented though if you build and use your own custom kernel. For the features Eureka-ROM adds to the stock OS, we add those by using googles open source cross compiler for the device to build supported binaries.
Hmm...interesting. So, if I understand the booting process properly, upon power-on, a small bit of code called the bootloader is run, loading the kernel into memory (where, among other things, the graphics driver is located). From there, other components of the operating system are loaded on "top" of the kernel. So, it's not the bootloader that's rebuilt - but the kernel - with buildroot. Now, what sort of things would be possible if an open source alternative for the graphics driver were available (bear with me in the hypothetical), or even if one were to take the blob from the stock CC kernel? Turn CC into an android stick, complete with USB input device compatibility maybe?
Now on another note. I want to learn about cross-compiling. I am thinking of trying my hand at cross-compiling samba for the chromecast. Now if I understand the buildroot compiling process correctly, the right compiler for making chromecast-runnable binaries is compiled (or do you include it externally), and in theory, it should be possible to compile samba, right? I've been poking around the buildroot directory tree with the chromecast source superimposed over the top, and as of yet, I havent found the compiling binary (gcc, maybe?). I will look in a bit more depth. Once I find this, it should be as simple as specifying host and target architecture, putting the compiler for the CC in PATH, and compiling, right?
Thanks again for your help, and if you feel this isn't the appropriate place to post this, let me know.
tomg09 said:
Hmm...interesting. So, if I understand the booting process properly, upon power-on, a small bit of code called the bootloader is run, loading the kernel into memory (where, among other things, the graphics driver is located). From there, other components of the operating system are loaded on "top" of the kernel. So, it's not the bootloader that's rebuilt - but the kernel - with buildroot. Now, what sort of things would be possible if an open source alternative for the graphics driver were available (bear with me in the hypothetical), or even if one were to take the blob from the stock CC kernel? Turn CC into an android stick, complete with USB input device compatibility maybe?
Now on another note. I want to learn about cross-compiling. I am thinking of trying my hand at cross-compiling samba for the chromecast. Now if I understand the buildroot compiling process correctly, the right compiler for making chromecast-runnable binaries is compiled (or do you include it externally), and in theory, it should be possible to compile samba, right? I've been poking around the buildroot directory tree with the chromecast source superimposed over the top, and as of yet, I haven't found the compiling binary (gcc, maybe?). I will look in a bit more depth. Once I find this, it should be as simple as specifying host and target architecture, putting the compiler for the CC in PATH, and compiling, right?
Thanks again for your help, and if you feel this isn't the appropriate place to post this, let me know.
Click to expand...
Click to collapse
If we had a fully working open source graphics driver, lots could be accomplished. Full custom linux distributions could run x11 shells, we could have xbmc working with hardware decoding, and yes android would technically be possible if enough people wanted to put the time and effort into it. You can take the blob from the rom to do some of this, but things like hardware accelerated decoding will still not be possible due to the fact there is no documentation on how to use the blobs properly for things like that. (this is my understanding so I may be off on some small details, @tchebb can probably explain it more in depth.)
As for cross compiling, you just need to use googles prebuilt toolchain as the compile source.
Link: https://code.google.com/p/chromecast-mirrored-source/source/browse?repo=prebuilt
Mind if I ask why you want to compile samba? do you want to host media or files from a chromecast device? I actually have CIFS added to the eureka-kernel configs on our repo, so if you compile our kernel from source, you can mount samba shares on the chromecast device using the CLI.
ddggttff3 said:
As for cross compiling, you just need to use googles prebuilt toolchain as the compile source.
Link: https://code.google.com/p/chromecast-mirrored-source/source/browse?repo=prebuilt
Mind if I ask why you want to compile samba? do you want to host media or files from a chromecast device? I actually have CIFS added to the eureka-kernel configs on our repo, so if you compile our kernel from source, you can mount samba shares on the chromecast device using the CLI.
Click to expand...
Click to collapse
Cool. Thanks for the link. Basically, I'm just looking to learn about cross compiling for mobile devices. I figure samba seems easy enough. It was the first thing that came to mind. Any other ideas for something to cut my teeth on? Other binaries that would be well suited to CC, but are easy to compile?
tomg09 said:
Cool. Thanks for the link. Basically, I'm just looking to learn about cross compiling for mobile devices. I figure samba seems easy enough. It was the first thing that came to mind. Any other ideas for something to cut my teeth on? Other binaries that would be well suited to CC, but are easy to compile?
Click to expand...
Click to collapse
One more question...I've looked through the toolchain...the way it's set up is somewhat confusing. In the root directory of the toolchain: bin=gcc, g++, everything else I need to compile. What are the two folders entitled "arm-unknown-linux-gnueabi" and "target-arm-unknown-linux-gnueabi"? They seem to have relevant stuff (one has gcc, g++, etc except without the arm-unk... prefix, and other binaries which seem important). How do I use these/should I use these/why are they kept separate?
Thanks for the help.
Related
Here is basic program for your windows computer that just does basic stuff.
It can reboot your phone to wherever you want like recovery, bootloader.
It will wipe your ext2/3 from recovery if you choose and it will repair your ext2/3.
This is still beta, so far everything that is on the app works. But when I say beta I mean I still to implement alot more features so just use it and then tell me what you guys want. I am working on implementing switchrom into it.
This is just about 3 hours of work so you will see alot more in the future.
Screenshots Below!
*(For those of you wondering it is writen in a mix of C++,vb.net,python,and MS-DOS)*
Twitter: http://twitter.com/kickfliprock13
** Oh I forgot to mention you need to have adb set up for this to work if you don't have it set up than it wont work. So if you want to set up just go here: http://punk-in.com/driver_vista.html
Continued
Changelog:
9/8/09: Added a link to tell you how to install usb drivers for your phone
Added links to our twitter's and plurk's
Fixed a few small bugs
Continued Again
This is for problems and things I am changing!
Problems:
Can't get it to put arguments into adb commands, for example adb shell sh /system/sd/switchrom -s (then the name they want to name it)
I suck with ShellExecute commands so I need to get better at those
Need to learn how to add .exe's and other files into a C++ file and then run it.
Changing:
I will probably be changing the layout in the next update
I will be learning ShellExecute commands hopefully. So then it can set up adb for you and do a switchrom.sh for you
looks good dling now btw how many programming languages do you know lol
Languages
I know a couple. This program is written in C++. I have only done C++ for about a week so I am still kind of a noob. But other than that I know: html, MS-DOS,Python, I am learning java, I know some C and C#.
I am taking some visual stuff right now, like blender and game development.
After that I want to learn CSS, and learn the reset of java and C++
do you think you can make it that the program can flash the new spl and radio so the phone won't brick. Anyway awesome program
It looks like it's just issuing the non-response ADB commands. Do you have anything there to capture the commandline output from ADB? I'm trying to get the push and pull confirmations for mine. It seems the stream is immedately written as blank and then changed to the confirmation but the change is not rewritten to the stream.
Also ADB does not have to be in a specific directory in order to work. Just change the working direcory of your process to the folder where you have them stored. I bundled the files with mine so I didn't have to worry about if someone didn't have them in the right place.
M..N said:
do you think you can make it that the program can flash the new spl and radio so the phone won't brick. Anyway awesome program
Click to expand...
Click to collapse
Yes, we are working on making that happen very soon. It is difficult but yeah, we already figured out a way to apply new radio,spl and get to hero in about a minute now we just need to implement that into the app but I just can't figure out exactly how to include multiple files in my C++ project but once I figure that out I will tell you.
Excellent thanks very much
Hi so how is this program coming along
Very well I almost have rooting figured out
Cool would this work on uk phones and when is the estimated release time
I have LUMIA 620 dev unlocked via dream spark.
I downloaded XAP file from marketplace and it seams to be encrypted so they are not installing via DEV tools to my device.
But i searched around some apps which can be installed via DEV tool because the are modified and i want to know what are the changes that are need to be made in XAP files:good:
One thing i have noticed that those XAP files which can be installed on device via DEV can be opend via any archive software like winrar etc...
but those XAP that are not able to install on device via DEV cannot be open with any archive software.
prashantvrm said:
One thing i have noticed that those XAP files which can be installed on device via DEV can be opend via any archive software like winrar etc...
but those XAP that are not able to install on device via DEV cannot be open with any archive software.
Click to expand...
Click to collapse
The XAP files from the store are encrypted. Unless someone figures out a way to break the encryption, it cannot be done.
The XAP files you found are probably home-made apps, which can be sideloaded, because they're deployed by developer tools in an unencrypted format, or WP7 apps. The encryption is applied after you submit the XAP to the store.
There is no known workaround to sideload store XAPs without an SD card, at the moment.
TheGoldrocker said:
The XAP files from the store are encrypted. Unless someone figures out a way to break the encryption, it cannot be done.
The XAP files you found are probably home-made apps, which can be sideloaded, because they're deployed by developer tools in an unencrypted format, or WP7 apps. The encryption is applied after you submit the XAP to the store.
There is no known workaround to sideload store XAPs without an SD card, at the moment.
Click to expand...
Click to collapse
You are correct sir. It sucks that you can't even sideload Xaps that were downloaded manually due to the app being removed from the WP store on a non-SD device. I'm trying to see if I can make a workaround for this though. It would be nice if it worked. In terms of modifying the encrypted XAP, it'll be a while before one of us figures out how to decrypt, but at the same time that opens a whole new can of worms regarding to piracy.
I've looked at the encrypted XAPs a bit myself; they're basically a PlayReady wrapper around the ZIP archive (XAPs are just renamed ZIP files; I usually use 7-Zip to open them). Unfortunately, I don't think anybody has broken PlayReady yet. The various programs which claim to strip PlayReady (usually from music or video) all appear to work by running the file through the decoder built into various programs like Zune and Windows Media Player, and re-capturing the content that comes out of the decoder. That won't work for these files.
We might be able to do something similar if we can get the XAP decoder out of the phone ROM and use that, though it will be ARM code (I don't know if the x86 "emulator" image includes the DRM decoder) and therefore somewhat tricky to work with. It will also probably be obfuscated to deter reverse engineering, and may be difficult to make work independently. A kernel debugger on the phone may be needed to figure it out.
GoodDayToDie said:
I've looked at the encrypted XAPs a bit myself; they're basically a PlayReady wrapper around the ZIP archive (XAPs are just renamed ZIP files; I usually use 7-Zip to open them). Unfortunately, I don't think anybody has broken PlayReady yet. The various programs which claim to strip PlayReady (usually from music or video) all appear to work by running the file through the decoder built into various programs like Zune and Windows Media Player, and re-capturing the content that comes out of the decoder. That won't work for these files.
We might be able to do something similar if we can get the XAP decoder out of the phone ROM and use that, though it will be ARM code (I don't know if the x86 "emulator" image includes the DRM decoder) and therefore somewhat tricky to work with. It will also probably be obfuscated to deter reverse engineering, and may be difficult to make work independently. A kernel debugger on the phone may be needed to figure it out.
Click to expand...
Click to collapse
It would be nice to be able to put one on the emulator itself and see what was going on..
I offer up my Programs folder dumped from my Lumia 928 if it is any help. Devs do with it as you will At the very least under common files you will find the xaps installed on my device which do open with 7zip and include the license xml. As far as installing or side loading I did throw a few xaps at the various emulators with mixed results. Have at it guys!!!
http://sdrv.ms/13tlc0F
tonbonz said:
I offer up my Programs folder dumped from my Lumia 928 if it is any help. Devs do with it as you will At the very least under common files you will find the xaps installed on my device which do open with 7zip and include the license xml. As far as installing or side loading I did throw a few xaps at the various emulators with mixed results. Have at it guys!!!
http://sdrv.ms/13tlc0F
Click to expand...
Click to collapse
Xaps within the Programs directory from a ROM are unencrypted. These will help out a lot though!
Edit: Ohhh... Something interesting. CommonFiles\Xaps\SyncUi.xap is the Verizon Backup Assistant. This has some code to intercept SMS..
<Extensions>
<!-- Email & Accounts UX Integration -->
<Extension ExtensionName="Accounts_Extension_Standard" ConsumerID="{47998C28-3D90-11E1-8E07-8B2B4924019B}" TaskID="_default" ExtraFile="Extensions\Extras.xml" />
<Extension ExtensionName="SMS_INTERCEPT_STANDARD" ConsumerID="{55DB4873-5CDF-43B0-82B4-87EB13E9BF6B}" TaskID="SmsInterceptAppExtension" ExtraFile="Extensions\Extras.xml" />
<Extension ExtensionName="Service_Agent_Application" ConsumerID="{208558CC-4407-40F8-83AE-AE3D567126B3}" TaskID="BackgroundTask" />
</Extensions>
snickler said:
Xaps within the Programs directory from a ROM are unencrypted. These will help out a lot though!
Edit: Ohhh... Something interesting. CommonFiles\Xaps\SyncUi.xap is the Verizon Backup Assistant. This has some code to intercept SMS..
<Extensions>
<!-- Email & Accounts UX Integration -->
<Extension ExtensionName="Accounts_Extension_Standard" ConsumerID="{47998C28-3D90-11E1-8E07-8B2B4924019B}" TaskID="_default" ExtraFile="Extensions\Extras.xml" />
<Extension ExtensionName="SMS_INTERCEPT_STANDARD" ConsumerID="{55DB4873-5CDF-43B0-82B4-87EB13E9BF6B}" TaskID="SmsInterceptAppExtension" ExtraFile="Extensions\Extras.xml" />
<Extension ExtensionName="Service_Agent_Application" ConsumerID="{208558CC-4407-40F8-83AE-AE3D567126B3}" TaskID="BackgroundTask" />
</Extensions>
Click to expand...
Click to collapse
I don't like the sound of that The app is part of the settings on my device but when opened says there is a problem with my account and contact Verizon.
@tonbonz: Thanks for the dump! That could be really handy. I'll explore and see if I can find anything useful. Any direct applications will likely be Nokia-specific (which among other things means I can't test them) but lots of people have Nokia phones, and I may find something more generally useful too.
GoodDayToDie said:
@tonbonz: Thanks for the dump! That could be really handy. I'll explore and see if I can find anything useful. Any direct applications will likely be Nokia-specific (which among other things means I can't test them) but lots of people have Nokia phones, and I may find something more generally useful too.
Click to expand...
Click to collapse
I've enjoyed the benefits of all the devs and their hard work here at XDA since my HTC Trophy. Glad to give back in any way I can. If any other files or folders are needed I would be happy to oblige...and... I thank you sir!!!
Oh what the h*** Rest of the dump files currently uploading. Dump 1, three 7z files altogether, is the Programs folder from earlier post. Left out maps data from Data/shared data folder as it was huge and of no consequence as to what we are trying to accomplish. Also, to be clear, this is a dump from the Lumia 928 variant package not my actual device. Have fun!!!
http://sdrv.ms/13tlc0F
@djtonka Thank you for your tutorial on Nokia Care Suite on wimdowsmania.pl.
@AnDim Extra thanks for ImgMount Tool which was used to dump these files!!!
I'll let you know. Just for curiosity's sake, how are you extracting those files? Is it from a working device, or a ROM image?
EDIT: Just saw your message, thanks for the info!
Initial results are a mix of cautious hope, disappointment, and speculation.
1) The OEM apps use a ton of restricted capabilities (among the most tame, for example, is "ID_CAP_MEDIALIB_PHOTO_FULL", which gives direct access to the image folders and has visibility "public" according to the policy XML files from the Windows directory).
2) The OEM apps can be sideloaded, but you have to remove the PlayReady header and all the restricted capabilities. They aren't very exciting at that point; they may not even start up.
3) Speculation: The so-called "public" restricted capabilities require a (Store-?)signed app when used on a standard phone. It *may* be possible to sign the apps ourselves, install that cert on the phone, and then sideload them, but I doubt it.
4) More speculation: These new, high-privilege capabilities seem to have largely replaced ID_CAP_INTEROPSERVICES. Although the error when trying to sideload them on an interop-locked phone is different than it is for INTEROPSERVICES, it may be that an interop-unlock would allow sideloading apps that use those capabilities anyhow.
5) The OEM apps include WPInteropManifest.xml. It's exactly the same near-empty file as on WP7. However, they don't use COM but instead use the same native-CLR interop as the official SDK advocates (.winmd files that bridge managed code to C++ DLLs). Its presence does not impede sideloading.
6) Speculation: The WPInteropManifest may be needed for apps which intend to use the "raw" win32 API (as opposed to WinRT) in C++. This theory is supported by the presence of things like DLLs that read and write to the registry directly (not through a driver, which would need INTEROPSERVICES), using APIs such as RegCreateKeyW.
7) More speculation: Since we can extract the system libraries from our phones, it should be possible to use the DLL-to-LIB tools to create .LIB files (the official WP8 SDK is extremely short on these) that we can then use to link to the native Win32 API. Although we would still be (cripplingly) limited by the sandbox's low permissions, we could probably do things like write a basic registry browser.
8) The provxml commands to install apps are very simple, but I don't understand all the parameters. Nonetheless, whenever we have an app, its license, and a tool which can process AppInstall provxmls, we should be able to install those apps on any reasonably compatible phone.
9) Speculation: Due to the use of OS-based capabilities rather than OEM drivers, an app that is installed on any given phone *should* work on other OEMs' phones even if it accesses the registry or does similarly privileged operations.
10) There may yet be a vulnerable app which we could exploit (possibly by using a provxml-injection attack?) to write to the registry / move files / do similar stuff. However, it would probably have very limited permissions even so; unlike on WP7, most things which can write to *some* of the registry can't write to *most* of it.
INTERESTED IN A BETTER LAGFIX?
Here is a small script which goes a little further than the Lagfix app in the PlayStore. This was originally posted in a different thread dedicated to a ROM so I'm trying to clean this post up as much as possible.
Caution!
A quick word of warning. Take the same safety precautions with this as you would the LagFix app. Both use the same utility which has been found to brick some devices. This was originally written for the VS980 (LG G2) and for a 4.2.2 ROM (fstrim support is native in 4.3+) though it should work fine as long as your device is compatible with the LagFix app (although you may need to tweak a few things)
Prerequisites
To begin with, you'll need a fstrim binary located in one of your device's PATH directories. A safe bet would be to drop it in /system/bin/ or /system/xbin/. Don't forget to change the permissions as well so it can run. If in doubt it's safe to give it full read/write/execute (I vouch for the one I link to at least...)
If you'd like the script to run on boot, then having init.d support on your ROM is ideal. If you don't have native init.d support, search xda as I've seen a "How to Enable init.d on Any Device Even Stock" how to floating around somewhere.
Finally, you'll need the filesystems-fstrim script that's also linked to at the end. The script basically performs three actions. First, it remounts all the filesystems (see note at the end if not on a LG G2) without the 'discard' flag. Since we will be running the fstrim utility on boot (or manually of you desire), having the OS clean up after deleted/moved files on the fly isn't necessary at all and just slows performance down noticeable. After that it attempts to trim each mounted volume oo your device (think defragment), then finally it writes all output to /$ANDROID_USER/logs/ (bytes trimmed from each mount, etc).
This script will trim other mounts besides /system, /cache, and /data. That and the fact that it removes the 'discard' flag is why I wrote it for personal use instead of using the app in the PlayStore (also nice having a record I'm /data/logs as well).
How to Run At Boot
With the fstrim utility in .../bin or .../xbin (with proper permission, and init.d support on your ROM and the 03-filesystems-fstrim script you're ready to go. Drop the 03-filesystems-fstrim script into your init.d directory and set permissions (it's safe to give it full read/write/execute access if unsure) and you're ready to go. Your init.d directory may vary depending on ROM. I'm used to always using /system/etc/init.d, but some ROMS (CyanogenMod for example) uses a different path. Ensure that it runs after any other scripts you may have in init.d which remount the filesystems to ensure that the filesystems aren't remounted elsewhere with the 'discard' flag. You can do this by appending a number to the beginning of the filename that's higher then the others (for example you could rename it 99-filesystem-fstrim and it will run after 01tweaks or whatever might be there already). More information on init.d can be found with a Google search as it's covered everywhere.
Now, at this point on next boot the script should run and if there are logs in /data/logs/ you can read them to determine if it succeeded or not. If successful, you won't see any error messages and on the mounts that were trimmed it will let you know how many bytes off each.
Notes
I wasn't expecting this post to get moved into its own thread and was sharing this to oothers using the same ROM I was. The section of code that remounts all the filesystems is hardcoded, so that section may fail on other devices that have a different structure {and having a filesystem mounted with 'discard' flag kind of defeats the purpose of trimming to begin with ), so you may need to change this section. If editing, use a text editor that allows you to turn word wrap off as for one, it can create nasty messes in the code with strange like breaks/etc and two, it's good habit anyways when dealing with any script or programming language. I used 920 Text Editor which is pretty decent but there are plenty other good ones in the Play Store. Running the 'mount' command with no arguments after it at the command prompt can help you map the filesystem on your device with the corresponding LG G2 one.
Files are currently hosted on my Drive until I find another browser that works or get on a PC. If you already have the fstrim binary you don't need this one..Feel free to PM Amy questions or ask here.
download ~ fstrim binary (rename to 'fstrim' without any extension
download ~ filesystems-fstrim script (again, strip off any extensions in the file name
MidnightHarvester said:
INTERESTED IN A BETTER LAGFIX?
Why would you want to use this (especially if using the LagFix in the PlayStore)? Good question!
Optimized Filesystem Mounts
If you use the lagfix app off the PlayStore (or any script/app/utility/etc that uses fstrim) then mounting the filesytems with the 'discard' option is not only redundant, but also gives a performance penalty since with 'discard', the file index AND OS are both made aware immediately when memory is free up to enable garbage collection. This sounds fine, except that doing this on the fly like this also slows things down a lot. Since we will he using fstrim ourselves we don't need this extra overhead. In the script is a good link to read that explains things better than I can.
More Thorough!
Every other method I've seen so far only trims /system, /data, and /cache. There are many other mounts that can be trimmed, and some are written to quite frequently (/persist as an example).
Maintains Lots of All Activity
All activity is logged and sent to $ANDROID_DATA/logs/ where it's then saved. That way you can tell if it's running on boot or on the schedule as it's supposed to he running.
OK well, there's not a lot going on here, just felt like being overly dramatic as it's boring over here at the moment. All of the above is true, and after deciding to post it in here I cleaned it up quite a bit so even the most novice at BASH (any language really) can understand what's going on and change it to suit your needs.
A few things to point out. You WILL need to have the fstrim binary located somewhere in one of your environment paths. A good spot for it is always /system/bin or /system/xbin of you are having trouble deciding where You will probably want to also ensure that the fstrim binary has the correct permissions. If you are unsure of what those are, just give it all read/write/execute.
Second, you will need the script and figure how out how you'll be using it. You need to keep in mind that in the /system/init.d/ directory there is a script there called 03filesystem (something like that) which also mounts the fileaystems. If you like, you can move that script to you sdcard (don't keep it in init.d though or it'll be run..I don't know if having a .bak file extension will stop it as I've never tried) and copy this script over. This script's mounts are EXACTLY the same (even includes the break lease at the end) as what Jake uses as default except without the 'discard' flag. Replacing the default 03filesystems with this one is a perfect place to run the script if you reboot your phone at least once every few days (can always run it manually as well if needed). If you leave Jake's in and still use this, then ensure this one is named appropriately so that it runs after his does, or his script will remount the filesystems again with 'discard'.
There are plenty of explanations in the script as well. Point is, just he aware that of it runs before Jake's filesystem mounts do his will overwrite this one's and you'll lose the advantage of trimming on startup (or a schedule).
Check the /data/logs/ directory for output from the script, and be sure to also give this script the correct permissions as well. If in doubt just give it all read/write/execute permissions (well that's what I've been using on both this and the fstrim binary. I've linked both of the files below. I couldn't upload as an attachment so I uploaded to my Drive. Enjoy.
Edit: This was written for and intended for the VS980 (Verizon G2). Other G2s should he perfectly fine and any device that is compatible to run LagFix off the Play Store (you don't need to use LagFix either BTW if using this). Just be sure that you device is on the compatible list before using, otherwise there is a possibility of bricking your device. If using a G2 you're fine, but I never know who else reads these threads.
download ~ fstrim binary
download ~ filesystems-fstrim script
Sorry everyone, I posted this late last night and didn't realize that the directory I uploaded the files to was private. The links should work now as I've set them to be Public.
If you have any questions, feel free to PM me.
Click to expand...
Click to collapse
Can someone chime in on what he's talking about in this very long winded post.
Sent from my VS980 4G using Tapatalk
friguy3 said:
Can someone chime in on what he's talking about in this very long winded post.
Sent from my VS980 4G using Tapatalk
Click to expand...
Click to collapse
If you can't be bothered to read it, it's probably not for you.
Dearborn1977 said:
If you can't be bothered to read it, it's probably not for you.
Click to expand...
Click to collapse
I did read it thank you very much sir. But, not all of us are devs or in the tech industry and understand this. Someone posts something, sometimes its nice to have others chime in or get a more simplified explanation. He posted it last night and nobody really commented on it (one maybe?)....makes you be cautious.
Sent from my VS980 4G using Tapatalk
The information is useful and should be in a thread of its own or maybe okibi can incorporate in 1.2.3
VS980 4G
friguy3 said:
Can someone chime in on what he's talking about in this very long winded post.
Sent from my VS980 4G using Tapatalk
Click to expand...
Click to collapse
It's a utility for trimming (defrafmenting) certain filesystems. This is built into 4.3+ and tries to run at least once every day or two, but we don't have it on 4.2.2 ROMs. The fstrim file is the binary that can run at the command prompt -
Code:
# usage
# fstrim [-v] {/mount-to-trim} // -v flag runs fstrim and sends output to stdout
#
# Example for trimming /data
fstrim -v "/data"
So fstrim goes into /system/bin or /system/xbin (set the permissions correctly so it can run. The other file is a script that I use to replace the /system/etc/init.d/03filesystems file that runs at boot that's included with the ROM (its named something like that, can't check at the moment). First it remounts all the filesystems just like the one in ROM does except they are mounted without 'discard' since we are trimming and don't need it. Then the script runs fstrim on all mounted volumes that it can run on and logs output to /$ANDROID_DATA/logs (/data/logs). Need to be sure to give this script the correct permmisions as well.
There's an app in the PlayStore that does the same thing except it doesn't tell all the filesystems or remount all your filesystems without the 'discard' flag which is really easy to use. This is just a more thorough method of trimming what that app doesn't and optimizing your mounts accordingly to take advantage of it (using trim on filesystems with 'discard' is redundant and using 'discard' slows performance down as the OS notifies in real time what files in the file index have been deleted/moved..
---------- Post added at 05:04 PM ---------- Previous post was at 05:01 PM ----------
smacklayer said:
What does this have to do with this ROM/Thread?
Click to expand...
Click to collapse
Well, it is meant (as is) to replace the 03filesystems script in the /system/etc/init.d folder. Or it can be noticed and set to run on a schedule. It was to written on a vs980 running this ROM, so that's where I'm sharing it.
Will the script trim on its own?
VS980 4G
veloct said:
The information is useful and should be in a thread of its own or maybe okibi can incorporate in 1.2.3
VS980 4G
Click to expand...
Click to collapse
Hopefully soon we won't have to worry about it since it's built into 4.3+. I might post it in the G2 (all) development area later this evening if it proves helpful to anyone.
This should really be the Themes and App thread not in a Rom thread.
Link to where it should be below.
http://forum.xda-developers.com/lg-g2/themes-apps
MidnightHarvester said:
INTERESTED IN A BETTER LAGFIX?
Why would you want to use this (especially if using the LagFix in the PlayStore)? Good question!
Optimized Filesystem Mounts
If you use the lagfix app off the PlayStore (or any script/app/utility/etc that uses fstrim) then mounting the filesytems with the 'discard' option is not only redundant, but also gives a performance penalty since with 'discard', the file index AND OS are both made aware immediately when memory is free up to enable garbage collection. This sounds fine, except that doing this on the fly like this also slows things down a lot. Since we will he using fstrim ourselves we don't need this extra overhead. In the script is a good link to read that explains things better than I can.
More Thorough!
Every other method I've seen so far only trims /system, /data, and /cache. There are many other mounts that can be trimmed, and some are written to quite frequently (/persist as an example).
Maintains Lots of All Activity
All activity is logged and sent to $ANDROID_DATA/logs/ where it's then saved. That way you can tell if it's running on boot or on the schedule as it's supposed to he running.
OK well, there's not a lot going on here, just felt like being overly dramatic as it's boring over here at the moment. All of the above is true, and after deciding to post it in here I cleaned it up quite a bit so even the most novice at BASH (any language really) can understand what's going on and change it to suit your needs.
A few things to point out. You WILL need to have the fstrim binary located somewhere in one of your environment paths. A good spot for it is always /system/bin or /system/xbin of you are having trouble deciding where You will probably want to also ensure that the fstrim binary has the correct permissions. If you are unsure of what those are, just give it all read/write/execute.
Second, you will need the script and figure how out how you'll be using it. You need to keep in mind that in the /system/init.d/ directory there is a script there called 03filesystem (something like that) which also mounts the fileaystems. If you like, you can move that script to you sdcard (don't keep it in init.d though or it'll be run..I don't know if having a .bak file extension will stop it as I've never tried) and copy this script over. This script's mounts are EXACTLY the same (even includes the break lease at the end) as what Jake uses as default except without the 'discard' flag. Replacing the default 03filesystems with this one is a perfect place to run the script if you reboot your phone at least once every few days (can always run it manually as well if needed). If you leave Jake's in and still use this, then ensure this one is named appropriately so that it runs after his does, or his script will remount the filesystems again with 'discard'.
There are plenty of explanations in the script as well. Point is, just he aware that of it runs before Jake's filesystem mounts do his will overwrite this one's and you'll lose the advantage of trimming on startup (or a schedule).
Check the /data/logs/ directory for output from the script, and be sure to also give this script the correct permissions as well. If in doubt just give it all read/write/execute permissions (well that's what I've been using on both this and the fstrim binary. I've linked both of the files below. I couldn't upload as an attachment so I uploaded to my Drive. Enjoy.
Edit: This was written for and intended for the VS980 (Verizon G2). Other G2s should he perfectly fine and any device that is compatible to run LagFix off the Play Store (you don't need to use LagFix either BTW if using this). Just be sure that you device is on the compatible list before using, otherwise there is a possibility of bricking your device. If using a G2 you're fine, but I never know who else reads these threads.
download ~ fstrim binary
download ~ filesystems-fstrim script
Sorry everyone, I posted this late last night and didn't realize that the directory I uploaded the files to was private. The links should work now as I've set them to be Public.
If you have any questions, feel free to PM me.
Click to expand...
Click to collapse
veloct said:
Will the script trim on its own?
VS980 4G
Click to expand...
Click to collapse
The script needs the fstrim binary, which you can grab elsewhere if worried about this one. I also went in and made the script as readable as I could. Without the fstrim binary, all this script does is remount all the filesystems without the 'discard' flag. If you are using the LagFix app then that's still useful as we don't need discard if manually trimming.
---------- Post added at 05:27 PM ---------- Previous post was at 05:14 PM ----------
Jimi Mack said:
This should really be the Themes and App thread not in a Rom thread.
Link to where it should be below.
http://forum.xda-developers.com/lg-g2/themes-apps
Click to expand...
Click to collapse
I need to clean it up in a proper text editor first before sharing to everybody. The built in text editor is not to useful when scripting because of the screen sizes and blocks of text often become mangled (especially in the comment). I'm going through it now and reediting with the proper text encoding. Won't take long but in the meantime I need to fix the encoding. I added the commenting in last night using the built in editor with Root Explorer which .. Well .. not too useful lol.
Once I'm sure the encoding will work across the board I'll post in that forum.
friguy3 said:
I did read it thank you very much sir. But, not all of us are devs or in the tech industry and understand this. Someone posts something, sometimes its nice to have others chime in or get a more simplified explanation. He posted it last night and nobody really commented on it (one maybe?)....makes you be cautious.
Sent from my VS980 4G using Tapatalk
Click to expand...
Click to collapse
I didn't mean to sound like a jerk, was just trying to say that given this mod has you replacing a script and adding a binary, if it's over your head I wouldn't mess with it.
Dearborn1977 said:
I didn't mean to sound like a jerk, was just trying to say that given this mod has you replacing a script and adding a binary, if it's over your head I wouldn't mess with it.
Click to expand...
Click to collapse
Went in and cleaned the formatting up using 920,l text editor and updated the original post I made with the updated link. If downloading, use the links on my posts and not any of the links from the quotes. If editing, it's best to use an editor that doesn't have word wrap enabled or at least an option to turn it off. That applies to any type of scripting or programming language. Otherwise, be careful that commented text doesn't get cut and interpreted code.
Anyways, he's right. If something looks like a foreign language to youz be sure to study up on it or bring along a good translator/guide before going to visit for a while. There's nothing complicated going on but the terminology obscufcates even the simplest of sentences. See? Malladus doesn't (I should say stock 4.2.2) doesn't include fstrim, a feature that's in 4.3+. You won't replacing any binaries unless you've already added fstrim yourself, in which case all you'd need is the script.
I think this is definitely a useful post for those interested, but has anyone actually verified that running fstrim on the G2 is 100% safe from the EMMC corruption issues that had plagued other devices in the past? Downloading Lagfix wouldn't be a good test as that program hasn't been updated since long before the G2 release (March 2013).
Just reporting back, I'm generally dubious of mods promising to smooth out the ui and have found things like entropy seeders to be more trouble than they're worth, but this mod works, plain and simple. Not that the G2 needs much smoothing out but if you've ever tried a CM based ROM on the G2, you can tell stock based ROMs aren't as smooth.
I was under the impression fstrim was only useful on older hardware.
Sent from my VS980 4G using Tapatalk
soapinmouth said:
I was under the impression fstrim was only useful on older hardware.
Sent from my VS980 4G using Tapatalk
Click to expand...
Click to collapse
The fstrim utility is built into Android 4.3/4.4 ROMs by way of baking it in the vold deamon. For more information you can read this page. Basically it's responsible for mounting the /system and /data, ... on start and running the init startup stuff (init.rc for example). They use analgorithm for fstrim as to attempt to have it run at least once every 24-48 hours.
On 4.2.2 we don't have fstrim and instead volumes are mounted so that the OS and disk are both kept up to date on which blocks of memory are free and that can be used. Doing this on the fly slows down performance, and that's why I remount the volumes without that option at the beginning of the script, so we can take advantage of the performance gains and run fstrim ourselves on all volumes (ffilesystem's that are able to be trimmed at least...if the file system doesn't support it then it won't be trimmed).
By placing this script in our init.d folder we can run keep our volumes 'defragmented' without having that extra process run all the time (simple way of pitting it). It should run at least once every 5 days or so at the least. Fstrim is relevent for ext4 volumes (and a handful of other types) and therefore relevant to any device where all filesystem layers support it. One other advantage of fstrim is that it returns a value whereby setting the 'discard' does not. If you run fstrim in verbose more or assign the result to a variable and it returns either "0 bytes were trimmed..." or "xxxx bytes were trimmed..." then you know it's supported and relevant. You can also check your mounts by typing 'mount' at a command prompt. There you can check and see if your filesystems are using discard or not.
Devices that mount their filesystems without discard and without the fstrim utility eventually can and will become intolerably slow or usable due to a process called "write amplification". Eventually it will become hard for the disk to find blocks of memory to erase. Only empty blocks of memory can be deleted. When writing to memory, the smallest is a page. A block holds many pages, so eventually space becomes a premium and it becomes difficult to find empty blocks to erase so that a page in the block can be used to write something do. The more complicated mappings and having to shuffle data around is a huge culprit of 'lagging' ones' device.
It gets confusing, especially when I'm deciding what's important enough to work on and use as there are a lot of tweaks out that don't actually do anything but are still used for some reason (probably out of habit over time). This is definitely one of the more useful tweaks to make on 4.2.x for improving performance (as long as the filesystem mount changes are used alongside it).
I'm not familiar with all the G2 ROMs (as in I've only used one and I use that as a base to build on), and this could possibly be built in in the form of init.d scripts or built into vold if on AOSP (though I haven't seen any AOSP 4.2.x ROMs for the G2 considering the newer versions). In that ca
xdabbeb said:
I think this is definitely a useful post for those interested, but has anyone actually verified that running fstrim on the G2 is 100% safe from the EMMC corruption issues that had plagued other devices in the past? Downloading Lagfix wouldn't be a good test as that program hasn't been updated since long before the G2 release (March 2013).
Click to expand...
Click to collapse
is just dared to try lagfix and it worked like a charm!
This is only good for Android 4.2.2 builds and older
Sent via Crossbreeded, 100% V6 Supercharged. KT747'd and Linaro Built Paranoid Android 3.10
I've been running LagFix Premium since the first day the G2 was rooted. Every morning at 5AM. Overkill, perhaps, but this is what kept me sane with the old Galaxy Nexus. When I first used LagFix on the GNex it changed my world.
luv2increase said:
This is only good for Android 4.2.2 builds and older
Click to expand...
Click to collapse
That's exactly what the OP said in the long post two above yours.
---------- Post added at 09:47 AM ---------- Previous post was at 09:45 AM ----------
MidnightHarvester said:
You can also check your mounts by typing 'mount' at a command prompt. There you can check and see if your filesystems are using discard or not.
Click to expand...
Click to collapse
What specifically should we see when we type "mount" if the filesystems are using discard?
Hi,
if you use a custom ROM on your Chromecast and for some reason want to get back the stock boot animation, this mod is for you.
This mod just replaces the boot animation on your Chromecast, everything else remains unchanged, it won't reactivate the Google OTA updates or anything else.
Install instructions:
Note: this is basically the same as if you were installing Eureka-ROM, nothing game-changing here.
Install and setup Flashcast (at least version 1.1.1) on a USB flash drive. You can use the Flashcast drive you created earlier when installing Eureka-ROM or similar.
Note: you have to boot your Chromecast from the Flashcast drive first, just like they say in the Flashcast tutorial, in order to be able to continue with those steps.
Download the file attached below, rename it to "eureka_image.zip" and copy it to the Flashcast drive.
Plug the Flashcast drive to your Chromecast, press and hold the button on the device, and plug in the power. Hold the button until the Flashcast screen appears.
Wait and let Flashcast install the mod. This could take a few minutes, so don't panic. Your Chromecast will reboot itself when done.
Done. Enjoy.
Big thanks to Team Eureka for their Eureka-ROM, whose installation zip and script I used when creating this mod.
Another big thanks goes to tchebb for creating Flashcast.
And another thanks to Google for creating Chromecast, and the boot animation used in this mod.
PS: the file attached to this post works on the build 14975, which is version 1.1 of the Eureka-ROM. See post #5 for an updated version for Eureka-ROM 2.0. Big thanks to mathorv for updating the mod, he beat me to it. If he's okay with it, I'll add it here for the convenience.
Flashing process is slow so people please don't panic if takes few minutes.
Mod is tiny - one new line in .sh script and just stock images and its works like advertised.
mathorv said:
Flashing process is slow so people please dont panick if takes few minutes.
Mod is tiny - one new line in .sh script, and just stock images and its works like advertised.
Click to expand...
Click to collapse
Yeah, it is quite slow, I'm not really sure why. In Flashcast log there is nothing strange which would explain it. I'll try to add some more debug logs with some timestamps to find out.
I guess I'll add the info about this slowness to the OP. Thanks for the notice.
(And actually, there is nothing really new in the .sh script, I just deleted some unneeded lines and added a comment. No hard work for which I could be proud. )
frantisek.nesveda said:
Yeah, it is quite slow, I'm not really sure why. In Flashcast log there is nothing strange which would explain it. I'll try to add some more debug logs with some timestamps to find out.
I guess I'll add the info about this slowness to the OP. Thanks for the notice.
(And actually, there is nothing really new in the .sh script, I just deleted some unneeded lines and added a comment. No hard work for which I could be proud. )
Click to expand...
Click to collapse
The slowness is due to the filesystem the Chromecast uses for /system, squashfs. It's a read-only, compressed, filesystem, which is great for saving space but not so great when you want to modify it. What FlashCast has to do is extract the filesystem into RAM, make the modifications, then repack and re-compress it. The last step is what takes the time, since the Chromecast's processor isn't all that fast. We hope to migrate to a more suitable filesystem in future versions of Eureka-ROM, which will eliminate slow flashing altogether; we still have a few issues to work out, though, so I doubt it will be in the next release.
eureka_stock_bootanimation_15250.001
Updated script for Eureka-ROM 2.0 - 15250.001
mathorv said:
Updated script for Eureka-ROM 2.0 - 15250.001
Click to expand...
Click to collapse
Thanks, I was planning to do that when I get home during the weekend. Can I add your file to the OP?
frantisek.nesveda said:
Thanks, I was planning to do that when I get home during the weekend. Can I add your file to the OP?
Click to expand...
Click to collapse
Sure. In future we can also can replace main eureka banner in web panel with something more pleasant.
[WIP][HTC 8x][8.1]Fiddler2 Update Utility UEFI, BOOT Dumps & Templates[ExploitsFound]
heres the story. i hex edit, spyder, leech, rip, hack all day everyday from my inseure server. always trying to break security on multiple platforms and remote locations. anyways my pc is just filthy. my devices probably have more imfections than a skid row street hooker. the is no exact explination on how this happened but all i know is a combination of a app\xap called webserver native access 0.4.3 , xenu url checker for pc and fiddler2 all running on the same ip and port [9999] started doing strange things. i fiddles when i typed in the address that webserver xap gave me while spyder crawling my phone with xenu,fiddler picked up lots of certificates while decoding system files.then o e after another probably 5 or 6 updates poped up on my phone. ive already had 3 windows 8.1 updates in the past. and wasnt aware of anything new. . also fiddler never picked up any remote link only local. strabge thing is i think rom updates for other devices got flashed to my phone. anyways the phone still works. im not sure the exact situation but the other day microsoft gave me a security signed symantic enterprise mobile code signig certificate when i made my store on the app studio website. i could of swore it was something of 250 dollar fee to get symantic to sign the cert for you. cant rember the process i went through a year or 2 ago when i need a cert signed. nice of mixrosoft the hook it upi guess. thats not enen the start with certs . i ripped hundreds of crt and crl from ruu's including qualcomm protected root ca's htc-cert , uefi keys, pulled from my device. anyways i had a dumb idea to install all of these onto my pc. what a dumb/smart mistake good happening. now i cam download all ota cabs with out going through proxy loops, and now have deeper access to htc and qualcomm based devices, it seems as the mpment i plug and windows phone with secure boot locked within minutes the device registery hive syncs with my servers hive and forcesthephone to disable uefi secure boot since my server isnt uefi compatible. i not if any sense is made here. ........soonyou will be seeing custom roms for htc8x fully flashable with out the use of a ycable. 2 jumps away from fullly rebuilding partitions from a 3.41 ruu . new roms will be a completely different platform. choice is in the air. right now my htc 8x is compiled from a mixture of windows phone 7 & 8, embedded compact 2013 and windows RT. strange thing is my device is based on gdr2..
my thumbs hurt from thping this on my nexus. sorry for the bad grammer and broken up sentences.
one last note anybody know wherr to get the OAK (OEM Adaptation Kit) layers and the 9600_POWERTOOLS with out having to sign up as an oem for microsoft.? I Have part of oak but only the portion for embedded compact 8
if anybody woild lit to join in be my guest. the more heads in this project the faster we break one of the most secure phones in the world. i will get everyone caught up wothin the soon on info. got to sort my files.
as of right now i think the ruu_signed.nbh is actually a .egisenx file extension which can be decrypted with edatasecurity by acer. once i find the framework software to install edatasecurity. i will give it a shot. in the mean time in anybody has an acer or gateway computer with that software installled on it already you could take a crack at. pick up any ruu_accord and 7z the exe file directly open the ruu_signed.nbh with a hex editoe without extracting the file and save the the nbh as a .egisenx file extension then proceed to attempt to decrypt. if it requires a password. i will provid some strings i pulled from the hexeditor. even beter if anybody has decrypting software that might work too.
also some of the htc 8x partitions arr encrypted SHK (SENTENIAL SKYNET) this is interensting i think this might be easier to crack.
softqare used so far in project accord
Revskills final release
Revskills 1.xx
qmi by revskillz
winrar good for converting damaged files
7zip good old extract to temp location
telerik justdecompile standalone version or visual studio extenson
webserver 0.4.3 or 0.5.0 .xap for wp8 winpone8 works on windows phone 8.1 also!
xenu url checker
fiddler2
winhttrack rip my phone like a website
010 editor with lots of custom scripts templates and syntex.
hhd hex editor is optional
hiew hex editor for the pros. still experimentig with this one.
lots of time.
cmd.exe and ecery damn xommand executible you can find that rips, strios, converts, merges, splits de/compress makes thing go backwards forward up down and flip around.
lots more fime
brew mp
win phone 7 tools.
OAK
osbuilder for wp7
basicly any file you can find that de/compiles that was made my microsoft mobile, embedded or ce department.
wak, wdk, hck 8.1 microsoft hardware tools
visual studio 2012 2013.
visual studio .net compiler 'rosylin'
lots of samples.
2014-05-24
RUU PARTITION RIPPING THE EASY WAY.
7zFM build 932 can directly open any file when using the options in the contex menu. just right click on the .ruu_signed.nbh highlight 7z open with arguement submenu and eithe choose # option or the #e option. both arguements work but with different outcomes. when 7z is done loading you will end of with a numbered liat of files some witj or without extensions. extensions as folowing .efi, .elf, .fat, .ntfs, .exe. all extenses with extensions open. the fat files are complete partitions. thw ntfs partition is metadata that is also embedded with in a file called boot.sdi located in one of the fat partitions. the exe files are normal MZ PE executable system32 applications. efi executable files are also located within the fat partitions. the elf files which strangely exist within the phones operating system can be extracted and read with a hex editor. strange that windows phone contains elf. considering Microsoft binary format is COFF/PE. DOWNLOADS WILL BE UP SOON FOR DEVELOPMENT. it is a possibility that the boot partition ripped form a accord_u_wwe was part of the updateos.wim. therr is refrence on how to add packages to the wim on the windows phone developer oem site.
an interesting experement done which worked on nokia ffu files. convert the nokia ffu to a vhd using winimage with fixed size settings. once completed. mount it with osfmount tool. none of the partitions show up nor are they mountable. so i proceded to generate a raw img from the vhd in osfmount which put out a raw img just over 7gb. jezuz the vhd was only just over 1gb. decided to mount the raw img using diskinternals linux reader and what do you know every partition showed up. even the secret one. most were still unable to open but boot uefi data and mainos. it did give me good insite on what to look for and discover within the windows phone lock filesystem.
There is a metadata file hidden deeply with MFT (MasterFileTable) called $Boot. this $Boot file header is R.NTFS.
i will get more in depth on thia later.
File system encryption used for the MAINOS is called RSDS mi. very hard maybe impossible to reverse engineer. I did find an explination in a .text file located inside of the file Liveupdate.exe located in The windows/system32 folder of my phone. the file gave vague instructions on how to compile an Fupdate.xml template which and be used to push update packages over wifi. more details layer.
Possibility to mount several partitions including mainos directly on my pc by minipulating binary regestery keys on windows 7. more soon.
Found these in my pc. Going to play around with them see what happens
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\WP8]
[HKEY_CURRENT_USER\Software\WP8\DL]
"MODE"=dword:d10ad121
"CSC"=hex:00,00,00,00
"SBL"=hex:00,00,00,00
"RPM"=hex:00,00,00,00
"UEFI"=hex:00,00,00,00
"ACPI"=hex:00,00,00,00
"MainOS"=hex:00,00,00,00
Click to expand...
Click to collapse
Diffrences in files located in the fat16 partitions cross refrenced branded and unbranded ruu's csv.cfg on the branded ruu has the radio build number defined while the unbranded ruu is blank 00 hex bytes through the entire csv.cfg file. RADIOVER.CFG unbranded ruu has anextra line IMEI line configured to 1 while the branded ruu is missing the imei line. my guess is with the imei 1 assignment with the unbranded ruu is once the device gets flashed with the original firmware it also gets assigned a new imei as well. just my guess. some insite would help on this.
Well, as the dev of NativeAccess I'm certainly very interested in what you found. My first guess is that you wandered into the section of the registry where the phone's certs are stored (yes, it's readable), although the format that the app returns them in isn't something that would normally be recognized as a certificate. Which means my *best* guess is that you wandered onto some certificate files stored on the phone in a readable directory, because the server app will let you download files
Everything from there is Really Weird though, and we'll need to investigate it more. I should spin up some VMs to try this... anyhow, getting additional updates to your phone is pretty weird, so let's start with that. Did you install those updates? What were their descriptions (i.e. what did they say was getting updated)? What are your current phone version strings (OS, Firmware, etc.) from Settings -> About -> More info (and do any of those look notably different than you expect)?
Installing certs ripped from RUUs onto your PC is... well, I would never have tried it on my main box, but now I really want to try it on a VM. Do you have the list of certs you installed anywhere handy? What ROMs did you rip them from, and where in those ROMs?
Deeper access into WP8 devices sounds *seriously* interesting! I don't have a modern HTC (only my old HD7, a WP7 device) but I could probably obtain one, at least temporarily, for research purposes. What registry hives do you think are synching (and why do you think it's a synch)? Is it actually turning off Secure Boot for real, or just causing the registry to report that it's off? (We can override the report value on Samsung WP8 phones, but that does no good.) If you've managed to turn off Secure Boot on HTC WP8 devices, you've probably just found the door to custom ROMs and possibly other fun hacks. Do you have any non-HTC WP8 devices you could test with too, to see if anything else interesting is happening?
Good luck cooking up those custom ROMs! That is unfortunately not my field at all, so I can't really help... but it would be pretty cool to have the ability to run RT instead of / in addition to WP! There's also a ton of tweaks and unlocks we can do if we have totally arbitrary access to the device and no pesky code signing enforcement getting in the way.
GoodDayToDie said:
Well, as the dev of NativeAccess I'm certainly very interested in what you found. My first guess is that you wandered into the section of the registry where the phone's certs are stored (yes, it's readable), although the format that the app returns them in isn't something that would normally be recognized as a certificate. Which means my *best* guess is that you wandered onto some certificate files stored on the phone in a readable directory, because the server app will let you download files
Everything from there is Really Weird though, and we'll need to investigate it more. I should spin up some VMs to try this... anyhow, getting additional updates to your phone is pretty weird, so let's start with that. Did you install those updates? What were their descriptions (i.e. what did they say was getting updated)? What are your current phone version strings (OS, Firmware, etc.) from Settings -> About -> More info (and do any of those look notably different than you expect)?
Installing certs ripped from RUUs onto your PC is... well, I would never have tried it on my main box, but now I really want to try it on a VM. Do you have the list of certs you installed anywhere handy? What ROMs did you rip them from, and where in those ROMs?
Deeper access into WP8 devices sounds *seriously* interesting! I don't have a modern HTC (only my old HD7, a WP7 device) but I could probably obtain one, at least temporarily, for research purposes. What registry hives do you think are synching (and why do you think it's a synch)? Is it actually turning off Secure Boot for real, or just causing the registry to report that it's off? (We can override the report value on Samsung WP8 phones, but that does no good.) If you've managed to turn off Secure Boot on HTC WP8 devices, you've probably just found the door to custom ROMs and possibly other fun hacks. Do you have any non-HTC WP8 devices you could test with too, to see if anything else interesting is happening?
Good luck cooking up those custom ROMs! That is unfortunately not my field at all, so I can't really help... but it would be pretty cool to have the ability to run RT instead of / in addition to WP! There's also a ton of tweaks and unlocks we can do if we have totally arbitrary access to the device and no pesky code signing enforcement getting in the way.
Click to expand...
Click to collapse
right now im hexediting ruus and they seem almost completely decrypted. its strange becUse a few weeks ago they were all scrambled.
i will postnmy findings on my website for every one to view
i rememersomeones post on possible certificates could bethekey to jailbreaking qindows phone 8. i think theymight beright
it said the updates i got stated they would further enchance my device. windows phone 8.1. funny.
i ripped certs from several ruu_accord_u and img_accord_u packages. i have 9 or 10 htc 8x ruu's stashed.
i installed the certs that had embedded htc_cert, qcom, qualcomm, symantic, uefi, and a few others i cant remember them all.
i have a lot to catch everybody up on. about 50gb of findings from accord ruu's and from files ripped from my phone. its a cluster **** of work.
uefi flashing
uefi disabling
source code
software lots of software refrences found.
wince800
winrt
qcomedk2 = edk2 part of the original dev kit ised to build flash dump reflash enable and disable uefi bios
certificates thousands of crl cer in every device. even the smallest file has a certificate. and i found their passwords
rsa-keys in the tesst faze
uefi keys
esn keeys
every partition size, format, offset and sector size.
port numbers and usages
every single registery key
.....
.....
keeps going on.
reserved
grilledcheesesandwich said:
reserved
Click to expand...
Click to collapse
reserved