[LEDE-DEV] [RFC] dwr-512: Image Cracking

Giuseppe Lippolis giu.lippolis at gmail.com
Tue Oct 18 11:22:48 PDT 2016


Dear All,
I'm working to port the Dlink DWR-512 in openwrt.
Currently I'm able to complete the boot and control properly a big part of
the system.
Nevertheless there is an issue with the oem bootloader.
The oem bootloader need to get the firmware in a propietary format.
If the format is not recognized by the bootloader, it prevent to boot.
Here the example:

Jboot B394
JRecovery Version R1.2 2011/05/26 09:53
=== 0xB0100004 = 00000000 
SPI FLASH: MX25l6405d 8M
CSID 6E20->6E24
...Rootfs CRC Error! BCD84A9E 992C3587
IP=192.168.123.254 NA=78:54:2E:A0:78:6D
#

Dlink provides the tool (called "binboy") to generate this format and this
is the procedure I'm currently using.
According to the LEDE philosophy no binary tool, only source code, are
allowed.
Is this true in generale or some exception are allowed?

In case we cannot introduce binary tool we need encode an emulator of the
binboy.
I start to analyze the tool but without complete success.
Therefore I want to present you the test perfomed and my result in order to
get some help.

The binboy tool compose the final firmware in three steps:
1) generation of the kernel image
2) generation of the rootfs image
3) generation of the firmware image

The last step should be a simple concatenation, on the first two add an
header to the image.
I'm currently focused on the first step.
To test the first step I generated a fake kernel image:
00000000: 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00  ................
00000010: 00                                               .

and I passed it to the tool.
After some analysis I noticed that the header is in some way hased with the
current host time.
This is the reason why I present you the memory dump result and the current
host time.

Do 25. Dez 12:00:00 CET 2014
00000000: 44 4c 4b 36 81 00 6b 80 f0 ff de 6f e0 bb 79 b6  DLK6..k....o..y.
00000010: 4c fb e8 86 25 3f 24 ae a0 f4 51 f9 69 07 ee e2  L...%?$...Q.i...
00000020: 21 20 0a c4 ce 1b 28 f5 6e 18 94 88 e8 e6 cc 9f  ! ....(.n.......
00000030: ed f9 2b 9f c0 c4 3a f4 c7 ff 68 ca 53 36 20 b9  ..+...:...h.S6 .
00000040: 0e 07 e3 b4 87 61 cb d0 82 ad 8e ab 4d f4 b0 98  .....a......M...
00000050: ff 04 24 2b cc 9f e6 07 39 00 00 00 ae d4 3d 54  ..$+....9.....=T
00000060: 24 21 03 02 00 00 00 80 11 00 00 00 7d 2e 61 08  $!..........}.a.
00000070: 00 00 00 80 00 00 15 bf 00 10 00 00 e9 93 98 90  ................
00000080: 4b 4f 8a 38 28 00 00 00 00 00 00 00 00 00 01 00  KO.8(...........
00000090: 00 00 00 00 00 00 00 00 00                       .........
Do 25. Dez 12:17:04 CET 2014
00000000: 44 4c 4b 36 81 00 6b 7f 76 73 b4 73 45 4f b2 8d  DLK6..k.vs.sEO..
00000010: f7 87 f3 f0 c1 e3 f2 c7 c2 2f 83 fa b0 a4 7e d8  ........./....~.
00000020: b1 06 e6 e2 e6 65 fc 98 f8 bb b2 95 d4 9f 2f 99  .....e......../.
00000030: b5 fa 65 b4 59 47 5f f9 9f e7 18 b9 d7 52 ba b9  ..e.YG_......R..
00000040: 40 1d a4 c7 b8 0a 73 9b fa 13 6b b9 ec 53 1e fd  @.....s...k..S..
00000050: ff 04 24 2b cc a0 e6 07 39 00 00 00 ae d4 3d 53  ..$+....9.....=S
00000060: 24 21 03 02 00 00 00 80 11 00 00 00 7d 2e 61 08  $!..........}.a.
00000070: 00 00 00 80 00 00 15 bf 00 10 00 00 e9 93 98 90  ................
00000080: 4b 4f 8a 38 28 00 00 00 00 00 00 00 00 00 01 00  KO.8(...........
00000090: 00 00 00 00 00 00 00 00 00                       .........
So 28. Dez 12:49:00 CET 2014
00000000: 44 4c 4b 36 81 00 6b 80 f0 ff de 6f e0 bb 79 b6  DLK6..k....o..y.
00000010: 4c fb e8 86 25 3f 24 ae a0 f4 51 f9 6e 07 ef e2  L...%?$...Q.n...
00000020: 26 20 0b c4 c9 1b 29 f5 69 18 95 88 ef e6 cd 9f  & ....).i.......
00000030: ea f9 2a 9f c7 c4 3b f4 c0 ff 69 ca 54 36 21 b9  ..*...;...i.T6!.
00000040: 09 07 e2 b4 80 61 ca d0 85 ad 8f ab 4a f4 b1 98  .....a......J...
00000050: ff 04 24 2b cb 9f e7 07 39 00 00 00 ae d4 3d 54  ..$+....9.....=T
00000060: 24 21 03 02 00 00 00 80 11 00 00 00 7d 2e 61 08  $!..........}.a.
00000070: 00 00 00 80 00 00 15 bf 00 10 00 00 e9 93 98 90  ................
00000080: 4b 4f 8a 38 28 00 00 00 00 00 00 00 00 00 01 00  KO.8(...........
00000090: 00 00 00 00 00 00 00 00 00                       .........
Do 9. Feb 05:04:00 CET 2017
00000000: 44 4c 4b 36 81 00 6b 80 f0 ff de 6f e0 bb 79 b6  DLK6..k....o..y.
00000010: 4c fb e8 86 25 3f 24 ae a0 f4 51 f9 69 06 ee ed  L...%?$...Q.i...
00000020: 21 21 0a cb ce 1a 28 fa 6e 19 94 87 e8 e7 cc 90  !!....(.n.......
00000030: ed f8 2b 90 c0 c5 3a fb c7 fe 68 c5 53 37 20 b6  ..+...:...h.S7 .
00000040: 0e 06 e3 bb 87 60 cb df 82 ac 8e a4 4d f5 b0 97  .....`......M...
00000050: ff 04 24 2b cc 9e e6 08 39 00 00 00 ae d4 3d 54  ..$+....9.....=T
00000060: 24 21 03 02 00 00 00 80 11 00 00 00 7d 2e 61 08  $!..........}.a.
00000070: 00 00 00 80 00 00 15 bf 00 10 00 00 e9 93 98 90  ................
00000080: 4b 4f 8a 38 28 00 00 00 00 00 00 00 00 00 01 00  KO.8(...........
00000090: 00 00 00 00 00 00 00 00 00                       .........

Here the Fact I realized by analysis:

1) The first 6 8-bit are fixed : 44 4c 4b 36 81 00
2) Starting from the location 0x58 the data formatted in a fixed way.
3) Starting from the location 0x88 the fake kernel image is copied.
3) The only way to get the same result over different runs is to apply the
same host time.
4) At location 0x07 there is a 16-bit data and its value is incremented
every time the host time increments of 4 second.
5) If the data described at point 4 is the same, the data from 0x00 to 0x1b
are the same.
6) Using a delta time of 262144 seconds between runs starting from the
location 0x1c the following delta pattern is found on the data: +5 0 +1 0
7) Using a delta time of xxxx seconds between runs starting from the
location 0x1c the following delta pattern is found on the data: -1 0 +b 0 -1
0 +7 0 +5 0 -1 0 -1 0 +1 0 .....

Then I removed one byte from the fake kernel image and this is the result:

Do 25. Dez 12:00:00 CET 2014
00000000: 44 4c 4b 36 81 00 36 7d 05 7e c7 14 41 a4 fa a9  DLK6..6}.~..A...
00000010: e1 b7 6c da 34 bd 30 80 c3 ce dc d4 5f c4 38 94  ..l.4.0....._.8.
00000020: c9 74 ed f7 9c ec 8a a3 44 ed 33 c6 1c 7c 0d 94  .t......D.3..|..
00000030: 5c 84 da 93 28 33 06 b4 73 40 be 82 d9 2a d9 ed  \...(3..s at ...*..
00000040: 1c 3a ce a5 1d 0b 1d cb 9a 29 d1 88 df cc 22 c6  .:.......)....".
00000050: ff 04 24 2b cc 9f e6 07 38 00 00 00 e4 d7 08 51  ..$+....8......Q
00000060: 24 21 03 02 00 00 00 80 10 00 00 00 6b 20 79 03  $!..........k y.
00000070: 00 00 00 80 00 00 15 bf 00 10 00 00 e9 93 98 90  ................
00000080: 12 4d f5 4f 28 00 00 00 00 00 00 00 00 00 01 00  .M.O(...........
00000090: 00 00 00 00 00 00 00 00                          ........

8) It seems that at location 0x68 is stored the firmware size.

Thanks to the tips from Mathias, running the strings command on the binboy
binary I get some additional info:
h  <topic...>	: show help about <topic>; try "h topic"
r  <file>	: read working data from <file>
w  <file>	: write working data to <file>
  wb <file>	: write current block to <file>
j  <file>	: join/append <file> to working data
bb		: backward to the beginning of working data
f		: forward to next block
  fa		: forward to block with any known type
  fs		: forward to block with same type
v		: view block in working data
  vh		: view block in working data (in hex)
e  <off> <val>: edit a byte of working data
c		: cast current and next block as an untyped one
  c  <size>	: cast current block as untyped block of <size> bytes
  c  <block>	: cast current block as type <block>
i  <block>	: insert a block of <block> type
-<opt> <val>	: set option or modify block
p "message"	: print one line message
/<func> ...: invoke transformation functions to change working data
  /derange <s>	: derange the working data (random seed <s>)
  /arrange <s>	: arrange the working data (random seed <s>)
  /addinfo <s>	: add embedded script info (random seed <s>)
> Unknown command: '%c'.
> Syntax error: %s
> No working data.
> EOF.
> %s (%s).
ERROR: fail to open %s
ERROR: fail to read info block
eBMS:
ERROR: invalid eBMS signature
ERROR: memory not enough
bend
##########################################
# ERROR binman <sch2>: KERNEL not found  #
############################################
# WARNING binman <sch2>: ROOTFS not found  #
flat
gzip
lzma
%s -- %s
	cp_type			(cp) 0x%02X (%s)
	version			(--) 0x%02X
	ram_addr		(ma) 0x%08lX
	image_len*		(--) 0x%08lX (%ld)
	image_crc32*		(--) 0x%08lX
	start_addr		(sa) 0x%08lX
	rootfs_addr		(ra) 0x%08lX
	rootfs_len*		(--) 0x%08lX (%ld)
	rootfs_crc32*		(--) 0x%08lX
	header_len*		(--) 0x%04X (%d)
	magic			(--) 0x%04X
	cmd_line_len*		(--) 0x%04X (%d)
	kernel_cmd_line*	(cl)
[%s]
  +	big_endian*		(bend) %d
sch2
RDS/00071: Start Code Header 2.0
bend
%s -- %s
	cmark			(--) 0x%02X
	section_id		(id) 0x%02X (%c)
	magic			(--) %04X
	time_stamp*		(ts) 0x%08lX (%s)
	image_length*		(--) 0x%08lX (%ld)
	image_checksum*		(--) 0x%04X
	tag_checksum*		(--) 0x%04X
  +	big_endian*		(bend) %d
-BPRADECF
stag
RDS/00014: Oasis Section Tag (Type 4 Image Info)
%02X-
%s -- %s
	rom_id			(r ) "%s"
	image_checksum*		(--) 0x%04X
	model_number		(mn) "%s"
	time_stamp*		(ts) 0x%08lX (%s)
	erase_start		(es) 0x%08lX
	erase_length		(el) 0x%08lX
	data_offset		(do) 0x%08lX
	data_length*		(--) 0x%08lX (%ld)
	cc_type_and_op_code	(ct) 0x%02X
	cc_operand		(co) 0x%02X
	cc_action		(ca) 0x%02X
	cc_value_in_hdr		(cv) {%s}
	header_id		(--) 0x%04X
	header_version		(--) ver %d.%d
	header_length		(--) 0x%04X (%d)
	image_type		(at) 0x%02X (%c)
	image_info_type		(it) 0x%02X
	image_info_offset	(io) 0x%08lX
	product_series		(ps) 0x%04X
	header_checksum*	(--) 0x%04X
-BPRADEC
auh11
RDS/00011: ARM Upgrade Header Version 1.1
dalg
dopt
bend
fgpl
Fail to arrange
Fail to arrange (GPL)
%s -- %s
	rom_id			(r ) "%s"
	image_checksum*		(--) 0x%04X
	lpvs			(lp) 0x%02X
	mbz			(--) 0x%02X
	time_stamp*		(ts) 0x%08lX (%s)
	erase_start		(es) 0x%08lX
	erase_length		(el) 0x%08lX
	data_offset		(do) 0x%08lX
	data_length*		(--) 0x%08lX (%ld)
	header_id		(--) 0x%04X
	header_version		(--) ver %d.%d
	section_id		(si) 0x%02X (%c)
	image_info_type		(it) 0x%02X
	image_info_offset	(io) 0x%08lX
	family_member		(fm) 0x%04X
	header_checksum*	(--) 0x%04X
  +	big_endian*		(bend) %d
  +	for_gpl*		(fgpl) %d
  +	derange_alg*		(dalg) %02X
  +	derange_opt*		(dopt) %02X
-BPRADECF
auh20
RDS/00012: ARM Upgrade Header Version 2.0
%s -- %s
	romid			(r ) "%s"
	opcode			(x ) 0x%02X
	opnd1_id		(t ) 0x%02X
	opnd2_val		(v ) {%02X-%02X-%02X-%02X}
	magic			(m ) 0x%02X
	id_len			(l ) 0x%02X (%d)
	image_type		(i ) 0x%02X
	erase			(e ) 0x%04X
	offset			(o ) 0x%08lX
	len*			(--) 0x%08lX (%ld)
	section			(s ) 0x%02X
	flag			(f ) 0x%02X
	chksum*			(--) 0x%04X
  +	deranged*		(# ) %d
RDS/00010: X86 Upgrade Header Version 3G
type
%s -- %s
	rom_id			(r ) "%s"
	a_image_chksum*		(--) 0x%04X
	x_skip_length*		(--) 0x%08lX (%ld)
	x_section		(--) 0x%02X
	x_flag			(--) 0x%02X
	x_header_chksum*	(--) 0x%04X
	a_skip_length*		(--) 0x%08lX (%ld)
	a_header_id		(--) 0x%04X
	a_major_version		(v0) %d
	a_minor_version		(v1) %d
	a_header_length		(--) 0x%04X (%d)
	a_family_member		(fm) 0x%04X
	a_header_checksum*	(--) 0x%04X
	a_checksum_patch*	(--) 0x%04X
  +	type			(type) %d (FUH-%c)
RDS/00044: Fusion Upgrade Header for X3G & AUH20/AUH11


Did someone see or is someone able to decode this format?
In the meantime I start to think how to port uboot on this device.

I'm looking forward to hearing from you.

Bye,
Giuseppe.





More information about the Lede-dev mailing list