45 replies to this topic

[L A M A]

I've been busy lately... but this is an interestingly cool thread

...
Traditionally on NT systems the SCSI driver for an actual SCSI card was copied "verbatim" in the Root directory of the boot drive (together with NTLDR, NTDETECT.COM and BOOT.INI) and renamed to "NTBOOTDD.SYS".
If the BOOT.INI has INSTEAD of the nowadays common "multi(0)" entries a "scsi(0)" entry, it will use the NTBOOTDD.SYS to "hook" the SCSI drive(s) at boot time.
...


Wonko

...
So there are potentially multiple uses:

In the problem that Vortex reported whereby Windows Server 2003 was working with neither Firadisk nor WinVBlock, it turned out that GRUB4DOS doesn't protect its INTerrupt 0x13 hook, so it gets obliterated at random by Windows processes during boot, depending on whether its memory happens to be overwritten or not. Without the INT 0x13 hook, the two aforementioned drivers cannot find the GRUB4DOS virtual disks without some new mechanism. Every time a new mechanism is introduced, things will get uglier, in my opinion. Some future version of this NTBOOTDD.SYS could find MEMDISK and GRUB4DOS parameters very early and then pass them on.

Additionally, NTBOOTDD.SYS has access to disks using INT 0x13, so it can scan disks and pass on information concerning which BIOS drive numbers (pre-kernel) correspond to which Windows disks (post-kernel). We want to know this so that we know which backing disks that G4D sector-mapped disks map to.

Another goal for a future version of this NTBOOTDD.SYS would be Microsoft .VHD support for all three VHD types: Fixed, dynamically expanding, differencing. There are still tons of XP computers out there in the world, and it might be nice to boot them from VHDs.

• Base image VHD
• Model-specific VHD difference from 1 (drivers, devices, kernel and HAL choice)
• Computer-specific VHD difference from 2 (this computer's MAC addresses, computer name, Active Directory account, AD Group Policies)
• Session-specific VHD difference from 3 (re-generated at every boot, thus discarding viruses, user profiles, cached AD credentials)

I always tried to figure out how real SCSI cards booted off (INFs, sys files etc) in comparison to firadisk/winvblock but this never came to me... Thanks


Respects: Sha0, Karyonix, Wonko and.... all that've missed.

[Sha0]

Anyway, there are two challenges to overcome using the NTBOOTDD.SYS strategy:

• Even if it works and we can pass very nice information to WinVBlock or FiRaDisk, where should we pass this information? karyonix: Have you any thoughts? I'd thought about abusing the INT 0x13 vector and throwing an address in there, but that seems very ugly.
• I haven't verified for absolute certain, but I believe that NTLDR only allows one file to be open at a time. What this means is that the version attached to the first post has to save NTLDR's file "table" (table of one?!), then open the HDD image file and work with it, then close it, then restore the file "table" so that whatever file NTLDR was working with is back the way it was. NTLDR loads the SYSTEM hive, HAL, kernel, drivers, fonts, etc. This save-and-restore process is very slow!

#2: Wrong! Hurray! I've improved the performance piece and NTLDR does allow for multiple files to be open. The speed is quite acceptable now.

But for #1, I'm still open to ideas. This NTBOOTDD.SYS has to pass information to the better driver, so where's a good place to pass the information? In fact, for a 32-bit system, just passing a single, 4-byte pointer would be sufficient. But where should we put it and where should the better driver look for it?

I won't bother posting a new version until this does something useful, but that depends on figuring out #1... Attached the improved-performance version to the first post in this thread. It has pretty limited use right now... It'll load Windows, but unless a driver provides a boot disk of some sort, you'll get a STOP 0x7B.

[karyonix]

NTLDR somehow passes information to kernel.
(1) parameter from boot.ini
(2) data returned ntdetect.com
(3) loaded files : SYSTEM registry hive, kernel, HAL, boot drivers
Is it possible to attach your data to (1) or (2) ?

I don't know data structure used by NTLDR and don't want to study it. I cannot help much.

[Wonko the Sane]

But for #1, I'm still open to ideas. This NTBOOTDD.SYS has to pass information to the better driver, so where's a good place to pass the information? In fact, for a 32-bit system, just passing a single, 4-byte pointer would be sufficient. But where should we put it and where should the better driver look for it?

If I may we (actually you) could proceed the good ol' way :

• hack something so that we can get the missing step working
• later re-do it properly

In the above view and knowing that it IS a quick and dirty trick, we could use:

• disk signature in the MBR
• almost "spare" bytes in the MBR (originally proposed for the XP Kansas City Shuffle):
  http://www.911cd.net...ic=21242&st=135
  we need to make sure that a NON-Vista /7 MBR is used, the XP one is OK
  http://www.911cd.net...ic=21242&st=139
  (read also karyonix's approach a few posts after the above)
• start of BOOT.INI just like hinted here:
  http://www.msfn.org/...ows/page__st__6
  http://www.msfn.org/...lem/page__st__8
  (though I cannot say what will happen with binary values )
• OEM field of bootsector, if Win9x/Me can ruin any otherwise good floppy and NT does the "cmdcons" trick, why we can't write a value there?

Another thing:
http://www.reactos.o...er_37.html#sec3
have you tried with 2003 (as opposed to XP)?
It would be anyway interesting to nderstand why freeldr supposedly works with 2003 but not with XP....


Wonko

[MedEvil]

(1) Is a brilliant idea. The kernel will write all parameters starting with a / to the registry. So the second stage driver could simply read the values from registry.

[Sha0]

NTLDR somehow passes information to kernel.
(1) parameter from boot.ini

Hmmm... Well the version attached to this post has some minor fun with BOOT.INI. It will look for a [wvbootdd] section in BOOT.INI and it will simply display the section. Just for fun.

(2) data returned ntdetect.com

I don't know where they put it.

(3) loaded files : SYSTEM registry hive, kernel, HAL, boot drivers

True, but messy.

Is it possible to attach your data to (1) or (2) ?

Perhaps there's a way to append to the already-chosen OS load options. I don't know where they are, though.

1. hack something so that we can get the missing step working

Sure. But right now I don't even know of a hack to do which wouldn't be most disagreeable.

2. later re-do it properly

Right.

• disk signature in the MBR

A 32-bit pointer will fit, but a 64-bit pointer won't fit.

• almost "spare" bytes in the MBR (originally proposed for the XP Kansas City Shuffle)...

Post-kernel, when we want to find the image file (file-backed) or contiguous sector range (sector-mapped), we cannot access the MBR because we do not yet have the disk; we are trying to provide it.

• start of BOOT.INI just like hinted here...

BOOT.INI isn't available (that I know of) post-kernel, either.

• OEM field of bootsector, if Win9x/Me can ruin any otherwise good floppy and NT does the "cmdcons" trick, why we can't write a value there?

Hmmm... It's possible that 0000:7C00 might still be intact, post-kernel. El Torito would be out of luck.

Another thing:
http://www.reactos.o...er_37.html#sec3
have you tried with 2003 (as opposed to XP)?
It would be anyway interesting to nderstand why freeldr supposedly works with 2003 but not with XP....

Well, as mentioned, they don't even call NTDETECT.COM, so who knows?

Anyway, attached to this post is a newer version. This one has been pre-patched for the English Windows XP Professional Service Pack 3 NTLDR with MD5 hash C1B29B4E6EEA9510610DB2EC4D6DB160. I am trying to provide a variety.

This version displays any [wvbootdd] section (case-sensitive, please) in BOOT.INI, as well as introduces a dumb "command prompt." The only command available right now is exit, which will continue the boot process. You will still STOP 0x7B unless another driver provides your file-backed disk (hint: Firadisk).

Enjoy. And if you have a different NTLDR version that you'd like to test with, please let me know!

WvbCheckPatchArea(): Done

Experimental NTBOOTDD.SYS by Shao Miller, 2011.

WvbHwScsiFindAdapter(): Entered.

WvbHwScsiFindAdapter(): Passed: ntldr=1;

[wvbootdd]

Hello world.



D exit WvbOpenWinHdd(): WIN.HDD MBR loaded.

WvbHwScsiFindAdapter(): Returning.

WvbHwScsiInitialize(): Entered.

WvbHwScsiInitialize(): Returning.

WvbHwScsiResetBus(): Entered.

WvbHwScsiResetBus(): Returning. Please wait a moment...

scsi(0)disk(0)rdisk(0)partition(1)\WINDOWS\system32\ntoskrnl.exe

scsi(0)disk(0)rdisk(0)partition(1)\WINDOWS\system32\hal.dll

scsi(0)disk(0)rdisk(0)partition(1)\WINDOWS\system32\KDCOM.DLL

...

--- EDIT ---

Attached version was downloaded 19 times. See original post for most recent version.

[Sha0]

I have updated the original post with a new version: 0.0.1.9-DEV. I also have a request for your assistance in that post, if you'd be so kind.

[Wonko the Sane]

Sha0, I am failing to see a "list" of NTLDRs, I see a list of hex strings found by your program:

Found: 7B6D8AB599A57B4784A34D873C4A87D0

Found: B840C1B30F4A6841A5B71FFE37C7F0E4 (cannot be supported)

Found: 70DDF0681786294FB31E7B4B32BDAFDE

Found: 4AFA75F6972FAD4C9350A7AC33EE33F4

MY XP SP2 NTLDR (italian) gives:

Found: 35857FDC63EBE74599311BAEB7F2D624

it is sized 251072.
It has MD5:e4564680ac4bc564f14793ea085c3523

A list should be something *like*:

# S OS SP# Lang FOUND String__________________________: Size_: MD5:

1 Y ?? ??? ???? Found: 7B6D8AB599A57B4784A34D873C4A87D0 xxxxxx ?

2 N ?? ??? ???? Found: B840C1B30F4A6841A5B71FFE37C7F0E4 xxxxxx ?

3 Y ?? ??? ???? Found: 70DDF0681786294FB31E7B4B32BDAFDE xxxxxx ?

4 Y ?? ??? ???? Found: 4AFA75F6972FAD4C9350A7AC33EE33F4 xxxxxx ?

5 ? XP SP2 IT-- Found: 35857FDC63EBE74599311BAEB7F2D624 251072 e4564680ac4bc564f14793ea085c3523

Don't forget to thank the developers of the board software for having completely failed to have CODE tags working, thus needing padding characters as SPACEs or TABs are not anymore left "as they are" inside CODE tags.


Wonko

[Sha0]

Sha0, I am failing to see a "list" of NTLDRs, I see a list of hex strings found by your program:
...
A list should be something *like*:

# S OS SP# Lang FOUND String__________________________: Size_: MD5:

1 Y ?? ??? ???? Found: 7B6D8AB599A57B4784A34D873C4A87D0 xxxxxx ?

2 N ?? ??? ???? Found: B840C1B30F4A6841A5B71FFE37C7F0E4 xxxxxx ?

3 Y ?? ??? ???? Found: 70DDF0681786294FB31E7B4B32BDAFDE xxxxxx ?

4 Y ?? ??? ???? Found: 4AFA75F6972FAD4C9350A7AC33EE33F4 xxxxxx ?

5 ? XP SP2 IT-- Found: 35857FDC63EBE74599311BAEB7F2D624 251072 e4564680ac4bc564f14793ea085c3523

This is too much information for me to ask people for. All I care about is the Found: result. Nevertheless, I've updated the original post according to your suggestion.

MY XP SP2 NTLDR (italian) gives:

Found: 35857FDC63EBE74599311BAEB7F2D624

it is sized 251072.
It has MD5:e4564680ac4bc564f14793ea085c3523

Thanks! Bad news: It can't be supported. Maybe you have another service pack version hidden somewhere? Maybe in WindowsDriver Cachei386*.cab ?

Don't forget to thank the developers of the board software for having completely failed to have CODE tags working, thus needing padding characters as SPACEs or TABs are not anymore left "as they are" inside CODE tags.

D'oh.

[Wonko the Sane]

Two questions, one on topic, and the other one completely Off Topic
How exactly do you get this kind of info?:

5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)

I can find the green one searching with an hex editor, (and it is the same 5.1.2600.2180 for my file) but cannot find the red one.

Since you are "playing" with NTLDR, if you happen to find anything about (or understand what it does) the /rollback parameter:
http://reboot.pro/2362/#entry18878
it would be interesting....

In any case, as I see it, the only use of a "localized" NTLDR is that when it crashes/produces an error the error message will be in your language of choice, otherwise it is a pretty much "silent" piece of code, so I guess everyone could download the English SP2 or SP3 and replace their own "localized" NTLDR.

I'll check if there if I can find an "updated" NTLDR in any of the smaller "fix downloads" from MS maybe there is one that can make the needed download smaller for those that have a non-supported localized version....


Wonko

[Sha0]

Two questions, one on topic, and the other one completely Off Topic
How exactly do you get this kind of info?:

I can find the green one searching with an hex editor, (and it is the same 5.1.2600.2180 for my file) but cannot find the red one.

If Microsoft's Sysinternals' strings doesn't show it up, then it's not in your file. You can extract OsLoader.exe from NTLdr by searching for the MZ signature, then copying from the MZ (including it) to the end of the file. You can then examine the OsLoader.exe details with Explorer.

Since you are "playing" with NTLDR, if you happen to find anything about (or understand what it does) the /rollback parameter:
http://reboot.pro/2362/#entry18878
it would be interesting....

Is there really a mystery? One of your links explains to use it to initiate removal of Windows XP. Yes, it patches the boot-sector, as far as I can see, with the string undo. If SetupLdr is invoked (probably by that boot-sector), it will notice this and remove XP, as far as I can tell.

In any case, as I see it, the only use of a "localized" NTLDR is that when it crashes/produces an error the error message will be in your language of choice, otherwise it is a pretty much "silent" piece of code, so I guess everyone could download the English SP2 or SP3 and replace their own "localized" NTLDR.

I'm not sure why your version isn't possible to support. Maybe you could EXPAND your installation media's i386OsLoader.ex_ and run WNtldr.exe on it? I might expect it to yield the same result, but maybe not!

I'll check if there if I can find an "updated" NTLDR in any of the smaller "fix downloads" from MS maybe there is one that can make the needed download smaller for those that have a non-supported localized version....

Cool! Meanwhile I will try to make WvBootDD a bit more useful, though it does currently load Windows from a flat file called WIN.HDD in whatever directory had NTLdr, and so is useful for the "XP Kansas City Shuffle."

[Wonko the Sane]

Cool! Meanwhile I will try to make WvBootDD a bit more useful, though it does currently load Windows from a flat file called WIN.HDD in whatever directory had NTLdr, and so is useful for the "XP Kansas City Shuffle."

Good.

What about using httpdisk on:
http://www.microsoft...s.aspx?id=25129
for the SP3 version?
(not tested )
(but I'll see if I can find something smaller/faster to download)


Wonko

[Sha0]

What about using httpdisk on:
http://www.microsoft...s.aspx?id=25129
for the SP3 version?

Yes, you can use httpdisk with that .ISO, then extract OSLoader.PDB.Exe from the disc's SupportSymbolsSymbols.Cab. Such a module can be loaded with Debugging Tools for Windows' DBH command, to be inspected for the special PdbSig70 value. The one you've referenced is already supported.

Using 7-Zip on the service pack executable requires decompressing all the files that come before OSLoader.Exe, unfortunately.

[Wonko the Sane]

Yes, you can use httpdisk with that .ISO, then extract OSLoader.PDB.Exe from the disc's SupportSymbolsSymbols.Cab. Such a module can be loaded with Debugging Tools for Windows' DBH command, to be inspected for the special PdbSig70 value. The one you've referenced is already supported.

Using 7-Zip on the service pack executable requires decompressing all the files that come before OSLoader.Exe, unfortunately.

I am sorry, I dont get it.
I thought that you (we) were after:
xpsp3_5512.080413-2113_usa_x86fre_spcd.isoWINDOWSXP-KB936929-SP3-X86-ENU.EXEi386ntldr
but yes, in any case having not a "direct" unpacking means to have to transfer the whole WINDOWSXP-KB936929-SP3-X86-ENU.EXE or the bigger part of it....


Wonko

[Sha0]

I am sorry, I dont get it.
I thought that you (we) were after:
xpsp3_5512.080413-2113_usa_x86fre_spcd.isoWINDOWSXP-KB936929-SP3-X86-ENU.EXEi386ntldr

All I care about is a particular signature. Since NTLdr contains OsLoader.Exe and the OsLoader .PDB was available outside of the service pack executable, but inside the symbols .CAB, it is certainly more easily accessible. So if you happen across any more of these downloads, please do let me know, so I can collect more signatures.

It's too bad NTLdr isn't named AALdr, as the service pack executable appears to have the files compressed alphabetically.

I believe that you were actually discussing how anyone else could obtain an NTLdr that's supported by WvBootDD. I just so happened to try it out and noticed it was a possible method for me to collect the signatures.

I did more WvBootDD development yesterday and earlier today. Then I started experimenting with using it over the network. Perhaps interestingly, anyone with a legitimate copy of Windows XP or Windows Server 2003 that has a supported NTLdr should be able to do some interesting stuff.

• Create a C:TFTPDRoot directory
• In the installation disc's I386 directory...
  
  • startrom.n1_ : expand to c:tftpdrootstartrom.n12
  • osloader.ex_ : expand to c:tftpdrootntldr
  • ntdetect.com : Copy to c:tftpdrootntdetect.com
  • tftpd.ex_ : expand to c:WindowsSystem32TFTPD.exe
• Create and start the TFTPD service
  

  
  sc create TFTPD binPath= c:windowssystem32tftpd.exe
  
  net start tftpd
  
  

• Allow the TFTP service through any firewall (UDP 69)
• Create C:tftpdrootBoot.Ini:
  

  
  [boot loader]
  
  timeout=10
  
  default=net(0)windows
  
  
  
  [operating systems]
  
  net(0)windows="net(0)windows" /fastdetect /sos
  
  scsi(0)disk(0)rdisk(0)partition(1)WINDOWS="WvBootDD" /fastdetect /sos
  
  

• Copy a future version of WvBootDD.Sys as c:tftpdrootntbootdd.sys
• Configure your network's DHCP service
  
  • to provide startrom.n12 as the boot filename
  • to provide the computer with c:tftpdroot as the TFTP server
• PXE-boot another computer on the same network

Then you could invoke WvBootDD without installing it to a hard disk drive, but it could access an NTFS volume on a hard disk drive.

Nothing new, but now for some random notes:

NTLDR, OSLOADER, SETUPLDR, NTDETECT.COM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I386 contains:

• NTDETECT.COM #1
• NTLDR
  
  • Real-mode #1
  • OSLOADER.EXE #1
• OSLOADER.EX_
  
  • OSLOADER.EXE #2 (only slightly different than #1)
• OSLOADER.NT_
  
  • OSLOADER.NTD
    
    • OSLOADER.EXE #3 (a bit different than #2)
    • NTDETECT.COM #1
• SETUPLDR.BIN
  
  • Real-mode #1
  • SETUPLDR.EXE #1
• SETUPLDR.EX_
  
  • SETUPLDR.EXE #2 (only slightly different than #1)

[Wonko the Sane]

My memory is getting worse and worse.
I seemed to remember that there was a "small" downloadable update (post SP2 and pre SP3) containing NTLDR, but I seem like not finding it anymore.
There is one which is seemingly post SP1 and pre SP2, and that is actually an hotfix (which MS may send you a link to through e-mail):
http://support.micro...kb/328269/en-us

Update: the hotfix is made of two files, the NTLDR in both is 233120 bytes in size:
2002-10-15 Found: 8BD7A02F7C98054C8F260BF64BB85638 5.1.2600.1123 MD5 = f56cdf28414a5d85197eee3c81b7ff59
2003-11-10 Found: 254F58C12453B444B13F526A106A38FE 5.1.2600.1319 MD5 = 0bdf2f2e41c765735f6eca7d365b906c

Note: these are the English versions, there are several langiages available.


Wonko

[Sha0]

Update: the hotfix is made of two files, the NTLDR in both is 233120 bytes in size:
2002-10-15 Found: 8BD7A02F7C98054C8F260BF64BB85638 5.1.2600.1123 MD5 = f56cdf28414a5d85197eee3c81b7ff59
2003-11-10 Found: 254F58C12453B444B13F526A106A38FE 5.1.2600.1319 MD5 = 0bdf2f2e41c765735f6eca7d365b906c

Thanks! Unfortunately, neither of those appear to be supportable. This isn't a good start...

[Sha0]

Wonko the Sane: Well it turns out that it's not that your NTLdr can't be downloaded, it's that decision-makers at Microsoft decided not to allow downloading symbols for the OsLoader.Exe component, at some point in recent history. Or I could be misremembering, though if that is the case, I don't know quite recall how I obtained them. You can still download the symbols for Notepad.Exe, for example. Now I wonder why they stopped offering it...

Fortunately, you probably have the information that I need for WvBootDD inside your installation media's SupportSymbolsSymbols.Cab file. It's just not as easy to get at as simply running WNtldr.Exe would have been.

Also, someone might have a collection of lots of these symbols files.

To the Microsoft decision-maker(s) responsible for removing the OsLoader symbols: Please put them back. Thank you.

[Icecube]

Because the PDB files for osloader.exe seems to be disappeared from Microsoft's website, I wrote a magic file for binwalk to find the offsets of the function and the RVA of the objects in osloader.exe that WvBootDD wants to call.

$ binwalk -m osloader.magic osloader/*/*.exe



Scan Time: Nov 16, 2012 @ 02:14:24

Magic File: osloader.magic

Signatures: 6

Target File: osloader/F675FA4A2F974CAD9350A7AC33EE33F41/osloader.exe

MD5 Checksum: d29026b5704a38cba958258c0fd48302



DECIMAL HEX	 DESCRIPTION

-------------------------------------------------------------------------------------------------------

1024	 0x400 To get the right RVA for a function: (0x400000 - this offset + offset of function)

16934 0x4226 BlClose

17564 0x449C BlOpen

17686 0x4516 BlRead

17730 0x4542 BlSeek

21716 0x54D4 BlPrint

22653 0x587D AEOpen

27691 0x6C2B AEBiosDisabled: 0x436a60

62256 0xF330 BlFileTable: 0x468dc0

89587 0x15DF3 BlInputString

118156 0x1CD8C DbgBreakPoint

157108 0x265B4 BootPartitionName: 0x46a960

212576 0x33E60 RSDS: F675FA4A2F974CAD9350A7AC33EE33F41





Scan Time: Nov 16, 2012 @ 02:14:24

Magic File: osloader.magic

Signatures: 6

Target File: osloader/DC7F8535EB6345E799311BAEB7F2D6241/osloader.exe

MD5 Checksum: 6216d335fe82837a5c288e9552d11628



DECIMAL HEX	 DESCRIPTION

-------------------------------------------------------------------------------------------------------

1024	 0x400 To get the right RVA for a function: (0x400000 - this offset + offset of function)

16934 0x4226 BlClose

17564 0x449C BlOpen

17686 0x4516 BlRead

17730 0x4542 BlSeek

21605 0x5465 BlPrint

22542 0x580E AEOpen

27471 0x6B4F AEBiosDisabled: 0x436a60

61887 0xF1BF BlFileTable: 0x468da0

89374 0x15D1E BlInputString

117888 0x1CC80 DbgBreakPoint

156723 0x26433 BootPartitionName: 0x46a940

212048 0x33C50 RSDS: DC7F8535EB6345E799311BAEB7F2D6241





Scan Time: Nov 16, 2012 @ 02:14:24

Magic File: osloader.magic

Signatures: 6

Target File: osloader/B58A6D7BA599477B84A34D873C4A87D01/osloader.exe

MD5 Checksum: 42387b6352d89ea811ff4bdc9317bb7e



DECIMAL HEX	 DESCRIPTION

-------------------------------------------------------------------------------------------------------

1024	 0x400 To get the right RVA for a function: (0x400000 - this offset + offset of function)

18510 0x484E BlClose

19207 0x4B07 BlOpen

19339 0x4B8B BlRead

19383 0x4BB7 BlSeek

20156 0x4EBC BlPrint

24916 0x6154 AEOpen

29913 0x74D9 AEBiosDisabled: 0x43ea8c

64371 0xFB73 BlFileTable: 0x470dc0

92738 0x16A42 BlInputString

123532 0x1E28C DbgBreakPoint

163647 0x27F3F BootPartitionName: 0x472960





Scan Time: Nov 16, 2012 @ 02:14:24

Magic File: osloader.magic

Signatures: 6

Target File: osloader/B3C140B84A0F4168A5B71FFE37C7F0E41/osloader.exe

MD5 Checksum: b87bb2331d3921645c67eb9a9138f1fb



DECIMAL HEX	 DESCRIPTION

-------------------------------------------------------------------------------------------------------

1024	 0x400 To get the right RVA for a function: (0x400000 - this offset + offset of function)

17691 0x451B BlClose

18321 0x4791 BlOpen

18443 0x480B BlRead

18487 0x4837 BlSeek

22825 0x5929 BlPrint

23762 0x5CD2 AEOpen

29129 0x71C9 AEBiosDisabled: 0x441f58

30652 0x77BC BlInputString

70563 0x113A3 BlFileTable: 0x4746a0

147276 0x23F4C DbgBreakPoint

189079 0x2E297 BootPartitionName: 0x475de0





Scan Time: Nov 16, 2012 @ 02:14:24

Magic File: osloader.magic

Signatures: 6

Target File: osloader/6A32D4E556BA46F6B744C7EEAB765DE61/osloader.exe

MD5 Checksum: 12b9ad2b9fd7c9f72d3dfbdf94cc1670



DECIMAL HEX	 DESCRIPTION

-------------------------------------------------------------------------------------------------------

1024	 0x400 To get the right RVA for a function: (0x400000 - this offset + offset of function)

17679 0x450F BlClose

18309 0x4785 BlOpen

18431 0x47FF BlRead

18475 0x482B BlSeek

22807 0x5917 BlPrint

23744 0x5CC0 AEOpen

29111 0x71B7 AEBiosDisabled: 0x442f58

30634 0x77AA BlInputString

70442 0x1132A BlFileTable: 0x478fc0

148244 0x24314 DbgBreakPoint

190191 0x2E6EF BootPartitionName: 0x47a700





Scan Time: Nov 16, 2012 @ 02:14:24

Magic File: osloader.magic

Signatures: 6

Target File: osloader/68F0DD7086174F29B31E7B4B32BDAFDE1/osloader.exe

MD5 Checksum: add8e740abc8df95546090ac9d83e0d9



DECIMAL HEX	 DESCRIPTION

-------------------------------------------------------------------------------------------------------

1024	 0x400 To get the right RVA for a function: (0x400000 - this offset + offset of function)

16934 0x4226 BlClose

17564 0x449C BlOpen

17686 0x4516 BlRead

17730 0x4542 BlSeek

21605 0x5465 BlPrint

22542 0x580E AEOpen

27471 0x6B4F AEBiosDisabled: 0x436a60

61887 0xF1BF BlFileTable: 0x468da0

89374 0x15D1E BlInputString

117888 0x1CC80 DbgBreakPoint

156723 0x26433 BootPartitionName: 0x46a940

212048 0x33C50 RSDS: 68F0DD7086174F29B31E7B4B32BDAFDE1

To calculate the RVA from a file offset:

0x400000 - 0x400 + offset = 0x3FFC00 + offset = RVA

The calculated RVA can be off by 0x1000. e.g. for osloader/DC7F8535EB6345E799311BAEB7F2D6241/osloader.exe, the offsets should be calulated with:

0x400000 -0x400 + 0x1000 + offset = 0x400C00 + offset = RVA

e.g.: BlPrint:

0x400C00 + 0x5465 = 0x406065

For the objects the RVA is always displayed correctly (0x4.....), don't use the offset to calculate the RVA (for the objects the displayed file offset is not related to the location of the object in the file).

osloader.magic:

# Magic file for binwalk to detect functions and objects of

# osloader.exe so they can be used by WvBootDD.





# Find the start of the code in the osloader.exe file.

0 string x8bxffx55x8bxecx81xecx6c To get the right RVA for a function:

>8 string x02x00x00xa1 (0x400000 - this offset + offset of function)



# Get RSDS signature.

0 string RSDS RSDS:

>4 lelong x %X

>8 leshort x b%X

>10 leshort x b%X

>12 belong x b%X

>16 belong x b%X

>20 leshort x b%X





# Find offsets of functions and RVA's of objects.



0 string x8bxffx55x8bxec

>5 string x81xec

>>7 string x04x01x00x00x83 BlOpen

>>7 string xc0x00x00x00 BlInputString

>>7 string x84x00x00x00 AEOpen

>5 string x83xecx0cxa1

>>13 string x85xc0 BlPrint

>5 string x83xecx0cx53x8bx5dx14x56

>>21 lelong x BlFileTable: 0x%x

>5 string x8bx45x08x6bxc0x68

>>11 string x8bx88

>>>17 string xf6xc1x01x74x0fxf6xc1x02 BlRead

>>11 string xf6x80

>>>18 string x74x09 BlClose

>>>18 string x74x0ax8bx80

>>>>26 string x5dxffx60x14 BlSeek



0 string xccxc3x8bxffxcc DbgBreakPoint



0 string x57x6ax20x50xe8 AEBiosDisabled:

>11 lelong x 0x%x



0 string x8dx45xfcx50xa1

9 string x57xbe BootPartitionName:

>11 lelong x 0x%x

Attached Files

•  osloader-functions-objects-offsets.zip   1.91KB   5 downloads

[Sha0]

Version 0.0.1.9 released. This one has a cat command for displaying files. Pretty fun!

[Icecube]

I uploaded binwalk v0.4.5 (compiled in a cygwin environment) so people who can't compile it themself can run it:
http://reboot.pro/fi...le/258-binwalk/

The magic file I wrote, works on osloader.exe, but also directly on ntldr:

binwalk -m osloader.magic osloader.exe

binwalk -m osloader.magic ntldr