flat assembler
Message board for the users of flat assembler.

flat assembler > Projects and Ideas > Quick Decoder 64 - Hex editor for DOS and WINDOWS

Author
Thread Post new topic Reply to topic
CandyMan



Joined: 04 Sep 2009
Posts: 285
Location: film "CandyMan" directed through Bernard Rose OR Candy Shop
Quick Decoder 64 - Hex editor for DOS and WINDOWS


Description:
Filesize: 11.68 KB
Viewed: 582 Time(s)

QD-00001.PNG


Description:
Filesize: 10.9 KB
Viewed: 582 Time(s)

QD-00000.PNG


Description:
Download
Filename: QD.7Z
Filesize: 694.34 KB
Downloaded: 49 Time(s)


_________________
smaller is better


Last edited by CandyMan on 28 Aug 2018, 20:35; edited 3 times in total
Post 11 Aug 2018, 20:47
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 419
Location: Belarus
Manages to draw its window only once before this happens.


Description: Screenshot of Access Violation in QD.
Filesize: 7.48 KB
Viewed: 562 Time(s)

1.png


Post 12 Aug 2018, 09:47
View user's profile Send private message Visit poster's website Reply with quote
CandyMan



Joined: 04 Sep 2009
Posts: 285
Location: film "CandyMan" directed through Bernard Rose OR Candy Shop
cannot reproduce this bug. what system version you use? whether you could check where exactly this bug is appearing using x96dbg debugger (the last correct address)? what instruction and register causes exception? try to delete the qd.hgl file and then to run a program.

_________________
smaller is better
Post 12 Aug 2018, 16:29
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 419
Location: Belarus
CandyMan wrote:
cannot reproduce this bug. what system version you use? whether you could check where exactly this bug is appearing using x96dbg debugger (the last correct address)? what instruction and register causes exception? try to delete the qd.hgl file and then to run a program.

1) Windows 10 LTSB, 1607, 14393.2368
2) Don’t have it right now, otherwise I’d probably give more insight on possible reasons. Will download it or something similar in the morning. At least, AFAICT, has nothing to do with file system paths (tried both long and short ones including different volumes).
3) qd.hgl deletion didn’t help.

UPD. IDA 7.0 stopped at ntdll.dll:00007FFA22A2D55B (which seems to be the same address as at the screenshot, with respect to ASLR). The instruction there is
Code:
movaps xmm0, xmmword ptr [rsp+40h]    
Tracing back to the program code it seems like the call to FindFirstFileA at 0x4065FA causes the access violation. The parameters passed are:
ECX = 0x4A2160 (pointer to "*.*" string)
EDX = 0x4A30CD

According to this page,
Quote:
The alignment of the beginning of a structure or a union is the maximum alignment of any individual member.


For WIN32_FIND_DATA this alignment is at least 4 while the program passes unaligned pointer. From my experience, this can be the case.
Post 12 Aug 2018, 23:36
View user's profile Send private message Visit poster's website Reply with quote
CandyMan



Joined: 04 Sep 2009
Posts: 285
Location: film "CandyMan" directed through Bernard Rose OR Candy Shop
it for me looks like the unaligned address of the stack. thanks for the help.

_________________
smaller is better
Post 13 Aug 2018, 15:06
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 419
Location: Belarus
CandyMan wrote:
it for me looks like the unaligned address of the stack. thanks for the help.

I don’t think 0x4A30CD is a stack address. It is somewhere in the data section. Both addresses are moved to registers as constants so it shouldn’t be a stack address. Don’t know why the function uses globally defined structure for its local task but it seems the problem is with this structure alignment which is easier to find and fix than looking through the whole program for stack misalignments.
Post 13 Aug 2018, 15:55
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2309
Location: Usono (aka, USA)
CandyMan wrote:
it for me looks like the unaligned address of the stack. thanks for the help.


Naive question (since I don't fully understand SIMD), why not just use "movups" instead?
Post 13 Aug 2018, 18:40
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 419
Location: Belarus
rugxulo wrote:
CandyMan wrote:
it for me looks like the unaligned address of the stack. thanks for the help.


Naive question (since I don't fully understand SIMD), why not just use "movups" instead?

The instruction is part of a function within a system DLL. 64-bit Windows conventions are written in a way that lets Microsoft rely on proper data alignment.

It sometimes shines through to the 32-bit applications though: I once had a problem with 32-bit application using DirectShow which passed some pointer to a component that required 64-bit-convention alignment.
Post 13 Aug 2018, 19:42
View user's profile Send private message Visit poster's website 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-2018, Tomasz Grysztar.

Powered by rwasa.