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.
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.