click
Monday, November 27, 2006
www.live.com default error message
Thursday, September 28, 2006
uhooker v1.2 is out!
you can download it from
or directly from http://oss.coresecurity.com/uhooker/release/1.2/uhooker_v1.2.tgz (tgz)
or http://oss.coresecurity.com/uhooker/release/1.2/uhooker_v1.2.zip (zip)
checkout the doc pages because Im constantly posting new stuff like sample scripts, etc.;
and also in this version there's a minor modification you'll have to make to your
existing scripts to make them work with version 1.2
http://oss.coresecurity.com/uhooker/doc/index.html
See http://oss.coresecurity.com/uhooker/release/1.2/WHATSNEW_1.2.txt for
a complete list of changes.
Saturday, July 01, 2006
Uhooker v1.1 is out!
you can download it from http://oss.coresecurity.com/projects/uhooker.htm
or directly from http://oss.coresecurity.com/uhooker/release/1.1/uhooker_v1.1.zip.
checkout the doc pages because Im constantly posting new stuff, sample scripts, etc.
http://oss.coresecurity.com/uhooker/doc/index.html
Friday, June 23, 2006
Release of the Universal Hooker
You can get more information about 'uhooker' in http://oss.coresecurity.com/projects/uhooker.htm
Basically, uhooker is a tool to intercept api calls/arbitrary addresses and then use python as the scripting language for the hook handlers. There's no need to recompile anything to hook functinos, and the hook handlers can be changed at runtime (e.g.: you can change the code of the hook handler between two different calls to te same function and everything will continue working).
Take a look at the URL I mentiond before, I spent a little more time trying to describe what uhooker does there :).
Saturday, February 18, 2006
Silly bug in gmail chat
When someone enters its gmail account, it will appear as online to others.
If that person closes the browser (not the window, the browser) without signing out from gmail first, it will remain in online state for the rest of this contacts. And from that point on, his state cannot be trusted, even if you logout the contact can appear as online.
I think adding <body onunload="signout"> can solve this.
So if you see online contacts when reading your email and you send messages to them and they do not answer, maybe they're not online :).
Saturday, January 21, 2006
Wehnus Wehntrust (Address Space Layout Randomization)
as its web site states, it is a "Host-based Instrustion Prevention System (HIPS) that
provides secure buffer overflow exploitation countermeasures." [..]
[..] "WenhTrust implements Address Space Randomization (ASLR) for Windows".
There are two versions available, one for commercial user and one for home users.
Both versions have different features:
Home version features:
- Randomized Image Files (DLLs, EXEs with relocations)
- Randomized Memory Allocations (Stack, Heap, etc)
- Randomized PEB/TEB
- Application and Image File Randomization Exemptions
- Same feature set as the home user version
- Native event logging when exploitation occurs
- Balloon tip notifications when an exploit is detected
- SEH overwrite prevention
- Format string vulnerability prevention
- Stack overflow detection
- Brute force detection and prevention
I did not have any stability problems. I did some tests
quick tests, this is not intented to be a full review of the product, just me
playing around for 2 minutes with the product:
The Randomized Memory Allocations seem to be working fine, sample program:
{
char *p;
int i;
unsigned int espvalue;
_asm { mov [espvalue], esp }
printf("esp: %X\n", espvalue);
for ( i = 0; i < 7; i++) {
p = malloc(2000);
printf("%p\n", p);
}
}
Output:
C:\tmp>test
esp: 5708FED8
572F0758
572F0758
572F0758
572F0758
572F0758
572F0758
572F0758
C:\tmp>test
esp: 372CFED8
37510758
37510758
37510758
37510758
37510758
37510758
37510758
C:\tmp>test
esp: 4151FED8
41790758
41790758
41790758
41790758
41790758
41790758
41790758
C:\tmp>test
esp: 48CDFED8
48F70758
48F70758
48F70758
48F70758
48F70758
48F70758
48F70758
C:\tmp>
This was tested on a WinXP SP2. Running the test without wehntrust shows
the same addresses on every execution (for both esp and heap address).
I did not test PEB randomization because it is already done in XP SP2 and I
didn't care much for it anyways. You can observe that how randomization
is performed is pretty clear.
To test the "Randomized Image Files (DLLs, EXEs with relocations)" feature
I wrote this simple program:
void main()
{
printf("%x\n", LoadLibrary("kernel32.dll"));
printf("%x\n", LoadLibrary("ntdll.dll"));
printf("%x\n", LoadLibrary("advapi32.dll"));
printf("%x\n", LoadLibrary("wsock32.dll"));
printf("%x\n", GetModuleHandle(NULL));
}
Output:
C:\tmp>test3
1b0a0000
1ac30000
1b230000
1ddd0000
400000
C:\tmp>test3
1b0a0000
1ac30000
1b230000
1ddd0000
400000
C:\tmp>test3
1b0a0000
1ac30000
1b230000
1ddd0000
400000
The product documentation says it only randomizes PE files with relocations, and my
PE file (as almost any regular EXE PE file) does not have relocation info, so
getting 400000 for GetModuleHandle(NULL) is expected. For the other dlls, the
address shown is in fact not the default one for the dlls, but as you can see,
the address does not change on a per execution basis.