Results 1 to 6 of 6

Thread: 'Signing' a compressed file system for app verification

  1. #1
    Member registered user
    Join Date
    Dec 2003
    Posts
    57

    'Signing' a compressed file system for app verification

    A friend asked me, "How do you know that someone didn't replace your KNOPPIX compressed file system with a tainted one containing malware and such?"

    I do verify portions of systems by appending a MD5 hash (plus a bit of arcania) to the end of some executables so that I can later verify they are the ones I supplied. The executables don't mind the extra 32 bytes,

    But the clooped file system DOES seem to mind. I only hash as much as is needed to detect changes. I then append the MD5 hash and a time stamp to the end of the file.

    I have been through the sourcecode in "cloop-2"; and not found anything that explicitly compares the end of compressed data with the file size. And I have compressed FSs with odd byte sizes, so there is no specific size multiple. So why the failures?

    BillS

    This is the result of loading and mounting a 'signed' compressed file.
    Code:
    root@lp2:/tmp# losetup /dev/cloop2 /tmp/KNOPPIX_NOV_29_04
    root@lp2:/tmp# losetup -a
    root@lp2:/tmp# head -4 KNOPPIX_NOV_29_04 
    #!/bin/sh
    #V2.0 Format
    insmod cloop.o file=$0 && mount -r -t iso9660 /dev/cloop $1
    exit $?
    root@lp2:/tmp# mount -r -t iso9660 /dev/cloop2 /mnt/test
    mount: wrong fs type, bad option, bad superblock on /dev/cloop2,
           or too many mounted file systems
    And then the same file without the signature (simply lacking the 32 bytes):
    Code:
    root@lp2:/tmp# losetup /dev/cloop /extra/CompressedFS/KNOPPIX_NOV_29_04
    root@lp2:/tmp# losetup -a
    root@lp2:/tmp# mount -r -t iso9660 /dev/cloop /mnt/test
    root@lp2:/tmp# losetup -a
    root@lp2:/tmp# ls /mnt/test
    bin   cdrom  etc     home  mnt   proc  sbin  tmp  var
    boot  dev    floppy  lib   none  root  sys   usr  vmlinuz
    root@lp2:/tmp# cmp KNOPPIX_NOV_29_04 /extra/CompressedFS/KNOPPIX_NOV_29_04
    cmp: EOF on /extra/CompressedFS/KNOPPIX_NOV_29_04

  2. #2
    Junior Member registered user
    Join Date
    Dec 2004
    Location
    The Looking Glass
    Posts
    22
    Does the cloop stuff seek to the end of the file anywhere?

    I remember that GIF headers are at the front of a file and the real headers for a zip file are at the end, so a person could make a dual format file. Maybe it was the other way around with the headers, but the point is, maybe it explicitly looks at the end of the file for something important.

  3. #3
    Member registered user
    Join Date
    Dec 2003
    Posts
    57

    'Signing' a compressed file system for app verification

    'cloop-2' code does 'lseek()' calls for either current position only, or to an absolute position using an offset value already stored in the compressed file index. And it is curious that the failure is in the mount (unless the losetup failed and didn't produce an error message.)

    BillS

  4. #4
    Senior Member registered user
    Join Date
    Apr 2003
    Posts
    220
    why not just put md5sum into md5.txt file?

    If one can replace your Knoppix, then he can also generate new md5 for it.

  5. #5
    Member registered user
    Join Date
    Dec 2003
    Posts
    57
    Not that simple to bypass. Without going into details;
    "appending a MD5 hash (plus a bit of arcania) to the end"

    1) Maybe it is a SHA1 rather than an MD5
    2) The hash is 'salted'; not simple to replicate
    2) 'arcania' is made of things like epoch time and size and such
    3) values are interleaved at a byte level.

    Suffice to say, the substitution of one file for another is a more complex task.
    Placing values in a seperate file leave the question of that external files integraty at question.


    Nothing wholey self-contained can ever be secure.
    Given enough resources, it can be comprimised.
    But the quantity of resources to compromise it can
    be forced to extremely high levels.

    BillS

  6. #6
    Member registered user
    Join Date
    Dec 2003
    Posts
    57
    OK ... I found the check that stops the cloop load.
    In 'compressed_loop.c' (AKA cloop.o) is a check if this is a block device, and that the end of the file matches the last offset. It is making the incorrect assumption that the offset is short, rather than the file has been extended.
    Code:
     if(!isblkdev &&
        be64_to_cpu(clo->offsets[ntohl(clo->head.num_blocks)]) != inode->i_size)
      {
       printk(KERN_ERR "%s: final offset wrong (%Lu not %Lu)\n",
              cloop_name,
              be64_to_cpu(clo->offsets[ntohl(clo->head.num_blocks)]),
              inode->i_size);
       vfree(clo->zstream.workspace); clo->zstream.workspace=NULL;
       goto error_release_free_all;
      }
    The result is a message in 'dmsg' of:
    Code:
    cloop: Initializing cloop v2.00
    cloop: /tmp/KNOPPIX_NOV_29_04: 1600 blocks, 65536 bytes/block, largest block is 65562 bytes.
    cloop: final offset wrong (39821172 not 39821204)
    Those two numbers are the file sizes before and after signing.

    BillS

Similar Threads

  1. System crashes when creating compressed file system
    By insolit in forum Customising & Remastering
    Replies: 2
    Last Post: 03-04-2006, 01:08 AM
  2. No compressed file
    By sydney075 in forum Customising & Remastering
    Replies: 3
    Last Post: 01-27-2006, 07:44 PM
  3. Runtime Compressed File system
    By grzegorz in forum Customising & Remastering
    Replies: 0
    Last Post: 02-19-2004, 05:17 AM
  4. How to unpack the compressed KNOPPIX file
    By Mongrol in forum Customising & Remastering
    Replies: 4
    Last Post: 07-02-2003, 08:27 AM
  5. No root file system (but system works)
    By freyley in forum Hdd Install / Debian / Apt
    Replies: 1
    Last Post: 01-31-2003, 09:21 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Dell PowerEdge M610 Blade Server E5620@2.2GHZ (6x)8GB RAM (2x)146GB 15K SAS HDD picture

Dell PowerEdge M610 Blade Server E5620@2.2GHZ (6x)8GB RAM (2x)146GB 15K SAS HDD

$75.00



Dell PowerEdge FX2 FX2S Enclosure - 4x PowerEdge FC640 w/ 8x Gold 6132 112C 1TB picture

Dell PowerEdge FX2 FX2S Enclosure - 4x PowerEdge FC640 w/ 8x Gold 6132 112C 1TB

$2294.99



Dell PowerEdge FX2 FX2S Enclosure - 4x PowerEdge FC640 w/ 8x Gold 6134 64C 1TB picture

Dell PowerEdge FX2 FX2S Enclosure - 4x PowerEdge FC640 w/ 8x Gold 6134 64C 1TB

$3299.99



DELL M630 BLADE SERVER x2 XEON E5-2660V3 @ 2.6GH H730 PERC HDD CADDIES 16GB FC picture

DELL M630 BLADE SERVER x2 XEON E5-2660V3 @ 2.6GH H730 PERC HDD CADDIES 16GB FC

$50.00



DELL POWEREDGE M620 Blade 2x Xeon E5-2670 2.5GHz 128GB 2x300GB HDD picture

DELL POWEREDGE M620 Blade 2x Xeon E5-2670 2.5GHz 128GB 2x300GB HDD

$94.50



Dell PowerEdge M620 Blade Server picture

Dell PowerEdge M620 Blade Server

$39.99



Dell PowerEdge M1000e (BMX01) Server Enclosure w/ 16-PowerEdge M610 Blade Server picture

Dell PowerEdge M1000e (BMX01) Server Enclosure w/ 16-PowerEdge M610 Blade Server

$899.99



HP ProLiant BL460c G8(Gen8) 2x 8 CORE E5-2670 2.6GHz 192GB RAM 2x 146GB SAS HDD  picture

HP ProLiant BL460c G8(Gen8) 2x 8 CORE E5-2670 2.6GHz 192GB RAM 2x 146GB SAS HDD 

$78.00



Dell PowerEdge FX2s CTO Blade 4 Slot 2U Chassis 2x 2000W picture

Dell PowerEdge FX2s CTO Blade 4 Slot 2U Chassis 2x 2000W

$349.00



UCSB-B200-M4 UCS Blade Server, 2x E5-2667 V3, 256GB RAM DDR4, 2x 300GB Drives picture

UCSB-B200-M4 UCS Blade Server, 2x E5-2667 V3, 256GB RAM DDR4, 2x 300GB Drives

$299.99