flat assembler
Message board for the users of flat assembler.

Index > Windows > [SOLVED]break of the SSSO principle? my fault

Author
Thread Post new topic Reply to topic
edfed



Joined: 20 Feb 2006
Posts: 4325
Location: Now
edfed 06 Feb 2023, 23:10
i tryed to compile again some codes with fasmw 1.73.30.
theses codes were still compiled with success with the same version of fasmw, and the same version of the source.
nothing should have been changed and now, when i compile, the binaries are not the same, and the new one doesn't execute...

what the f***?

is that possible for a window update to modify the fasm compiler behavior?
have i a strange virus or so?
does a newly installed program modify some stuff somewhere???


Description: both binaries are compiled with the exact same source, and the same fasmw version...
Download
Filename: altered_polygon.zip
Filesize: 21.96 KB
Downloaded: 164 Time(s)



Last edited by edfed on 07 Feb 2023, 12:06; edited 1 time in total
Post 06 Feb 2023, 23:10
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20116
Location: In your JS exploiting you and your system
revolution 07 Feb 2023, 00:38
Some binary formats have embedded timestamps. PE files have them.

So it is possible it is just the timestamp changing each time you assemble.

It is only a few bytes that change 6 or 8 or similar, in fixed positions, so they are easy to recognise.
Post 07 Feb 2023, 00:38
View user's profile Send private message Visit poster's website Reply with quote
FlierMate11



Joined: 13 Oct 2022
Posts: 94
FlierMate11 07 Feb 2023, 07:35
Nice polygon.exe.bak that you have, nice graphics, but they are not the same size.

Original is 32,768 bytes (0x8000), but polygon.exe is 33,280 (0x8200), the file alignment is correct though.

I took a look via hexdump, both headers are not the same. I will post again after I inspect with CFF Explorer.
Post 07 Feb 2023, 07:35
View user's profile Send private message Visit poster's website Reply with quote
FlierMate11



Joined: 13 Oct 2022
Posts: 94
FlierMate11 07 Feb 2023, 07:44
The section headers are not the same, the VirtualSize and RawSize between code sections, for example, are different in size. I don't know how come they become like this if compiled from the same source with the same assembler.

Looks like your newly compiled polygon.exe has extra 0x200 bytes of code section. That explains why polygon.exe is 512 bytes longer than original working executable.


Description: Original working polygon 32KB
Filesize: 13.04 KB
Viewed: 2815 Time(s)

original.png


Description: Newly compiled polygon 33KB
Filesize: 12.86 KB
Viewed: 2816 Time(s)

polygon.png


Post 07 Feb 2023, 07:44
View user's profile Send private message Visit poster's website Reply with quote
FlierMate11



Joined: 13 Oct 2022
Posts: 94
FlierMate11 07 Feb 2023, 07:59
It does look like the disassembled code is not the same, too. I will post again after insepcting with Ghidra.
Sorry for multiple posts.

I am not good in debugging, so I will just show the few lines in the beginning of the EXE:
Disassembly:
Code:
original working exe:

        00401000 6a 00           PUSH       0x0
        00401002 ff 15 a4        CALL       dword ptr [->KERNEL32.DLL::GetModuleHandleA]     = 000020ee
                 20 40 00
        00401008 a3 33 30        MOV        [DAT_00403033],EAX
                 40 00
        0040100d 6a 11           PUSH       0x11
        0040100f 50              PUSH       EAX
        00401010 ff 15 ac        CALL       dword ptr [->USER32.DLL::LoadIconA]              = 00002290
                 21 40 00
        00401016 a3 37 30        MOV        [DAT_00403037],EAX
                 40 00

newly compiled non-working exe:

        00401000 6a 00           PUSH       0x0
        00401002 ff 15 a4        CALL       dword ptr [->KERNEL32.DLL::GetModuleHandleA]     = 000020ee
                 20 40 00
        00401008 a3 33 30        MOV        [DAT_00403033],EAX
                 40 00
        0040100d 50              PUSH       EAX
        0040100e ff 15 ac        CALL       dword ptr [->USER32.DLL::LoadIconA]              = 00002290
                 21 40 00
        00401014 6a 11           PUSH       0x11
        00401016 ff 15 ac        CALL       dword ptr [->USER32.DLL::LoadIconA]              = 00002290
                 21 40 00
        0040101c a3 37 30        MOV        [DAT_00403037],EAX
                 40 00
    


As you can see, the non-working LoadIconA only take one parameter at a time:

Code:
HICON LoadIconA(
  [in, optional] HINSTANCE hInstance,
  [in]           LPCSTR    lpIconName
);    


It is supposed to be two parameters, which is correct in the first polygon.exe.

Hope this give some help already!
Post 07 Feb 2023, 07:59
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4325
Location: Now
edfed 07 Feb 2023, 08:57
hooo, i get it.

that's my fault.

i tryed this in proc32.inc from fasm MACRO includes.

Code:
macro stdcall proc,[arg]                ; directly call STDCALL procedure
 { common
    if ~ arg eq
   reverse
    pushd arg
   common
    end if
    call proc }

macro invoke proc,[arg]                 ; indirectly call STDCALL procedure
 { stdcall [proc],arg }   
    


what is incredible is that the fasmw compiled with this version of macro works... and can compile itsleft... WTF again.

but at least i can reuse my code.

thank you. i am not so familiar with MZ format.
Post 07 Feb 2023, 08:57
View user's profile Send private message Visit poster's website Reply with quote
ProMiNick



Joined: 24 Mar 2012
Posts: 786
Location: Russian Federation, Sochi
ProMiNick 07 Feb 2023, 09:16
edfed wrote:

Code:
macro invoke proc,[arg]                 ; indirectly call STDCALL procedure
 { stdcall [proc],arg }   
    

it is equivalent to
Code:
macro invoke proc,[arg]                 ; indirectly call STDCALL procedure
 { forward stdcall [proc],arg }; so for every instance of arg made separate one call    

but thou need this I guess:
Code:
macro invoke proc,[arg]                 ; indirectly call STDCALL procedure
 { common stdcall [proc],arg }    

_________________
I don`t like to refer by "you" to one person.
My soul requires acronim "thou" instead.
Post 07 Feb 2023, 09:16
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20116
Location: In your JS exploiting you and your system
revolution 07 Feb 2023, 09:21
edfed wrote:
... fasmw compiled with this version of macro works... and can compile itsleft...
Last time I looked the fasm/fasmw sources don't use macros so it has no effect.
Post 07 Feb 2023, 09:21
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4325
Location: Now
edfed 07 Feb 2023, 11:02
ok, then it's completelly solved... as always, the bug comes from the guy on the chair
Post 07 Feb 2023, 11:02
View user's profile Send private message Visit poster's website Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1588
Location: Toronto, Canada
AsmGuru62 07 Feb 2023, 16:50
It is a rare thing to meet a compiler bug, the real one.
I saw a case of this only once in ... well, I code since 1984.
In famous VC++ 6.0 if you use "?:" expressions inside a for( ... <-- here --> ...) loop -- the Debug version is OK, but Release will crash -- optimizer fails to do it properly.
Post 07 Feb 2023, 16:50
View user's profile Send private message Send e-mail Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.