Bummer ... got my hands on 3.62 firmware and PD removed the section of code that dealt with enabling mass-storage mode. The new address is 0x8013e098, but the case 10 code is now noop. :(
BillW- 09-19-2005
Translation for those watching at the sidelines: It looks like they've removed the mass-storage code in the 03.62 firmware!
Nice find CVSfan... if I only had 03.62 cameras, I'd be redoubling my efforts to get at least one 3.40 camera at the same PCB version as my 03.62 cameras. At least that way you may be able to reflash in the mass storage functionality some day.
carpespasm- 09-19-2005
maybe they saw the mass storage as our next likely place to open the camcorders from and took it out to remove one more potential hole.
radarman- 09-19-2005
That, and it isn't required for normal operations. It could be they just streamlined the code to do just what it needed to do, and no more. (while simultaneously making life hard for us.)
However, since we have seen recycled cameras with board revisions of B1-B3 running 3.62 FW, it stands to reason you could reflash 3.40 on camcorders that came loaded with 3.62 - as I would suspect any "personalizers" would involve bumping the board rev.
Of course, only about three people on this board could do this magical FW swap, and it currently involves removing and replacing a TSOP chip, so I doubt PD is going to get very concerned about this.
Cosmic Gecko- 09-19-2005
Makes me wonder what's other goodies might be present in the 3.01 firmware version. My local CVS won't let me buy their demo model to find out. :-(
mattcam3- 09-19-2005
for the people that have a recyled 3.62, does the flash chip look like it was taken off then put back on? if not then they must have a way to reflash it thru the connecter. is there a simmilar method we could exploit? or does that require the camera be unlocked, which is really the whole prob.
Corscaria- 09-19-2005
mattcam3, it's already known there is code in the firmware to support flashing a new version of the firmware on.
What i know of the upgrade functions is they allow repartitioning, flashing individual partitions, and full reflash.
CVSfan- 09-19-2005
For those looking at fetching the 3.62 firmware, starts at 0x81ec6800, length 0x139800.
Here's initial output from objdump:
firmware_362.o: file format elf32-littlemips
architecture: mips:isa32, flags 0x00000002:
EXEC_P
start address 0x80000600
Sections:
Idx Name Size VMA LMA File off Algn Flags
0 .spc0 00000210 bfc08000 bfc08000 0013919c 2**2 CONTENTS, ALLOC, LOAD, CODE
1 .spc1 00000000 bfc09000 bfc09000 001393ac 2**0 CONTENTS
2 .spc2 00000000 bfc09400 bfc09400 001393ac 2**0 CONTENTS
3 .spc3 00000000 bfc09800 bfc09800 001393ac 2**0 CONTENTS
4 .spd0 00000000 90008000 90008000 001393ac 2**0 CONTENTS
5 .spd1 00000000 90009000 90009000 001393ac 2**0 CONTENTS
6 .spd2 00000000 90009400 90009400 001393ac 2**0 CONTENTS
7 .spd3 00000400 90009800 90009800 00138d9c 2**2 CONTENTS, ALLOC, LOAD, DATA
8 .exception 0000013c 80000180 80000180 000000d4 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE
9 .boot 00000040 80000600 80000600 00000220 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE
10 .text 0012e168 80000640 80000640 00000260 2**5 CONTENTS, ALLOC, LOAD, READONLY, CODE
11 __ex_table 00000010 8012e7a8 8012e7a8 0012e3c8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA
12 .scratch 0000011c 8012e7b8 8012e7b8 0012e3d8 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE
13 .scratchpad3 00000070 8012e8d4 8012e8d4 0012e4f4 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE
14 .data 0000a818 8012e948 8012e948 0012e568 2**3 CONTENTS, ALLOC, LOAD, DATA
15 .data1 00000018 80139160 80139160 00138d80 2**2 CONTENTS, ALLOC, LOAD, DATA
16 .sbss 000005c4 80139178 80139178 00138d98 2**2 ALLOC
17 .bss 0000c5d0 80139740 80139740 00138d9c 2**4 ALLOC
And, for comparison, here's the 3.40:
firmware_340.o: file format elf32-littlemips
architecture: mips:isa32, flags 0x00000002:
EXEC_P
start address 0x80000600
Sections:
Idx Name Size VMA LMA File off Algn Flags
0 .spc0 00000210 bfc08000 bfc08000 00138fec 2**2 CONTENTS, ALLOC, LOAD, CODE
1 .spc1 00000000 bfc09000 bfc09000 001391fc 2**0 CONTENTS
2 .spc2 00000000 bfc09400 bfc09400 001391fc 2**0 CONTENTS
3 .spc3 00000000 bfc09800 bfc09800 001391fc 2**0 CONTENTS
4 .spd0 00000000 90008000 90008000 001391fc 2**0 CONTENTS
5 .spd1 00000000 90009000 90009000 001391fc 2**0 CONTENTS
6 .spd2 00000000 90009400 90009400 001391fc 2**0 CONTENTS
7 .spd3 00000400 90009800 90009800 00138bec 2**2 CONTENTS, ALLOC, LOAD, DATA
8 .exception 0000013c 80000180 80000180 000000d4 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE
9 .boot 00000040 80000600 80000600 00000220 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE
10 .text 0012dfc0 80000640 80000640 00000260 2**5 CONTENTS, ALLOC, LOAD, READONLY, CODE
11 __ex_table 00000010 8012e600 8012e600 0012e220 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA
12 .scratch 0000011c 8012e610 8012e610 0012e230 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE
13 .scratchpad3 00000070 8012e72c 8012e72c 0012e34c 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE
14 .data 0000a808 8012e7a0 8012e7a0 0012e3c0 2**3 CONTENTS, ALLOC, LOAD, DATA
15 .data1 00000018 80138fa8 80138fa8 00138bc8 2**2 CONTENTS, ALLOC, LOAD, DATA
16 .sbss 000005c4 80138fc0 80138fc0 00138be0 2**2 ALLOC
17 .bss 0000c5d0 80139590 80139590 00138bec 2**4 ALLOC
Two sections changed size, .text and .data. Good news is that .bss appears to have stayed intact (other than for it's new starting address). Hopefully all objects (including USP.BIN) are still in the same order so it's a matter of adjusting their offset compared to 3.40 (.bss offset between 3.40 and 3.62 = 0x1b0). If only we'd be so lucky!!!!
carpespasm- 09-19-2005
for the people that have a recyled 3.62, does the flash chip look like it was taken off then put back on? if not then they must have a way to reflash it thru the connecter. is there a simmilar method we could exploit? or does that require the camera be unlocked, which is really the whole prob.
they can update the firmware through usb, but the thing is, they can get in the camcorders with the real response keys, no such niceness for us yet.
star882- 09-19-2005
Couldn't you also connect a logic probe to the original WR line to see if it's trying to write?
Unfortunately not that I know of. The WP\ (Write Protect) pin is usually kept HIGH (writable) always during normal operation; the idea behind that pin is it will be low right when the device is first turned on, to keep random glitches on the power/data/etc. lines, which could possibly match a data-write or erase operation, from damaging anything while the power is still coming up and the CPU is still booting.
The WR\ line on this type of chip isn't helpful either, as it indicates writing a command to the chip (not necessarily a data write); this will also show activity even when 'writing' a Read command. :(
So you're saying that the WR\ line is also used to write addresses to some of the address registers?
In that case, find out what address is on the main address lines while mapped address registers are being written to. Then make some logic that senses for a write at an address other than the register addresses.
Or maybe put a Jessica Simpson microcontroller between the board and Flash to do a "man in the middle" attack. I'm not sure how fast the memory accesses are, though. A FPGA may be necessary to handle the speeds involved. Even that may introduce enough delay to mess it up.
Or what about find a way to use a CF card instead of the original Flash so if you mess it up, you can just put it into the reader and write a good image.
radarman- 09-19-2005
Actually, I had something slightly less invasive than a "man in the middle" attack planned.
I plan on sniffing the data from the flash. Remember, FLASH memories are block devices. This is why you can't just use the WE line. You write to the memory the address you want (or control operation you want), and the host controller on the flash will either buffer up your writes, or start sending out your reads. The flash memory on these parts is 512 bytes per block.
It is fairly easy to follow reads from the flash, because the host controller must strobe the RE line for each byte recieved. Thus, the RE line can be used to "clock" the data into a third party receiver.
So, I plan on designing an FPGA which will count the number of write enables, then trigger a FIFO to start capturing the USP.BIN as it is being read out of the flash. This will require some experimentation to know where to set the trigger, but is perfectly safe.
I already have the basic blocks for the project sketched out - UART, control logic, FIFO, etc. I even have my FPGA board - I just don't have a Byteblaster cable yet! (it's pretty simple, so I can probably build it at home with veroboard)
With this, I can simply extract the C/R pair from the datastream, then go in later and change it to something more amenable to automated tools, like all zeros. (or at least identical data)
Corscaria- 09-20-2005
instead of counting the cycles, couldn't you sniff for the magic of the USP.BIN. and start your recording when that triggers it? Throw in upto 9 bytes following the magic for increased likely hood of finding an accurate match. It'd be much more accuracte than counting cycles, and would survive future firmware changes more robustly.
not sure how complex this would be to implement in FPGA, never worked with them, but seems to me using the magic and upto 9 bytes following might be just as easy, to implement. And definately more adaptable.
radarman- 09-20-2005
Damn, great minds must think alike. I was thinking about entering the serial number through the serial port, then having it scan incoming frames for it - keeping the first frame that it found it in.
Interestingy enough, you don't need a processor to use a serial port. A state machine can do the job quite nicely. :)
brite_eye- 04-25-2007
Got dismipper to run under cygwin, two files needed patching to work around some stack corruption and other memory issues (diff with original to see changes): pass_one.c and sections.c. Hopefully the output is accurate ...
To compile under cygwin (as pure-analog discovered, needs no-cygwin):
$ gcc -mno-cygwin -o dismipper *.c
And for reference:
- Get camcorder firmware by using Ops' Download Memory button:
Start Location=200043008 and Length=1283583; save as firmware.o
- Using objdump built to understand MIPS, generate firmware.hd:
$ objdump-mips -w -f -h -D -M reg-names=r3000 firmware.o > firmware.hdVER 2.16.1). Extract and configure (./configure --target=mips), type make and then find the binary in binutils/objdump.exe ... rename to objdump-mips>
- Generate the re-disassembly:
$ dismipper > firmware.lst
The links to CVSfan's pass_one and sections no longer work. Would someone please repost those changes.
Amyn- 04-25-2007
Why don't you do it... :roll:
Forumer™ is Voted #1 Free Forum Hosting provider
Build your own community today with the largest message board hosting company.