Ady Wicaksono Daily Activities

landrover lr2 2008 – engine maintenance part 1

with 2 comments

Start learning how to maintain my 1st car. LandRover LR2, 3.2 L i6, petrol engine. Below is the first point for engine maintenance.

Engine oil needs to be checked regularly (weekly). Engine oil consumption is influenced by many factors. Under high loads an engine will consume more oil than usual. To check the engine oil use engine oil dipsticks and see if the oil is between min-max scale. Technically, you need to withdraw the dipstick and wipe the blade clean with a lint free cloth and then fully re-insert the dipstick and withdraw again to clearly see the oil level. NEVER allow the oil level to fall below the lower mark/notch on the dipstick.

Engine oil in my case needs to be replaced at least every 10000km. Recommended oil for landrover LR2 2008 is Castrol. Engine oil spec is OW-30 engine oil meeting ACEA A5/B5 spec.The approximate quantity of oil required the level from minimum to maximum on the distick is 1.2 litres (for petrol model only)

Point no. 2 for checking is engine coolant reservoir

This collant as per Wikipedia (http://en.wikipedia.org/wiki/Coolant) is a fluid which flows through a device to prevent its overheating, transferring the heat produced by the device to other devices that use or dissipate it. Hence this is very important, no collant means your engine can be overheated and damaged. In LR2, we will get warning from computer system if the coolant reservoir level drop below the recommendation. Currently I still have no idea the brand used for my car but I will ask my dealer soon, in the manual it’s only mentioned that it;s mixed between 50% water and 50% Texaco XLC antifreeze. Remember to always check things when engine is off and cool.

Please note that we can only use fresh (rain/distilled) water, water contains salt can make serious engine damaged so don’t use it.

Written by adywicaksono

June 24, 2011 at 7:43 am

Posted in landrover

APDU Spytools – sniff communication between SIMcard & Mobile

with 9 comments

During the 3GSM event in Dubai few weeks ago, I got information about 2 spy tools from 2 companies:
AspectsTools (www.aspectstools.com) – an UK company & Comprion (www.comprion.com/) – an Germany Company.

Personally, I like both tools and feels that those tool will be very usefull in the future.
I was struggling to find a tool to spy communication between SIMcard and Mobile, but now if I need it,
I will contact both of them 🙂

If you like & need it, try to contact them.

Written by adywicaksono

December 28, 2009 at 10:09 am

Posted in Uncategorized

function convert8bitTo7bit with PHP

with one comment

As per GSM 03.40 we can send up to 140 octets (8-bit data), so if we send 7-bit data (septet) we can send up to 160 7-bit ASCII characters. Few days ago I need a function to convert a string to septet hexadecimal representation with PHP without any luck. I tried googling with keyword “convert 8bit to 7bit PHP”, “convert octet to septet PHP”, and similar keyword with no luck.

So I managed to create my own function that works fine so far (hopefully) (but I don’t care if my algo is not optimal nor bad:)) below:


<?
function strToHex($string)
{
    $hex='';
    for ($i=0; $i < strlen($string); $i++)
    {
        $hex .= dechex(ord($string[$i]));
    }
    return $hex;
}
function hexToStr($hex)
{
    $string='';
    for ($i=0; $i < strlen($hex)-1; $i+=2)
    {
        $string .= chr(hexdec($hex[$i].$hex[$i+1]));
    }
    return $string;
}

function hexbin($hex){
    $bin='';
    for($i=0;$i<strlen($hex);$i++)
        $bin.=str_pad(decbin(hexdec($hex{$i})),4,'0',STR_PAD_LEFT);
       return $bin;
} 

function binhex($bin){
    $hex='';
    for($i=strlen($bin)-4;$i>=0;$i-=4)
        $hex.=dechex(bindec(substr($bin,$i,4)));
   return strrev($hex);
}

function Convert8BitTo7Bit($string){
	// Convert String to Hex first
	// E.g *135# will be converted to 2A 31 33 35 23
	$string = strToHex($string);
	// print   "STR = $string\n";
	$total = "";
	for($i = 0; $i < strlen($string); ){
		// Get 1st character string, it's 2 character hex
		$X = $string[$i++].$string[$i++];
		// Convert it to binary
		$my8bit = hexbin($X);
		//print "(8bit) ==> $my8bit\n";
		// remove left side of octet, it shall be septet
		// e.g 2A in octet is 00101010 (8 bit), remove most left 0 --> 0101010 (7 bit)
		$my7bit = substr($my8bit,1,7);
		//print "(7bit) ==>  $my7bit\n";
        // Concatenate it
		$total = $my7bit.$total;
	}
	// Padding the string
	if(strlen($total) % 8 != 0){
		$p1     = (intval((strlen($total) / 8)) + 1) *  8;
		$total  = str_pad($total,$p1,'0',STR_PAD_LEFT);
	}
	$pad   = 7;
	// Conversion begin
	for($i = strlen($total) - 1; $i >= 0 ; $i--){
		$mypad[$pad--] = $total[$i];
		if($pad < 0 || $i <= 0){
			$pad  = 7;
			$tmp1 = array_reverse($mypad);
			//print_r($tmp1);
			$tmp2 = implode($tmp1);
			$res = binhex($tmp2);
			$result .= "$res";
		}
	}
	return $result;
}


?>


To use that code, we simply call the function like this

print Convert8BitTo7Bit("*135#")."\n";

It will print “AAD8AC3602” which represent hexcode to be send on top of TP-UD GSM 03.40

Another wxample: we have 160 characters to send like below
“Test SMS content 160 characters will be displayed as 140 octets. Test SMS content 160 characters will be displayed as 140 octets.Test SMS content 160 characters”

With calling

print Convert8BitTo7Bit("Test SMS content 160 characters will be displayed as 140 octets. Test SMS content 160 characters will be displayed as 140 octets.Test SMS content 160 characters");

We get 140 octets/bytes hexadecimal code for this:


d4f29c0e9a36a7a0f1db4d2fbbe9a0980d061aa3c3f2f0985e96cf41f7349b0d129741e4f41cce0ee7cb6450780e8ad160a0f7985ea6cf5d206a794e074d9b53d0f8eda697dd7450cc06038dd16179784c2fcbe7a07b9acd0689cb20727a0e6787f36532283c07c56830d07b4c2fd3e72e6a794e074d9b53d0f8eda697dd7450cc06038dd16179784c2fcbe7

Anyway, there’s 1 thing missing here:
as per GSM 03.38

If the total number of characters to be sent equals (8n 1) where n=1,2,3 etc. then there are 7 spare bits at the end of the message. To avoid the situation where the receiving entity confuses 7 binary zero pad bits as the @ character, the carriage return or character (defined in clause 6.1.1) shall be used for padding in this situation, just as for Cell Broadcast.
If is intended to be the last character and the message (including the wanted ) ends on an octet boundary, then another must be added together with a padding bit 0. The receiving entity will perform the carriage return function twice, but this will not result in misoperation as the definition of in clause 6.1.1 is identical to the definition of .
The receiving entity shall remove the final character where the message ends on an octet boundary with as the last character.

So please fix this function and if the latest one is 0x00, replace it with 0X1A (Carriage Return) 😉

Written by adywicaksono

December 24, 2009 at 4:24 pm

Sending USSD Proactive Command on Javacard

with 4 comments

First at all, take a look at below Send USSD APDU Proactive Command:

|---[:] COMMAND DETAILS
|---[:] Command Number: 01
|---[:] Command Type: Send USSD
|---[:] Command Qualifier: RFU ==> value: 00
|---[:] DEVICE IDENTITIES
|---[:] Source Device: SIM Card
|---[:] Destination Device: Network
|---[:] ALPHA IDENTIFIER
|---[:] Sending your request
|---[:] USSD STRING: 0F AA 58 6C 36 02
|---[:] Card Status: 90 00
\---[:] Raw data: D027810301120082028183851453656E64696E6720796F757220726571756573748A060FAA586C36029000

This is example of APDU for Send USSD Proactive Command on javacard with USSD string *113#.
The code for sending is very simple:

ProHdlr.init((byte)PRO_CMD_SEND_USSD,(byte)0x00,(byte)DEV_ID_NETWORK);
ProHdlr.appendTLV(TAG_ALPHA_IDENTIFIER, USSD_TITLE_EN,(short)0x00,(short)USSD_TITLE_EN.length);
ProHdlr.appendTLV((byte)(TAG_USSD_STRING), USSDBuffer, (short)0x01, (short)f);
ProHdlr.send();

Where ProHdlr is ProactiveHandler, USSD_TITLE_EN is static byte for alpha identifier to be used
during sending the USSD request, USSDBuffer is buffer for USSD string, f is length of data of USSD string.

The most important thing here is that USSD string consist of:
1. Data Encoding Scheme (which most probably use 0x0F)
2. USSD string itself, which must be 7-bit encoded just like normal 7bit SMS.

E.g we have assigned below *113#

byte lenUSSDBuffer = (byte)0x01;
USSDBuffer[(byte)lenUSSDBuffer++] = (byte)0x0F; // Data encoding scheme
USSDBuffer[(byte)lenUSSDBuffer++] = (byte)'*';
USSDBuffer[(byte)lenUSSDBuffer++] = (byte)'1';
USSDBuffer[(byte)lenUSSDBuffer++] = (byte)'1';
USSDBuffer[(byte)lenUSSDBuffer++] = (byte)'3';
USSDBuffer[(byte)lenUSSDBuffer] = (byte)'#';

*113# will become 0xAA 0x58 0x6C 0x36 0x02 once we code it in 7-bit encoding rule (see TS 23.038).
0x0F is encoding scheme which follow standard encoding scheme for Cell Broadcast (see TS 23.038).
0x0F means GSM 7 bit default alphabet – language unspecified.

Good luck with your USSD !

Written by adywicaksono

December 6, 2009 at 11:52 am

Posted in SmartCard, Telco - GSM

Kebohongan Merajalela pasca Gempa

with 2 comments

Dikutip dari sebuah milis

Menambahkan tulisan mas Adie ini, saya justru kepikiran Allah sedang mulai melakukan skenario mencabuti ilmu2 Quran pelan2 dengan mewafatkan orang2 yang mukmin diantara kita….

Kebohongan yang merajalela setelah gempa
By Adie Jordan

Sun at 8:32pm
Beberapa saat setelah gempa Sumbar terjadi, banyak status di
Facebook yang mengkait-kaitkan gempa ini dengan ayat Alqur’an 17.16
yang berbunyi :

“Dan jika Kami hendak membinasakan suatu negeri, maka Kami
perintahkan kepada orang-orang yang hidup mewah di negeri itu (supaya
menta’ati Allah) tetapi mereka melakukan kedurhakaan dalam negeri itu,
maka sudah sepantasnya berlaku terhadapnya perkataan (ketentuan Kami),
kemudian Kami hancurkan negeri itu sehancur-hancurnya.”

Tentu saja ini membuat gerah sebahagian korban yang tertimpa
musibah ini, mereka merasa sebagai “korban yang dihakimi”.

Kenapa sampai ayat ini dijadikan vonis bahwa mereka adalah
orang-orang “berhidup mewah yang melakukan kedurhakaan kepada
Allah”.??

Hal ini sangat menggelitik bagi kami untuk mencari dari gempa yang
terjadi di Aceh 26 Desember 2004. Kenapa tidak dikaitkan dengan
satupun ayat Al-Qur’an? Berikut rekam kejadian gempa Aceh :

Gempa terjadi pada waktu 7:58:53 WIB. Pusat gempa terletak pada
bujur 3.316° N 95.854° EKoordinat: 3.316° N 95.854° E kurang lebih 160
km sebelah barat Aceh sedalam 10 kilometer. Gempa ini berkekuatan 9,3
menurut skala Richter dan dengan ini merupakan gempa bumi terdahsyat
dalam kurun waktu 40 tahun terakhir ini yang menghantam Asia Tenggarai
http://id.wikipedia.org/wiki/Gempa_bumi_Samudra_Hindia_2004

Lalu apa “Ramalan” Al Qur’an pada waktu kejadian tersebut..??

[7:58] Dan tanah yang baik, tanaman-tanamannya tumbuh subur dengan
seizin Allah; dan tanah yang tidak subur, tanaman-tanamannya hanya
tumbuh merana. Demikianlah Kami mengulangi tanda-tanda kebesaran
(Kami) bagi orang-orang yang bersyukur.

Sebenarnya yang menjadi masalah adalah dalam kaitan Ayat 17.16
yang dihubungkan, “Ahli-ahli tafsir” dadakan ini seolah olah
mengaitkan bahwa korban gempa di Padang sama dengan orang yang
dimaksud dalam Ayat 17.16 tersebut.

Apakah orang2 yang menghakimi tersebut pernah ke kota Padang atau
tinggal di kota Padang.?

Di Sumatera Barat secara umum dan Padang khususnya dalam 5 tahun
belakangan ini sangat bersungguh-sungguh untuk menjadi kota yang
bertaqwa kepada Allah (setidaknya itu dari pandangan saya selama
bekerja disana). Setiap pagi ada gerakan Subuh Mubarakah dan di setiap
Masjid lantunan Asma’ul Husna terdengar hampir setiap pagi.

Lihatlah para pelajar di kota padang, selalu menggunakan busana
muslim di setiap hari dan rata-rata mereka hapal dengan Asma’ul Husna.
http://www.padang.go.id/v2/content/view/1646/1/

Apakah ini negeri yang “Durhaka kepada Allah” itu.?

Kita seharusnya sepakat bahwa negeri itu sedang disayang Allah
karena mereka sedang mendekatkan diri kepada Nya sesuai dengan Firman
Allah

[2:214] Apakah kamu mengira bahwa kamu akan masuk syurga, padahal
belum datang kepadamu (cobaan) sebagaimana halnya orang-orang
terdahulu sebelum kamu? Mereka ditimpa oleh malapetaka dan
kesengsaraan, serta digoncangkan (dengan bermacam-macam cobaan)
sehingga berkatalah Rasul dan orang-orang yang beriman bersamanya:
“Bilakah datangnya pertolongan Allah?” Ingatlah, sesungguhnya
pertolongan Allah itu amat dekat.

Maka dari itu, agar teman2 dapat menyebarkan pesan ini kepada
teman lain di Facebok atau dimanapun. Marilah kita sama-sama
bertaubat, karena bisa jadi bukan mereka yang dihukum, tapi kita yang
sedang diberi kesempatan kedua.

[53:32] (Yaitu) orang-orang yang menjauhi dosa-dosa besar dan
perbuatan keji yang selain dari kesalahan-kesalahan kecil.
Sesungguhnya Tuhanmu maha luas ampunanNya. Dan Dia lebih mengetahui
(tentang keadaan)mu ketika Dia menjadikan kamu dari tanah dan ketika
kamu masih janin dalam perut ibumu; maka janganlah kamu mengatakan
dirimu suci. Dialah yang paling mengetahui tentang orang yang
bertakwa.

Wallahu’alam

Written by adywicaksono

October 7, 2009 at 1:19 pm

Posted in Uncategorized

Setup Call – APDU, Call Control by SIM, Call Connected Event

leave a comment »

From UICC, it send below APDU (e.g calling +6611555678111 – it’s fake number dude)

============================================================

|—[:] COMMAND DETAILS
|—[:] Command Number: 01
|—[:] Command Type: Set Up Call
|—[:] Command Qualifier: Set up call, but only if not currently busy on another call, with redial
|—[:] DEVICE IDENTITIES
|—[:] Source Device identity: UICC
|—[:] Destination Device identity: Network
|—[:] ALPHA IDENTIFIER
|—[:] Alpha identifier details Calling…
|—[:] ADDRESS
|—[:] Type-OF-Number: International number
|—[:] Numbering-Plan-Identification: ISDN/telephony numbering plan (‘The internationalpublic telecommunication numbering plan’ and E.163 recommandation)
|—[:] Dialling number: 66 15 55 67 81 11
|—[:] Card Status: 90 00
\—[:] Raw data: D01E010301100102028183050A43616C6C696E672E2E2E0607916651557618119000
============================================================

If you already register for Call Control by SIM, then below envelope data will be available to
your SIM java applet first

============================================================
[+] APDU Command: ENVELOPE – Call control
|—[:] DEVICE IDENTITIES
|—[:] Source Device identity: Terminal
|—[:] Destination Device identity: UICC
|—[:] ADDRESS
|—[:] Type-OF-Number: International number
|—[:] Numbering-Plan-Identification: ISDN/telephony numbering plan (‘The internationalpublic telecommunication numbering plan’ and E.163 recommandation)
|—[:] Dialling number: 66 15 55 67 81 11
|—[:] CAPABILITY CONFIGURATION PARAMETERS
|—[:] 06 60 04 02 00 05 81
|—[:] LOCATION INFORMATION
|—[:] Mobile Country & Network Codes(MCC & MNC): XX XX XX
|—[:] Location Area Code(LAC): 01 96
|—[:] Cell Identity Value(Cell ID): 13 A9
|—[:] Header: 80C2000021
\—[:] Data: D41F020282810607916651557618110707066004020005811307XXXXXX019613A9
============================================================

Sorry I remove MCC/MNC information 🙂

Once it’s allowed by SIM (by Call Control by SIM envelope command), then terminal/handset
will start calling

============================================================
[+] APDU Command: TERMINAL RESPONSE
|—[:] COMMAND DETAILS
|—[:] Command Number: 01
|—[:] Command Type: Set Up Call
|—[:] Command Qualifier: Set up call, but only if not currently busy on another call, with redial
|—[:] DEVICE IDENTITIES
|—[:] Source Device identity: Terminal
|—[:] Destination Device identity: UICC
|—[:] RESULT
|—[:] RESULT DETAILS : Command performed successfully
|—[:] Header: 801400000C
\—[:] Data: 010301100102028281030100
============================================================

Once connected and you register for Call Connected Event, below event will be available to your card applet
============================================================
[+] APDU Command: ENVELOPE – Event download
|—[:] EVENT LIST
|—[:] Event list detail: Call connected
|—[:] DEVICE IDENTITIES
|—[:] Source Device identity: Network
|—[:] Destination Device identity: UICC
|—[:] TRANSACTION IDENTIFIER
|—[:] List :
|—[:] Transaction Identifier 1
|—[:] TI Flag is true TI Value : 268435448
|—[:] Header: 80C200000C
\—[:] Data: D60A190101020283811C0180
============================================================

Once finished and call disconnected, below event will be available
============================================================
[+] APDU Command: ENVELOPE – Event download
|—[:] EVENT LIST
|—[:] Event list detail: Call disconnected
|—[:] DEVICE IDENTITIES
|—[:] Source Device identity: Terminal
|—[:] Destination Device identity: UICC
|—[:] TRANSACTION IDENTIFIER
|—[:] List :
|—[:] Transaction Identifier 1
|—[:] TI Flag is false TI Value : 0
|—[:] CAUSE E0 90
|—[:] Header: 80C2000010
\—[:] Data: D60E190102020282811C01001A02E090
============================================================

Written by adywicaksono

September 7, 2009 at 11:19 am

Posted in SmartCard, Telco - GSM

Provide Local Information – IMEI APDU

leave a comment »

From UICC to Handset:
——————————————————————————–
[+] APDU
|—[:] COMMAND DETAILS
|—[:] Command Number: 01
|—[:] Command Type: Provide Local Information
|—[:] Command Qualifier: IMEI of the terminal
|—[:] DEVICE IDENTITIES
|—[:] Source Device identity: UICC
|—[:] Destination Device identity: Terminal
|—[:] Card Status: 90 00
\—[:] Raw data: D0098103012601820281829000

Handset Response to UICC:
——————————————————————————–
[+] APDU Command
|—[:] COMMAND DETAILS
|—[:] Command Number: 01
|—[:] Command Type: Provide Local Information
|—[:] Command Qualifier: IMEI of the terminal
|—[:] DEVICE IDENTITIES
|—[:] Source Device identity: Terminal
|—[:] Destination Device identity: UICC
|—[:] RESULT
|—[:] RESULT DETAILS : Command performed successfully
|—[:] IMEI: 3A 45 02 03 03 18 38 00
|—[:] Header: 8014000016
\—[:] Data: 81030126010202828103010014083A4502030318xxxx

We get IMEI 3A 45 02 03 03 18 xx xx, sorry I override 2 latest byte

Written by adywicaksono

September 7, 2009 at 9:36 am

Posted in SmartCard, Telco - GSM