I'm using 7-zip to extract all kinds of binaries. Back then I was using verion 9.30 alpha with "l" command (list contents) and parsed the output. There were hints if an executable file contains any other binaries in the resource section. Let's take Sandboxie (http://www.sandboxie.com/SandboxieInstall.exe) as example:
"7z.exe l SandboxieInstall.exe" gave me an output (posting just the relevant snippets):
Path = .rsrc\RCDATA\6464
Type = PE
CPU = x86
...
Type = Nsis
(followed by a complete listing of the files inside the archive from the resource section).
and when then unpacking that Sandboxie executable I got the files in the resources.
With the current version I'm not able to gather that information with the "l" command anymore, even not when using the -slt switch. Also when blindy unpacking that executable I'm getting the disasembled parts of that binary instead of just the "good" data of the rsrc section.
My questions:
1) Is it possible to give more information again about the files in the resource section like 9.30 alpha did?
2) When unpacking that executable to get only the "good" data from the resources and leave the garbage... like in 9.30 alpha?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suppose that new version of 7-Zip is better for that archive.
File contains two binaries (32-bit and 64-bit) in resources:
3232
6464
And 7-Zip 15.06 allows you to unpack any of them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes I noticed that the old version only found one and new version can find both - that is why I want to update :). My matter is, I have plenty of executable files, some of them like Sandboxie, with executables in the resource section but also some of them without executables in the resources. Also I do not know which archive type it is (switch -t). For that reason I first used the list command, if there is evidence for executables (e.g. output Type = Nsis from the list command) in resources, if yes I extracted them.
With the current version I'm not able to figure out if there is something in the resources with the "l" command... So printing more detailed info about what is inside the resource section (like 9.30) would help a lot.
Last edit: Daniel Steiner 2015-09-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
are there any news on future MSI installers? I would love to deploy 15.06 to our networks, but i can´t because company-/it-policy is to NOT use 3rd party exe installers and tools like InstallAware ( hi Mr. Simon King, president of InstallAware... ) and crap like that. By today there are 4217 machines waiting to be fed with 15.06 :-)
@ Igor Pavlov - Thanks a lot for supporting RAR5 - loving it !
Last edit: Local Host 2015-09-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Было бы здорово наконец в новой версии получить при использовании драг н дроп в окно проводника без временной папки, а напрямую в ту папку которую перетаскиваешь.
Если это другой жесткий диск происходит распаковка на диск с системой, а потом еще копирование в конечную папку.
Хотя бы как опцию в настройках.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
v15.06 Beta meets multivolume archives RAR5, then there 7z.dll type AV "An unhandled exception at 0x00000000100835A8 (7z.dll) in 7z.exe: 0xC0000005: Access violation reading at 0x00000002004A025E." causing the fall of the parent task.
Found in the subject of Far ruboard on one of razrabotchikolv Far showed the proposed location of the error:
wseventeen
"DVall
Benchmark
7z l caviar.rar
also drops, so it is better to bug report to the author.
add: 7z 15.06
Code:
7z.dll! NArchive :: NRar :: CVolumeName :: GetNextName () Line 104 C ++
7z.dll! NArchive :: NRar5 :: CHandler :: Open2 (IInStream * stream, const unsigned __int64 * maxCheckStartPosition, IArchiveOpenCallback * openCallback) Line 1848 C ++
7z.dll! NArchive :: NRar5 :: CHandler :: Open (IInStream * stream, const unsigned __int64 * maxCheckStartPosition, IArchiveOpenCallback * openCallback) Line 2121 C ++
arclite.dll! Archive :: open (IInStream * stream, const std :: vector <unsig
ned char, std :: allocator <unsigned char="">> & type) Line 329 C ++
wchar_t c = _changedPart [- i];
i == 0xffffffff "
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, it's BUG.
7-Zip works incorrectly, if the name of multi-volume RAR archive was changed from original name (name.part01.rar) to some name without digits before ".rar" extension.
I'll fix the BUG in next version.
Thanks!
Last edit: Igor Pavlov 2015-09-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, some people used the old scripts form the volume names in the old style type * .rar - * .r [0-9][0-9] and in them there 7z.dll AV. I have a couple of colleagues asked, "Why do you use the old style volume naming does not support RAR5?" their response "We use it backup software - the source has long been lost, but after ./etc/backup.conf connected rarbsd v5.20." and they are "adapted", but I agree with the assessment that this is a case of incorrect file naming and ignoring documentation.
For RAR4 format archive old name stile <arcname>.rar - <arcname>.r[0-9][0-9] is supported in RAR v5.xx, but for RAR5 format not.
Last edit: VictorVG 2015-09-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you use "rar -vn" for old-style, then 7-Zip doesn't crash for that archive.
The problem for rar4/rar5, only if you rename .part[N].rar to something without digits at the end before ".rar".
So it's not so easy to create such archives.
Or maybe there are some rar commands that can create such archives (without additional "renaming script")?
Last edit: Igor Pavlov 2015-09-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My experiments are not allowed to reproduce the situation of forming an incorrect name:
"You can make an experiment - take a long-known to any file larger size of the volume (for example, 2 MB), and gave the command rar a -ma5 -v <size> k -vn arcname filename to see what happens. For example: rar a -ma5 -v1025k -vn coviar videoinspector.exe and something I can only see these file names - coviar.part1.rar, coviar.part2.rar, videoinspector.exe. where coviar.rar, coviar.r00, videoinspector.exe? "
However, Benchmark said this argument:
Victor_VG
"So someone specially renamed volumes at its own discretion ignoring the documentation."
And it does not matter.
Winrar itself perfectly smoothly and unpacked the archive. I see no reason why the 7-zip on it should fall.
I offered to call Eugene Roshal (EugeneRoshal) for consultations in order not to be in a situation "Everyone my opinion, but to find a common language have failed" and give it to answer you. The truth is a Benchmark rights - the supplied WinRAR/rarbsd module unrar in this case asks the user name of the next volume, or meet old naming scheme for volumes silence them unpack, though I would not mind that it displays a message on the inadmissibility of the use of the old naming scheme volume format RAR5 and stopped unpacking to eliminate violations of the format specification.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"1) ignore the error and continue naming volumes unpacking if the volume names match format RAR29 agreements despite the fact that they themselves have the format files RAR5 - this opinion Benchmark
2) does not begin to decompress and display a message abuse format specifications RAR5 "
Acceptable any of the options. The first creates a less immediate problems to users, and the second prevents renaming volumes is unclear why it is necessary and leads to confusion.
RAR I chose the first option, but for me they are almost equal.
I personally believe that the second option will reduce the likelihood of errors, although more strict in regard to monitoring of compliance with the format specifications.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
7z l GoogleChromePortable.sfx.sfx.exe -slt > list.txt
Currently I reinstalled version 9:38
Last edit: Nidasio Silvano 2015-09-09
Change modules
https://dl.dropboxusercontent.com/u/35142695/Modules_1.6_develop_build_3574_sl2_150909_17-42.7z
Thanks for the solution.
Last edit: Nidasio Silvano 2015-09-10
I'm using 7-zip to extract all kinds of binaries. Back then I was using verion 9.30 alpha with "l" command (list contents) and parsed the output. There were hints if an executable file contains any other binaries in the resource section. Let's take Sandboxie (http://www.sandboxie.com/SandboxieInstall.exe) as example:
"7z.exe l SandboxieInstall.exe" gave me an output (posting just the relevant snippets):
Path = .rsrc\RCDATA\6464
Type = PE
CPU = x86
...
Type = Nsis
(followed by a complete listing of the files inside the archive from the resource section).
and when then unpacking that Sandboxie executable I got the files in the resources.
With the current version I'm not able to gather that information with the "l" command anymore, even not when using the -slt switch. Also when blindy unpacking that executable I'm getting the disasembled parts of that binary instead of just the "good" data of the rsrc section.
My questions:
1) Is it possible to give more information again about the files in the resource section like 9.30 alpha did?
2) When unpacking that executable to get only the "good" data from the resources and leave the garbage... like in 9.30 alpha?
I suppose that new version of 7-Zip is better for that archive.
File contains two binaries (32-bit and 64-bit) in resources:
3232
6464
And 7-Zip 15.06 allows you to unpack any of them.
also you can use:
Yes I noticed that the old version only found one and new version can find both - that is why I want to update :). My matter is, I have plenty of executable files, some of them like Sandboxie, with executables in the resource section but also some of them without executables in the resources. Also I do not know which archive type it is (switch -t). For that reason I first used the list command, if there is evidence for executables (e.g. output Type = Nsis from the list command) in resources, if yes I extracted them.
With the current version I'm not able to figure out if there is something in the resources with the "l" command... So printing more detailed info about what is inside the resource section (like 9.30) would help a lot.
Last edit: Daniel Steiner 2015-09-10
rar5 is ok it's good news,thank you
Good Morning,
are there any news on future MSI installers? I would love to deploy 15.06 to our networks, but i can´t because company-/it-policy is to NOT use 3rd party exe installers and tools like InstallAware ( hi Mr. Simon King, president of InstallAware... ) and crap like that. By today there are 4217 machines waiting to be fed with 15.06 :-)
@ Igor Pavlov - Thanks a lot for supporting RAR5 - loving it !
Last edit: Local Host 2015-09-14
Было бы здорово наконец в новой версии получить при использовании драг н дроп в окно проводника без временной папки, а напрямую в ту папку которую перетаскиваешь.
Если это другой жесткий диск происходит распаковка на диск с системой, а потом еще копирование в конечную папку.
Хотя бы как опцию в настройках.
v15.06 Beta meets multivolume archives RAR5, then there 7z.dll type AV "An unhandled exception at 0x00000000100835A8 (7z.dll) in 7z.exe: 0xC0000005: Access violation reading at 0x00000002004A025E." causing the fall of the parent task.
Found in the subject of Far ruboard on one of razrabotchikolv Far showed the proposed location of the error:
Additionally - according to Benchmark
please see post in topic.cgi?forum=5&bm=1&topic=31718&start=7600 (page 381)
Yes, it's BUG.
7-Zip works incorrectly, if the name of multi-volume RAR archive was changed from original name (name.part01.rar) to some name without digits before ".rar" extension.
I'll fix the BUG in next version.
Thanks!
Last edit: Igor Pavlov 2015-09-15
Thank you! Let's wait for correction because these names are common RAR5 archives.
What do you mean?
Common name for multi-volume archive is
name.part01.rar
7-zip works ok for it.
And uncommon name for multi-volume RAR4/RAR5 archive is
name.rar
Note that rar5 doesn't create multi-volume archives with such names.
No, some people used the old scripts form the volume names in the old style type * .rar - * .r [0-9] [0-9] and in them there 7z.dll AV. I have a couple of colleagues asked, "Why do you use the old style volume naming does not support RAR5?" their response "We use it backup software - the source has long been lost, but after ./etc/backup.conf connected rarbsd v5.20." and they are "adapted", but I agree with the assessment that this is a case of incorrect file naming and ignoring documentation.
For RAR4 format archive old name stile <arcname>.rar - <arcname>.r[0-9][0-9] is supported in RAR v5.xx, but for RAR5 format not.
Last edit: VictorVG 2015-09-15
If you use "rar -vn" for old-style, then 7-Zip doesn't crash for that archive.
The problem for rar4/rar5, only if you rename .part[N].rar to something without digits at the end before ".rar".
So it's not so easy to create such archives.
Or maybe there are some rar commands that can create such archives (without additional "renaming script")?
Last edit: Igor Pavlov 2015-09-15
My experiments are not allowed to reproduce the situation of forming an incorrect name:
"You can make an experiment - take a long-known to any file larger size of the volume (for example, 2 MB), and gave the command rar a -ma5 -v <size> k -vn arcname filename to see what happens. For example: rar a -ma5 -v1025k -vn coviar videoinspector.exe and something I can only see these file names - coviar.part1.rar, coviar.part2.rar, videoinspector.exe. where coviar.rar, coviar.r00, videoinspector.exe? "
However, Benchmark said this argument:
I offered to call Eugene Roshal (EugeneRoshal) for consultations in order not to be in a situation "Everyone my opinion, but to find a common language have failed" and give it to answer you. The truth is a Benchmark rights - the supplied WinRAR/rarbsd module unrar in this case asks the user name of the next volume, or meet old naming scheme for volumes silence them unpack, though I would not mind that it displays a message on the inadmissibility of the use of the old naming scheme volume format RAR5 and stopped unpacking to eliminate violations of the format specification.
I got a response from Eugene Roshal:
I personally believe that the second option will reduce the likelihood of errors, although more strict in regard to monitoring of compliance with the format specifications.
Igor! Big thanks! Bug ln RAR5 multivolum archive use old name style is fixed. Test-report:
is Ok!, AV don't exists. :)