view rvinterf/doc/tfc139.usage @ 965:2969032bdfac

fcup-smsend[mult]: fix buglet in K&R C NULL pointer passing The only 100% safe way to pass a NULL pointer as a function argument in K&R C is to cast 0 to a pointer type; failing to do so may cause mysterious bugs (invalid stack frames or garbage in argument registers) on 64-bit machines. This issue has already been fixed in most of FC host tools, but I just found some missed spots: passing of NULL UDH to PDU encoding functions in fcup-smsend[mult] in the case of single (not concatenated) SMS.
author Mychaela Falconia <falcon@freecalypso.org>
date Fri, 01 Sep 2023 07:33:51 +0000
parents e7502631a0f9
children
line wrap: on
line source

The tfc139 hack-utility (see ../../doc/Compal-unlock) is based on the
rvinterf/rvtdump skeleton, and it needs to be invoked as follows:

tfc139 [options] /dev/ttyXXX

In the well-tested use case of breaking into TFC139 phones with fw version
8.8.17, no options are normally needed, but the following options are supported:

-a address

	This option changes the RAM address into which the "shellcode" is to be
	written; the argument is always interpreted as hex.  The default is
	0x800000, as used by the mot931c.exe closed source tool on whose
	reverse-engineering our hack-utility is based.

-B baud

	This option changes the serial baud rate just like in rvinterf and
	rvtdump, but the default is 57600 as needed for breaking into TFC139
	firmware.

-l logfile

	Log activity in a file, just like rvinterf and rvtdump.

-s address

	Just like mot931c.exe has been observed to do, we start our stack
	smashing attempts at a certain address, and keep incrementing by 4
	until we either succeed or crash the fw in some other way that does not
	help us.  This option changes the starting address for these stack
	smashing attempts; the argument is always interpreted as hex.  The
	default is 0x837C54, as observed from the reverse engineering of
	mot931c.

-w number_in_seconds

	See rvinterf.usage; the option is the same for tfc139 as for rvinterf.