DavidL http://davidl.javaeye.com UTF-8 Copyright 2003-2008, JavaEye.com http://blogs.law.harvard.edu/tech/rss JavaEye - 做最棒的软件开发交流社区 交行网站跨站漏洞 DavidL 作者: DavidL  链接：http://davidl.javaeye.com/blog/141608  发表时间: 2007年11月19日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

http://www.bankcomm.com/jh/cn/detail.jsp?c=1121231469100&id=1168824142100&cName=%3Cscript%3Ealert('hacker')%3C/script%3E&type=CMS.STD
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Mon, 19 Nov 2007 09:20:41 +0800 http://davidl.javaeye.com/blog/141608 http://davidl.javaeye.com/blog/141608 Descent Hacking DavidL 作者: DavidL  链接：http://davidl.javaeye.com/blog/113520  发表时间: 2007年08月17日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Descent is a great IDE plugin for eclipse (D language) which takes advantage of ddbg debugging and the powerful eclipse texteditor.

And it comes to a stage nearly really usable. And I took a look at it.

The main problem of the descent is debugging.  It doesn't feed the module name to ddbg, i.e. a file in C:\dmd\project\abc.d would be directly fed to ddbg which would result the breakpoint not taking any effect. Workaround is simple. In the addBreakpoint it add a DescentLineBreakpoint. What I did was adding a parsing right before the breakpoint was added to the breakpoint manager.  Translating the "module abc.mymodule;" to abc/mymodule.d and at last send it to ddbg debugger backend.

This solution was the first patch I posted in the forum. In the fourm because the code was not quoted under code tag, so indentation info got lost, you can see the indentation in the HTML source anyway :) The newest patch is guarded by the code tag, so you can view it nicely :)

Yet I came to another problem of reloading eclipse D project, the breakpoints were not working any more. After tracing around the eclipse.org.breakpointmanager?( I can't launch the eclipse right at the moment, cause the machine's memory is so limited , 512M, so this two patches took me  1 week ) , the breakpoint manager loaded the breakpoints from the IMarker info. So all extention in DescentLineBreakpoint all got lost. This is actually a design flow of the breakpoint manager. A breakpoint manager shouldn't be launched in such an early stage, and also the breakpoint manager shouldn't add all breakpoints as its own interface class LineBreakpoint, it prevents others from enhancing the breakpoint or any fancy extention points like IWorkbench. After understanding the whole bug, I can now come to fix the problem. We need to refresh all the breakpoints after the breakpoint manager got them loaded. I stupidly wanted to fix it by simply copy code from the original fix. So it required IDocumentProvider and therefore ITextEditor. At last , I found out that was not required. The code in the DescentLineBreakpoint constructor was actually need the ITextEditor-> IDocumentProvider -> lineStart, lineEnd, and at last those two variables are set to IMarker for further reusing(possibly the highlighting). And actually those two values I can get from IMarker by getAttributes, at last I can reuse the constructor recreate the breakpoint, also I would remove the breakpoint firstly :)

I can't paste much code here :) Sorry for the poor blogging. You can get the newest patch in the following link:

http://www.dsource.org/forums/viewtopic.php?p=16025#16025

Setting breakpoints is correct now, though it gets issues of F8 (continue the execution of the source), you need to type something(arbitrarily) in the console to feed ddbg , and then the eclipse debugging system seems to take the control back again.

Have fun with descent !
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Fri, 17 Aug 2007 15:23:51 +0800 http://davidl.javaeye.com/blog/113520 http://davidl.javaeye.com/blog/113520 Cleanups Done DavidL 作者: DavidL  链接：http://davidl.javaeye.com/blog/108918  发表时间: 2007年08月04日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Clean up two old blogs, which was edited in opera (the edit box was so small). In firefox, I can review these blogs easily, and some clean up done.

NASM 0.99.01 was buggy for the 32bit/16bit codegen. When an instruction which access register and mem, it would be generated with 0x67 prefix for a 16bit segment. This blocks the elf2 bootsect, which has size limitation, extra 0x67 makes the code bloated, so the compilation breaks.
I did a quick hack, and posted the new compiled binary to the ReactOS Build Environment maintainer. Also I filed it as a bug, though the nasm64developer told me that this couldn't be reproduced in 0.99.02 CVS snapshot. O_O , after a try , yes, it's already fixed. ;) so my hacking over nasm is useless.

Though another thing interesting is spotted about GDB. GDB itself is a nice debugger. But...

c 代码
 
  1. #include "stdio.h"  
  2. void __stdcall call()  
  3. {  
  4.     printf("hello!");  
  5. }  
  6. void main()  
  7. {  
  8.     call();  
  9. }  

when you try to
gdb下调试
  1. b call  
gdb fails.

This is the reason why gdb couldn't get all symbols work in Kernel Debugging.

Remarks:
__stdcall __fastcall are calling convention in Windows, they both add @ to the mangled name, seems like gdb fail to deal with mangle name with '@'

mangle name(link time symbol):
c mangle convention: underscore prefix, so every C symbols in asm would be prefixed with an underscore.
so a typical link with ASM files would be
test.c
c 代码
 
  1. extern int myasmSymbol;    
  2. int main()    
  3. {    
  4.       return myasmSymbol;    
  5. }    
myasm.S
asm 代码
 
  1. .text  
  2. .global _myasmSymbol  
  3. _myasmSymbol: .int 0   


gcc -c myasm.S
gcc -c test.c

gcc test.o myasm.o -o test.exe







本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Sat, 04 Aug 2007 15:30:03 +0800 http://davidl.javaeye.com/blog/108918 http://davidl.javaeye.com/blog/108918 Sadly, what I did was wrong due to MSDN DavidL 作者: DavidL  链接：http://davidl.javaeye.com/blog/104705  发表时间: 2007年07月24日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

the API is designed in a way of weirdness. People call this API sending integer value to subsystem thru randomly choosed arg by the specific SPI_GETblahblah. Recently I posted MmGrowKernelStack patch to ReactOS. This internal func is for cut down the kernelstack memory. Cause most threads use only KERNEL_STACK_SIZE, only GUI threads require KERNEL_LARGE_STACK_SIZE, and what's been done in NT? From the comments in ReactOS code, we find out that NT actually allocates KERNEL_STACK_SIZE for GUI thread at the very beginning. So the GUI thread would have only KERNEL_STACK_SIZE stack, while it could be not enough, so every call of growing kernel stack which might exhaust kernel stack would call MmGrowKernelStack. More details could be seen in bug 2413.
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Tue, 24 Jul 2007 13:27:46 +0800 http://davidl.javaeye.com/blog/104705 http://davidl.javaeye.com/blog/104705 NT / Subsystem DavidL 作者: DavidL  链接：http://davidl.javaeye.com/blog/100483  发表时间: 2007年07月12日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

It's interesting to work with the subsystem. Recently I discovered a bug of CPL(Control Panel) in reactos. The original one didn't send SPI to subsystem, and also the way of sending is incorrect. How do we get system parameter set and sent to the kernel space and also updated in registry? It itself is complicated problem. While my understanding is , CPL itself a dll calls SystemParametersInfo, and this API is in user32.dll, the API is implemented in the user32\misc\desktop.c we get two versions there SystemParametersInfoA and SystemParametersInfoW dealing with different encoding as other APIs do. And this API establishes a call to NtUserSystemParametersInfo which switch to the kernel mode. And the kernel mode subsystem would deal with the DATA sent from CPL. At last we understand the calling chain clear. Inside the subsystem , the core func calls UserSystemParametersInfo internally. After some protection check in kernel mode being done , the kernel func calls IntSystemParametersInfo. This at last deal with the data we sent. There are two ways of sending data to this func.
c 代码
 
  1. ULONG FASTCALL IntSystemParametersInfo( UINT uiAction, UINT uiParam, PVOID pvParam, UINT fWinIni)   


As we can see there are uiAction which stands for our action, uiParam & pvParam represents different data sent. When we are sending some int like builtin small data we use the 2nd arg uiParam, while if we want to pass more we need pvParam. And obviously pvParam points to area of user space. So it's already get probed correct in order to not result KeBugCheck. That's how our Control Panel works. And at last I developed the software mouse acceleration for Reactos. It's also in subsystem. Subsystem is really a funny place to play with. And I hope someday POSIX subsystem gets done, and running linux binaries in Reactos. Maybe coLinux uses the similar implementation as a subsystem
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Thu, 12 Jul 2007 18:47:00 +0800 http://davidl.javaeye.com/blog/100483 http://davidl.javaeye.com/blog/100483