Related
Hi all, hope u had a nice week-end
I have resuscitated an old HP Jornada, and I was wondering if one can still find softwares for windows CE. Especially games, even basic ones since it is intended for use by my kids.
Thank you and take care
i believe that games for the cpu will work
as in if it have an arm cpu arm based games will work
and if it's mips mips games will work
games are typicaly written in asm directly for the cpu and the os dont mean that much
Redugar - I don't mean to be rude but are you leaving in the 80s?
No one has bee writing games or anything other than drivers and other OS / basic components using assembler in over a decade and a half!
It's way way too much work and not at all necessary.
But you are right about one thing - I've seen on some freeware sites like www.pocketpcfreeware.com apps that were compiled for CE2.11 so yes I do believe there is a good chance to find a few games.
Thanks folks for your replies.
I've tried very "basic" games like ICBM, but they won't run.
Visual basic stuff works provided one downloads the appropriate dll.
Will keep searching.
Take care,
well i may still look like this
http://thor.mirtna.org/features/titular_movie_themes_limahl.jpg
but my dukenukeem3d and warcraft2 are just in dirs on my sd card and they run under wm2002 to wm2005 3.5AKU without even a reinstall
so they are not really taking advantage of any newer features of the os
same with this doomCE port
http://www.revolution.cx/DoomCE.htm
levenum said:
Redugar - I don't mean to be rude but are you leaving in the 80s?
No one has bee writing games or anything other than drivers and other OS / basic components using assembler in over a decade and a half!
It's way way too much work and not at all necessary.
Click to expand...
Click to collapse
Check out SmartGear (see my emulation-related articles) and the new Pocket QuickView ( http://www.modaco.com/Pocket-QuickView-40-looking-for-ideas-t255364.html )
The mission-critical sections were all written in assembly. This is why it's WAY faster than any other, C-based emulators / image viewers.
maybe using gcc for arm to some some nativ arm code would also have less overhead then win32 stk
though not sure how many libs would be required to be linked to so could end up a drag
Ok, I know when I am bitten but I am just no willing to quit!
(Just to reiterate - to 80's remark was meant in good fun and not intended as an insult, plus this was written late at night after a long work day)
Any way it does make sense that for high speed some graphics rendering routines will be written in assembler (note that unfortunately eVC tools do not include inline assembler so modules have to be compiled separately and then linked)
I do remember taking a peak at the DOOM port and it is mostly C. (Though I am sure it has assembler sections).
What I was trying to say is this:
a) You can't write a whole game like DOOM in assembler only in reasonable time.
b) Even assembler modules need to be eventually linked in to an executable so the OS (what ever it is) can load them - and here is the problem. Every exe has a header that states what processor and what OS it is designed for. Even if your app does not use new OS features, but is linked using a higher OS SDK settings the exe header will contain a version number unknown to the OS and it will refuse to load stating that it is "illegal file".
A less prehistoric example would be files compiled with WM 6 SDK refusing to run on WM 5 despite the fact that there is almost no difference in the OS.
"(Just to reiterate - to 80's remark was meant in good fun and not intended as an insult, plus this was written late at night after a long work day)"
dont think anybody took it any other way at least i did
what i should had said maybe rather then that they were in pure asm
then maybe that they were not that depending on the os and version of the os itselfs
and maybe of those fps like doom and nuke3d and such
are ports of old dos games where that was more the custom then later on when windows gaming took off
Hello the community
I would like to know how to perform a soft reset (reboot) from a WM user interface. Of course there is a lot of external programs and utilities providing such the functionality also, but I guess there should be a mechanism built in WM.
I am sure there should be a DLL responsible for that, so probably there is also a way to execute this DLL?! Something like Windows’ rundll.exe?
My device is HTC p3600/Trinity with WM5, but I think it doesn’t make sense.
Your advice would be much appreciated,
Br, Alexey
dll mean dynamic linked libary
which pretty much mean it's a lib full of functions that
other apps call you cant normaly just call it's functions from
the GUI
yes, I know what DLL actually mean
And that’s why I made a guess about a possible way to run DLL similar to rundll.exe
I would prefer using something like reboot.exe, but if such a program isn’t provided along with standard WM, I don’t mind using workarounds like running DLL, if possible.
Anyway, my question was not about real nature of DLL but the way how to perform a reboot using standard functions of WM.
Check out the SDK documentation, MS might have made a direct api to achieve this through a direct rundll type action, but the easiest way is just to code a tiny app and launch it, eg
http://www.pocketpcdn.com/qa/softreset.html
VJEschaton will reset in a variety of fashions.
V
Thanks
Is there a way to compile such a tiny application without installing any huge C++ IDE? Something like command line compiler downloadable thru a simple ZIP file?
shkaff said:
Thanks
Is there a way to compile such a tiny application without installing any huge C++ IDE? Something like command line compiler downloadable thru a simple ZIP file?
Click to expand...
Click to collapse
The C# compiler is free and can produce WM executables. The only problem is that you must instruct it to use the .NET Compact Framework libraries instead of the normal ones. I readied a guide when the last OS was WM2003. I don't know if it is still working, but actually I have no reason to think it won't. Just choose the right subset of files.
Here is the link:
http://www.jargoncode.it/tips/netcfcompile-eng.htm
If you want a C++ compiler... I don't know.
I brought up some thoughts about Dropbox in mamaich's thread and netham45 was nice enough to bring up some interesting facts about Dropbox, namely that it's compiled in Python.
I'm totally unqualified and have no idea how to actually do the tough stuff, but i'm just going to leave all my notes so far in this thread so someone perhaps more knowledgeable with Python can take it from here. I will try to play it around to get it working though.
Basically after extracting Python from the .exe I got left with a bunch of .pycs that need to be recompiled into the .py that made up the file. I have no idea how to do this. See here http://nixforums.org/about81754.html - if this can be built into some sort of functional program, then it may be very well possible to take this one step further and recompile an .exe for ARM that runs dropbox - or even more easily just compile a working python file for Dropbox
this also might be interesting http://kyl191.net/2012/04/dropbox-api-python-to-sync-a-folder/
I also thought it's worth pointing out this https://github.com/mdornseif/dropbox-client-python
last but not least http://stackoverflow.com/questions/2678180/how-does-dropbox-use-python-on-windows-and-os-x
Maybe someone will have a better idea about what's going on here
The compiled python -should- be platform independent. I honestly don't know much about Python, but we should be able to just reverse whatever dropbox.exe is doing (which should be just a launcher), mimic it, and get a rather functional dropbox.
Another thing that could be done is implement a client in .net. I played with doing just that a couple weeks ago, I had a semi functional (it worked, but had some issues still) offline client in not very many lines of code using a .net library for Dropbox. I'll see if I can get my code up sometime soon.
netham45 said:
The compiled python -should- be platform independent. I honestly don't know much about Python, but we should be able to just reverse whatever dropbox.exe is doing (which should be just a launcher), mimic it, and get a rather functional dropbox.
Click to expand...
Click to collapse
The Python-to-exe packers I know basically include a native loader that unpacks the python dll and loads it either from temporary location or directly from memory and then passes the script to that dll.
It's probably just a matter of figuring out which packer they used and/or porting one of the packers and repackaging it again for RT
DarkoLord said:
The Python-to-exe packers I know basically include a native loader that unpacks the python dll and loads it either from temporary location or directly from memory and then passes the script to that dll.
It's probably just a matter of figuring out which packer they used and/or porting one of the packers and repackaging it again for RT
Click to expand...
Click to collapse
Wrong track completely. The compiled python being referred to above is not python packed into an exe. It is a .pyc file. Contrary to popular belief python is not interpreted line by line. Instead it is compiled into bytecode and then a virtual machine executes that. The bytecode can be saved into a .pyc file (there is a tool included in the standard python install for it somewhere, alternately if you try importing any script as a python module then python will automatically make a .pyc for it which you can use), it has a smaller file size and is not human readable. This is the file being referred to.
It is possible to reverse engineer .pyc files. I remember seeing a tool which is capable of making a pretty good attempt of reverse engineering non obfuscated bytecode, thats the disadvantage to python being open source, the bytecode specification is publicly viewable can't remember the tools name and I would think dropbox have obfuscated their pyc files.
SixSixSevenSeven said:
Wrong track completely. The compiled python being referred to above is not python packed into an exe. It is a .pyc file. Contrary to popular belief python is not interpreted line by line. Instead it is compiled into bytecode and then a virtual machine executes that. The bytecode can be saved into a .pyc file (there is a tool included in the standard python install for it somewhere, alternately if you try importing any script as a python module then python will automatically make a .pyc for it which you can use), it has a smaller file size and is not human readable. This is the file being referred to.
It is possible to reverse engineer .pyc files. I remember seeing a tool which is capable of making a pretty good attempt of reverse engineering non obfuscated bytecode, thats the disadvantage to python being open source, the bytecode specification is publicly viewable can't remember the tools name and I would think dropbox have obfuscated their pyc files.
Click to expand...
Click to collapse
I'm aware of that (by script file I meant pyc, of course), but what would be the reason for trying to reverse engineer the pyc files since the bytecode itself is platform independent?
For starters someone should just try running the unpacked .pcy files on the RT or are we past that and there is some platform specific stuff inside that prevents it from working?
DarkoLord said:
I'm aware of that (by script file I meant pyc, of course), but what would be the reason for trying to reverse engineer the pyc files since the bytecode itself is platform independent?
For starters someone should just try running the unpacked .pcy files on the RT or are we past that and there is some platform specific stuff inside that prevents it from working?
Click to expand...
Click to collapse
The pycs are getting magic number errors when I try to look at them because i'm not running it through the interpreter - because I dont know what the interpreter is. I think the first step is to find a way to get it compiled and running to find out if its platform independent or if there are dependencies.
I also have no idea which .pyc to start with
Ah, magic number.
Apparently Dropbox uses a bit modified version of python interpreter with some encryption and mixed opcodes.
Here are some details: http://blog.codepainters.com/2012/09/17/python-care-and-feeding-the-dropbox-way/. It looks like it could be done
Wow, if we could have legit dropbox on RT, that would be AMAZING!!
https://www.dropbox.com/developers/sync
Any idea if this would be helpful?
userno69 said:
Wow, if we could have legit dropbox on RT, that would be AMAZING!!
Click to expand...
Click to collapse
I really agree, is this project still alive??
maxxie85 said:
I really agree, is this project still alive??
Click to expand...
Click to collapse
It's been six months since this thread was posted in. I doubt it.
netham45 said:
It's been six months since this thread was posted in. I doubt it.
Click to expand...
Click to collapse
yeah I noticed that to, never hurts to ask.
And by the way, maybe now the life in this project is getting resparkeld.
Sent fromy my ASUS Transformer Pad TF300T using XDA Premium HD app
So I know pretty much how my jailbreak is going to work from end to end, except with regard to PatchGuard. I don't need to burn my "Holy Grail" exploit in order to release a jailbreak, but it means that I have to deal with PatchGuard.
In Windows 8.1, Microsoft modified the kernel and ci.dll so that PatchGuard protects the signing enforcement mode variables. This means that if you modify the variables that were modified by 8.0's jailbreak, some random time in the next hour from that point, your system will bugcheck (bluescreen) because PatchGuard detected something tampering with the kernel. It is very obvious that the addition of these variables to PatchGuard's protected list was a deliberate attack against the RT jailbreak, because there is little other reason to care about enforcing these variables' integrity after startup.
I need to get around PatchGuard somehow. PatchGuard itself is designed to be an obfuscated mess, deliberately difficult to modify in a stable manner. It does a lot of nasty tricks, things that you would typically find in copy protection systems. Obviously, disabling it would be nice, but quite difficult. So is stopping it from bugchecking.
I can load kernel drivers, so I know of a way in which I can hook parts of the system that would not anger PatchGuard such that arbitrary unsigned DLLs and drivers could be loaded without hassle. For things like the lockdown in WinDbg, VBScript and PowerShell, I can hook NtQuerySystemInformation in the user-mode ntdll.dll and intercept the request to check the lockdown setting. Even though the system lockdown state would still be active, as long as user mode programs don't know about it, it won't be enforced. (The kernel doesn't care at all.)
However, this leaves one thing to be desired: executing ARM code. I already know how we can patch the kernel so that ARM code can execute without the CPU being switched back to Thumb2 all the time. However, patching the kernel definitely will get PatchGuard's attention, so there's no way to pull that off without defeating PatchGuard.
The optimal solution is definitely to defeat PatchGuard, but I don't know how. I'm not an expert in the field of low-level NT kernel stuff.
please release your jailbreak so that other people can help you.
If i got it correctly, it will BSOD in a hour of running, so releasing it to public is not a good idea. Maybe via PM to other devs, but that depends on OP.
why not change the variables back after you launch your unsigned exe?
windowsrtc said:
why not change the variables back after you launch your unsigned exe?
Click to expand...
Click to collapse
I think about doing this too. Can we discard hacked? If it can done. Will it have problem with running unsigned exe? And did we know exactly when did PatchGuard notice about hack?
Myriachan said:
However, this leaves one thing to be desired: executing ARM code.
Click to expand...
Click to collapse
Perhaps I'm missing something, ... why do you want to do this? The reason I ask is because this seems to be your motivation for wanting to "defeat" patch guard.
WRT simply running native applications/driver - If you can successfully load a driver, even once, then there are a few easy ways to support this without a patch guard defeat.
Cheers!
bfosterjr said:
Perhaps I'm missing something, ... why do you want to do this? The reason I ask is because this seems to be your motivation for wanting to "defeat" patch guard.
WRT simply running native applications/driver - If you can successfully load a driver, even once, then there are a few easy ways to support this without a patch guard defeat.
Click to expand...
Click to collapse
That it's currently impossible to execute ARM code reliably on Windows RT is a major reason that Firefox hasn't been ported. Fixing that would require patching two context-switch routines in ntoskrnl.exe.
You're right that there are various ways of loading unsigned executables and drivers once the initial driver is bootstrapped. ci.dll and ntoskrnl.exe have so many variables that aren't protected by PatchGuard that this is pretty much inevitable. Ironically, removing the lockdown from WinDbg, PowerShell and VBScript is actually harder than running unsigned code when using this attack.
Defeating PatchGuard would be the optimal experience for users.
...
...
Myriachan said:
That it's currently impossible to execute ARM code reliably on Windows RT is a major reason that Firefox hasn't been ported.
Click to expand...
Click to collapse
Actually, I don't agree. There is no hard requirement for ARM code that I can see. The major reason for a lack of FF port is that the native RT community is too small to get behind the port to sort out re-writing parts of the code base. There is also the large build system/process that needs to be shifted to VS. Throw in the lack of a public RT 8.1 JB.. and there is little motivation for this community to invest the time/effort in making FF work.
Don't get me wrong, FF will likely come to RT (even 8.1) eventually.. but I don't see the lack of ARM code being the roadblock. Its time and effort along with a new JB.
bfosterjr said:
Actually, I don't agree. There is no hard requirement for ARM code that I can see. The major reason for a lack of FF port is that the native RT community is too small to get behind the port to sort out re-writing parts of the code base. There is also the large build system/process that needs to be shifted to VS. Throw in the lack of a public RT 8.1 JB.. and there is little motivation for this community to invest the time/effort in making FF work.
Don't get me wrong, FF will likely come to RT (even 8.1) eventually.. but I don't see the lack of ARM code being the roadblock. Its time and effort along with a new JB.
Click to expand...
Click to collapse
The javascript JIT engine is to ARMv7 not THUMB_2 though.
SixSixSevenSeven said:
The javascript JIT engine is to ARMv7 not THUMB_2 though.
Click to expand...
Click to collapse
I gathered as much. I'm suggesting a re-write of that as part of the port.
Cheers!
Possible, but not easy. The result would likely be significantly less efficient... but better than no JIT at all. It substantially increases the effort required for porting, though.
As for PatchGuard... I don't know as much about it as I'd like, but the fact that it only checks periodically suggests something that we can anticipate and head off, assuming we can get our own drivers loaded... hmm. This is a pretty "out there" solution, but is there any chance that the version of PG from RT8.0 could be substituted in? That may assume a greater degree of encapsulation of PG functionality than is actually warranted, but it does seem to me that, if we can't modify it, we might be able to just replace (or possibly remove) it. Another option: rather than modifying the value itself, modify the code that checks it? I mean, if they were smart, that's under PG as well, but it *might* not be. Either bypassing the check for the values, or the signature check, or just spoofing the signature check, or taking it a level even further and replacing the whole loader function with a clone that lacks the check (which allows the original to remain intact, aside from however the shim is injected).
Any which way, a lot of binary RE... ick, but that's life.
A few ideas:
1) Put a memory read breakpoint on the memory addresses you wish to change, check the context reading it and change it to what it should be if it's PatchGuard, and what you want if it's not.
2) Hook BugCheck to make it just return if PatchGuard calls it (I seem to recall reading something about PG wiping the stack/any context before calling BugCheck, so this may not work)
3) Forcibly enable Debug mode VIA setting the required kernel flag/calling the proper function (kdStartDebugger? something like that; I had found it at one point) to enable the debugger. I have no idea if PG will sense this on pre-existing threads or not, but if it does then it should shut itself down.
4) Check if THIS approach works in 8.1 (I suspect not, since it was published for 8.0 previews)
5) (This would work for g_ciOptions, but not patching the interrupt handlers), hook the usermode function that queries the state of the signing, make it call a driver that changes the bit back, check, then call the driver to set it to default again. You would only get a BSoD if you were really unlucky and PatchGuard happened to run during the 30ms that the flag was changed.
I'd like to play with some of these ideas, but without access to the current prototype (hint hint), and not having a PC I want to upgrade to 8.1 right now, it's difficult.
netham45 said:
A few ideas:
1) Put a memory read breakpoint on the memory addresses you wish to change, check the context reading it and change it to what it should be if it's PatchGuard, and what you want if it's not.
2) Hook BugCheck to make it just return if PatchGuard calls it (I seem to recall reading something about PG wiping the stack/any context before calling BugCheck, so this may not work)
3) Forcibly enable Debug mode VIA setting the required kernel flag/calling the proper function (kdStartDebugger? something like that; I had found it at one point) to enable the debugger. I have no idea if PG will sense this on pre-existing threads or not, but if it does then it should shut itself down.
4) Check if THIS approach works in 8.1 (I suspect not, since it was published for 8.0 previews)
5) (This would work for g_ciOptions, but not patching the interrupt handlers), hook the usermode function that queries the state of the signing, make it call a driver that changes the bit back, check, then call the driver to set it to default again. You would only get a BSoD if you were really unlucky and PatchGuard happened to run during the 30ms that the flag was changed.
I'd like to play with some of these ideas, but without access to the current prototype (hint hint), and not having a PC I want to upgrade to 8.1 right now, it's difficult.
Click to expand...
Click to collapse
1. You can't set a read breakpoint because PatchGuard is also checking the contents of the interrupt vectors/registers. It would notice that someone is using the hardware breakpoints before it tried to read kernel memory.
2. Yes, PatchGuard overwrites KeBugCheckEx with a pristine copy among other tricks.
3. PatchGuard knows that the debugger was not enabled at boot, and will not allow it to be enabled. It will bugcheck if you try to enable it.
4. It's possible that the approach where you look for the self-decryption code at the beginning of the DPC handlers would work.
5. There is a better way, closely related to how I'm writing my installation program, to allow unsigned PEs to load. It would escape PatchGuard's notice. A user-mode hook would be required in order to neuter wldp.dll, though, since ntoskrnl.exe would still tell programs that the current policy was locked down.
I think I can do everything I need to do except execute ARM code reliably without harassing PatchGuard.
Melissa
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
sahack said:
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
Click to expand...
Click to collapse
There is a lot of software that we would like to port over that is written in arm assembly. We would have to rewrite it to THUMB-2 to use it on Windows RT, though. Porting software is (relatively) easy, rewriting it is difficult.
sahack said:
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
Click to expand...
Click to collapse
Common one that needs the ARM instruction set would be a javascript engine. V8 which is the javascript JIT used in chrome only has x86 and ARMv7 versions available, it doesn't have a THUMB_2 version. Although V8 itself can compile for THUMB2, that is only the JIT'er itself, it will only ever JIT to the full instruction set. So to port chrome we wouldnt be able to use V8, there might be a way to get it to compile using the windows javascript engine (which is slower than V8 but perfectly fine) or something but its still a significant obstacle.
The same applies to quite a few other softwares.
Then as netham says, we have software written in arm assembly which people have requested, thats great but it takes alot of effort to rewrite it in thumb2 assembly.
If you have software which can indeed compile for thumb2 and function on thumb2, yeah thats great. But there is some which doesnt.
netham45 said:
There is a lot of software that we would like to port over that is written in arm assembly. We would have to rewrite it to THUMB-2 to use it on Windows RT, though. Porting software is (relatively) easy, rewriting it is difficult.
Click to expand...
Click to collapse
Okay... I used to think that only JIT compilers and media decoders needed that...
But that gives another question.... Were we able to let the CPU stay in ARM mode in Windows RT 8.0?
(And if PatchGuard checks periodically, is it possible to just reset its timer once in a while?)
sahack said:
Okay... I used to think that only JIT compilers and media decoders needed that...
But that gives another question.... Were we able to let the CPU stay in ARM mode in Windows RT 8.0?
(And if PatchGuard checks periodically, is it possible to just reset its timer once in a while?)
Click to expand...
Click to collapse
First question, no.
Second question, thats what the thread is discussing although your suggestion is perhaps worth a look into (if myriachan hasnt already)
SixSixSevenSeven said:
First question, no.
Second question, thats what the thread is discussing although your suggestion is perhaps worth a look into (if myriachan hasnt already)
Click to expand...
Click to collapse
Sure, you could reset the timer on PatchGuard continuously, if you can find all its timers and perfectly distinguish them from those that were created by legitimate drivers. That's the harder part, unfortunately. =/
Bit of a story here.
So I have been long into car hacking, doing all sorts of canbus related modifications to my Merc W203 model.
The stock radio is utter garbage by today's standard, and Xtrons do a ton of android head units for my car. (Either with an A35 CPU and 2gb ram, or Px5 CPU with 4gb ram).
I am wondering, would it be possible to COMPLETELY remove android from it, and instead boot something like archlinux-arm on it. I want to create some custom applications on it whilst also having full control over the entire OS (Hence the want for Linux, not android).
I do kernel development as well so I am not worried at all about devices not working, I can likely hack together a kernel driver for nonworking hardware on the unit.
I am simply looking if it is possible to wipe android and see if it's possible to use it as a bare bones PC.
Any help would be appreciated, before I bite the bullet and spend £250 on one!:laugh:
You still need the GUI and stuff like that.
Besides, Android "is" Linux! Much better, imo, to base it off of Android, to keep the ecosystem that that comes with.
FransUrbo said:
You still need the GUI and stuff like that.
Besides, Android "is" Linux! Much better, imo, to base it off of Android, to keep the ecosystem that that comes with.
Click to expand...
Click to collapse
I am pretty sure by he said 'bare bones' does not mean an (Linux kernel based) operating system with only an command line terminal (i.e. something that looks like MS-DOS).
My point is that native Linux doesn't HAVE "mobile GUI". It have X11, which is *NOT* (!!) suited for such a project..
So either have to port whatever GUI Android have back to Android, or write his own. Which is a *MASSIVE* (!!) undertaking..
Also, Linux isn't quite suited for mobile applications. That's why Android was created. It took all the good from Linux and made it fit a mobile application.. Reverse engineering or back porting all that work to Linux is just dumb..
FransUrbo said:
My point is that native Linux doesn't HAVE "mobile GUI". It have X11, which is *NOT* (!!) suited for such a project..
So either have to port whatever GUI Android have back to Android, or write his own. Which is a *MASSIVE* (!!) undertaking..
Also, Linux isn't quite suited for mobile applications. That's why Android was created. It took all the good from Linux and made it fit a mobile application.. Reverse engineering or back porting all that work to Linux is just dumb..
Click to expand...
Click to collapse
Wait does the OP mean he need some thing like postmarketOS(some kind of Linux distribution with mobile GUI)?
Of course he does!! What do you think "Linux" is?!
Linux is *JUST* (!!) the kernel! NOTHING else.
The *distribution* is everything else. Boot procedure (scripts, commands, filesystem tools - technically that's "The Userland" - the install procedure, the packaging etc etc). Then you put your GUI on top of that.
On top of that you have X11. Or "The GUI". TECHNICALLY, X11 require some more stuff, the window manager too actually be useful. Without it (the window manager), X11 is just an API to the graphical functions - "draw window border", "draw a close button" etc etc. Which is what the window manager utilises.
So: kernel <- userland <- X11 <- Window manager <- Graphical apps
Then all of that is packaged up in a need CD/DVD/Image to make it easily installed and used. And we call that "The Distribution".
This is how UN*X works and that's how LINUX works. Simple, portable and very useful. But not for a phone, tablet or, in this case, a car!
That's why Android was created. It is ALL of that, in ONE package! With thousands and probably millions of apps compiled for it. Do it yourself, and you have to write EVERY (!) app you need yourself - radio apps, navigation etc etc ad-finitum..
Because NO ONE/THING (except in very rare occasion) "talks" to the kernel. They "talk" to libraries (libc, libX11 etc) to do what they need. Which is why you need "The Userland". THEY (the libraries) then "talk" to the kernel (networking, filesystem, input, output etc) giving the apps a nice API - "Application Programming Interface". A set of functions and tools for applications to use, so they don't have to recreate "the wheel" every time.
Now, I'm not going to go deeper, unless you want me to . I do understand that the un-initated don't know the difference between "Linux" the-kernel and "Linux" the-everything. But this *IS* important, believe it or not..
The kernel is absolutely useless on its own. It can't do squat! It was never MEANT to be used on its own. It was designed and built to be used *with* a distribution - "GNU" in the large majority of cases..
Although it's possible to use bare-bones Linux with either your own distribution (MASSIVE amounts of work, I know, I've tried it!) or an existing one (Debian GNU/Linux, RedHat, SuSE etc - they all provide binaries and packages for a multitude of processors), none of them have all the goodies that Google Play Store have.
And none of them are really targeted towards a mobile graphical environment.
Raspbian for example, was made for the Raspberry Pi, but that is in 99% of cases a non-graphical environment (robots and media stations mostly). Most distributions is like that.
The Play store on the other hand is *specifically* targeted towards a mobile, graphical environment. As this is. I would be foolish to try to reinvent the wheel when Android already IS Linux+userland+GUI+distribution.
Keep in mind though that Android apps on Google Play is compiled for an ARM (ARM64) architecture! Meaning, whatever hardware utilised, MUST run on/with an ARM processor..
All this limits the hardware choices substancially.
Everything "is possible". In theory. In practice though, I'd say the answer is "no". It is simply to much work to get it working. For absolutely no benefit.
With that being said... Bare Android on the other hand!! Now THAT is an idea.
Get your Android kernel source and compile it for the specific hardware you're using and then your Android distribution, set it up juuuuuuust so and you'll get what I (and probably everyone always wanted - a non-bloated piece of ... well, we've all seen them.