[RELEASE] COSMIAS - a new approach to g4d images

http://en.wikipedia.org/wiki/Cosmia

Cosmia is a genus of moths of the Noctuidae family.

Naah!

COSMIAS
a.k.a.
Container Of Self Mounting Image (And Stuff )

At the moment this is nothing more than a PoC (proof of concept).

Instructions:

• download the attachment and expand it to *any* bootable media that uses grub4dos (tested with grub4dos 0.4.5c-2012-06-19 )
• get to command line
• at the grub4dos prompt type
  

  freedos
  
  [ENTER]

• hep!

Though the PoC is based on a (very little) hard disk image, it can be most probably expanded/adapted to an ext2/3 floppy or superfloppy (FAT12/16/32 and NTFS are seemingly not possible - though still to be fully tested ) and/or to a .iso, this latter could result in the end one of the few best things in life (after freedom, beer and ice-cream).

The example is a bootable system, but the approach can be also used to make - as an example - a "unique" container for all small grub4dos "tools" like WENV, FAT, etc. and grub4dos !BAT files in order to have everything in a "monolithic" container (without having the ROOT or the /grub directory of the device/drive cluttered with n small files).

The generic concept opens IMHO a much wider range of possibilities, where only the fantasy is the limit to make grub4dos loaded images simpler/more user friendly.

I feel allowed to peruse the "walking like an Egyptian thingy" :


As always ideas/comments/whatever are welcome....



Wonko

I get a Bad or missing Command Interpreter message - both on a QEMU boot and a real boot.
FAT32 USB Flash drive used....???

I get a Bad or missing Command Interpreter message - both on a QEMU boot and a real boot.
FAT32 USB Flash drive used....???

Yep , this is expected.

The concept of PoC must be alien to you .

The Freedos kernel has some difficulties with a --mem mapped hard disk to (hd9).

It's up to the reader finding a solution.
hint: try mapping it to (hd0) instead .



Wonko

The concept of PoC must be alien to you .

Proof of Concept is a demonstration that a theory or concept works (i.e. proof that it can work). What you supplied was a demonstration that does not work, and so it does not prove anything!

Proof of Concept is a demonstration that a theory or concept works (i.e. proof that it can work). What you supplied was a demonstration that does not work, and so it does not prove anything!

Oh yes it works, Freedos boots allright (but cannot find it's command interpreter).

The PoC is NOT at all about Freedos completely booting, or necessarily about booting but rather having a container "self mount" from invoking the filename of the container in grub4dos command line.

The teasing part was/is to make readers find the simple way to avoid this issue (and thus find by themselves how the general idea works).



Wonko

OK, patched the lines and it boots.
So basically you take a disk image with an MBR and partition table and then you overwrite the boot code in the MBR with grub4dos batch text which loads the image as a disk and then boots to it.
I used


!BAT
find --set-root /%~0
map --mem /%~0 (hd0)
map --hook
root (hd0,0)
chainloader (hd0,0)+1
boot

which seems to work fine.

OK, patched the lines and it boots.
So basically you take a disk image with an MBR and partition table and then you overwrite the boot code in the MBR with grub4dos batch text which loads the image as a disk and then boots to it.

Yep , but as said the booting part is only one of the possible uses.

I used


!BAT
find --set-root /%~0
map --mem /%~0 (hd0)
map --hook
root (hd0,0)
chainloader (hd0,0)+1
boot

which seems to work fine.

Yep
Actually by only changing the 9 to 0 in the original:

!BAT
find --set-root /%~0
map --mem /%~0 (hd9)
map --hook
root (hd9,0)
chainloader /kernel.sys
boot

you would get the same result.
As a variation one could use %~1 and invoke it with freedos <disknumber>...

This is applicable "as is" to any hard disk image (with a limit of 440 or possibly of 446 bytes of length for the !BAT file).

I have used in the example the "normal" 0x0D0A "new line+line feed" that DOS and Windows use, but it should be possible to use the *nix style with just 0x0A, thus saving one precious byte at every line.

The approach could be applied to a .iso image with virtually no limits to the length of the !BAT file and to ext2/ext3 floppy and superfloppy images as there are no "strict" BPB settings in the first sector of those.

I cannot work on FAT12/16/32 floppy or superfloppy images because of the MS DOS/Windows need of having "jump bytes", see here:
http://www.msfn.org/...post__p__987482
and most probably also on NTFS.... but should be doable if the OS is not "MS-ish"


Wonko

This is applicable "as is" to any hard disk image (with a limit of 440 or possibly of 446 bytes of length for the !BAT file).

I have used in the example the "normal" 0x0D0A "new line+line feed" that DOS and Windows use, but it should be possible to use the *nix style with just 0x0A, thus saving one precious byte at every line.

Maybe you can avoid this limit, by putting a comment (#) before the first byte of the partition table (or disk signature), and making sure that no 0x(0D)0A bytes occur from position 446/440 till position 512.
I didn't try it, but it should work (unless the !BAT parser thinks otherwise).

Maybe you can avoid this limit, by putting a comment (#) before the first byte of the partition table (or disk signature), and making sure that no 0x(0D)0A bytes occur from position 446/440 till position 512.
I didn't try it, but it should work (unless the !BAT parser thinks otherwise).

Yep it's a possibility, but at first sight the 440 (or 446) bytes seem more than enough for any "normal" "self mounting" set of directives, after all the last directive could be INSTEAD of a booting one either a call to another !BAT grub4dos file already residing in the container or a configfile directive pointing to a .lst file....

If chenall could add *something* allowing to recognize besides !BAT, i.e.:

21424154

as header also (say ):

E9210A

We could have something like:

E9210A676F746F203A670A

and use the g: label (still provided that the !BAT parser does not "choke" on the BPB data) for *anything* (say) after 0x5B and up to 0x1FD ....



Wonko

P.S.: Quick test made with Kolibri.iso:
http://kolibrios.org/en/
with:

!BAT

find --set-root /%~0

map --mem /%~0 (0xFF)

map --hook

chainloader (0xFF)

boot

Success!
In theory it should work with *any* .iso which is "simply mappable" as (0xFF) or (hd32)

OK, patched the lines and it boots.

Can you explain further? I am trying to grasp this concept. Seems very interesting.

Can you explain further? I am trying to grasp this concept. Seems very interesting.

Open first sector of the expanded file with a hex editor.


Wonko

Open first sector of the expanded file with a hex editor.


Wonko

Ok, got that far. Map to mem can be an issue for large ISO files as you already know. Will this work with just a map (OxFF) command without the --mem option or have I missed something?

Ok, got that far. Map to mem can be an issue for large ISO files as you already know. Will this work with just a map (OxFF) command without the --mem option or have I missed something?

Yes, you are missing something (but not a problem , though it has been already stated/explained).
The concept is more general, it is about the possibility of have a number of !BAT grub4dos commands be executed by invoking (from grub4dos command line or from an entry in menu.lst) just the name of the "container" (which is nothing but either a HD image or a .ISO image).

The difference is not so light, as for all .iso's that right now you can boot as 0xFF mapping, typically with a menu.lst entry like:

title foo

find --set-root /foo.iso

map /foo.iso (0xFF)

map --hook

root (0xFF)

chainloader

or:

title foo

find --set-root /foo.iso

map --mem /foo.iso (0xFF)

map --hook

root (0xFF)

chainloader

or:

title foo

find --set-root /foo.iso

map /foo.iso (0xFF) || map --mem /foo.iso (0xFF)

map --hook

root (0xFF)

chainloader

You can have a menu.lst entry like:

title foo

foo.iso

And in the actual first sector of the .iso something like:

find --set-root /%~0

map / %~0 (0xFF) || map --mem /%~0 (0xFF)

map --hook

root (0xFF)

chainloader



boot

and this latter code is the same for any and all .iso's that can be booted through plain (0xFF) mapping.

But as said it is a more general concept, as an example, say that you want a FAT12/16/32 ONLY filesystem defragger working from grub4dos.
You prepare a COSMIAS "container" with in it:

• a "basic" FreeDOS system
  
• the FreeDOS defrag.exe
  
• a suitable autoexec.bat

and name this container (say) qdefrag or qdefrag.g4b. (see here about the .g4b "tentative" extension: http://reboot.pro/to...l-for-grub4dos/ )
The !BAT code in the container first sector will take care of everything, and on grub4dos command line you just type qdefrag or qdefrag.g4b followed by a partition id, say (hd1,0) and the filesystem on that partition will be defragged.

Same goes for a number of grub4dos "native" utilities, as an example the above referenced MBRVIEW.g4b !BAT needs WENV, which may or may not be available in the "final user" root directory or grub4dos path, so you just put the mbrview.g4b and WENV in a COSMIAS container with something like this in it's first sector:

!BAT

find --set-root /%~0

map --mem /%~0 (hd9)

root (hd9,0)

mbrview.g4b %~1

and name the container "mbrview".
When you boot to grub4dos you simply type on command line (say)

mbrview (hd0)

and you can check the MBR partition table.


Wonko

The attached is "outright cheating"  but it effectively solves the issue of using a floppy-like (as opposed to hard disk-like) image.
Boot the fdodin.img in Qemu (outer hard disk-like image).
At the grub4dos prompt enter:
fdodin
to boot to the Freedos floppy disk image ....

 

 

Wonko

New Cosmias tool FDEFRAG.

To run FreeDOS defrag (only a VERY BASIC thing is provided)

Originated here:
http://reboot.pro/to...ssion/?p=168090


Wonko