The VCD format allows most video players to playback movies. My portable camera can only save files to AVI format. Using the ffmpeg and K3B, the AVI can be burned to a VCD format. I am doing this on Ubuntu 7.10 and a CDROM burner that comes with the Lenovo R60.
This how to converted a 32Mb AVI to 286Mb VCD under 5 mins.
Step 1. Translate to MPG, which is a format K3B recognises. I am using the PAL TV system, if it is NTCS, replave with the value ntsc-vcd.
ffmpeg -i jacq_grad20080824.03.avi -target pal-vcd /tmp/jacq20080824.mpg
This gave me resolution of 352x228 and the following output:
FFmpeg version SVN-rUNKNOWN, Copyright (c) 2000-2007 Fabrice Bellard, et al.
configuration: --enable-gpl --enable-pp --enable-swscaler --enable-pthreads --enable-libvorbis --enable-libtheora --enable-libogg --enable-libgsm --enable-dc1394 --disable-debug --enable-libmp3lame --enable-libfaadbin --enable-libfaad --enable-libfaac --enable-xvid --enable-x264 --enable-liba52 --enable-amr_nb --enable-amr_wb --enable-shared --prefix=/usr
libavutil version: 1d.49.3.0
libavcodec version: 1d.51.38.0
libavformat version: 1d.51.10.0
built on Aug 10 2008 11:11:16, gcc: 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
Input #0, avi, from 'jacq_grad20080824.03.avi':
Duration: 00:03:48.1, start: 0.000000, bitrate: 10031 kb/s
Stream #0.0: Video: mjpeg, yuvj422p, 640x480, 20.00 fps(r)
Stream #0.1: Audio: pcm_u8, 11024 Hz, mono, 88 kb/s
PIX_FMT_YUV420P will be used as an intermediate format for rescaling
Output #0, vcd, to '/tmp/jacq20080824.mpg':
Stream #0.0: Video: mpeg1video, yuv420p, 352x288, q=2-31, 1150 kb/s, 25.00 fps(c)
Stream #0.1: Audio: mp2, 44100 Hz, stereo, 224 kb/s
Stream mapping:
Stream #0.0 -> #0.0
Stream #0.1 -> #0.1
--- end of output---
Step 2. Use K3B 1.0.4 to burn to the VCD format.
In K3B choose File ->New Project ->New Video CD Project.
Drag the MPG file to the VideoCD0, window.
Click on the Burn button.
Select the Volume Descriptor tab, edit the Volume name.
Click Start button.
Sunday, August 24, 2008
Tuesday, August 19, 2008
A CMS called Plone
Plone is a content management system using Zope application server. Just like any other popular application, it is prone to hacker attack. There is lesser exploits compared to PHP based CMS,
Example of pre Plone 3.1 security issue is the
Cross Site Request Forging (CSRF) security vulnerability where CSRF attacks work against people with a valid session on a Plone site: an attacker can — by tricking them (or their browser) to make an HTTP request to the site — use their active session and change security sensitive settings such as the users email address.
Following are general precautions on installation of CMS, refer to http://tboxmy.blogspot.com/2008/08/cms-called-joomla.html
Additional precautions you can take:
Password reset vulnerability, Plone tools did not have proper security checks for its password reset method, allowing anonymous users to reset any users password through the web. (affects pre 2.5)
plone-group-spoofing, Plone could allow a remote attacker to spoof certain information, caused by an unspecified vulnerability in member registration. If anonymous users can register as a member, a remote attacker could exploit this vulnerability and falsely register as a group. (Affects 2.5.1)
Plone CMS cookie places a base64 encoded form of the username and password in the __ac cookie for all user accounts, which makes it easier for remote attackers to obtain access by sniffing the network. (Affect pre 2.5)
Example of pre Plone 3.1 security issue is the
Cross Site Request Forging (CSRF) security vulnerability where CSRF attacks work against people with a valid session on a Plone site: an attacker can — by tricking them (or their browser) to make an HTTP request to the site — use their active session and change security sensitive settings such as the users email address.
Following are general precautions on installation of CMS, refer to http://tboxmy.blogspot.com/2008/08/cms-called-joomla.html
Additional precautions you can take:
- Keep Python updated.
Password reset vulnerability, Plone tools did not have proper security checks for its password reset method, allowing anonymous users to reset any users password through the web. (affects pre 2.5)
plone-group-spoofing, Plone could allow a remote attacker to spoof certain information, caused by an unspecified vulnerability in member registration. If anonymous users can register as a member, a remote attacker could exploit this vulnerability and falsely register as a group. (Affects 2.5.1)
Plone CMS cookie places a base64 encoded form of the username and password in the __ac cookie for all user accounts, which makes it easier for remote attackers to obtain access by sniffing the network. (Affect pre 2.5)
Monday, August 18, 2008
A CMS called Joomla
Joomla! is a widely used content management system using PHP and its frameworks. However due to its large user base, hackers have been attracted like bees to honey.
Example of pre Joomla! 1.5.6 security issue is the
Joomla "token" Password Change Vulnerability where the admin password could be reset easily. Users can then install the Joomla explorer component, and upload malicious scripts.
Following are some precautions on installation of Joomla!
One good reason to use Apache web server is the availability of a benchmarking tool. There are some constrains that you should know in using this data. Read the documentations. Install Apache and execute as below:
ab -n7500 -c100 http://server.com
Where
-n option is the number of request for benchmark
-c is the number of concurrent page request
===========
Document Path: /
Document Length: 36649 bytes
Concurrency Level: 100
Time taken for tests: 183.819035 seconds
Complete requests: 500
Failed requests: 383
(Connect: 0, Length: 383, Exceptions: 0)
Write errors: 0
Total transferred: 6472586 bytes
HTML transferred: 6260026 bytes
Requests per second: 2.72 [#/sec] (mean)
Time per request: 36763.806 [ms] (mean)
Time per request: 367.638 [ms] (mean, across all concurrent requests)
Transfer rate: 34.38 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1446 4324.4 0 21000
Processing: 47 23707 49002.2 1897 175812
Waiting: 47 21936 45081.7 1897 173650
Total: 47 25153 49793.2 2214 183816
Percentage of the requests served within a certain time (ms)
50% 2214
66% 6756
75% 10461
80% 27527
90% 132227
95% 151803
98% 175812
99% 181539
100% 183816 (longest request)
=== END ====
Other references:
For discussion on application security see https://nvd.nist.gov/cwe.cfm#NVD-CWE-DesignError.
My advice to those considering other CMS is this;
All CMS will have their weak points. However Joomla! have thus far been prompt with security notices and updates. Hackers tend to crawl the webs on Friday to Sundays, when systems are unattended. As the care taker of the Joomla! you need to be proactive, it goes the same for any other CMS. Finally, Joomla! is easy to use for end-users and provides lots of features for beautifications.
Example of pre Joomla! 1.5.6 security issue is the
Joomla "token" Password Change Vulnerability where the admin password could be reset easily. Users can then install the Joomla explorer component, and upload malicious scripts.
Following are some precautions on installation of Joomla!
- Patch the OS and its other software
- Open only needed ports (HTTP, HTTPS)
- Patch the software
- Configure the software in a secure manner
- Verify that Joomla! is from the official site http://www.joomla.org
- During installation - Do not use the default MySQL tables prefix as jos_
- Change the default administrator name (default is admin)
- Remove all files as instructed by Joomla! And other unneeded files or directories
- Ensure files and directories have the proper permissions. Below are for Linux based systems.
- PHP files: 644
- Config files: 666
- Other folders: 755
- Password protect sensitive directories with .htaccess
- Move the configuration.php file to outside of the web directory if possible. Make it non-writable.
- Use a search engine friendly (SEF) URLs
-
The Google inurl: command can be used to search for a vulnerable exploit. Use Artio, SH404SEF or another SEF component to re-write your URLs. This will prevent hackers from finding the exploits.
- Establish a security plan and ensure the relevant parties know about it.
- Remove unused extensions and themes. Existing extensions and themes should have their version removed from the end user view.
- Subscribe to Joomla! and the extensions/themes sites for continuous updates. Additional sites that can help with updates:
- http://joomla-wiki.de/doku.php?id=howto_s:security:checklist
- http://docs.joomla.org/Joomla_Administrators_Security_Checklist
- Subscribe to security sites such as http://www.ictsecurity.gov.my/
- Carryout routine backup of Joomla! Site and its database.
One good reason to use Apache web server is the availability of a benchmarking tool. There are some constrains that you should know in using this data. Read the documentations. Install Apache and execute as below:
ab -n7500 -c100 http://server.com
Where
-n option is the number of request for benchmark
-c is the number of concurrent page request
===========
Document Path: /
Document Length: 36649 bytes
Concurrency Level: 100
Time taken for tests: 183.819035 seconds
Complete requests: 500
Failed requests: 383
(Connect: 0, Length: 383, Exceptions: 0)
Write errors: 0
Total transferred: 6472586 bytes
HTML transferred: 6260026 bytes
Requests per second: 2.72 [#/sec] (mean)
Time per request: 36763.806 [ms] (mean)
Time per request: 367.638 [ms] (mean, across all concurrent requests)
Transfer rate: 34.38 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1446 4324.4 0 21000
Processing: 47 23707 49002.2 1897 175812
Waiting: 47 21936 45081.7 1897 173650
Total: 47 25153 49793.2 2214 183816
Percentage of the requests served within a certain time (ms)
50% 2214
66% 6756
75% 10461
80% 27527
90% 132227
95% 151803
98% 175812
99% 181539
100% 183816 (longest request)
=== END ====
Other references:
For discussion on application security see https://nvd.nist.gov/cwe.cfm#NVD-CWE-DesignError.
My advice to those considering other CMS is this;
All CMS will have their weak points. However Joomla! have thus far been prompt with security notices and updates. Hackers tend to crawl the webs on Friday to Sundays, when systems are unattended. As the care taker of the Joomla! you need to be proactive, it goes the same for any other CMS. Finally, Joomla! is easy to use for end-users and provides lots of features for beautifications.
Subscribe to:
Posts (Atom)