Jump to content


Photo

Is Anyone Seriously Trying To Get A Full Windows Kernel Running?


  • Please log in to reply
102 replies to this topic

#1 torne

torne

    X-S Expert

  • Members
  • PipPipPip
  • 684 posts
  • Location:London, UK
  • Interests:Reverse engineering, Linux, crazy operating systems voodoo, embedded development
  • Xbox Version:v1.1
  • 360 version:v1 (xenon)

Posted 22 February 2006 - 04:30 PM

Yes, I have read the stickies, and other long tedious posts filled with criticism. wink.gif

It would be amusing to see a full Windows boot on the Xbox, and there doesn't seem to be that much to do tbh: poke the kernel/HAL/etc to not touch the bits of the address space and PCI bus that kill the machine, and then write a couple of drivers (graphics, mostly, much of the rest of the hardware should be supported). The latter is pretty easy; the Linux port's drivers are there as a reference for how to program the hardware.

Is anyone seriously looking at fixing the kernel/HAL to avoid the hardware bugs? It's only a couple of megs of code, with full symbolic information available...
I'd do it myself but I have access to, and have spent a lot of time working with, the Windows source (legally under signed NDA) and thus it's extremely dubious for me to reverse-engineer the Windows kernel - I am 'tainted' and would get the project in legal difficulties =(

If the fixes to the existing binaries are done I'd be interested to help write the few required drivers, which would not be subject to such restrictions..

#2 x-fox

x-fox

    X-S Senior Member

  • Members
  • PipPip
  • 206 posts

Posted 23 February 2006 - 02:44 AM

Well if you are saying you have access to the windows kernal source, I have a few questions for you.

Which specific windows kernal build do you have access to?

What specific patches would apply to the kernal to make it stable enough to run on the xbox hardware?

What bios would you use bearing in mind a standard pc bios would not work?

What graphics driver would you use bearing in mind that the nvidia source has never been released?

Seriously if you cannot provide meaningful answers to the above there would be no point continuing with this thread. Its all been said before.

#3 nt authority

nt authority

    X-S Enthusiast

  • Members
  • 10 posts
  • Xbox Version:unk
  • 360 version:unknown

Posted 23 February 2006 - 09:31 AM



WINDOWS SOURCE CODE FOR BOTH NT4 AND WIN2K BUILDS WERE LEAKED.

Considering the massive knowledge base and amount of applications and hardware devices created to exploit the xbox system this source code can most definitley be used to create a full version of windows for the xbox that can be installed in a native, proper, and full fashion that is truly complete.

Has anyone considered these methods, resources, concepts ???

(1) Build a full Xbox Native Windows from the ground up: Using leaked Windows 2000 Source Code with the missing "non-leaked" components substituted with the relative parts from

(A) leaked Windows NT4 {this has boot code and kernel initialization code in \nt\private\ntos\private\boot\ and \nt\private\ntos\init\ which would allow for the construction of an XBOX specific NTLDR/OSLOADER.EXE and/or NTOSKRNL.EXE

( REACTOS source code: the REACTOS avenue appears great as it already has a Hardware Abstraction Layer with custom code for the XBOX.

(2) Windows CE.NET source code, samples, and binary image building - Dependent on the CE .NET framework to a large extent it nevertheless provides an execellent resource especially when it comes to the construction of pre-kernel (and as such pre WinCE) executions such as those that occur in the hardware enumerating OEM ADAPTION LAYER during boot: a DEFAULT.XBE boot loader has already been constructed for the XBOX and a WinCE NK.NB0 image has been released. Modification to WinCE source code, specifically to the XBOX WinCE image mentioned above (that already works) could lead us somewhere.

By injecting leaked NT/WIN2K code, BIOS/x86 Emulation code such as Bochs, and possibly code from the EFI firmware interface released from INTEL, one could create a glorified superBIOS: This would be a WinCE OS perhaps residing on a LPC module like normal modchips and would allow execution of a normal PC windows setup program (unmodified). This is quite a complex idea but essentially works by creating an intermediate layer between the XBOX and Windows and thus makes Windows think it is installing itself on a PC instead of an XBOX.

(3) Create a BIOS PE FILE to replace XBOXKRNL.EXE then package it up under CABinet protocol and insert it back into the BIOS BOOT ROM so that it is unpacked upon POST.

Obviously we would rebuild NTOSKRNL.EXE using leaked code, rename it as XBOXKRNL.EXE, reseal it with appropriate cryptography and compression and then flash it into the region where the XBOX exepcts such to be.

This would then expect a HAL and Device Drivers as well as a Session Manager Sub-System and further programs at least up to the Winlogon.exe point where a system boot officially comes to an end.


#4 torne

torne

    X-S Expert

  • Members
  • PipPipPip
  • 684 posts
  • Location:London, UK
  • Interests:Reverse engineering, Linux, crazy operating systems voodoo, embedded development
  • Xbox Version:v1.1
  • 360 version:v1 (xenon)

Posted 23 February 2006 - 05:44 PM

QUOTE(x-fox @ Feb 23 2006, 01:51 AM) View Post

Well if you are saying you have access to the windows kernal source, I have a few questions for you.

Sure.

QUOTE

Which specific windows kernal build do you have access to?

Windows XP SP1, no post-SP1 patches. I forget the build number as I don't have access to it from this computer. I have access to the entire Windows Shared Source distribution, not just the kernel - everything from HAL to device drivers to Explorer and so on, though I've never worked outside of the core code (kernel, hal, devices, NTDLL, etc).

QUOTE

What specific patches would apply to the kernal to make it stable enough to run on the xbox hardware?

Based on what I've read about the xbox so far, and looking at the changes required for xbox-linux, it would be neccecary to amend which parts of the memory and IO map are probed for devices (disabling support for finding SuperIO chips and other legacy controllers, since it appears that some of those probe locations cause the box to lock), and to amend which parts of the PCI bus space are probed (as probing 0.00.1 or 0.00.2 cause crashes). The only other issues I'm aware of from the Linux code and from general discussion is the eject fix to stop the box resetting on DVD eject, and the nonstandard poweroff/reboot sequence, but those could both be left until later.

QUOTE

What bios would you use bearing in mind a standard pc bios would not work?

You don't need a BIOS - only NTLDR requires BIOS services, and very few at that - it gets into protected mode as soon as possible. Someone would have to write a new loader to get the kernel, HAL, disk driver, registry and the few other bits that NTLDR is normally responsible for loaded, and appropriate virtual address space mappings set up, but I've done that before so it must be possible. The entire process is well-documented by publically available books on Windows internals.

On non-legacy hardware the kernel needs no BIOS services and simply accesses devices via the PCI space. No sensible modern OS uses the BIOS for anything other than first-stage bootloading and perhaps initial hardware detection in the early boot.

QUOTE

What graphics driver would you use bearing in mind that the nvidia source has never been released?

I'd get the required details from the open source 'nv' driver for X.org under Linux, and write a new driver from scratch based on nv as documentation. It doesn't support 3D but it can bring up a 2D framebuffer on the xbox just fine, with no binaries or source from nvidia (all reverse engineered).

QUOTE

Seriously if you cannot provide meaningful answers to the above there would be no point continuing with this thread. Its all been said before.

Meaningful enough for you? I can't answer any specific questions on any unpublished details of the Windows code, but anything else is fair game.

You sound like you think you know what you're talking about.. I assume you've implemented device drivers and other kernel-mode code in Windows before? Or have at least read MS Windows Internals?



As for you, "nt authority", suggesting doing anything based on the leaked code is a relatively bad plan, plus you don't seem to know an awful lot about what would actually be required...

#5 nt authority

nt authority

    X-S Enthusiast

  • Members
  • 10 posts
  • Xbox Version:unk
  • 360 version:unknown

Posted 24 February 2006 - 03:22 AM

QUOTE(torne @ Feb 23 2006, 04:51 PM) View Post


As for you, "nt authority", suggesting doing anything based on the leaked code is a relatively bad plan, plus you don't seem to know an awful lot about what would actually be required...



I take your constructive criticisim onboard torne and admit I dont know an awful lot about this subject yet am willing to learn; I furthermore acknowledge that it appears you do know an awful lot (compared to most other persons in this forum anyway) and I appreciate your input as it is the most logical approach I have seen in a thread on this site. By the way, my expertise is not in code but in neuroscience, cognition, and artificial intelligence.

I am currently working within a team of consultants with a Private Corporation who require massive computing power for processing specific tasks I can not mention as this company's client is a Government Department and, as I am under a NDA with secrecy provisions, doing such would be breaking the law.

The construction of a cluster has been made a sub-project and we are considering using the XBOX conoles as nodes for this cluster and are looking for persons willing to assist in the creation of a true and proper and complete XBOX native Windows operating system. If persons are detected in this forum to have sufficient knowledge and are interested we are prepared to negotiate to employ them under contract.

------------------------------------------------------------------------------------------------------------------------------
This Windows-XBOX-OS would be created by the exact methods torne has stated:
modified NTLDR/OSLOADER.EXE, NTDETECT.COM, NTOSKRNL.EXE, HAL.DLL, NTDLL.DLL etc to avoid the system being locked and drivers specific for the XBOX.
-----------------------------------------------------------------------------------------------------------------------------

The only further modification would be the inclusion of project specific APIs that are required by my program's end result: these include Message Passing Interface, Terminal Services Device Redirector, and Vitual SMP code written into the NTOSKRNL itself so that such is executed within privileged RING 0. This code is required to make all the cluster salve node XBOX's devices (CPU, HDD, RAM, DVD, etc) "divert" transparently to the primary domain controlling server. Ultimately we want the end machine to seemlessly "see" these devices as being local and for the server to have full ownership. Using 9 XBOX slaves for example, and 1 Windows 2003 Compute Cluster Server/Windows 2000 ADS, the Server Machine would see it had 10 CPUs (Virtual SMP code into kernel) as well as 10 DVD drives and 10 HDDs etc... I am presuming a combination of MPI,SMP,and Device Redirection code written into NTOSKRNL could allow such to be achieved by initing these as described during phase 0.
------------------------------------------------------------------------------------------------------------------------------
May I please ask torne why do you state using Windows leaked source would be a bad plan -
are you stating this from a perspective of computer science or law and ethics ?

furthermore,

what made you state that it appears i dont know what needs to be done to start ?

am i misunderstanding your concept of modifying the NTLDR, NTOSKRNL, and HAL to make windows boot ?

did you understand the WinCE-OS as "superBIOS-on-LPC" concept was to act as nothing more than an extended firmware device providing a layer to STOP windows' PCI scans reaching the XBOX hardware and to report back to the LDR/KRNL/HAL that such scans were completed ok ?

is this not possible - to use an intermediate layer (winceOS or even XBE application) to "trick" windows into moving on past the PCI scan phases through a null emulation as such ?















#6 nt authority

nt authority

    X-S Enthusiast

  • Members
  • 10 posts
  • Xbox Version:unk
  • 360 version:unknown

Posted 24 February 2006 - 04:37 AM


Anyway, to keep things simple and after reading through the thread again I think we should focus on the main task and keep an eye on the title "Is anyone Seriously Trying To Get A Full Windows Kernel Running ?"

I AM...

I have installed the MS XBOX SDK into Visual Studio.NET (also with MSDN Universal Subscription tongue.gif) and, for experimental reasons only, have introduced the code from the "leaked" nt 4 source code for the loader subcomponent as found in \nt\private\ntos\boot\

My intention here is to build a DEFAULT.XBE makefile that is an XBOX friendly NTLDR/OSLOADER.EXE

This DEFAULT.XBE will do exactly what NTLDR/OSLOADER.EXE does on a PC, but with all the bugs that stop Win-XBOX working distilled out, and will ultimately await NTOSKRNL.EXE to which it will pass control to once we get to that ---> first things first ---> build the bootstrap.

could someone please tell me:

what build commands/options/settings should be used in VS.NET so this does build ?

what modifications should be made to the dirs/makefile/sources so this does compile into an XBE ?

what modifications need to be done so that, when NTOSKRNL.EXE receives control, it is able to do such low level things such as CPU initialization even though the XBOX has already done a processor initialization ?



#7 torne

torne

    X-S Expert

  • Members
  • PipPipPip
  • 684 posts
  • Location:London, UK
  • Interests:Reverse engineering, Linux, crazy operating systems voodoo, embedded development
  • Xbox Version:v1.1
  • 360 version:v1 (xenon)

Posted 24 February 2006 - 02:12 PM

QUOTE(nt authority @ Feb 24 2006, 02:29 AM) View Post

I am currently working within a team of consultants with a Private Corporation who require massive computing power for processing specific tasks I can not mention as this company's client is a Government Department and, as I am under a NDA with secrecy provisions, doing such would be breaking the law.

Then sign a Shared Source agreement with MS and build your own Windows from the real code. Seriously dude, you wouldn't need help from some random xbox forum if that were the case wink.gif

QUOTE

May I please ask torne why do you state using Windows leaked source would be a bad plan -
are you stating this from a perspective of computer science or law and ethics ?

I have been told by various people that the source is not complete and does not correspond to a stable build; I have intentionally avoided looking at the leaked code for legal reasons. Creating a derived work of Windows based on an illegal source code distribution is an invitation to get sued really hard, especially on a public forum wink.gif

QUOTE

did you understand the WinCE-OS as "superBIOS-on-LPC" concept was to act as nothing more than an extended firmware device providing a layer to STOP windows' PCI scans reaching the XBOX hardware and to report back to the LDR/KRNL/HAL that such scans were completed ok ?

You can't do that. PCI bus probing is done by Windows mapping particular physical addresses (the PCI controller's mapping regions) and writing/reading them. This does not go through any BIOS or intermediate layer; the only way to prevent this reaching the hardware is to modify Windows, or to virtualise the entire machine. Windows does not depend on any BIOS services once NTLDR has proceeded far enough to enter protected mode, which is *very early* in the boot process and thus there is nothing you can substitute, it simply talks to the hardware directly.

The clustering application you talk about would be mind-bogglingly difficult to implement even with a full copy of the Shared Source tree. With binaries or partial leaked source you may as well give up now.

QUOTE

I have installed the MS XBOX SDK into Visual Studio.NET (also with MSDN Universal Subscription tongue.gif) and, for experimental reasons only, have introduced the code from the "leaked" nt 4 source code for the loader subcomponent as found in \nt\private\ntos\boot\

So you have a stolen SDK to compile some stolen source with, good for you wink.gif

There's no sensible reason to use the Xbox SDK even if you had a legal copy, of course; it would be far more sane to take the approach used by Cromwell and have the loader become the OS as soon as possible, rather than depending on the Xbox kernel for functionality - it would probably be easiest to start off without making it an XBE at all, but by making it a BIOS replacement as with the normal Cromwell build - throw the Xbox kernel out completely. Hell, base it on Cromwell. wink.gif

Building NTLDR is not really first-things-first. It would be more useful to ignore it and to instead devise a prelinking stage run on a development PC, which would take the required files and turn them into a prelinked image (registry and all) ready to run from a particular address under a particular set of virtual address mappings. A tiny stub executable with almost none of the functionality of NTLDR that just installs the correct mappings and hits the entry point would do.

NTLDR assumes all kinds of things are present that just aren't on the Xbox, you are not going to make rapid progress starting from it.

QUOTE

what build commands/options/settings should be used in VS.NET so this does build ?

Windows code is not built by Visual Studio but by an extremely complex set of custom build scripts inside the source tree. I have no idea how you would get it to run from VS.

QUOTE

what modifications should be made to the dirs/makefile/sources so this does compile into an XBE ?

You have no idea, do you. What about "start again from scratch"? wink.gif

QUOTE

what modifications need to be done so that, when NTOSKRNL.EXE receives control, it is able to do such low level things such as CPU initialization even though the XBOX has already done a processor initialization ?

NTOSKRNL doesn't *do* CPU initialization or anything else 'low level'. Those things are done by the PC BIOS long before NTLDR even takes control, and NTLDR is the one responsible for creating the basic kernel page tables and enabling protected mode.

It's readily apparant that you know nothing about the Windows boot process; I suggest you read the book I linked in my previous post. wink.gif


Looks like the answer to my question is 'nobody'. Bah.

#8 x-fox

x-fox

    X-S Senior Member

  • Members
  • PipPip
  • 206 posts

Posted 25 February 2006 - 06:49 AM

QUOTE(torne @ Feb 24 2006, 03:19 PM) View Post

Looks like the answer to my question is 'nobody'. Bah.


Of course the answer is nobody. I don't realy think you had to ask the question. Just a flick arround this forum reveals there is nobody with the required tools and most importantly skills (me included) (you maybe excluded) to port windows to the xbox. Sure there has been plenty of ideas, some good (reactos and win98 emulated), some outragiously silly (windows XP with 64MB biggrin.gif ), some damn right stupid.

This windows forum has been seriously pruned of late. It doesnt take genious to work out why that is.
Anyway getting back to your question. It does sound like you are the first one who has put forward some good ideas. But it also sounds like you are not prepared to act upon them. So can I ask why you did ask the question. Do you have something in mind for which you are trying to drum up some support?

Edited by x-fox, 25 February 2006 - 06:50 AM.


#9 torne

torne

    X-S Expert

  • Members
  • PipPipPip
  • 684 posts
  • Location:London, UK
  • Interests:Reverse engineering, Linux, crazy operating systems voodoo, embedded development
  • Xbox Version:v1.1
  • 360 version:v1 (xenon)

Posted 25 February 2006 - 01:59 PM

QUOTE(x-fox @ Feb 25 2006, 05:56 AM) View Post

This windows forum has been seriously pruned of late. It doesnt take genious to work out why that is.

I guess.

QUOTE

Anyway getting back to your question. It does sound like you are the first one who has put forward some good ideas. But it also sounds like you are not prepared to act upon them. So can I ask why you did ask the question. Do you have something in mind for which you are trying to drum up some support?

I asked because I'd like to help someone do it.

The part of the process I can't actually *do* is to disassemble the kernel and related bits in order to remove the problematic parts that kill the xbox, as mentioned above. I can't do this in good faith because I'm tainted by having seen and worked on the source code for those very components, and thus reverse-engineering them would in all likelihood be considered a violation of the NDA (or at least, it would be hard to prove that I *didn't* use my knowledge of the code to aid the process...)

The rest of the process - getting a bootloader working, implementing device drivers, etc - I am perfectly able to contribute to, as the information required is publically available (on MSDN, published in books, etc).

So, what would be handy would be someone who knows about, and has the tools for, reverse engineering binaries, who knows as much about the Windows internals as possible without having been exposed to the source, who can then do the binary hacking parts smile.gif
Though, knowing about Windows would probably be optional, since there are plenty of sources I can point to (the above-mentioned book, the DDK, etc) for information, and much of the symbolic information for the binaries is available.

Oh, and who says Windows XP in 64MB is stupid? As has been previously mentioned, Windows is more componentised than most people are aware of (e.g. XP Embedded) and it's possible to exclude an awful lot if you are building a system image from scratch. Using an older kernel (2000?) may be more reasonable, but I'd think it would be easier to port an NT-based kernel than a consumer Windows (98, etc) - NT is much better at platform independance, having been ported to multiple architectures and systems in the past - there are far less assumptions about PC hardware present in the core system.

Edited by torne, 25 February 2006 - 02:03 PM.


#10 windowsex

windowsex

    X-S Enthusiast

  • Members
  • 3 posts

Posted 25 February 2006 - 07:08 PM

QUOTE(torne @ Feb 25 2006, 01:06 PM) View Post

I asked because I'd like to help someone do it.


I hereby sign myself up for this role;

lets start this project already;

how are we going to begin ?

wink.gif

#11 torne

torne

    X-S Expert

  • Members
  • PipPipPip
  • 684 posts
  • Location:London, UK
  • Interests:Reverse engineering, Linux, crazy operating systems voodoo, embedded development
  • Xbox Version:v1.1
  • 360 version:v1 (xenon)

Posted 25 February 2006 - 07:49 PM

QUOTE(windowsex @ Feb 25 2006, 06:15 PM) View Post

I hereby sign myself up for this role;

lets start this project already;

how are we going to begin ?

Hehehe.

1) Grab a (good) disassembler, a windows internals book, and copies of ntdetect, ntldr, ntoskrnl, and a uniprocessor non-ACPI HAL. Rip said binaries apart with the aid of the symbol files from msdn/resource kits and see if anything is even vaguely comprehensible to you.

2) Write xbox code to replace the virtual memory map, segment descriptors, etc, with the ones that the regular NT kernel expects, then work out what format ntdetect outputs its hardware info in and write a fake set for the xbox (ntdetect will never run, all that probing), load some binaries (kernel, hal might be enough to start, it would be interesting to see how far it got without drivers or a registry) to the places ntldr would've put them, run it, see what happens. Easiest would be to insert the binaries you are going to load into the xbe/bios that you are writing, to save you having to access the disk yourself; that way everything can be neatly kept as just RAM accesses and no drivers, or use of the xbox kernel, are required in the loader.

3) When it blows up in a big flaming heap, laugh merrily and realise you can't run the kernel debugger due to it requiring a serial UART. Start hacking up the kernel code to introduce some kind of primitive debug output a la printf, perhaps by changing the background colour of the framebuffer or some other hideous hack that communicates very little information.

Step 2 is the one that's gonna be fun, but will undoubtedly involve lots of disassembly. If someone can get the kernel to start coming up, and communicating some progress information (by hacking the binary) then I can probably help from there, but I can't tell you anything about the boot process that isn't available from books or MSDN - anything else I know about it is from reading the source - so you'll have to figure out the missing pieces from the binaries (oh goody).

Heh.

#12 nt authority

nt authority

    X-S Enthusiast

  • Members
  • 10 posts
  • Xbox Version:unk
  • 360 version:unknown

Posted 14 March 2006 - 05:40 PM

all i ask:

torne could you (or anyone here) please at least humour me with a genuine answer to this scenario:

for arguments sake, a given person or body of persons incorporated wish to create a DEFAULT.XBE
and as such remain within the xboxkrnl and not use any alternative bios or other method to bootstrap

these persons or body of persons have a genuine or "complex" debug xbox kit connected to a development machine running a licensed, legitimate, and legal installation of the MS Xbox SDK in Visual Studio.NET

these persons or body of persons have, again for arguments sake, permission to use windows source code in writing from MS

so, now, the question is:

whilst remaining within the xboxkrnl would it be possible to create a DEFAULT.XBE based on the source contained in the dir \private\ntos\boot\ which normally produces NTLDR/SETUPLDR.BIN/OSLOADER.EXE so that such a DEFAULT.XBE could bootstrap the machine onto a modified xboxkrnl friendly ntdetect, ntoskrnl, driver set, registry, and finally onto SMSS.EXE, CSRSS.EXE and WINLOGON.EXE to complete the boot ?

This is all I want to know: a DEFAULT.XBE could, even if MS had to write it and as if it were the starting point on a normal xbox dvd game, bring Windows (ie the 2003 WINPE) into life ?













#13 nt authority

nt authority

    X-S Enthusiast

  • Members
  • 10 posts
  • Xbox Version:unk
  • 360 version:unknown

Posted 15 March 2006 - 09:29 AM



ok, just to make my question clear, i thought i would add this:

With WinCE.NET (proof of concept) for the XBOX, as released on P2P networks and readily available,
a DEFAULT.XBE bootstraps the NK.BIN binary image build (NK.NB0) and NK.EXE (Windows CE Kernel) is executed.

I am just wanting to know if it is possible to do the same for a Full Windows Kernel, regardless of wether or not it is the best way. My question simply asks if it is possible to use the normal debug kit setup with MS owned xboxkrnl.exe firmware bootstrap bios and XDK debug dash and not some third party alternative like crom and still boot into Windows as if it were any other xbox application or game.

In this scenario the debug xbox is connected to Visual Studio.NET with a legal XDK installation using xbox windows-explorer-shell extensions (Add an Xbox...) over standard Ethernet TCP/IP. The Ethernet connection allows one to reset the xbox from windows explorer as well as download an executable built in VS.NET-XDK and debug this application by attatching the debugger to the process.

Now, want I want to know is, could someone make a DEFAULT.XBE boot loader and strap based on the source in \private\ntos\boot\ (assuming they had permission from MS) that could bootstrap the machine just like the normal NTLDR/SETUPLDR.BIN/OSLOADER.EXE ?

Of course all the PCI probing would be removed and a friendly HAL created but otherwise we are speaking of a DVD-9 xISO media that is identical to any other Xbox game disk.

This disk is the Windows 2003 Preinstallation Environment (WINPE) on proper Xbox DVD media containing a root directory DEFAULT.XBE that when executed brings ...\I386\SYSTEM32\NTOSKRNL.EXE into execution and skips the ETFSBOOTsector and ...\I386\SETUPLDR.BIN which is not required to be called thanks to the DEFAULT.XBE containing the equivalent xboxkrnl friendly boot code.

I dont think I can make my question any clearer.

This may not be the most logical way to go about getting Windows to work on the xbox but I would nevertheless appreciate an answer as I am confused as to how Windows CE "boots" on the xbox using a DEFAULT.XBE when, in reality, the xbox has already booted:

is the CE kernel running on top of the xboxkrnl ?

if so, is it possible to make an equivalent XBE to bring up ntoskrnl ?

can applications in WinCE make calls to the CE kernel that could be passed down to the xboxkrnl to, for example, allow a WinCE application to make use of functionality native to the xbox like those functions for XBOXLIVE ?















#14 torne

torne

    X-S Expert

  • Members
  • PipPipPip
  • 684 posts
  • Location:London, UK
  • Interests:Reverse engineering, Linux, crazy operating systems voodoo, embedded development
  • Xbox Version:v1.1
  • 360 version:v1 (xenon)

Posted 15 March 2006 - 06:02 PM

QUOTE(nt authority @ Mar 14 2006, 04:47 PM) View Post

whilst remaining within the xboxkrnl would it be possible to create a DEFAULT.XBE based on the source contained in the dir \private\ntos\boot\ which normally produces NTLDR/SETUPLDR.BIN/OSLOADER.EXE so that such a DEFAULT.XBE could bootstrap the machine onto a modified xboxkrnl friendly ntdetect, ntoskrnl, driver set, registry, and finally onto SMSS.EXE, CSRSS.EXE and WINLOGON.EXE to complete the boot ?

This is all I want to know: a DEFAULT.XBE could, even if MS had to write it and as if it were the starting point on a normal xbox dvd game, bring Windows (ie the 2003 WINPE) into life ?


You're confusing several issues. You would need to write a *totally new* loader, from scratch. It could be a default.xbe, if you wanted. But, you aren't going to be able to use the code from ntos\boot to do it; that code is assuming it has a legacy PC environment to use to bootstrap itself. That code would be a handy reference to what you needed to do, of course, if you had the legal permission to use it.

#15 torne

torne

    X-S Expert

  • Members
  • PipPipPip
  • 684 posts
  • Location:London, UK
  • Interests:Reverse engineering, Linux, crazy operating systems voodoo, embedded development
  • Xbox Version:v1.1
  • 360 version:v1 (xenon)

Posted 15 March 2006 - 06:14 PM

QUOTE(nt authority @ Mar 15 2006, 08:36 AM) View Post

With WinCE.NET (proof of concept) for the XBOX, as released on P2P networks and readily available,
a DEFAULT.XBE bootstraps the NK.BIN binary image build (NK.NB0) and NK.EXE (Windows CE Kernel) is executed.

I don't have this and haven't read about it. Not that interesting.

QUOTE

I am just wanting to know if it is possible to do the same for a Full Windows Kernel, regardless of wether or not it is the best way. My question simply asks if it is possible to use the normal debug kit setup with MS owned xboxkrnl.exe firmware bootstrap bios and XDK debug dash and not some third party alternative like crom and still boot into Windows as if it were any other xbox application or game.

There's no meaningful technical difference between using the xbox kernel, debug or retail, and using cromwell, as a boot environment. Both are about to be replaced by another OS image anyway. The only difference is the legal one; code based on Cromwell is legal to distribute under the GPL, code based on the XDK has the well-known problems. This is why I suggested using Cromwell.

QUOTE

This disk is the Windows 2003 Preinstallation Environment (WINPE) on proper Xbox DVD media containing a root directory DEFAULT.XBE that when executed brings ...\I386\SYSTEM32\NTOSKRNL.EXE into execution and skips the ETFSBOOTsector and ...\I386\SETUPLDR.BIN which is not required to be called thanks to the DEFAULT.XBE containing the equivalent xboxkrnl friendly boot code.

You can't just skip the boot sector, you need to skip pretty much the whole of NTLDR. It does very xbox-unfriendly things with the hardware.

QUOTE

This may not be the most logical way to go about getting Windows to work on the xbox but I would nevertheless appreciate an answer as I am confused as to how Windows CE "boots" on the xbox using a DEFAULT.XBE when, in reality, the xbox has already booted:

is the CE kernel running on top of the xboxkrnl ?

I don't know a great deal about CE, it's a totally different and unrelated codebase that I've never worked with, and as I mentioned I've not used the xbox port of it. But, I would assume that it takes control of supervisor mode, all interrupt vectors, and so on, which effectively 'replaces' the xbox's kernel. A Windows NT port would do the same. You can't run one OS kernel 'on top' of another without either the host kernel being adapted to virtualise/emulate the hardware (vmware/qemu/etc approach) or the guest kernel being adapted to run in a lower ring as an application (xen/uml approach).

If you don't understand how one OS image can replace another in memory without needing the system to reboot, then you really don't have anything like the required level of technical expertise to do this project. By the time a normal Windows PC has booted there have been a large number of programs that have been the supervisor for brief periods: the BIOS, the master boot record, the partition boot sector, NTLDR, OSLOADER, NTOSKRNL... all these run in ring 0 with complete control of the hardware and can thus be considered to be an OS image wink.gif

You may want to look into kexec for Linux, which is a mechanism whereby a Linux kernel can replace itself with another Linux kernel while the machine is running (all userspace processes die, it's equivalent to a shutdown and restart except control is handed directly from one kernel to the other without the PC rebooting or the bios getting a look in). That may enlighten you as to how the hardware-initialisation phase of an OS startup is independent of the initialisation of the OS software.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users