Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Inno 4.x vs Inno 5.x major "intern...

dos386
2011-02-18
2013-05-30
  • dos386
    dos386
    2011-02-18

    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 )

     
  • Ariman
    Ariman
    2011-02-18

    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?

     
  • dos386
    dos386
    2011-02-22

    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.

     
  • Ariman
    Ariman
    2011-02-22

    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).

     
  • dos386
    dos386
    2012-09-25

    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?

    ************************************************************************
    GOOD (INNO 4.xx detected & 5.xx-UNI detected)
    **********
    C:\INNOTEST>DIR
     Volume in drive C is XP
     Directory of C:\INNOTEST
    01/01/2002  00:26    <DIR>          .
    01/01/2002  00:26    <DIR>          ..
    01/01/1980  02:00           496,128 I037.EXE
    01/01/1980  02:00         2,157,832 X1D90D2X.EXE
    01/01/1980  02:00         3,267,041 X1D98D0Y.EXE
    01/01/1980  02:00               519 INNOTEST.TXT
                   4 File(s)      5,921,520 bytes
                   2 Dir(s)     490,791,780 bytes free
    C:\INNOTEST>I037 X1D90D2X.EXE
    ; Version detected: 4206
    Compression used: lzma
    Files: 138 ; Bytes: 3386078
    C:\INNOTEST>I037 X1D98D0Y.EXE
    ; Version detected: 5309
    Compression used: lzma2
    Files: 162 ; Bytes: 8476123
    C:\INNOTEST>VER
    Microsoft Windows XP [Version 5.1.2600]
    C:\INNOTEST>
    ************************************************************************
    BAD (INNO 4.xx detected but 5.xx-UNI NOT detected)
    **********
    E:\>DIR
     Volume in drive E is EE
     Directory of  E:\
    I037     EXE       496'128   1980-01-01 00:00
    X1D90D2X EXE     2'157'832   1980-01-01 00:00
    X1D98D0Y EXE     3'267'041   1980-01-01 00:00
            3 File(s)     370'258'628 bytes free
    E:\>I037 X1D90D2X.EXE
    ; Version detected: 4206
    Compression used: lzma
    Files: 138 ; Bytes: 3386078
    E:\>I037 X1D98D0Y.EXE
    The setup files are corrupted or made by incompatible version. Maybe
    it's not an Inno Setup installation at all.
    (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?

     
  • Ariman
    Ariman
    2012-09-26

    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.

     
  • dos386
    dos386
    2012-09-26

    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 :-(

     
  • Ariman
    Ariman
    2012-09-27

    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?

     
  • dos386
    dos386
    2012-10-02

    > But I will take a look at what the difference between processing of your 2 files.

    Thank you :-)

     
  • dos386
    dos386
    2013-02-03

    > 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.

     
  • Ariman
    Ariman
    2013-02-05

    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.

     
  • dos386
    dos386
    2013-02-06

    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.

     
  • Ariman
    Ariman
    2013-02-06

    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.

     
  • dos386
    dos386
    2013-02-06

    > 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.

    00011E70  72 44 6C 50 74 53 CD E6 D7 7B 0B 2A 01 00 00 00   rDlPtSÍæ×{*••••
    00011E80  E1 D9 31 00 C4 1A 2E 00 00 30 0B 00 AC A5 B4 54   áÙ1•Ä•.••0••¬¥´T
    00011E90  4C E6 2D 00 00 2A 01 00 17 4E 4F                  Læ-••*•••NO
    

    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 )?

     
  • dos386
    dos386
    2013-02-08

    > 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

     
  • Ariman
    Ariman
    2013-02-08

    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.

     
  • dos386
    dos386
    2013-02-09

    > 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 :-(

     
  • Ariman
    Ariman
    2013-02-09

    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.