polprog 01-09-2022
MC7004 is a portable ruggedized data terminal made by Symbol (aka Motorola) around January 2008. It runs Windows Mobile on a 624MHz XScale CPU. These devices are used in the industry as portable data entry terminals. It featues a lightweight an ergonomic design suitable for use in industrial settings.
The MC70 series is very well suited for this task having many connectivity options such as cellular and WiFi. The unit has a 1D optomechanical barcode scanner which acts as a keyboard after installing Symbol Datawedge application. It then can be activated using either of the side buttons.
The unit is fairly poor when it comes to external IO, it has a docking connector on the bottom, headphone jack (back, left hand side) and an SD card slot for storage (right hand side, under two screws).
The MC7090 has a SIM port on the PCB but lacks a way to install a card (The MC7004 has a SIM card slot in the latching door under the battery). There is a debug connector near the battery slot. On the MC7004 the card door does not slide to open, unlike most of these kind. You have to lightly pry it so that it clicks open with a fingernail or a small screwdriver.
The dock connector most carries ethernet and USB (device), as these are the ports on the dock.
The dock allows to simultaneously charge one extra battery and the MC70 itself. It has an ethernet jack, 12V in and USB device ports.
If some of the keyboard keys are not working, check CN8 flat flex (the closest one to the bottom) on it's both ends. If it's loose, then some of the keys will not function
Zebra offers a no-login download for a so called Clean Boot and Blank pacckage for the entire MC70 (and other) series. This package is a ZIP file that you extract to the SD card. When the terminal boots with the SD card in, it will perform a factory wipe. This is a useful approach if you have a terminal that came from a recycling facility and has some locked vendor application installed. If you do not care about saving it, just blow the clean boot and blank package to an SD card and factory wipe it.
However if you would like to preserve the application for some reason, read on...
The terminal is held together by 7 screws. 6 on the edge and one under the battery, under the sticker on the bottom of the compartment. Be careful when lifting the back part of the shell as there is a wire going to the speaker and the headphone jack. To lift the PCB you need to disconnect all 3 flat flex cables on the side and release the dock connector flat flex on the bottom.
Here's some annotated photos
The metal shield hides a detachable WiFi card attached by 4 screws and provides mechanical support for the barcode scanner module. It also holds down the mainboard to the magnesium frame of the device with 4 screws.
If your unit came with a battery that is not holding charge anymore, you can jump run it from a laboratory power supply. The battery connector on the main board is 6 pogo pins.
Looking at the back of the unit, upright, the two left ones are +, the to middle ones are battery sense/data and the two right ones are -. Apply 3.8V from a power supply to the + and - pins and the unit should boot up to a battery door error.
This computer will refuse to boot with the battery door open, which is problematic when running it from a lab power supply when you have no battery. The original battery door has a magnet which is sensed by a Hall effect switch on the main board. For a temporary solution, you can put a manget to the left side of the battery compartment. Alternatively you can short the hall effect sensor by soldering a piece of wire between the top right and the left pins (see diagram below)
<- board edge
.---. SW7
| |]*
*[| |
| |]
'---'
Connect the two marked pins of SW7 with a short piece of small wire to make it permanently closed and make the terminal think the battery door is in.
Hold down left trigger (yellow) key while booting. Can be used to re-flash the OS from SD card (presumably deeper than Clean Boot and Blank)
Motorola seems to have encouraged development of applications for the MC70 series as apps which rely on the builtin internet explorer heavily. In my opinion it's a technology stack like any other. However these terminals, especially when coming from recyclers, often are not wiped and have a vendor application installed. That application quite often is locked down to prevent the original user from messing up the terminal.
If you can get to a screen which looks like a webpage, it is likely
that this will be Internet Explorer in full screen mode. Long press on
the screen to bring up the context menu and exit full screen. Now you
can type in any URL in the address bar, including local URLs. Type in
C:\ to bring up the root directory listing. Here is the best part -
IE on Windows Mobile, for some reason unknown to me, has file
management functions. You can navigate to the Autostart folder and
just delete the shortcuts (context menu). Now when you reboot the
terminal it should start to the Win Mobile desktop! Amazing...
At the end of July 2022 I reverse engineered the Clean Boot and Blank package for these terminals. I was hoping to be able to modify some of the files to just delete autostart entries and not wipe the memory in case the IE trick does not work.
The Clean Boot and Blank package is a ZIP from the manufacturer that you unzip onto the SD Card, and boot the terminal with the card in it. This is the way to perform a factory wipe on these terminals. You can read more in the "Clean boot and blank" section above. I was curious how it works.
I have looked at the CBnB package for MC70 and MC75 series. They consist of several files, some of which I don't know how they work.
The MC75 Clean Boot and Blank packge contains
MC75_cleanbootblank$ LC_ALL=C ls -l
-rw-r--r-- 1 poplar poplar 262195 Aug 26 2008 CleanAppl.bin
-rw-r--r-- 1 poplar poplar 47 Apr 18 2008 Cleanps.bin
-rw-r--r-- 1 poplar poplar 411 May 12 2009 INSTRUCTIONS.TXT
-rw-r--r-- 1 poplar poplar 26 Apr 1 2010 Pkgs.lst
-rw-r--r-- 1 poplar poplar 4840 Jan 6 2010 StartUpdLdr.exe
(The Clean Boot package contains the same files except CleanAppl.bin)
MC75_cleanbootblank$ file *
CleanAppl.bin: Windows Embedded CE binary image
Cleanps.bin: Windows Embedded CE binary image
INSTRUCTIONS.TXT: ASCII text, with CRLF line terminators
Pkgs.lst: ASCII text, with CRLF line terminators
StartUpdLdr.exe: PE32 executable (Windows CE) ARM Thumb, for MS Windows
MC70 Clean Boot and Blank contains similar set of files with the
exception that CleanAppl.bin is called Application.udl.bin.
$ binwalk Application.udl.bin
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 Windows CE image header, image start: 0x82800000, image length: 25165824
For some strange reason (maybe compatiability reasons?) the
Application.udl.bin file contains several MS-DOS boot sectors. And I
mean it - i wrote a tool that extracts them to separate files
$ tail -c 25164416 Application.udl.bin > application_0xa1b.bin
$ file application_0xa1b.bin
application_0xa1b.bin: DOS/MBR boot sector
$ head -c 512 application_0xa1b.bin | xxd
00000000: eb00 fa33 c08e d0bc 007c fbfc b860 008e ...3.....|...`..
[ ... ]
00000090: 813d 55aa 75c4 8bf5 ea00 7c00 000d 0a4e .=U.u.....|....N
000000a0: 6f20 626f 6f74 6162 6c65 2070 6172 7469 o bootable parti
000000b0: 7469 6f6e 7321 0049 6e76 616c 6964 2070 tions!.Invalid p
000000c0: 6172 7469 7469 6f6e 2074 6162 6c65 0045 artition table.E
000000d0: 7272 6f72 206c 6f61 6469 6e67 2052 4f4d rror loading ROM
000000e0: 2d44 4f53 004d 6973 7369 6e67 2052 4f4d -DOS.Missing ROM
000000f0: 2d44 4f53 0000 0000 0000 0000 0000 0000 -DOS............
[ ... ]
000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa ..............U.
Remember - this is an ARM device, and for some reason the factory reset image contains x86 code from MS-DOS. I've further analyzed the next two bootblocks.
The second bootblock has a different signature:
$ tail -c 25163904 Application.udl.bin > application_0xc1b.bin
$ file application_0xc1b.bin application_0xc1b.bin: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "DLDOS6.0", sectors/cluster 4, root entries 256, sectors 45119 (volumes <=32 MB), Media descriptor 0xf8, sectors/FAT 45, sectors/track 16, heads 4, hidden sectors 1, serial number 0xf9a8f498, label: " ", FAT (16 bit)
$ head -c 512 application_0xc1b.bin | xxd
00000000: eb3c 9044 4c44 4f53 362e 3000 0204 0100 .<.DLDOS6.0.....
[ ... ]
000001a0: 02cd 13c3 4e6f 2053 7973 7465 6d20 6f6e ....No System on
000001b0: 2044 6973 6b0d 0a50 7265 7373 2045 7363 Disk..Press Esc
000001c0: 2074 6f20 5265 626f 6f74 0044 6973 6b20 to Reboot.Disk
000001d0: 426f 6f74 2046 6169 6c75 7265 0000 0000 Boot Failure....
000001e0: 0000 7000 0000 000c 0000 0000 0000 0000 ..p.............
000001f0: 5049 424d 4249 4f20 2043 4f4d 0000 55aa PIBMBIO COM..U.
The third bootblock starts at 0xe21b and has an MSDOS5.0
signature.
Rest of the file is mostly empty.
If you know why a factory reset file for an ARM device has three different x86 DOS boot blocks in it, please let me know.
Let's take a look at the StartUpdLdr.exe. If I were to guess, the
terminal looks for this file in the root of the SD card and will
execute it.
It's contents are ARM Thumb code for MS Windows, as file(1) told us.
The code did not change much between MC70 and MC75. The only
differences are the compilation date and the registers used to pass
arguments to core.dll syscalls. Note that the MC75's compilation date
is nonsense (Fri Nov 14 05:07:53 1986) (lol)
After the first syscall, the MC70 and MC75 program code is identical byte-to-byte.
It calls several functions from CORE.DLL and AYGSHELL (GUI library).
syscall_coredll_545(r0 = pc+0x88)
syscall_coredll_557(r0 = pc+0x7c, $1, $0, $0)
syscall_coredll_545(r0 = pc+0x50)
syscall_aygshell_2011(r1=0, r0=2)
if(r0 == 0){
syscall_core_545(r0 = pc+0x30)
//This only sets two parameters, r4 = ?
syscall_core_557(r0 = pc+0x24, r4, r4)
}
Decompiling it with IDA reveals the function names
It looks like the program just reboots and calls some OEM function.
I haven't set up Win Mobile SDK but I believe that it's possible to replace this .exe with your own under the same name. I am not sure about the bin files, but I have a feeling that they are only loaded when the original exe file calls the OEM kernel functions.
It's likely that if you wrote an .exe that cleans up the autorun
directory on C:, and place it under the name of StarUpdLdr.exe on
the SD card, then the terminal would run it on boot.
I call this the alternative clean boot package and perhaps I will make it some day.