Index
> Windows > win64 64 bit source samples, executablesGoto page Previous 1, 2, 3, 4, 5, 6, 7 Next |
| Author |
|
|
MazeGen 15 Feb 2006, 20:32
It seems so, but the manual is very laconic in this point.
Could anybody confirm this? |
|||
15 Feb 2006, 20:32 |
|
|
Vitaliy Jungle 16 Feb 2006, 09:37
Hello, Feryno! Thanks for the reply! Yes, I’ve tried to link a05.sys 64-bit driver to my test 32-bit application compiled with Borland Delphi 6.0, because I’m not experienced in pure ASM enough. I used classic Win32 Service API functions – OpenSCManager, OpenService, CreateService and so on. My test application successfully registers the driver in the Service Manager and starts it, but when I’m trying to communicate with the driver, e.g. to read any DWORD port, using a classic WriteFile function exported from kernel32 in result I receive zeros. Maybe I should fill both wparam and lparam parameters? Currently, I put a port address into the wparam only.
p.s. I’m glad to hear the driver works perfectly with legacy applications! |
|||
|
16 Feb 2006, 09:37 |
|
|
Feryno 17 Feb 2006, 12:46
Hello, Vitaliy,
I suppose that Delphi 6 isn't able to produce "hybrid" code (32+64 bit mixed together), it produce only pure 32-bit and you aren't able to use first 2 IO (DRIVER_QUERY_PROC_NOARGS, DRIVER_QUERY_PROC_STDCALL). But other IO should work, especialy things you have tried. Maybe Delphi produce 1 dword = 4 bytes for iocode, wparam, lparam instead of 1 qword = 8 bytes... so the size is 0Ch, not 18h ? I got a few system resets during trying to change offsets for handle 32-bit app request in 64-bit a05 driver. Then I decided, that a05.sys should be good and I focused on 32-bit user application. For the first try, I got a correct value returned by reading CMOS year byte by DRIVER_QUERY_PORT_OUT_BYTE folowed by DRIVER_QUERY_PORT_IN_BYTE and then a system hang after executing 32-bit procedure with 64-bit a05.sys (but fortunately no reset, only brutaly slow system reactions -> no correct shutdown after a few minutes of waiting, only reset button on PC-case helped... I like so much to explain to win2003 server what have happend... on recovery boot I like to choose possibility like Power failure or AC cord unplugged instead of nonexisting System reset by lamer code...) Procedure in 32-bit app was proc_to_execute_in_64_bit: ... mov eax,20000000h L0: dec eax or eax,eax jnz L0 ... ret opcodes were: B800000020 mov eax,20000000 L0: 48 dec eax 09C0 or eax,eax 75FB jnz L0 and disassembling them in 64-bit world: B800000020 mov eax,20000000 L0: 4809C0 or rax,rax 75FB jnz L0 So I saw that loop assembled under 32-bit is neverending loop under 64-bit because byte 48 is REX prefix in 64 and no anymore dec eax as in 32 bit. I just added directive use64 at begin of proc_to_execute_in_64 and then 32-bit user app did what I expected, everything was correct. But back into your problem... You tried to write to the driver. You have to write exactly 3 qwords = 18h bytes to it, because driver verify this ;cmp [rsi + IO_STACK_LOCATION.Parameters.Write.dwLength],sizeof.DriverQuery cmp dword [rsi + 8],3*8 jnz ... Just prepare 18h bytes buffer in Delphi, put iocode at offset 0, port at offset 8 (wparam) and last qword (lparam) may be empty, it is used to send the result of value read from port back to the user app. I don't know how it will be coded under Delphi, but only a few things are necessary when read from port by 32-bit user app: 1. iocode e.g. DRIVER_QUERY_PORT_IN_BYTE = 20h at offset 0 2. port number at offset 8 3. write to the driver 18h bytes exactly. 4. then you can grab value returned by reading of port at offset 10h of structure sent to the driver. Please send a feedback of your succes, it must be done in delphi too, but delphi is for me much more complex than clear asm code, so I'm not able to help you more. |
|||
|
17 Feb 2006, 12:46 |
|
|
Vitaliy Jungle 17 Feb 2006, 17:46
Hello, Feryno!
Thank you for your respond! Frankly speaking, I’m have never saw a man who have spent so much time for the problem of unknown person. Thank you! So, as for Delphi 6.0, which was developed in 2001, it compiles projects into 32-bit applications only. Of course, it supports 32-bit inline assembler and can operate with MMX/3Dnow!/SSE instructions, but nothing more! Nonetheless, it supports a new int64 integer type which lies in the range of –2^63..2^63–1. Well, I’ve made some corrections regarding your notice in the source code of my test application. So, below is the source code to read from the byte port. I think you are able to read it, because it’s very simple to understand and has no any significant differences in comparing with FASM code: Code: type TR0DriverQuery = record iocode : int64; // user I/O code wparam : int64; // parameter lparam : int64; // parameter end; //the same record on FASM ;struct DriverQuery ; iocode dq ? ; user I/O code ; wparam dq ? ; parameter ; lparam dq ? ; parameter ;ends function GetPortByte(PortAddr: Word) : byte; var dwResult : DWORD; PortInBQuery : TR0DriverQuery; begin PortInBQuery.iocode:=$20; PortInBQuery.wparam:=PortAddr; PortInBQuery.lparam:=$00; if WriteFile(hDriver, PortInBQuery, SizeOf(PortInBQuery), //the size is 18h dwResult, nil) then begin Result:=dwResult; showmessage('HELLO!'); //it’s just 4 debugging purposes. OK! end else Result:=$FF; end; Unfortunately, the problem is the same. I receive zeros in dwResult, but the function succeeds now! This is due to your notice about 24-byte size of in buffer. The function failed before, because I allocated 12-byte buffer (3 variables with DWORD type). Also, I decided to disassemble an EXE file in OllyDebugger, PE Explorer 1.96 and WDASM 10. There was no any difference. So, below is the screen dump of my GetPortByte function gotten in OllyDebugger: 
Well, This evening I’ll install Borland Delphi 2005 Architect that is much newer. Maybe this will solve the problem. BTW, your optimized 64-bit a05.sys driver works perfectly with its code native write_device application! Good luck, Feryno! |
|||
|
17 Feb 2006, 17:46 |
|
|
r22 19 Feb 2006, 02:35
Any macros for PE64 resource sections? Or a ported Dialogue example.
|
|||
|
19 Feb 2006, 02:35 |
|
|
Vitaliy Jungle 19 Feb 2006, 12:28
Feryno, I have found an example of 64-bit driver that works with ports too - http://www.logix4u.net/inpout64.htm So, I have linked it to my 32-bit application and all works fine! Besides, I’ve dissembled 64-bit driver of ASUS PC Probe utility to find some I/O codes to communicate with I/O ports. Fortunately, I linked the driver too and it works fine for me! So, I’m sure there is no any problem around applications compiled with Delphi 6.0! Good luck!
|
|||
|
19 Feb 2006, 12:28 |
|
|
Feryno 20 Feb 2006, 09:58
Hello Vitaliy, you received zeros in dwResult, it meens that writing to device succeeded. You should receive value of port reading in lparam - not in dwResult.
try Result:=PortInBQuery.lparam I'm surprised of "economical" code produced by delphi! Disassembled looks well, fast, without unnecessary ballast. Hello r22, fdbg have resource, look into fdbg.asm in sources another sample http://board.flatassembler.net/topic.php?p=33645#33645 Hello everybody, I tried bochs emulator and it was able to run pure 16-bit dos under win64. Of course slow emulation only, no real V86... DOSBox emulator works well in win64 too. |
|||
|
20 Feb 2006, 09:58 |
|
|
valy 07 Mar 2006, 12:56
Hi Feryno
I really appreciate your fdbg0003 
A few bugs when displaying the following opcodes: movntq [rdi+8],mm2 movq [12345678],mm1 => 0f 7f 0c is displayed first, then 25 78 56 34 12 as if it were a 2nd instruction 
The same with: movq [045DF31h+rbx*8],mm0: it displays three lines: "0f 7f 04" then "dd 31" then "df 45 00" I think u can say the same with any "movq mem,mmx" instruction. Another problem with jnz mylabel when jnz is coded 0f 85... Try for instance: 0f 85 10 10 00 00, bad display Keep the good work 
Regards valy _________________ Easier, faster |
|||
|
07 Mar 2006, 12:56 |
|
|
Feryno 09 Mar 2006, 09:40
Thanx to everybody for finding disasm mistakes and to improve fdbg !
Long conditional jump mistake was caused by forgotten adding of opcode size and this was fixed in http://board.flatassembler.net/download.php?id=2087 from 2006 Feb 15 Fix was simple by replace old bad add rax,rbx with new correct lea rax,[rbp+rax+6] where rbp is absolute offset of opcode, rax relative jump offset, 6 opcode size. The whole 0F80-0F8F group of long conditional jumps was affected and then fixed. Mistake described by Valy was caused by destroying opcode size in RAX, so simple push rax, pop rax helped to fix it. According to Valy's experiences, both movntq (0F7F) and movq (0FE7) was affected and then fixed, later I found another instruction with the same mistake - movd (0F7E). Again, Alorent and Valy, thanx you very much guys for improving fdbg, your names are now included in sources as well displayed in fdbg help. Now I plane to add API name after displaying API call, something like: call qword [00000001000031D4] ; Kernel32.CloseHandle Today it's displayed call qword [00000001000031D4] only - which tells you nothing. Edit from 2006 03 13 updated final version of fdbg0004 in attachment - displaying API name after call instruction is implemented edit 2011-11-30 deleted fdbg0004_final_20060311.zip because of quota limit Last edited by Feryno on 30 Nov 2011, 12:11; edited 1 time in total |
|||
|
09 Mar 2006, 09:40 |
|
|
alorent 16 Mar 2006, 00:02
Thanks a lot for the update Feryno! I love this debugger more each day!
Would it be possible to make a WhatsNew.txt file, so we know what's new in upcoming versions and we are ready to try those new features 
So, do you plan to improve the user interface? That will be great, I'm sure that will attract a lot of people to your debugger!
Keep the good work! Alorent |
|||
|
16 Mar 2006, 00:02 |
|
|
r22 16 Mar 2006, 06:11
Feryno, great job. Seems to disassemble even the larger files pretty quickly.
Some GUI ideas: -Make sure you can copy text from it. Block copy even better so you can copy just code. or just the the addresses and raw opcodes -Make the window fit in 800x600 res |
|||
|
16 Mar 2006, 06:11 |
|
|
Feryno 16 Mar 2006, 08:48
Thanx guys for reply, now I know that people use fdbg and that's the motivation for me to improve it.
It will have include file what's new. It would be good to add help file to it. Functionality is completely done, I tried to develop especially the fastest disasm routine (using conditional moves, xmm calculated hexa transformations and reduce jumps, calls, memory access). Disassembling is very fast, but source of disasm routine isn't clear enough, just at the time of finishing of disasm routines I got the idea how to do it clearer (when I almost lost my orientation in by finishing SSE/SSE2/SSE3 disasm). It's the time to improve fdbg face. No everybody has drivers for graphics card, so someone is able to use only 640x480 or 800x600 resolution with 16 colors. To fit it into this resolution, it is necessary to make it multiwindowed, so user is able to turn on/off child windows to display only necessary things (e.g. only disassmebled instructions and general purpose regs and stack ON and e.g. XMM and MM regs OFF). It's Alorent's idea, I like it. I saw it in Jeremy's Gordon GoBug.exe Listboxes display what they have to display but don't support copy to clipboard function now, this is necessary to implement. |
|||
|
16 Mar 2006, 08:48 |
|
|
alorent 16 Mar 2006, 21:29
Hi Feryno,
I'm happy that you are motivated to continue with this project. I hope to see some improvements again. I really respect your work. Alorent. |
|||
|
16 Mar 2006, 21:29 |
|
|
leh 21 Mar 2006, 07:29
|
|||
|
21 Mar 2006, 07:29 |
|
|
Feryno 03 Apr 2006, 14:37
Hello guys, especially Alorent and r22 !
Implemented what you suggested: copy to clipboard, rearrange ListViews, save 'face' on exit and reload by next startup. Migrated to Project and Ideas forum - fdbg isn't sample anymore, but a real project - later versions will be there: http://board.flatassembler.net/topic.php?p=36918#36918 Using, testing, reports, ideas are welcome. |
|||
|
03 Apr 2006, 14:37 |
|
|
Feryno 10 Apr 2006, 14:08
Please go to Projects and Ideas section
http://board.flatassembler.net/topic.php?p=37236#37236 fdbg 'camouflage' (I have never seen this in any debugger, but I had these ideas and I have transformed them into reality) - hide itself against IsDebuggerPresent - hide itself against FindWindow (needs fdbg restart) - camouflage TrapFlag (avoid to detect debugger by save TrapFlag by pushf) |
|||
|
10 Apr 2006, 14:08 |
|
|
Garthower 21 Apr 2006, 14:52
Hi to all!
I have such question - whether there is an opportunity to use extensions x64 under Win32, but started on AMD64 platform? |
|||
|
21 Apr 2006, 14:52 |
|
|
r22 23 Apr 2006, 04:27
You'd have to change the CPU's processing mode.
This question has been asked a lot Garthower, and the general answer seems to be "You can't use x86-64 on a 32bit OS." Even if you made some sort of driver that could switch the CPU to long mode none of the win32 API's would work and the addressing would be all messed up. It just wouldn't be worth it. Win XP64 is surprisingly, not that bloated. If you sacrifice: -System Restore -Administrative Tools -Sound You can run Win XP64bit with barely any memory, overhead, or loss of functionality (except for the above stated).
|
||||||||||
|
23 Apr 2006, 04:27 |
|
|||||||||
|
Feryno 23 Apr 2006, 10:09
to r22 - nice configuration !!!
to all - fdbg0007: http://board.flatassembler.net/topic.php?p=37847#37847 |
|||
|
23 Apr 2006, 10:09 |
|
| Goto page Previous 1, 2, 3, 4, 5, 6, 7 Next < Last Thread | Next Thread > |
Forum Rules:
|