The program says, that the space is RAW and has only the above size. Which is not true.
The MBR is corrupted. This may or may not mean significant parts of the rest of the card are also trashed. You need to recreate the MBR as it was;
fdisk is a decent tool for this.
All the information is in the same place, as to assume usually, but somehow I can't access it.
Exactly. You will need to find out what the original partition boundaries were (i.e., where "the same place" is). These seem to change slightly over time with Raspbian images, so if the card was created a while back and you do not have the original image it was created from, you may be out of luck. If you do have the image, you can get the boundaries like this:
> fdisk -l 2017-03-02-raspbian-jessie-lite.img
Disk 2017-03-02-raspbian-jessie-lite.img: 1.3 GiB, 1393557504 bytes, 2721792 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb2455b06
Device Boot Start End Sectors Size Id Type
2017-03-02-raspbian-jessie-lite.img1 8192 137215 129024 63M c W95 FAT32 (LBA)
2017-03-02-raspbian-jessie-lite.img2 137216 2721791 2584576 1.2G 83 Linux
The numbers that are important here are
End. These are (hopefully obviously) related to
Size. This is from the 2017-03-02 jessie lite image, and the hurdle for you is determining the size of the first parition. The starting block (8192) is always the same, but looking back at a jessie image from Jan/2015, the first partition size is 56M, and in the March/2016 jessie lite, it is 60M.
So, most likely it is one of those. You can use, e.g.,
60M as the size when creating a partition.
(Re)creating a partition table won't do anything to any of the data on the disk. The purpose of the table is to indicate where partitions are located. If the table is wrecked, those can't be found, but unless the card is corrupted significantly beyond the partition table, they are still there. So, if you create a partition table that matches where they are, you will be able to access them.
Do that with
gparted, just make sure if you use the latter that's all it is doing (do NOT format the partitions).
Presumably you expanded the root filesystem, so when you set the size for the second partition, use the end sector (which will be the default). Beware when entering the starting sector that
fdisk may offer you something less than 8192, i.e., somewhere before the first partition. Don't go for that.
After you're done, you can test by mounting each one manually. If you get something to the effect "wrong fs type or bad starting block", then either the size is wrong (start over, try again) or else too much of the card is corrupted :(
If they mount, unmount them and run
fsck to fix any corruption problems internal to the filesystem. If this becomes very long winded, there is a chance the filesystem is essentially wrecked anyway.
Since it is obvious that the Raspi won't boot because of faulty updates
That is not obvious at all. In fact, I'd say this definitely is not the cause. It is coincidental. By analogy, "I wore my hat and went for a walk. It rained. Since it is obvious it rained because I wore my hat..." -> Nope, that is not why it rained.
I spent a lot of time configuring the Raspbian to my liking [...] it is entirely unnecessary to make this radical step of just deleting all the work that went into it
This is why if you have something you like that took you a long time stored on digital media of any sort (spinning disk, SD card, a cloud somethere...) you should keep it backed up.