OS/2, eCS & ArcaOS - Technical > Utilities
XDF disk extractor
Dave Yeo:
Other then on the first few boot disks, most of the files are compressed. Couldn't get too fancy on a 386 with compression though. Use unpack.exe to decompress them.
I take it you're using an ISO. Wouldn't be easier to just examine the disk images in OS2IMAGE rather then the floppy images?
Bogdan:
--- Quote from: Rick C. Hodgin on November 02, 2018, 12:49:58 am ---Is there an XDF disk image extractor? I've tried WinImage, WinEMT, DiskExplorer, and WinXDF. DiskExplorer was able to read it, but it wouldn't read directories and wasn't able to reliably extract the files. I couldn't find any tool to read the XDF format and export out the files.
--- End quote ---
Most disk image tools work only with fixed 512 bytes/sector.
--- Quote ---I tried xdfcopy in OS/2, but I can't see where it extracts to a folder, but only to a physical floppy drive/disk.
--- End quote ---
It copies from physical drive to an image or vice versa.
--- Quote ---I've ordered an external floppy drive for my laptop. It will be here possibly this weekend, but probably Monday or Tuesday.
--- End quote ---
External USB floppy drives will not work, because of 512 bytes/sector limitation used by their transfer method. External floppy drives connected through the dedicated external floppy connector found on ThinkPad port replicators or docking stations will do fine.
The only OS/2 tool that handles XDF images virtually is SVDISK: https://www.bmtmicro.com/BMTCatalog/os2/svdisk.html
Under Windows you can simply use Virtual PC which supports at least XDF image files - but not physically.
RickCHodgin:
--- Quote from: Dave Yeo on November 02, 2018, 06:41:30 am ---I take it you're using an ISO. Wouldn't be easier to just examine the disk images in OS2IMAGE rather then the floppy images?
--- End quote ---
I've recently learned about something called TTD (Time Travel Debugging, which I think I mentioned elsewhere). It's a system where the entire state of the CPU is captured (Microsoft uses a "soft machine" (like Bochs) to capture it, but it can also be captured using a facility/feature of the x86 CPU, which is the ability to single-step every instruction by setting a flag value to signal an INT 1 interrupt).
I'd like to ultimately develop a set of primitive tools to enable this capture ability (initially across a COM port at bootup, then eventually to local disk files once drivers are loaded), to allow everything the CPU does to be intercepted, with all memory reads/writes being captured, and then an optional bit of storage to capture physical register changes as well as flags.
By doing this, any OS to be examined for security research would only need to be booted and arrive at the user interaction state. It would capture the entire range of everything in memory, how it got there, which instruction did it, and everything. This would allow for a comprehensive post-mortem analysis of the system after the fact. Every aspect of which logic was chosen at each branch, how structures were updated, etc., would be captured.
It would then become a process of mining that operation to follow branches algorithmically, to categorize them, prioritize them as items of interest (oft-called, central branching points, etc.), and to extrapolate from the code being run exactly what is happening where, why, when, and how often.
I've never done this before, so I'm charting new waters.
I would prefer to modify a version of Bochs to handle this all virtually for me, but I've never been able to get Bochs setup to properly run / boot / install OS/2. It's always reported a fatal error at some point.
In the alternative, Microsoft uses a custom-built virtual machine for this purpose. It is integrated seamlessly with Windows and allows the full host of host machine attributes being exposed tot he virtual machine, so that when you create a Window it actually displays on the screen, you can interact with keyboard, mouse, network, etc. It's quite a thing.
In any event, my goal is that instruction-by-instruction capture. If I can do it with INT 1 it would be great because that facility would work on any machine, but bet slow (probably 200-500x slower than normal, so a normal 45 second boot would take over 6 hours). But, it would only need to be done one time on each fixpack revision once everything is setup properly.
We'll see. I'm in uncharted waters here (at least with regards to my own experience / expertise). I proceed now only operating in theory, and it will require trial and error. I will post my efforts / attempts / results as I go though.
Remember also, the goal here is security research. I'm looking for where there are fatal flaws that could impact users resulting in data corruption, or the ability for some malicious software to take over / damage the system in some way.
Dave Yeo:
Interesting, going to be a lot of data to go through :) Still not sure about the need to unpack XDF files.
Someone did suggest the diunpack program which is referenced here, https://wiki.gentoo.org/wiki/QEMU/OS2WarpV3_guest. Search for fastkick141.zip on the net.
RickCHodgin:
--- Quote from: Dave Yeo on November 02, 2018, 03:31:04 pm ---Interesting, going to be a lot of data to go through :) Still not sure about the need to unpack XDF files.
Someone did suggest the diunpack program which is referenced here, https://wiki.gentoo.org/wiki/QEMU/OS2WarpV3_guest. Search for fastkick141.zip on the net.
--- End quote ---
Right now I am looking for unpacked XDF files for IBM PC DOS 7 disks for my guest machine partition in VirtualBox. I'm going to extract them, then try to create them as 2.88 MB floppies so they'll load like normal and have enough space for their weird format.
If I get my XDF extractor written, I can probably just truncate some of the files, recompress them, add them to the floppies by number, and then add an extra step at the end to copy over the portions which were truncated, so it would install on regular 1.44 MB floppies. As long as it's just copying and not running the programs it installs, truncating a few hundred bytes on a few files here and there would work, knowing they'll be copied over later.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version