Link [Sammelthread] WinRAR, alle aktuellen Updates und Betaversionen

HardwareHarry

MitGlied
AW: WinRAR 4 Update(Ehemals: Immer Infos über die neueste Version)

Na dann hab ich die 4.2 für wenig Geld. Die letzte 3.8 aus der PC-Welt hab ich bis vorgestern benutzt und die 4.x wollte ich eigentlich nur wegen der 64bit Variante und der Mehrkern-Optimierung.
 
AW: WinRAR 4 Update(Ehemals: Immer Infos über die neueste Version)

Wenns eine kurze Antwort gibt, gerne hier, ansonsten bitte ins Tech verschieben:

Weiß jemand, warum die die Wiederherstellungsinformationen bei Splitarchiven maximal 1 % betragen? Die lassen sich zwar vorher höher stellen, es wird jedoch nicht dauerhaft gespeichert. Bug oder tieferer Sinn?
 

JamesBond

gone for good
AW: WinRAR 4 Update(Ehemals: Immer Infos über die neueste Version)

Kann ich nicht nachvollziehen, geht auch bei Split mit 10%.

Dauerhafte Einstellung geht über Optionen --> Einstellungen --> Komprimierung --> Standard festlegen --> (von da an hoffentlich klar)
 
AW: WinRAR 4 Update(Ehemals: Immer Infos über die neueste Version)

Habs bisher nicht dauerhaft eingestellt, das muss ich noch testen. Standard ist beim Rechner meiner Frau "ohne". Und wenn ich da dann Dateien auswähle und mit Rechtsklick auf Archiv packen gehe, dort dann den Haken bei Wiederherstellungsinfo setze und diese dann auf 10 % korrigiere, dann kann ich beim fertigen Archiv unter Info (dort der 2. Reiter) sehen, dass es nicht 10 sind, sondern 1 %. Das lässt sich auch nicht im Nachhinein über "Schützen" korrigieren.

Nachtrag 1:

Auch wenn ich 5 % dauerhaft einstelle, werden dann in Winrar über Info/Optionen (2. Reiter dort) nur 1 % bestätigt.

Nachtrag 2:

win.rar GmbH hat mir gestern (04.12.) zurückgeschrieben:

Hallo Herr xxx,

Vielen Dank für Ihren Bugreport,
ich werde unseren Entwickler über dieses Problem informieren.

Viele Grüße,
xxx xxx at WinRAR-Support

win.rar GmbH
Schumannstr. 17
10117 Berlin
Germany

www.win-rar.com (website)
support@win-rar.com (e-mail)
Ich interpretiere das mal so, dass die das Problem dort nachvollziehen konnten. Sicher bin ich mir da aber nicht. :icon_xmas:

Nachtrag 3:

Der Entwickler hat mir heute (05.12.) auch geschrieben und den Fehler bestätigt. Wird in der nächsten Version behoben.
 
AW: WinRAR 4 Update(Ehemals: Immer Infos über die neueste Version)

Bei der Gelegenheit habe ich gleich mal wegen Update gefragt. Alle, die Winrar über die Sonderaktion erstanden haben, dürfte das hier interessieren:

win.rar GmbH schrieb:
Sie haben WinRAR in einer speziellen Werbeaktion (3 EUR statt 29,95 EUR) gekauft.
Leider ist Ihre Lizenz nur auf die WinRAR Version 4.20 beschränkt.

Sie haben aber bei einer Aktion mitgemacht, die 1 Jahr Update-Support
(bis 18.09.2013) in Angebot beinhaltet.

Somit sollten Sie noch auf die nächste Version updaten können.
 

JamesBond

gone for good
AW: WinRAR 4 Update(Ehemals: Immer Infos über die neueste Version)

Seltsam, aber bei mir tritt dieses Problem nicht auf. Ich verwende aber WinRAR x86

/Edit:
Ah, jetzt habe ich ein grösseres Archiv erstellt, jetzt sehe ich das auch. Wird aber nur falsch angezeigt, tatsächlich ist es trotzdem mit 10% Recovery gepackt.

Leider ist Ihre Lizenz nur auf die WinRAR Version 4.20 beschränkt.

Sie haben aber bei einer Aktion mitgemacht, die 1 Jahr Update-Support
(bis 18.09.2013) in Angebot beinhaltet.

Somit sollten Sie noch auf die nächste Version updaten können.
Seltsame Logik...
 

adhome

Bekanntes Mitglied
AW: WinRAR 4 Update(Ehemals: Immer Infos über die neueste Version)

RAR decompression
is not able to use several processor cores, so its performance
does not depend on a number of cores.
Weiß einer warum und wird das für immer so sein?
 

Deluser957

janz wech. fresse halten,wenn man keine ahnung hat
WinRAR 5.0 Beta1 (englisch)
http://rarlab.com/download.htm
http://rarlab.com/rarnew.htm

WinRAR - What's new in the latest version


Version 5.00 beta 1

1. New RAR 5.0 archiving format. You can use "RAR 5.0" option
in archiving dialog or -ma command line switch to create
RAR 5.0 archives.

Older software including older WinRAR versions is not able to
decompress RAR 5.0 archives, so if you plan to send an archive
to other people, it is necessary to take the compatibility issue
into consideration. You can select "RAR" instead of "RAR5" option
in archiving dialog to create RAR 4.x archives compatible with
previous WinRAR versions.

2. Changes in RAR 5.0 compression algorithm:

a) maximum compression dictionary size is increased up to 1 GB
in 64 bit WinRAR. 32 bit WinRAR version can use up to 256 MB
dictionary when creating an archive. Both 32 bit and 64 bit
versions can unpack archives with any dictionary size,
including 1 GB;

b) default dictionary size for RAR 5.0 is 32 MB, typically resulting
in higher compression ratio and lower speed than RAR 4.x 4 MB.
You can use "Dictionary size" archiving dialog option or -md
switch to change this value;

c) -md switch syntax is modified to support larger dictionary
sizes. Append 'k', 'm' and 'g' modifiers to specify the size
in kilo-, mega- and gigabytes, like -md64m for 64 MB dictionary.
If modifiers are not present, megabytes are assumed,
so -md64m is equal to -md64;

d) RAR 5.0 format includes Intel IA-32 executable and delta
compression algorithms, but RAR 4.x text, audio, true color
and Itanium algorithms are not supported. These excluded algorithms
are not efficient for modern data types and hardware configurations;

e) RAR 5.0 decompression can utilize several CPU cores.
Though not to same extent as in compression algorithm,
it improves the decompression speed on large files
with poorly compressible data or when using BLAKE2 checksums.

3. Changes in RAR 5.0 archive format:

a) file times are stored as Coordinated Universal Time (UTC)
instead of former local time, making file exchange among
several time zones more straightforward;

b) file names and archive comments use UTF-8 encoding.

4. RAR 5.0 recovery record is based on Reed-Solomon error correction
codes. If recovery record size is large enough, 5% and more,
the new error correction scheme provides much higher resistance to
multiple damages comparing to RAR 4.x recovery record.
Smaller record, such as 1 - 2%, or less random damage type would
result in less difference between 4.x and 5.0. For single continuous
damage 4.x and 5.0 efficiency is about the same.

Additionally to usual data erasures, the new recovery record
is able to detect deletions and insertions of much larger size
than in previous RAR versions. Maximum insertion size is several
megabytes. Maximum deletion size depends on the damage type
and in some cases can be as large as the recovery record size.

Still, the best recovery performance and efficiency is achieved
if no deletions and insertions are present, so all data including
damaged sectors preserve their original positions. Thus, if you use
some special software to copy an archive from damaged media,
it is better to choose the mode, when damaged sectors are filled by
zeroes or any other data instead of cutting them out completely
from resulting file.

RAR 5.0 recovery record is more resistant to damage of recovery record
itself and can utilize a partially corrupt recovery record data.
Note, though, that "Repair" command does not fix broken blocks
in recovery record. Only file data are corrected. After successful
archive repair, you may need to create a new recovery record
for saved files.

New recovery record is not based on 512 byte sectors anymore
and incorporates more complicated data structures. So it is impossible
to specify its size in sectors. For RAR 5.0 archives the parameter of
-rr[N] switch and rr[N] command is always treated as a percent of
archive size regardless of presence of % character. Typically N%
recovery record can repair up to N% of continuously damaged data
and increases the archive size by only slightly more than N%.
Ability to fix multiple damages is proportional to N.

We used "Screaming Fast Galois Field Arithmetic Using Intel
SIMD Instructions" paper by James S. Plank, Kevin M. Greenan
and Ethan L. Miller to improve Reed-Solomon coding performance.
Also we are grateful to Artem Drobanov and Bulat Ziganshin
for samples and ideas allowed to make Reed-Solomon coding
more efficient.
 

Deluser957

janz wech. fresse halten,wenn man keine ahnung hat
5. "Test" command verifies validity of RAR 5.0 recovery record.
Recovery record is tested after processing all archived files.

If corrupt archive contains the recovery record, it might be possible
to repair it even if recovery record validity test is failed.
"Repair" command attempts to utilize even a partially damaged
recovery record. So treat the negative recovery record test result
as a reason to re-create the archive if original files are still
available, but not as a reason to avoid "Repair" command.

6. Changes in RAR 5.0 encryption algorithm:

a) encryption algorithm is changed from AES-128 to AES-256 in CBC mode.
Key derivation function is based on PBKDF2 using HMAC-SHA256;

b) special password verification value allows to detect most of
wrong passwords without necessity to unpack the entire file;

c) if archive headers are not encrypted ("Encrypt file names" option
is off), file checksums for encrypted RAR 5.0 files are modified
using a special password dependent algorithm, to make impossible
guessing file contents based on checksums. Do not expect such
encrypted file checksums to match usual CRC32 and BLAKE2 values.

7. RAR 5.0 archives allow to utilize 256 bit length BLAKE2sp hash
( https://blake2.net ) instead of 32 bit CRC32 as a file checksum.
Enable "Use BLAKE2 file checksum" option in "Options" page of
archiving dialog or specify -htb command line switch to use BLAKE2
checksums.

While producing slightly larger archives, BLAKE2 can be used
for file contents identification. If two files have the same
BLAKE2 value, it practically guarantees that file contents
is the same. BLAKE2 error detection property is also stronger
than in much shorter CRC32.

8. Features removed:

a) authenticity verification feature did not provide the required
level of reliability and was removed;

b) switch -en (do not add "end of archive" block) is not supported
by RAR 5.0 archives, which always have the end of archive block.
This block helps WinRAR to safely skip external data like
digital signatures appended to archive;

c) old style extension based arcname.rNN volume names are not
supported by RAR 5.0 archives, which use only arcname.partN.rar
volume names;

d) file comments are not supported anymore both in RAR 4.x
and RAR 5.0 archives. Console RAR 'cf' command is removed.
It does not affect the archive comment support, which is present
in both versions of archive format and is not planned for removal.

9. "Set password" command and "Dictionary size" option are moved to
"General" page of archiving dialog.

10. You can use "Save symbolic links as links" option on "Advanced" page
of archiving dialog to save and restore NTFS symbolic links
and reparse points as links, so their contents is not archived.
Command line equivalent of this option is -ol switch.

Similar option for NTFS hard links is "Save hard links as links".
Its command line equivalent is -oh switch.

Both options are available only for RAR 5.0 archive format.

11. Added extraction only support for XZ archive format.

12. Changes in recovery volume processing in RAR 5.0 archive format:

a) maximum number of RAR+REV volumes in RAR 5.0 format is 65535
instead of 255;

b) recovery volume operations are faster than in RAR 4.x;

c) additionally to recovery data, RAR 5.0 REV files also store
service information such as checksums of protected RAR files.
So they are slightly larger than RAR volumes which they protect.
If you plan to copy individual RAR and REV files to some removable
media, you need to take it into account and specify RAR volume
size by a few kilobytes smaller than media size.

13. Maximum path length for files in RAR and ZIP archives is increased
up to 2048 characters.

14. Command line RAR returns the exit code 11 if it can detect that
user entered a wrong password. This code can be returned only
for RAR 5.0 archives. It is impossible to distinguish a wrong
password and data damage for RAR 4.x archives.

15. 'v' and 'l' commands display archived file names in the end of line,
not in that beginning as before. Also some fields previously
available in 'l' and 'v' output are now shown only by 'lt' and 'vt'.

'vt' and 'lt' commands provide the detailed multiline information
for every archived file.

'vta' and 'lta' also include service headers into list.

16. Now the default charset for filelists in commands like
'rar a arcname @filelist' is ANSI for both WinRAR and console RAR.
In previous versions it was ANSI for WinRAR and OEM for console RAR.
You can use -scl switch to override this default.

17. Internal WinRAR viewer can detect and display files in UTF-8
and UTF-16 little endian encodings.

18. UTF-16 little endian encoding is used in RAR and WinRAR log file
rar.log, so Unicode file names are stored in the log correctly.
WinRAR automatically truncates the old rar.log file in non-Unicode
format to avoid mixing different encoding in the same log file.
In case of console RAR you need to delete the old rar.log manually,
otherwide RAR will append UTF-16 messages to existing rar.log.

19. Command line 'r' (repair) command can include an optional destpath\
parameter defining the destination folder for repaired archive:

rar r archive.rar destpath\
 

JamesBond

gone for good
m.leimer@leimer.name schrieb:
WinRAR 5.00 Beta 2 Inoffizielle deutsche Distribution (32-Bit, 64-Bit): Eine vollständige Übersetzung wird es in der nächsten Zeit erst einmal nicht geben. Es ist noch offen, ob es bis zum Erscheinen der finalen Version überhaupt eine deutsche Version geben wird. Der Grund ist der hohe Zeitaufwand für die Lokalisation, Zeit, die ich derzeit wegen meines Vollzeitjobs nicht habe. Ich schließe nicht aus, dass es zumindest eine Lokalisation der Programmoberfläche geben wird.
http://leimer.name/winrar/index.html

Hm... Brummel?
 

Deluser957

janz wech. fresse halten,wenn man keine ahnung hat
Ich hab mit leimer nix am hut, b1 hatte der nicht. b2 hat der auch nicht!? Ach, nur News, lmaa.
 

JamesBond

gone for good
Beta4

Version 5.00 beta 4

1. If archiving operation cannot allocate memory required for compression
dictionary, it automatically reduces the dictionary size.

2. Decompression algorithm can store the dictionary in several memory
blocks. It helps to unpack an archive on systems with high level
of memory heap fragmentation, when no single memory block
is large enough to fit the entire compression dictionary.
 

jr33

.......
Im Original:

Older software including older WinRAR versions is not able to
decompress RAR 5.0 archives, so if you plan to send an archive
to other people, it is necessary to take the compatibility issue
into consideration. You can select "RAR" instead of "RAR5" option
in archiving dialog to create RAR 4.x archives compatible with
previous WinRAR versions.
 

DetLife

Bekanntes Mitglied
Ich glaube, das Zeitalter proprietärer Archivformate ist vorbei. Wenn RAR5 zu allem inkompatibel ist, kann man auch gleich 7-Zip nehmen. Das ist immerhin Open-Source.
 

adhome

Bekanntes Mitglied
Schnelleres Entpacken von RaR5 Archive ist schon ein netter Vorteil.
Wie ist es mit der Komprimierleistung? Vermutlich kaum Änderung. Oder spuckt es nur noch 42 aus?
 

JamesBond

gone for good
WinRAR 5.00 ist verfügbar!
Was ist neu?

Die offiziellen deutschen Distributionen entsprechen (bis auf die Codesignierung) zu 100% diesen hier angebotenen Versionen, da ich der offizielle Übersetzer für WinRAR bin. Die hier veröffentlichten Versionen werden wenig später auch als offizielle Versionen auf der rarlab-Homepage zum Download angeboten.
http://leimer.name/winrar/index.html
 

Wary

✠ T(r)oll ✠
b) Ein spezieller Wert zur Passwortüberprüfung ermöglicht die schnelle
Erkennung von falschen Passwörtern. In den meisten Fällen muss nun
nicht mehr die ganze verschlüsselte Datei entpackt werden, um das
Passwort zu überprüfen;
Top, das bedeutet also WinRAR 5 Archive kann man viel viel schneller knacken! Yay!
 

Elektrospeedy

Bekanntes Mitglied
Die NSA scheint bei den Datenmengen überlastet zusein, was die alles abgreifen. Soll bestimmt eine Erleichterung für die Geheimdienste sein :D
 

jr33

.......
Bei all dem Shice erscheinen Versuche der Regierungen
innerhalb der EU das Internet zu reglementieren in einem ganz anderem Licht.
"Die verarschen uns" ist da noch milde geurteilt.
 

DetLife

Bekanntes Mitglied
AES-256 gilt bereits als angreifbar, AES-128 derzeit noch nicht.

Grundsätzlich würde ich aber von einem Entwickler von Closed-Source-Packersoftware kein kryptographisch sicheres Verfahren erwarten. Dafür braucht es nämlich ausgebildete Krypto-Spezialisten und Code-Audits von unabhängigen Experten. Die meiste Software wird nämlich über Implementierungsfehler angegriffen und die stecken mit 100%iger Sicherheit auch in WinRAR, notfalls auch als Backdoor für den FCB. :icon_mrgreen:
 

gis

Bekanntes Mitglied
AES-256 gilt bereits als angreifbar, AES-128 derzeit noch nicht.. :icon_mrgreen:
Naja, mal die Kirche im Dorf lassen, denn Bruce Schneier schreibt in seinem Blog:

However, AES-192 and AES-256 were recently shown to be breakable by attacks which require 2176 and 2119 time, respectively. While these complexities are much faster than exhaustive search, they are completely non-practical, and do not seem to pose any real threat to the security of AES-based systems.
und weiter:

There are three reasons not to panic:
  • The attack exploits the fact that the key schedule for 256-bit version is pretty lousy -- something we pointed out in our 2000 paper -- but doesn't extend to AES with a 128-bit key.
  • It's a related-key attack, which requires the cryptanalyst to have access to plaintexts encrypted with multiple keys that are related in a specific way.
  • The attack only breaks 11 rounds of AES-256. Full AES-256 has 14 rounds.

Auf Wikipedia findet sich dann:

Die Forscher Alex Biryukov und Dmitry Khovratovich veröffentlichten Mitte des Jahres 2009 einen Angriff mit verwandtem Schlüssel[11] auf die AES-Varianten mit 192 und 256 Bit Schlüssellänge. Dabei nutzten sie Schwächen in der Schlüsselexpansion aus und konnten eine Komplexität von 2119 erreichen. Damit ist die AES-Variante mit 256 Bit Schlüssellänge formal schwächer als die Variante mit 128 Bit Schlüssellänge.[12] Ende 2009 wurde mit einer Verbesserung des Angriffs eine Komplexität von nur noch 299,5 erreicht.[13] Für die Praxis hat dieser Angriff jedoch wenig Relevanz, denn AES bleibt weiterhin praktisch berechnungssicher.
Aber schon richtig:
mehr Bit ist nicht automatisch gleichbedeutend mit sicherer:
 

Wary

✠ T(r)oll ✠
Nicht wirklich: Encryption algorithm is changed from AES-128 to AES-256 in CBC mode. Key derivation function is based on PBKDF2 using HMAC-SHA256
Doch! Jetzt muss man nur ein paar kleine Byte entschlüsseln! Das kann jede Grafikkarte extrem schnell parallel!
Vorher musste man die GANZE DATEI entschlüsseln und wusste erst dann, ob das Passwort stimmt!
Während jetzt also eine Grafikkarte tausende Passwörter pro Sekunde (mindestens) prüfen kann, konnte man z.B. bei einem großen CD-Image vorher EIN passwort in MEHREREN MINUTEN probieren!

Kann jetzt jeder mal selber nachdenken was sicher ist!

Naja, mal die Kirche im Dorf lassen, denn Bruce Schneier schreibt in seinem Blog […]
Der schreibt aber auch:
And for new applications I suggest that people don't use AES-256.
Aber vielleicht kennen die WinRAR Entwickler Bruce Schneier nicht! Spricht dann sicher für ihr Können und Wissen in dem Bereich! Man kann also damit prima verschlüsseln, wenn man der NSA und den WinRAR Entwicklern vertraut!
 

gis

Bekanntes Mitglied
Cooles Zitaten Ping-Pong, da vervollständige ich es doch gleich mal damit es nicht so ganz aus dem Zusammenhang heraus da steht:

And for new applications I suggest that people don't use AES-256. AES-128 provides more than enough security margin for the forseeable future. But if you're already using AES-256, there's no reason to change.
Und noch ein bisschen weiter unten:

Bruce Schneier July 30, 2009 1:22 PM
"So if I read this right (haven't seen the paper yet), AES-128 is actually harder to break than AES-256 due to the nature of this attack?"
Yes and no. Neither can be broken. There are no attacks against any AES variants that are better than brute force; all of these attacks are against reduced-round variants.
That being said, the key schedule for AES-256 is very poor. I would recommend that people use AES-128 and not AES-256.
Also die Empfehlung ist AES-128, aber hier wird ja der Eindruck erweckt AES-256 sei bereits geknackt oder einfach zu knacken.
 

DetLife

Bekanntes Mitglied
Rijndael (AES) ist definitiv verdächtig, einfach geknackt werden zu können. Deswegen hat sich ja die NSA dafür ausgesprochen. :icon_mrgreen:

Verwendet lieber Twofish und Serpent!

Auf jeden Fall ergibt der Wechsel bei WinRAR von AES128 zu AES256 überhaupt keinen Sinn, es sei denn, man möchte der NSA helfen...
 

DeSmi

Bekanntes Mitglied
Re: Aw: Referenz-Nr. 36xxxxx2: Ihre Bestellung von WinRAR GmbH-Produkten

Hallo,

wir haben Ihnen den Schlüssel für WinRAR 5.00 in einer separaten E-Mail nachgeschickt.

Viele Grüße,
Gerxxxx Luexxxxx at WinRAR-Support

win.rar GmbH
Schumannstr. 17
10117 Berlin
Germany
Das kostenlose Update der Lizenz von der v4.20 auf v5.00 ist soeben erfolgt... :yo
 
Sauber ;) Ich habe heute auch angefragt. Wobei sicher die die 5.01 bald folgen wird, die wäre dann wohl out of range, da 18.09. fällig.

edit//

done :icon_prost:
 

JamesBond

gone for good
Version 5.01 beta 1

Dass dies noch keiner gepostet hat... Offenbar nicht mehr so interessant wie noch vor Jahren. :p


Version 5.01 beta 1

1. RAR 5.0 archives can include an optional quick open information
controlled with -qo[-|+] switch or "Quick open information" options
group in archiving dialog. It allows to open the archive contents
in WinRAR faster.

This version provides better update performance for archives
containing both quick open information and service records,
such as NTFS file security. Also default parameters of quick open
information are optimized to achieve faster open time for such archives.

2. Bugs fixed:

a) "Find" command could fail when searching text string in .7z archives;

b) when opening RAR 5.0 archive with encrypted file names stored
in another such archive, WinRAR could issue an erroneous message
that password is incorrect. It happened only if passwords to inner
and outer archives were different. It did not affect extraction,
all files could be unpacked regardless of this message;

c) option "Use for all archives" in password dialog did not suppress
additional password requests for RAR 5.0 archives with encrypted
file names;

d) WinRAR address bar did not process correctly environment variable
based paths, such as %temp%;

e) storing NTFS file security and alternate data streams did not work
for file pathnames longer than 260 characters;

f) "Test" command could erroneously report damaged data in valid
recovery record if only a part of files in RAR 5.0 archive
was tested. It did not happen if entire archive contents was tested;

g) "Test" command erroneously reported errors when verifying
RAR 4.x Unix symbolic links;

h) WinRAR "View" command did not work for files inside of BZIP2 archives;

i) if "High precision modification time" option in archiving dialog
was turned off, WinRAR did not store the modification time at all
instead of storing a lower precision time;

j) destination paths containing .\ or ..\ component did not work
when extracting non-RAR archives in WinRAR command line mode;

k) WinRAR failed to unpack multivolume CAB archives.

Der 3€-Key wird noch akzeptiert.
 

Zapata

Bekanntes Mitglied
Titel: WinRAR: Eine Schwachstelle erlaubt das Einschleusen von Programmen
Datum: 28.03.2014
Software: RARLAB WinRAR <= 5.1
Plattform: Microsoft Windows , Microsoft Windows 7, Microsoft Windows 8, Microsoft Windows XP
Auswirkung: Ausführen beliebigen Programmcodes mit Benutzerrechten
Remoteangriff: Ja
Risiko: hoch
Bezug: Exploit DB Papers 32480



Für WinRAR ist eine kritische Schwachstelle festgestellt worden, welche in WinRAR-Archiven das Vortäuschen von falschen Dateierweiterungen erlaubt ("File extension spoofing"). Hierdurch können Benutzer in Bezug auf die enthaltenen Dateitypen getäuscht und Schadsoftware (z. B. Trojaner) eingeschleust werden. Da derzeit kein Sicherheitsupdate für die Software zur Verfügung steht, kann allen Anwendern nur empfohlen werden, bis auf Weiteres keine unbekannten ZIP-Dateien mittels WinRAR zu entpacken.
Quelle: https://www.cert-bund.de/advisoryshort/CB-K14-0368


Zapata
 
Oben Unten