Jump to content











Photo
- - - - -

Busting the Myth about ramdisk.sys - XP/2003


  • Please log in to reply
60 replies to this topic

#26 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 27 October 2009 - 09:13 AM

Any idea how to adjust the pointer for for SP1/SP2 NTLDR. So we can get rid ARC Path and have full x64 Support?


Are you implying there exist such a patch for SP0?

Are you referring to 2003 or xp ntldr (should not matter anyway)?

What pointer do you mean, inside ntldr (osloader.exe) itself?? If yes, then execution flow can be controlled to your likes...if we just locate the address of that function.

Joakim

#27 was_JFX

was_JFX

    Frequent Member

  • Advanced user
  • 483 posts
  •  
    Germany

Posted 27 October 2009 - 05:01 PM

Sorry I mean the 2003 NTLDR's. Since sp1 version there is no longer the need of using the ARC PATH for /RDPATH, what make usage much easier.

As most of our setupldr pachtes (MultiCPU/Wimboot/CAB optimation) are done for the setupldr from 2003 sp1, I think this one would be the most interesting.

The ntldr of 2003 sp1, the line is on offst 0x18562

00419162 mov dword ptr [eax], 20000h

but to what value change the 20000h, I mean want actually does the change for sp0 version do?

#28 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 27 October 2009 - 11:13 PM

It makes it a little bit tedious to disassemble ntldr/setupldr since we cannot easily debug execution of ntldr/setupldr itself , and are stuck with an assembly deadlisting. My own experience, and knowledge in general, about 64-bit, is close to nothing and thus makes it harder than necessary to follow the code, since I don't really know what I am trying to achive with what you've mentioned. And it makes no sense to me to patch something when I cannot test it afterwards.

Since you already have the address of what you believe is the critical place, why not just do some "trial and error" with patch -> rebuild -> reboot.

There are substantial amount of code packed in those 250-300 Kb files...enough to get confused..

I am also trying to isolate nikzzzz's wimboot patch in setupldr.bin and see if "Universal XP" can be wimbooted with ntldr. I am also trying to modify the "boot.ini menu editor patch" to ntldr, from the chinese site.

Then it would be cool to have one ntldr capable of;
- editing boot.ini
- wimbooting
- rambooting over 512 Mb
- and more crazy things


Joakim

#29 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 28 October 2009 - 12:18 PM

The size patches for sp2 5.2.3790.3959 are not complete. They work in the 600-700 Mb range but are not good enough. The result is also dependant upon available/reserved ram on your test system (one value will not ramboot with some given ram, while the same value will ramboot with more ram available).

For those willing to test it, you need these relative addresses (with 16bit stub cut off);

for ntldr look at
004186D5

for setupldr look at
00314143

Remember to update checksum before merging the 16bit stub again.

I would be happy to get feedback and thoughts about this. :confused1:

Joakim

#30 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 28 October 2009 - 06:06 PM

How do you solve the problem that ntldr can't use tag files to identify the correct drive to boot from?

:confused1:

#31 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 28 October 2009 - 06:36 PM

How do you solve the problem that ntldr can't use tag files to identify the correct drive to boot from?


I haven't solved it and I have never even tried.

If you or someone could explain what the actual issue is, then maybe we could come up with something.

I believe it should be possible to write such code and add it at the end of last section or as a new last section, and make a call for it at the appropriate place. Problem is to find a volunteer capable of creating this..

Joakim

#32 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 28 October 2009 - 07:32 PM

The problem is that one needs to tell the loader from where to boot.
ntldr needs the arcpath, which changes from machine to machine.
setupldr scans all available drives and uses a tagfile to identify the right drive to boot from.

A way to say, use this drive, does not exist as far as iknow.


:confused1:

#33 dog

dog

    Frequent Member

  • Expert
  • 236 posts

Posted 28 October 2009 - 08:16 PM

Remember to update checksum before merging the 16bit stub again.
I would be happy to get feedback and thoughts about this. :confused1:

Can you use the setupldr patch to avoid messing with checksums?
http://www.msfn.org/...tml#entry580692

I reckon more people could play if there was a patch or offset to test with xp ntldr or setupldr, I'd certainly give it a go.

#34 was_JFX

was_JFX

    Frequent Member

  • Advanced user
  • 483 posts
  •  
    Germany

Posted 28 October 2009 - 10:20 PM

I reckon more people could play if there was a patch or offset to test with xp ntldr or setupldr, I'd certainly give it a go.

XP SP3 NTLDR
offset exe: 0x12FDC

offset with stub: 0x17C9C

change 0002 to 8007
For setupldr this makes no sense, i only allows to load an image through txtsetup.sif, so there no booting from this image (possible).

EDIT: real offset is changes on different languages, so here's virtual offset: 00413BD5

#35 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 28 October 2009 - 10:42 PM

The 16-bit stub is identical for each set of ntldr/setupldr.bin but may vary for different versions. The last 2003 sp2 stub is exactly 20080 bytes. Or just search for the letters MZ with a hex editor and cut off everything before MZ. This can be cut off before loading the 32-bit part into a disassembler (IDA undoubtedly the best). The 16-bit stub looks for and calculate the crc of the 32-bit part, and fail to load if crc is not correct. The crc test in the stub is the only integrity check performed (you can modify everything). Mixing 16-bit stubs over different versions may not always work.

After any modification of 32-bit part, correct the crc. It is 4 bytes reversed starting at physical hex offset 128. I usually do this with my favourite PE editor (PEiD with fixcrc.dll plugin). LordPE has also always been good.

After modification is finished, merge the 2 parts with;

copy /b 16.stub+ntldr.exe ntldr

or

copy /b 16.stub+setupldr.exe setupldr.bin

The problem with setupldr.bin of XP is it cannot properly read winnt.sif (and therefore ramloading don't work).

Joakim

#36 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 28 October 2009 - 10:52 PM

The virtual address of the size patch for 2003 sp1 (5.2.3790.1830) is;

setupldr.bin
00314BBE

which eqiuvalents to physical offset;
13FBE

Joakim

#37 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 29 October 2009 - 12:47 PM

The problem with setupldr.bin of XP is it cannot properly read winnt.sif (and therefore ramloading don't work).

What exactly do you mean by "cannot properly read winnt.sif"?

btw. Everything you usually write into winnt.sif can also be written into txtsetup.sif.

:confused1:

#38 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 29 October 2009 - 01:19 PM

What exactly do you mean by "cannot properly read winnt.sif"?

btw. Everything you usually write into winnt.sif can also be written into txtsetup.sif.


What I mean is setupldr.bin of XP (any version) cannot read winnt.sif, and jumps directly to txtsetup.sif (even though both is present). Entries like RDPATH (and ramboot related entries like RDIMAGEOFFSET) will crash your PE if put into txtsetup.sif. Remember txtsetup.sif was supposed to be inside the mapped ramdisk, so if you had a RDPATH inside txtsetup.sif that supposedly worked, then you could, at least in theory, perform nested rambooting (disk image inside disk image, etc), which is possible with grub4dos "--map mem" and "memdisk raw", but is stupid and makes no sense except as testing for the fun of it. So that's maybe why MS has blocked this. But as far as I know it is not possible with setupldr/winnt.sif/txtsetup.sif. Definetely not rambooting through txtsetup.sif (gives an I/O error). Also verified on 2003 version of setupldr.bin.

Joakim

#39 Rinrin

Rinrin
  • Members
  • 8 posts
  •  
    China

Posted 29 October 2009 - 01:33 PM

I am also trying to modify the "boot.ini menu editor patch" to ntldr, from the chinese site.

Are you referring to my patch? :confused1:

#40 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 29 October 2009 - 01:34 PM

I use a winnt.sif parameter in txtsetup.sif to tell NaughtyPE to boot off a folder called Windows, instead of a folder called i386.
Works without problems.
Can you PM me the XP ramdisk driver that works with ntldr, then i look into the setupldr problem.


:confused1:

#41 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 29 October 2009 - 01:38 PM

Are you referring to my patch? :confused1:


Yes I am.

I had a quick look at it and located the areas that you've patched. I also repatched the english version to accept UNSUPPORTEDDEBUG.

Could you please explain what it actually does? Because when I boot with "your" patched ntldr, then nothing happens when typing UNSUPPORTEDDEBUG. How do you force activate the "write mode"?

Joakim

#42 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 29 October 2009 - 02:07 PM

I use a winnt.sif parameter in txtsetup.sif to tell NaughtyPE to boot off a folder called Windows, instead of a folder called i386.
Works without problems.


That is because you are not rambooting NaughtyPE, ok?

#43 Rinrin

Rinrin
  • Members
  • 8 posts
  •  
    China

Posted 29 October 2009 - 02:31 PM

Could you please explain what it actually does? Because when I boot with "your" patched ntldr, then nothing happens when typing UNSUPPORTEDDEBUG.

You can press F10. :confused1:

How do you force activate the "write mode"?

Sorry, I can't remember. may be you should read BlpPresentMenu() function deeply?

#44 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 29 October 2009 - 02:45 PM

You can press F10. :confused1:

Sorry, I can't remember. may be you should read BlpPresentMenu() function deeply?


Thanks for replying. Maybe the google translator did not work correctly. I will try this tonight.

So basically you can choose to enter "write mode" by pressing F10?

Joakim

#45 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 29 October 2009 - 07:19 PM

Here is the modified patch of Rinrin's original. http://www.mediafire..._menu_patch.zip

The patch works on ntldr of english 2003 sp2 (5.2.3790.3959) only.

By pressing F10 after boot.ini is accessed, you will be presented with a screen like this;

Posted Image

You now have commandline access to edit "loadoptions" for each entry in boot.ini. The patch force enables the "edit mode" that otherwise only would be possible given certain conditions and after the typing of UNSUPPORTEDDEBUG when presented with normal menu of boot.ini.

Thanks to Rinrin for great work!

Joakim

#46 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 03 November 2009 - 09:04 PM

Here's was checksum cracked ntldr and setupldr.bin of 2003 sp2;

LINK REMOVED: Microsoft files are NOT redistributable.

No need to update CRC after modification on these.


Joakim

#47 dog

dog

    Frequent Member

  • Expert
  • 236 posts

Posted 04 November 2009 - 09:27 PM

I had success booting a patched xpsp3 ntldr 640MB image in a vm with 1024MB ram, but the same size image reset when booted on 2GB physical ram.

(Moderation is not up for discussion :dubbio: , but I think mods try to avoid Nuno getting nasty letters from lawyers. He's a nice guy :( )

#48 was_JFX

was_JFX

    Frequent Member

  • Advanced user
  • 483 posts
  •  
    Germany

Posted 05 November 2009 - 05:19 PM

I had success booting a patched xpsp3 ntldr 640MB image in a vm with 1024MB ram, but the same size image reset when booted on 2GB physical ram.

Does it load the image before reset? May it is a blue screen caused by different hardware.

I've no problem here using a 1GB image with xpsp3 ntldr.

#49 Brito

Brito

    Platinum Member

  • .script developer
  • 10616 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 05 November 2009 - 06:12 PM

(Moderation is not up for discussion, but I think mods try to avoid Nuno getting nasty letters from lawyers. He's a nice guy)


That's nice to hear, if it's true then I'll have to agree because over these years I was never bothered.

Personally, I think this happens because the community is always moving on a thin line between doing progress in boot disks and trying to respect legal software constraints.

So, the challenge of doing everything in legal terms as you see today is surely bound to bring results that everyone can be proud and enjoy in the public arena one day.

:thumbup:

#50 dog

dog

    Frequent Member

  • Expert
  • 236 posts

Posted 06 November 2009 - 06:37 PM

Does it load the image before reset?

It loads the image, then gets maybe a third of the way through the second white bar before resetting. The progress of the second bar is too quick to measure really. It's not a blue screen, and the image includes
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl]

"AutoReboot"=dword:00000000
so I don't know what's going on.
I tried the xpsp3 image that had worked in vmserver, and one built from a fresh install on the target hardware, same result.
I've not tried other image sizes, 640MB seemed a modest increase over the unpatched 488 or so.
Back to firadisk and winvblock for now...




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users