Hi,

Who is the official maintainers of OnGuard located in the Lazarus CCR repository?

The wiki page doesn't give much information about who maintains it, what is (not) working etc.
http://wiki.freepascal.org/OnGuard

I want to use the OnGuard components with a non-GUI projects and non-LCL based projects. To be able to do that it needs a lot of code clean-up and code restructuring. A clean svn checkout of OnGuard yesterday ( r1156 ) also doesn't compile out of the box - but with a quick work-around I managed to get it working to a point. But this highlights the point that it is not actively being maintained.

Anyway, I don't know if my changes will be in-line with the goals of Lazarus CCR. Remember, I only use fpGUI Toolkit for my GUI projects. So I don't know if working inside Lazarus CCR is the best choice - for myself or Lazarus CCR. So maybe I should start fresh, from the original Delphi OnGuard code, or fork the copy in Lazarus CCR. The fork will probably be less effort for me, but I can't guarantee backward compatibility with LCL. I'm on a tight schedule and will only be able to test with fpGUI and console applications.

So this is really a courtesy email to anybody interested in OnGuard components. I think I will go with forking the Lazarus CCR code for now and publish my changes somewhere on the internet. The official maintainers (if there are any) are welcome to backport my changes to Lazarus CCR - if you think it is appropriate. If you think we can work together, I am willing to discuss this further.

A quick question to anybody that previously worked on OnGuard:

* What is the IBO_CONSOLE defines for? What is IBO?

Regards,
- Graeme -

In our previous episode, Graeme Geldenhuys said:

http://www.ibobjects.com/

Thanks Marco. Still makes no sense why there is a special DEFINE for that?

If you want Console support, split the units into GUI and non-GUI packages. For security features (core code) in an application you really don't need GUI components at all, so the split should be relatively easy.

Regards,
- Graeme -

Bogus?aw Brandys did this port.

See also his recent mail to this list:
http://lists.lazarus.freepascal.org/pipermail/lazarus/2010-February/049310.html

Vincent

Yep.I did the port.Currently I have no time to actively maintain it.It worked some time ago and I added some new code to read HDD hardware serial number but as I not needed this components I have no strong motivation to continue the efforts.
The main problem with lazarus lcl is that after a few month such components are full of nasty bugs due to internal inconsistencies in code break by new features of compiler of lcl. For example there is a lot of pointer operations without strict type checking. Feel free to modify as you wish.Forms are used only to generate unlocking codes and I think could be excluded from component set as a separate program.

Bogus?aw Brandys

How well did you test the reading of HDD serial number? I see you are looking inside /proc/cmdline to fine a line with 'root=/dev/' to get the boot device.

This already fails on my system (64bit Ubuntu 8.04.2) because I don't have a 'root=/dev/xxx' line, in which case you default to device 'hda'. I unfortunately only have a SATA device in my system, so that would be a 'sda' device under Linux.

To make matters worse, the 'root=' line in my /proc/cmdline looks as follows.

root=UUID=ab4aeffc-8918-40a9-96ab-f84114949611 ro quiet splash

As you can see it rather uses the UUID of the partition. So a extra lookup (not sure where yet - anybody with Linux knowledge please chip in) is required before we know which /dev/XXX is the boot device.

For the UUID lookup, I think we can use the symlink target based on the /dev/disk/by-uuid/ab4aeffc-8918-40a9-96ab-f84114949611 symlink file. On my system this is a relative path and has a target '../../sda1'.

So hopefully this shouldn't be too hard to fix. Though I have heard that reading SATA and SCSI hard drive serial numbers are not as easy as for ATA (IDE) devices.

One more issue:
* I don't have a /proc/scsi/model file in my system. I do have a /proc/scsi/scsi file, but it lists all scsi type devices, but no serial numbers.
* I also have /proc/scsi/usb-device/5 which contains all the information required from my USB Strick, but unfortunately there is no entry for my boot hard drive (it's not USB). :-(

The main problem with lazarus lcl is that after a few month such components are full of nasty bugs due to internal inconsistencies in code break by new features of compiler of lcl. For example there is a lot of pointer operations without strict type checking.

I have already split the OnGuard components into two packages. tponguard.lpk (runtime only) and tponguard_lcl.lpk (designtime only). Soon I'll add tponguard_fpgui.lpk too.

Now that the GUI is separated from the core code, it should be easier to keep stable or at least do unit testing against to make it stable.

BTW:
Doing some Google'ing and looking for information on how to extract the HDD serial number from a SATA drive without root access is quite tough. I did find an ingenious alternative though - something that will work on all platforms too.

Query the date/time value of the '/bin' directory under Linux, or 'C:\Windows' or 'C:\WinNT' under Windows. Then work out how many seconds or milliseconds since say 1980-01-01. You then have a pretty unique value. The chances of somebody else running your software and having installed their OS in the exact same millisecond as somebody else is pretty slim. :-)

Regards,
- Graeme -

In the other side, knowing that a cracker can change the time stamp of that folder to match other system

Luiz

Luiz Americo Pereira Camara wrote

In the other side, knowing that a cracker can change the time stamp of that folder to match other system

Make no mistake, there is no single "fix" to ensure a product is 100% secure. This is especially true if the protection is implemented in 100% software (no external hardware dongles). I was very impressed to actually read in the OnGuard documentation that they actually highlight the short comings of each protection method. Most other companies I have seen and used simply state they are foolproof - which they are not.

Also, getting a relatively unique value based on the date/time offset from a specified date in history, is only part of the information used by OnGuard to secure your software. In OnGuard terms, this is called "key modifiers". The hacker would still have to find the original Key too.

We simply want to make our product a bit more difficult to hack, thinking in terms of the average end-user to medium skilled hacker. Our content (teaching material) is also encrypted with various encryption schemes, based on Grade, Language, Product etc. But like I said, anything is hackable.

PS:
Even the Playstation 3 finally got hacked - it only took 3 years, 2 months and something like 11 days - that's dedication! :-)

Graeme Geldenhuys wrote

How well did you test the reading of HDD serial number?

I think I found another alternative to find the HDD serial number. Getting the boot define is fairly easy, so is the serial number for a ATA (IDE) hard disk. As I said, SCSI and SATA is a bit more difficult. But there seems to be a new method that should work too - I tested it in three very different machines, each have a different version of Linux too. And more importantly, all without ROOT access.

Option 1)
UUID look-up can be done via /var/log/udev
This same file also gives you ALL the information about each device, including the long and short serial number.

Option 2)
Knowing the UUID or device (eg: /dev/sda1) one can simply do a lookup in the /dev/disk/by-id/ directory. Each file in that directory has the following information: <bus>-<brand>-<model>-<serial#>[-<partition>] So by simply parsing the name, you can find the serial number of the device.

Can anybody else running Linux, and preferably not Ubuntu (as I am using Ubuntu), have a look and see if they have the same files with information about hard drives?

Option 1) UUID look-up can be done via /var/log/udev This same file also gives you ALL the information about each device, including the long and short serial number.

No such file in OpenSuse 11.2.

/dev/disk/by-id/ has some files :

/dev/disk/by-id/ata-Maxtor_6B200P0_B419N81H
/dev/disk/by-id/ata-Maxtor_6B200P0_B419N81H-part1
/dev/disk/by-id/ata-Maxtor_6B200P0_B419N81H-part3
/dev/disk/by-id/ata-Maxtor_6B200P0_B419N81H-part4
... and others...

They are all zero bytes so all info is in the name.

Can anybody else running Linux, and preferably not Ubuntu (as I am using Ubuntu), have a look and see if they have the same files with information about hard drives?

Regards,
Juha Manninen

Graeme:

Is it really accurate to the millisecond? Anyway, also interested if OEMs like HP would have the same timestamps then, as from my understanding many just clone an hdd, which would leave hundreds of computers with the same system, file dates and all, no?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100210/1bae5752/attachment.html>

Matt Shaffer wrote

Is it really accurate to the millisecond?

As far as Windows and MSDN documentation, the answer seems to be yes. The resolution of create time is 10 milliseconds.

http://msdn.microsoft.com/en-us/library/ms724290(VS.85).aspx

Anyway, also interested if OEMs like HP would have the same timestamps then, as from my

Luckily Windows needs to be reinstalled every 6 months to be usable (speed wise). :-) On a serious note, you raise a valid point. But for our clients (franchisees - we are a franchise business), they never tend to by branded PC's because they are too expensive. So I doubt this will really be an issue for us.

The other question raised by our technician is that he believes some programs modify the date of the Windows install folder. This will prompt the security software to ask for a new unlock code. We still need to confirm what the technician suspects.

Regards,
- Graeme -

Juha Manninen wrote

> Option 1) > UUID look-up can be done via /var/log/udev No such file in OpenSuse 11.2.

I thought it would be to easy. :-)

/dev/disk/by-id/ has some files : /dev/disk/by-id/ata-Maxtor_6B200P0_B419N81H

Excellent, so your hard drive serial number is B419N81H. Two distros down, thousands to go! :)

Thanks for responding Juha.

Regards,
- Graeme -

El 11/02/2010 8:15, Graeme Geldenhuys escribi?:

UUID look-up can be done via /var/log/udev

No such file on Debian testing.

But /dev/disk/by-id/ has the files, has many files! ata-ASUS-PHISON_SSD_SOQ2882217
ata-ASUS-PHISON_SSD_SOQ2882217-part1
ata-ASUS-PHISON_SSD_SOQ2882259
ata-ASUS-PHISON_SSD_SOQ2882259-part1
ata-ASUS-PHISON_SSD_SOQ2882259-part2
ata-ASUS-PHISON_SSD_SOQ2882259-part3
scsi-SATA_ASUS-PHISON_SSDSOQ2882217
scsi-SATA_ASUS-PHISON_SSDSOQ2882217-part1
scsi-SATA_ASUS-PHISON_SSDSOQ2882259
scsi-SATA_ASUS-PHISON_SSDSOQ2882259-part1
scsi-SATA_ASUS-PHISON_SSDSOQ2882259-part2
scsi-SATA_ASUS-PHISON_SSDSOQ2882259-part3
usb-Single_Flash_Reader_058F63356336-0:0
usb-Single_Flash_Reader_058F63356336-0:0-part1

I have an Asus EEEPC901, with 2 HDD SSD, so I think that my two hard disks are duplicated, if you see carefully, the serial numbers are the same on ata and scsi, only adding SSD on scsi interface. The last two entrys own to a SD memory card that it is plugged on.

Hope helps

Raistware wrote

> > UUID look-up can be done via /var/log/udev No such file on Debian testing.

OK, so clearly the 'udev' file is not an option.

But /dev/disk/by-id/ has the files, has many files! ata-ASUS-PHISON_SSD_SOQ2882217 scsi-SATA_ASUS-PHISON_SSDSOQ2882217 usb-Single_Flash_Reader_058F63356336-0:0

It doesn't matter if they are duplicated. What is important is that the files exist and that they are in the same format as all the other distros - which is seems to be. This is great news, 3 of the big distros are compatible. :-)

Thanks for replying.

I still need information regarding the other big players:

- CentOS
- Mandriva
- Fedora

Can anybody help with these?

hm... I think that such info in dev depends on kernel version and udev, so such thing can have problems on older distros.
I'm using fedora 3 with my own kernel 2.6.26 and I have such info, but I'm wondering does original fc3 kernel (think it was 2.6.9) and udev provides such info. Of course there's always direct kernel ctl call to disk (but then you have to be logged as root) and read disk id.
So conclusion is that Fedora, CentOS & Mandriva provides such info.

zeljko

zeljko wrote

hm... I think that such info in dev depends on kernel version and udev, so such thing can have problems on older distros.

My answer to that is.... Linux is free, UPGRADE! :-) This is exactly what I tell people about FPC, Lazarus and fpGUI too. With a kernel upgrade, you also get many security fixes and newer hardware support - which is all important reasons to upgrade.

such info. Of course there's always direct kernel ctl call to disk (but then you have to be logged as root) and read disk id. So conclusion is that Fedora, CentOS & Mandriva provides such info.

The VERY important point is that I need to be able to get the information without root access, otherwise it is fairly easy (as root - but pointless).

I did a Google search for each of the big distro names with the string '/dev/disk/by-id/' and all of them came back with hits. So yes, I think all modern distros support what I need. Finally something I can work with. :)

Regards,
- Graeme -

Hi All

Mandriva (2010) has /dev/disk/ with

by-id
by-uuid

subdirectories. by-uuid lists the disks by uuid (!!) and the by-id has entries for each disk as both ata and scsi-SATA.

HTH

Tim

tim launchbury wrote

Mandriva (2010) has /dev/disk/ with

Thanks Tim!

Regards,
- Graeme -

Graeme Geldenhuys wrote

I did a Google search for each of the big distro names with the string '/dev/disk/by-id/' and all of them came back with hits. So yes, I think all modern distros support what I need. Finally something I can work with. :)

not modern only, but you can be sure that all distros went out during last 5 yrs have such info :)

En/na zeljko ha escrit:

Nope, not there in mandriva 2006.0 (kernel 2.6.12)

ok, then 4 yrs :)

Luca Olivetti wrote

Nope, not there in mandriva 2006.0 (kernel 2.6.12)

Time to upgrade Luca. ;-)

Regards,
- Graeme -

En/na Graeme Geldenhuys ha escrit:

Luca Olivetti wrote: > Nope, not there in mandriva 2006.0 (kernel 2.6.12) Time to upgrade Luca. ;-)

While I upgrade individual packages (and I backport/repackage them once the distribution is no longer supported) I don't upgrade critical servers if it isn't strictly necessary. This is one is a dying machine, already replaced with a new one, but still online to do some hardware tests.

Bye

Mandriva Linux Free 2009.1 ( i586 )

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

ls -l /dev/disk/by-id :

total 0
lrwxrwxrwx 1 root root 9 2010-02-11 02:58 ata-ST3160811AS_6PT2KJT4 -> ../../sdb
lrwxrwxrwx 1 root root 10 2010-02-11 02:58
ata-ST3160811AS_6PT2KJT4-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 9 2010-02-11 02:58 ata-ST3250410AS_6RY65LGR -> ../../sda
lrwxrwxrwx 1 root root 10 2010-02-11 02:58
ata-ST3250410AS_6RY65LGR-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 2010-02-11 02:58
ata-ST3250410AS_6RY65LGR-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 2010-02-11 02:58
ata-ST3250410AS_6RY65LGR-part5 -> ../../sda5
lrwxrwxrwx 1 root root 10 2010-02-11 02:58
ata-ST3250410AS_6RY65LGR-part6 -> ../../sda6
lrwxrwxrwx 1 root root 9 2010-02-11 02:58 edd-int13_dev80 -> ../../sda lrwxrwxrwx 1 root root 10 2010-02-11 02:58 edd-int13_dev80-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 2010-02-11 02:58 edd-int13_dev80-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 2010-02-11 02:58 edd-int13_dev80-part5 -> ../../sda5
lrwxrwxrwx 1 root root 10 2010-02-11 02:58 edd-int13_dev80-part6 -> ../../sda6
lrwxrwxrwx 1 root root 9 2010-02-11 02:58 edd-int13_dev81 -> ../../sdb lrwxrwxrwx 1 root root 10 2010-02-11 02:58 edd-int13_dev81-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 9 2010-02-11 02:58
scsi-SATA_ST3160811AS_6PT2KJT4 -> ../../sdb
lrwxrwxrwx 1 root root 10 2010-02-11 02:58
scsi-SATA_ST3160811AS_6PT2KJT4-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 9 2010-02-11 02:58
scsi-SATA_ST3250410AS_6RY65LGR -> ../../sda
lrwxrwxrwx 1 root root 10 2010-02-11 02:58
scsi-SATA_ST3250410AS_6RY65LGR-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 2010-02-11 02:58
scsi-SATA_ST3250410AS_6RY65LGR-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 2010-02-11 02:58
scsi-SATA_ST3250410AS_6RY65LGR-part5 -> ../../sda5 lrwxrwxrwx 1 root root 10 2010-02-11 02:58
scsi-SATA_ST3250410AS_6RY65LGR-part6 -> ../../sda6

-------------------------------------------------- dir /dev/disk/by-id

ata-ST3160811AS_6PT2KJT4 edd-int13_dev80-part6
ata-ST3160811AS_6PT2KJT4-part1 edd-int13_dev81
ata-ST3250410AS_6RY65LGR edd-int13_dev81-part1
ata-ST3250410AS_6RY65LGR-part1 scsi-SATA_ST3160811AS_6PT2KJT4 ata-ST3250410AS_6RY65LGR-part2 scsi-SATA_ST3160811AS_6PT2KJT4-part1 ata-ST3250410AS_6RY65LGR-part5 scsi-SATA_ST3250410AS_6RY65LGR ata-ST3250410AS_6RY65LGR-part6 scsi-SATA_ST3250410AS_6RY65LGR-part1 edd-int13_dev80 scsi-SATA_ST3250410AS_6RY65LGR-part2 edd-int13_dev80-part1 scsi-SATA_ST3250410AS_6RY65LGR-part5 edd-int13_dev80-part2 scsi-SATA_ST3250410AS_6RY65LGR-part6 edd-int13_dev80-part5

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

Thank you very much

Mehmet Erol Sanliturk

Please keep the Linux gore at arms length, so that later solutions for other platforms can be plugged in without a million ifdefs

dir /dev/disk :

by-id by-path by-uuid

ls -l /dev/disk :

total 0
drwxr-xr-x 2 root root 460 2010-02-11 02:58 by-id/ drwxr-xr-x 2 root root 200 2010-02-11 08:02 by-path/ drwxr-xr-x 2 root root 120 2010-02-11 02:58 by-uuid/

dir /dev/disk/by-path :

pci-0000:00:0f.0-scsi-0:0:0:0 pci-0000:00:0f.0-scsi-0:0:0:0-part6 pci-0000:00:0f.0-scsi-0:0:0:0-part1 pci-0000:00:0f.0-scsi-1:0:0:0 pci-0000:00:0f.0-scsi-0:0:0:0-part2 pci-0000:00:0f.0-scsi-1:0:0:0-part1 pci-0000:00:0f.0-scsi-0:0:0:0-part5 pci-0000:00:0f.1-scsi-0:0:0:0

ls -l /dev/disk/by-path :

total 0
lrwxrwxrwx 1 root root 9 2010-02-11 02:58 pci-0000:00:0f.0-scsi-0:0:0:0 -> ../../sda
lrwxrwxrwx 1 root root 10 2010-02-11 02:58
pci-0000:00:0f.0-scsi-0:0:0:0-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 2010-02-11 02:58
pci-0000:00:0f.0-scsi-0:0:0:0-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 2010-02-11 02:58
pci-0000:00:0f.0-scsi-0:0:0:0-part5 -> ../../sda5
lrwxrwxrwx 1 root root 10 2010-02-11 02:58
pci-0000:00:0f.0-scsi-0:0:0:0-part6 -> ../../sda6
lrwxrwxrwx 1 root root 9 2010-02-11 02:58 pci-0000:00:0f.0-scsi-1:0:0:0 -> ../../sdb
lrwxrwxrwx 1 root root 10 2010-02-11 02:58
pci-0000:00:0f.0-scsi-1:0:0:0-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 9 2010-02-11 08:02 pci-0000:00:0f.1-scsi-0:0:0:0 -> ../../sr0

dir /dev/disk/by-uuid :

3C6CC1C36CC177E2 8e2d2da0-8d84-4fb3-aeb7-bd64c1bc2d32 65e93751-f2ae-41f1-9543-29942a6aca4d a6b92d0c-5bcc-49b9-9c1b-b23fd7db8df9

ls -l /dev/disk/by-uuid :

total 0
lrwxrwxrwx 1 root root 10 2010-02-11 02:58 3C6CC1C36CC177E2 -> ../../sdb1 lrwxrwxrwx 1 root root 10 2010-02-11 02:58
65e93751-f2ae-41f1-9543-29942a6aca4d -> ../../sda5 lrwxrwxrwx 1 root root 10 2010-02-11 02:58
8e2d2da0-8d84-4fb3-aeb7-bd64c1bc2d32 -> ../../sda6 lrwxrwxrwx 1 root root 10 2010-02-11 02:58
a6b92d0c-5bcc-49b9-9c1b-b23fd7db8df9 -> ../../sda1

Luca Olivetti wrote

While I upgrade individual packages (and I backport/repackage them once the distribution is no longer supported) I don't upgrade critical servers if it isn't strictly necessary.

No need to explain, I do the same thing. I have a Linux server here serving content 24/7, and it is still running Ubuntu 6.06. It's rock solid, so why fix what isn't broken. :)

Regards,
- Graeme -

Marco van de Voort wrote

Please keep the Linux gore at arms length, so that later solutions for other platforms can be plugged in without a million ifdefs

If you ever read the tiOPF newsgroups, you would see I *hate* IFDEF code. I think I have been writing cross-platform code for enough years so it comes to me without thinking.

As I explained in another post, I already split the OnGuard code into GUI an non-GUI packages to make it more manageable and flexible. Since that post I have also reduced the existing IFDEF code a lot by replacing code blocks with features FPC already supports or something implemented in pure Object Pascal.

Also note, our company projects are cross-platform, so the end result of my changes to OnGuard will be too. Currently OnGuard only supports Windows and Linux, but hopefully it should be easy to extend it to other platforms once I am done with it.

Regards,
- Graeme -

> hm... I think that such info in dev depends on kernel version and udev, so > such thing can have problems on older distros. My answer to that is.... Linux is free, UPGRADE! :-)

Never change a running system!

In the past days I had to replace my old CRT, and now I have left no working Linux, only Vista made the change without problems. SuSE 10.3 has lost its X configuration, 11.2 probably caused more damage to all Linux drives with disk "checks" (and repairs), now doesn't find its kernel any more, Ubuntu cannot use the second monitor any more, and Kubuntu looses the desktop configuration on every new boot :-(

Fortunately my VM's continue to work :-)

Very frustrated
DoDi

All that by replacing your monitor??? Wow, that must be some special monitor. :-)

I maintain 6 Linux systems and 3 VM systems. 6 work stations and 3 servers. The servers run the Ubuntu LTS releases and upgrade from one to the next using apt. No problems so far and no reinstall required. Ubuntu seem pretty good at this as long as you stay with LTS releases only.

The workstations, I prefer not to "upgrade", but rather reinstall when a new stable Ubuntu is releases. For Ubuntu desktop, I normally use every second release (every six months is to quick for me). I always split my hard drive into 4 partitions (/, /home, /opt, swap) and when I reinstall I backup the 'etc' directory first, then format the '/' partition and reinstall. So all my custom installed software like FPC, Lazarus, MSEide etc live in /opt so they are not my custom settings, data, source code etc are in /home, and is not affected either. So a reinstall is a 30 minute job and I'm up and running like I was before with all my previous applications intact. Config settings are restored very easily from my backed-up 'etc', if the new Ubuntu install did not detect them automatically.

Fortunately my VM's continue to work :-)

VM's are a pleasure to work with! The best thing since sliced bread. ;-) I actually have a fully functional development system setup in a VM. So if anything hardware wise has to fail on my development system, I can switch to another system, install VirtualBox and load my VM. I'll be up and running in 10 minutes and coding as usual.

Regards,
- Graeme -

I turned out to be a combined me-monitor-driver-X11 problem. The new screen is bigger than the old one, so that the system fell back into single-monitor mode. Afterwards I managed to damage my xorg.conf, supported by the nVidia driver, and on [K]Ubuntu by "parsing" errors before writing back the config. The latter problems make [K]Ubuntu useless for now, though these work better with the rest of my hardware, and have much faster application management than SuSE has.

Nice, but I also have a problem in identifying all my partitions. Having 5 systems on my machine, and several shared partitions, I'm looking for giving them unique names, visible from every (Linux) system, but don't know how to do that :-(

DoDi

Hans-Peter Diettrich wrote

I turned out to be a combined me-monitor-driver-X11 problem. The new screen is bigger than the old one, so that the system fell back into single-monitor mode. Afterwards I managed to damage my xorg.conf,

I never edit config files without making backups first. There is nothing more frustrating than killing a working system.

systems on my machine, and several shared partitions, I'm looking for giving them unique names, visible from every (Linux) system, but don't know how to do that :-(

Do you mean something like the 'e2label' command?

  $ e2label  [new-label] # display/set label on ext2/3

I think you can use 'tune2fs' command too.

A quick Google search or reading some man pages to get you started.