Nope. Versions differ mostly in internal layout. The only notable change is addition of Unicode branch in 5.3 version.
Also latest 5.x versions have new compression algo (lzma2).
What kind of problems are you experiencing?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks. It says (on some systems only) it would be "most likely corrupt or no INNO at all" :-(
I'll test more … any idea where to download various INNO test files ?
BTW, suggestion:
Instead of just saying "most likely corrupt or no INNO at all", it could
report the PE size + overlay size and dump (HEX + text) a few Byte's
(maybe cca 16) from the overlay and test them for some other common packers/installers
(ZIP,7-ZIP,RAR,SHIELDCAB,MSCAB,SETFACTORY,WISE,NSIS,WINGRK) revealing what to
do with a file that __really__ isn't INNO :-) NO, I won't ask for unpacking those other formats.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It says (on some systems only) it would be "most likely corrupt or no INNO at all"
You mean same file may open on one system and refuse to do it on another? Any chance you can provide me with such file?
any idea where to download various INNO test files ?
Sorry, can't help you with that. I usually test any new update on official IS installers. Except for very old versions for which I used Google with signature string as query.
test them for some other common packers/installers
Not gonna happen. This tool is and will be for Inno Setup unpacking only. There are number of other tools that can do the trick (e.g. Universal Extractor).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> The only notable change is addition of Unicode branch in 5.3 version.
Maybe it's about Uni-vs-non-Uni rather than 4.xx-vs-5.xx :-|
> What kind of problems are you experiencing?
************************************************************************GOOD(INNO4.xxdetected&5.xx-UNIdetected)**********C:\INNOTEST>DIRVolumeindriveCisXPDirectoryofC:\INNOTEST01/01/200200:26<DIR>.01/01/200200:26<DIR>..01/01/198002:00496,128I037.EXE01/01/198002:002,157,832X1D90D2X.EXE01/01/198002:003,267,041X1D98D0Y.EXE01/01/198002:00519INNOTEST.TXT4File(s)5,921,520bytes2Dir(s)490,791,780bytesfreeC:\INNOTEST>I037X1D90D2X.EXE;Versiondetected:4206Compressionused:lzmaFiles:138;Bytes:3386078C:\INNOTEST>I037X1D98D0Y.EXE;Versiondetected:5309Compressionused:lzma2Files:162;Bytes:8476123C:\INNOTEST>VERMicrosoftWindowsXP[Version5.1.2600]C:\INNOTEST>************************************************************************BAD(INNO4.xxdetectedbut5.xx-UNINOTdetected)**********E:\>DIRVolumeindriveEisEEDirectoryofE:\I037EXE496'128 1980-01-01 00:00X1D90D2X EXE 2'157'832 1980-01-01 00:00X1D98D0Y EXE 3'267'041 1980-01-01 00:00 3 File(s) 370'258'628 bytes freeE:\>I037 X1D90D2X.EXE; Version detected: 4206Compression used: lzmaFiles: 138 ; Bytes: 3386078E:\>I037 X1D98D0Y.EXEThe setup files are corrupted or made by incompatible version. Maybeit'snotanInnoSetupinstallationatall.(0046BF66)E:\>************************************************************************
> Also latest 5.x versions have new compression algo (lzma2).
I see :-) The licenses inside the INNOUNP source package are outdated ;-)
After some more investigations, I see that Uni-versions have all the version structs in the source doubled (!!!), and for both Uni and non-Uni, the source file is being opened multiple times, and closed for non-Uni (???) but left opened for Uni (???) … is there a special reason for opening it multiple times? What's the difference in handling Uni-vs-non-Uni (the 2 files I supplied) versions of installers?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What was the system that has problems with Unicode version. As I can see good one is WinXP but what was the other.
> What's the difference in handling Uni-vs-non-Uni (the 2 files I supplied) versions of installers?
There is no difference between Uni and Ansi versions. They just have different size of data structures. Uni version has some strings as wide string (2 bytes per char), in Ansi version all string are 1 byte per char.
To reflect that all struct files are doubled. You can see that there are some differences between 2 files for same IS version.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah I do know what Unicode is about … the question is, how does INNOUNP process the newer files differently, as it fails to detect INNOSETUP at all. There must be some file I/O vulnerability. I tried to RTFS but got not very smart (apart from doubled structures). PS: The "bad" one are both ME and HX :-(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You mean Windows Millennium?!? Wow. I didn't thought anybody uses this antique crap anymore )).
I never did any testing on 9x branch of windows (and I don't have any plans for it to be honest). So I'm not sure why program behaves like that there. But I will take a look at what the difference between processing of your 2 files.
And what is HX?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> But I will take a look at what the difference between processing of your 2 files.
Any results ? I see that 0.38 is out (2013-Feb-01) … not yet tested. Some additional verbosity beyond "Maybe it's not an Inno Setup installation at all" would help to debug.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've checked the sources and found that versions is different in offset table location storage, First file (4.x) stores info in header but second one (5.x) in the resources. However why resource reading fails on Win 9x I can't say.
So I decided to find installation of 98 or Me, deploy to VMWare and debug on it. But on that step I didn't find install nearby and later kinda forgot about this ). Sorry for that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I've checked the sources and found that versions is different in offset table location storage,
> First file (4.x) stores info in header but second one (5.x) in the resources.
What exactly is stored differently? I see that the 5.x file has a __MUCH__ bigger resource
area ($2800 10 KiB -> $8200 32.5 KiB) … what's in? In what header is it in 4.x?
I don't see anything evil in the PE header ,,, but I see 12 funny Byte's in the MZ header at $30 !!!
> However why resource reading fails on Win 9x I can't say.
How do you read it? Using FindResource+LoadResource?
If for 5.xx files INNOUNP uses FindResource+LoadResource to detect INNOSETUP,
and for 4.xx it doesn't, then the original question
"Inno 4.x vs Inno 5.x intern … Is there a major difference"
is answered now.
Follow-up questions:
- Why does it fail? (we have a hint at least …)
Native processing of the resource stuff (analyze PE header, check directory
and section table, …) would most likely fix this mysterious problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you want details you can check functions GetSetupLdrOffsetTableFromFile (used in 4.x) and GetSetupLdrOffsetTableFromResource (used in 5.x). The later fails on Win9x for some reason. Resource that should be read is RCDATA\11111.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> If you want details you can check functions GetSetupLdrOffsetTableFromFile (used in 4.x)
> and GetSetupLdrOffsetTableFromResource (used in 5.x). The later fails on Win9x for some reason.
> Resource that should be read is RCDATA\11111.
Thanks, seen them … a MASSIVE MAJOR difference ;-)
The 5.x file has more icons (more bloat) and the RCDATA\11111 raw data.
The "GetSetupLdrOffsetTableFromFile" function confirms my MZ header hypothesis.
The "GetSetupLdrOffsetTableFromResource" has strange stuff:
hMod := LoadLibraryEx(PChar(Filename), 0, LOAD_LIBRARY_AS_DATAFILE);
// Loading very large files in datafile mode requires a lot of memory
// And can sometimes fail if system memory is not very large.
// If this is the case then let's try to load file a regular module
if (hMod = 0) and (GetLastError() = ERROR_NOT_ENOUGH_MEMORY) then
hMod := LoadLibraryEx(PChar(Filename), 0, 0);
if hMod=0 then exit;
…
Rsrc := FindResource(hMod,
…
ResData := LoadResource(hMod, Rsrc);
…
p := LockResource(ResData);
What's the point of "LOAD_LIBRARY_AS_DATAFILE" (can live without it too?) ???
Could you please compile a version with following 2 lines commented out:
hMod := LoadLibraryEx(PChar(Filename), 0, LOAD_LIBRARY_AS_DATAFILE);
if (hMod = 0) and (GetLastError() = ERROR_NOT_ENOUGH_MEMORY) then
and send ( x x x x x x @ g m a i l . c o m )?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't care about ME … but on HX, it fails due to "LOAD_LIBRARY_AS_DATAFILE" being ignored. HX fails to load the EXE as (fake) library, as the base address is occupied and there are no fixups. Patching the EXE by either providing (fake) fixups or changing the base address from $0040'0000 to some high value "fixes" the problem … INNOUNP can detect the INNOSETUP and extract it (maybe).
There seem to be 2 ways to fix this:
- Upgrade HX to support "LOAD_LIBRARY_AS_DATAFILE" properly (unlikely)
- Rewrite the "GetSetupLdrOffsetTableFromResource" function from PE-handling-API to native PE processing:
- - Check MZ
- - Look at $3C where PE should be
- - Check PE
- - Check size of "optional header" (probably always $E0)
- - Check the resource area entry in directories index 2
- - Search the section table to find the section with it (resource area usually has a
"private" section, but does not have to)
- - Seek to the resource area and load it
- - Find and read out the RCDATA\11111 resource
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well. It probably could resolve the issue.
But I don't have intentions on supporting rare systems. So it is up to you or anyone else to provide new version of the function.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Well. It probably could resolve the issue. But I don't have intentions on supporting rare systems. So it is up to you
> hMod := LoadLibraryEx(PChar(Filename), 0, LOAD_LIBRARY_AS_DATAFILE);
> // Loading very large files in datafile mode requires a lot of memory
> // And can sometimes fail if system memory is not very large.
> // If this is the case then let's try to load file a regular module
How comes it that "LOAD_LIBRARY_AS_DATAFILE" needs much more memory ?
It loads the overlay too, while ordinary LoadLibrary loads the "true" PE only ?
The existing function has many drawbacks:
- Needs too much memory (??? see above)
- Slow on huge files (??? see above) read complete file just to detect whether it's INNO?
- Doesn't work with HX
- Relies too much on WinAPI making it not portable
I'm not very good with Pascal/Delphi, sorry :-(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How comes it that "LOAD_LIBRARY_AS_DATAFILE" needs much more memory ?
It loads the overlay too, while ordinary LoadLibrary loads the "true" PE only ?
System doesn't really loads everything into memory. Just maps entire file. And you need to have amount of free memory greater then size of file. Problem is not with speed but with memory requirements.
But for cases when there is not enough memory there are next lines of code. If call with LOAD_LIBRARY_AS_DATAFILE failed with error about memory then next attempt is made without this flag.
- Doesn't work with HX
- Relies too much on WinAPI making it not portable
Program wasn't intended to be portable. It is based on Inno sources that are not portable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there a major difference between those 2, and in the "internal" handling of those files by innounp ?
(I have problems with 5.x, might be on my side, though, http://www.jrsoftware.org/files/is5-whatsnew.htm )
Nope. Versions differ mostly in internal layout. The only notable change is addition of Unicode branch in 5.3 version.
Also latest 5.x versions have new compression algo (lzma2).
What kind of problems are you experiencing?
Thanks. It says (on some systems only) it would be "most likely corrupt or no INNO at all" :-(
I'll test more … any idea where to download various INNO test files ?
BTW, suggestion:
Instead of just saying "most likely corrupt or no INNO at all", it could
report the PE size + overlay size and dump (HEX + text) a few Byte's
(maybe cca 16) from the overlay and test them for some other common packers/installers
(ZIP,7-ZIP,RAR,SHIELDCAB,MSCAB,SETFACTORY,WISE,NSIS,WINGRK) revealing what to
do with a file that __really__ isn't INNO :-) NO, I won't ask for unpacking those other formats.
You mean same file may open on one system and refuse to do it on another? Any chance you can provide me with such file?
Sorry, can't help you with that. I usually test any new update on official IS installers. Except for very old versions for which I used Google with signature string as query.
Not gonna happen. This tool is and will be for Inno Setup unpacking only. There are number of other tools that can do the trick (e.g. Universal Extractor).
I still have this BUG in 0.37 :-(
> You mean same file may open on one system and refuse to do it on another?
Exactly.
> Any chance you can provide me with such file?
http://jafile.com/uploads/dos386/innotest.zip (5 MiB)
> The only notable change is addition of Unicode branch in 5.3 version.
Maybe it's about Uni-vs-non-Uni rather than 4.xx-vs-5.xx :-|
> What kind of problems are you experiencing?
> Also latest 5.x versions have new compression algo (lzma2).
I see :-) The licenses inside the INNOUNP source package are outdated ;-)
After some more investigations, I see that Uni-versions have all the version structs in the source doubled (!!!), and for both Uni and non-Uni, the source file is being opened multiple times, and closed for non-Uni (???) but left opened for Uni (???) … is there a special reason for opening it multiple times? What's the difference in handling Uni-vs-non-Uni (the 2 files I supplied) versions of installers?
What was the system that has problems with Unicode version. As I can see good one is WinXP but what was the other.
> What's the difference in handling Uni-vs-non-Uni (the 2 files I supplied) versions of installers?
There is no difference between Uni and Ansi versions. They just have different size of data structures. Uni version has some strings as wide string (2 bytes per char), in Ansi version all string are 1 byte per char.
To reflect that all struct files are doubled. You can see that there are some differences between 2 files for same IS version.
Yeah I do know what Unicode is about … the question is, how does INNOUNP process the newer files differently, as it fails to detect INNOSETUP at all. There must be some file I/O vulnerability. I tried to RTFS but got not very smart (apart from doubled structures). PS: The "bad" one are both ME and HX :-(
You mean Windows Millennium?!? Wow. I didn't thought anybody uses this antique crap anymore )).
I never did any testing on 9x branch of windows (and I don't have any plans for it to be honest). So I'm not sure why program behaves like that there. But I will take a look at what the difference between processing of your 2 files.
And what is HX?
> But I will take a look at what the difference between processing of your 2 files.
Thank you :-)
> And what is HX?
HX
> But I will take a look at what the difference between processing of your 2 files.
Any results ? I see that 0.38 is out (2013-Feb-01) … not yet tested. Some additional verbosity beyond "Maybe it's not an Inno Setup installation at all" would help to debug.
I've checked the sources and found that versions is different in offset table location storage, First file (4.x) stores info in header but second one (5.x) in the resources. However why resource reading fails on Win 9x I can't say.
So I decided to find installation of 98 or Me, deploy to VMWare and debug on it. But on that step I didn't find install nearby and later kinda forgot about this ). Sorry for that.
Hi
> I've checked the sources and found that versions is different in offset table location storage,
> First file (4.x) stores info in header but second one (5.x) in the resources.
What exactly is stored differently? I see that the 5.x file has a __MUCH__ bigger resource
area ($2800 10 KiB -> $8200 32.5 KiB) … what's in? In what header is it in 4.x?
I don't see anything evil in the PE header ,,, but I see 12 funny Byte's in the MZ header at $30 !!!
> However why resource reading fails on Win 9x I can't say.
How do you read it? Using FindResource+LoadResource?
If for 5.xx files INNOUNP uses FindResource+LoadResource to detect INNOSETUP,
and for 4.xx it doesn't, then the original question
"Inno 4.x vs Inno 5.x intern … Is there a major difference"
is answered now.
Follow-up questions:
- Why does it fail? (we have a hint at least …)
Native processing of the resource stuff (analyze PE header, check directory
and section table, …) would most likely fix this mysterious problem.
If you want details you can check functions GetSetupLdrOffsetTableFromFile (used in 4.x) and GetSetupLdrOffsetTableFromResource (used in 5.x). The later fails on Win9x for some reason. Resource that should be read is RCDATA\11111.
> If you want details you can check functions GetSetupLdrOffsetTableFromFile (used in 4.x)
> and GetSetupLdrOffsetTableFromResource (used in 5.x). The later fails on Win9x for some reason.
> Resource that should be read is RCDATA\11111.
Thanks, seen them … a MASSIVE MAJOR difference ;-)
The 5.x file has more icons (more bloat) and the RCDATA\11111 raw data.
Only 43 Byte's (4.x has 12).
The "GetSetupLdrOffsetTableFromFile" function confirms my MZ header hypothesis.
The "GetSetupLdrOffsetTableFromResource" has strange stuff:
hMod := LoadLibraryEx(PChar(Filename), 0, LOAD_LIBRARY_AS_DATAFILE);
// Loading very large files in datafile mode requires a lot of memory
// And can sometimes fail if system memory is not very large.
// If this is the case then let's try to load file a regular module
if (hMod = 0) and (GetLastError() = ERROR_NOT_ENOUGH_MEMORY) then
hMod := LoadLibraryEx(PChar(Filename), 0, 0);
if hMod=0 then exit;
…
Rsrc := FindResource(hMod,
…
ResData := LoadResource(hMod, Rsrc);
…
p := LockResource(ResData);
What's the point of "LOAD_LIBRARY_AS_DATAFILE" (can live without it too?) ???
Could you please compile a version with following 2 lines commented out:
hMod := LoadLibraryEx(PChar(Filename), 0, LOAD_LIBRARY_AS_DATAFILE);
if (hMod = 0) and (GetLastError() = ERROR_NOT_ENOUGH_MEMORY) then
and send ( x x x x x x @ g m a i l . c o m )?
> and send ( x x x x x x @ g m a i l . c o m )?
NOT needed anymore as I got it :-)
I don't care about ME … but on HX, it fails due to "LOAD_LIBRARY_AS_DATAFILE" being ignored. HX fails to load the EXE as (fake) library, as the base address is occupied and there are no fixups. Patching the EXE by either providing (fake) fixups or changing the base address from $0040'0000 to some high value "fixes" the problem … INNOUNP can detect the INNOSETUP and extract it (maybe).
There seem to be 2 ways to fix this:
- Upgrade HX to support "LOAD_LIBRARY_AS_DATAFILE" properly (unlikely)
- Rewrite the "GetSetupLdrOffsetTableFromResource" function from PE-handling-API to native PE processing:
- - Check MZ
- - Look at $3C where PE should be
- - Check PE
- - Check size of "optional header" (probably always $E0)
- - Check the resource area entry in directories index 2
- - Search the section table to find the section with it (resource area usually has a
"private" section, but does not have to)
- - Seek to the resource area and load it
- - Find and read out the RCDATA\11111 resource
Well. It probably could resolve the issue.
But I don't have intentions on supporting rare systems. So it is up to you or anyone else to provide new version of the function.
> Well. It probably could resolve the issue. But I don't have intentions on supporting rare systems. So it is up to you
> hMod := LoadLibraryEx(PChar(Filename), 0, LOAD_LIBRARY_AS_DATAFILE);
> // Loading very large files in datafile mode requires a lot of memory
> // And can sometimes fail if system memory is not very large.
> // If this is the case then let's try to load file a regular module
How comes it that "LOAD_LIBRARY_AS_DATAFILE" needs much more memory ?
It loads the overlay too, while ordinary LoadLibrary loads the "true" PE only ?
The existing function has many drawbacks:
- Needs too much memory (??? see above)
- Slow on huge files (??? see above) read complete file just to detect whether it's INNO?
- Doesn't work with HX
- Relies too much on WinAPI making it not portable
I'm not very good with Pascal/Delphi, sorry :-(
System doesn't really loads everything into memory. Just maps entire file. And you need to have amount of free memory greater then size of file. Problem is not with speed but with memory requirements.
But for cases when there is not enough memory there are next lines of code. If call with LOAD_LIBRARY_AS_DATAFILE failed with error about memory then next attempt is made without this flag.
Program wasn't intended to be portable. It is based on Inno sources that are not portable.