So I have elf executable file from a montavista linux ARM device and I wanna know if I can run this application on another ARM device, different linux distro, and/or a desktop machine using some sort of "emulator" or tool kit.

The file command says the file is:
ELF 32-bit LSB executable, ARM, version1, dynamically linked (uses shared libs), for GNU/Linux 2.4.17, not stripped

Something else I'm curious about is the file format itself. I'm trying to use a device that will be able to communicate with data from this executable so I loaded the file into IDA decompiler and noticed there's a ton of entries for files that aren't on the operating system. Does this file format store "files" inside it that are accessed through commands? Can I extract these files?

Sounds more like the usual runtime problem. Your system doesn't have the runtime libraries the application needs.

SOME applications outright will not run - these are the ones that look at kernel internal structures for information. They depend on the specific kernel they were built for, or the specific kernel major version (there has been a LOT of changes between 2.4 and 6.x).

The applications that will run do not depend on the kernel - they use the standard application interfaces. These applications may not run because the depend on libraries that DO depend on kernel interfaces. Most likely, the C runtime (which HAS been updated) might not be compatible - some things do change even in user space (libc specifically). If the application doesn't use those it SHOULD run. Other libraries such as libpthread changed a LOT, so multi-threaded applications might not run.

BTW, the specific answer to your question is No. The ELF format does not contain files. It is a description of how to combine the contents of the file with other files (shared libraries) to create a complete execution environment for the application.

Sorry it took a while to respond but would you be able to expand on your comment regarding kernel specific applications? Is there a way to determine if the application I have requires kernel specific binaries to run? Or would the only way to test that be putting the application on another arm device and seeing if it runs?

It almost depends on the hardware platform and where the dependency lies.

In some applications the kernel doesn't really get involved - these can go directly to the device registers (after having the kernel map them to the application) and then do things - direct platform dependency.

Kernel dependency is caused by using kernel data structures for access to data - these are tied to the specific kernel as a new version may change the data structures, or change where/how they are accessed. Many of these have been added to the sysfs filesystem so that when the kernel changes, the access (via sysfs) doesn't change. But when the data structure itself changes, sometimes the sysfs access must also change, and again cause application problems.

I would expect the application documentation to cover both of these possibilities. I think the second shows up by having the process open /dev/mem or /dev/kmem (and /boot/System.map file) to gain access to the data.

The "ldd" command will list the libraries an application needs, and, if they are available, will show them as being mapped.

SOMETIMES, creating a symbolic link of the old name pointing to the current library will work. For such an old one though, this would be unreliable (specifically changes to libc have been rather large - but still, might work).