PhatHack
The Hacking Hoedown => PhatBox Hacking => Topic started by: spin on June 05, 2005, 07:29:07 am
-
Bling bling fellas. Finally popped this sucka. Absolutely drooling-on-itself stupid too. After ~25 attempts of hacking phatbox.ini, walking ~800 feet to the car, testing it, walking 800 feet back, and checking the logfile, the solution was dead simple: Just use plsign. Seriously. Replace a player with a shell script, execute plsign on it, add a menu item that executes a file handled by that player. Now that the cat is out of the bag, lets hope PhatNoise doesnt be mean and restrict the keys used to sign the players. If they do that, we will have to actually replace the pubkeys in the disk image...
For example:
PID Uid Stat Command
1 0 S init
2 0 S [keventd]
3 0 S [ksoftirqd_CPU0]
4 0 S [kswapd]
5 0 S [bdflush]
6 0 S [kupdated]
7 0 S /bin/sh /etc/init.d/rcS
9 0 S /bin/sh /etc/init.d/rcS
12 0 S /dos/phatd
13 0 S /dos/51d
85 0 S /bin/sh /dos/oggplay-ha /dos/tts/it_about.ogg 0
86 0 S /bin/sh /dos/hack.sh
90 0 R ps aux -wwwwwwwwwwwwwww
XXX: DISK
Filesystem Size Used Available Use% Mounted on
/dev/root 363.0k 342.0k 1.0k 100% /
/dev/hda1 259.5M 8.8M 250.7M 3% /dos
/dev/hda5 37.0G 1.5M 37.0G 0% /dos/Data
/dev/root on / type ext2 (rw)
proc on /proc type proc (rw)
/dev/hda1 on /dos type vfat (rw)
/dev/hda5 on /dos/Data type vfat (rw)
XXX: INFO
Processor : ARM ARM720T rev 2 (v4l)
BogoMIPS : 36.76
Features : swp half thumb 26bit
Hardware : CL-7312 (Phatnoise v1.1)
Revision : 0000
Serial : 0000000000000000
total: used: free: shared: buffers: cached:
Mem: 13332480 4030464 9302016 0 233472 2256896
Swap: 0 0 0
MemTotal: 13020 kB
MemFree: 9084 kB
MemShared: 0 kB
Buffers: 228 kB
Cached: 2204 kB
SwapCached: 0 kB
Active: 964 kB
Inactive: 1988 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 13020 kB
LowFree: 9084 kB
SwapTotal: 0 kB
SwapFree: 0 kB
XXX: DMESG
Linux version 2.4.18-rmk3-crypt1 (vince@VonHagen.phatnoise.com) (gcc version 2.95.3 20010315 (release)) #5 Thu May 29 11:53:53 PDT 2003
Processor: ARM ARM720T revision 2
Architecture: CL-7312 (Phatnoise v1.1)
Machine name is: CL-7312 (Phatnoise v1.1)
Param offset is: 0xC0023000
Tags offset is: 0xC0023000
fixup_clep7312()
Converting old-style param struct to taglist
edb7211_map_io()
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: init=/bin/bash
Relocating machine vectors to 0xffff0000
clps711x_init_irq() begin NR_IRQS = 128
clps711x_init_irq() end
clps711x_setup_timer() SYSCON1 = 0xff000100 adding TC2S and TC2M bits
clps711x_setup_timer() SYSCON1 = 0xff0001c0
clps711x_setup_timer() SYSCON2 = 0xff000100
clps711x_setup_timer() SYSCON3 = 0xff000026
Calibrating delay loop... 36.76 BogoMIPS
initrd_start = 0xC0C00000
Memory: 16MB = 16MB total
Memory: 11952KB available (711K code, 2229K data, 44K init)
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
ttyAM0 at I/O 0x100 (irq = 12) is a CLPS711x
ttyAM1 at I/O 0x1100 (irq = 28) is a CLPS711x
pty: 256 Unix98 ptys configured
block: 64 slots per queue, batch=16
RAMDISK driver initialized: 16 RAM disks of 1048576K size 1024 blocksize
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
PhatNoise ide_init_default_hwifs()
IO_SYSCON1 = 0x000401C0
IO_SYSCON2 = 0x00040100
IO_SYSCON3 = 0x00040026
IO_MEMCFG1 = 0x00000080
IO_MEMCFG2 = 0xFFFDBD00
hda: FUJITSU MHV2040AT, ATA DISK drive
ide0 at 0xfe100000-0xfe100007,0xfe10000e on irq 6
hda: 78140160 sectors (40008 MB) w/2048KiB Cache, CHS=77520/16/63
Partition check:
hda: hda1 hda2 < hda5 >
DAI: Version 1.2
DAI: major 14
DAI: dai_init() initializing stuff
DAI: regs.ARM_ip = 0xff002000
DAI: dai_init() setting fiq handler
FIQ: copying code to 0xFFFF001C
DAI: dai_init() SYSCON1 (0x000401c0)
DAI: dai_init() SYSCON2 (0x00040100)
DAI: dai_init() SYSCON3 (0x00040026)
DAI: dai_init() INTMR1 (0x00040240)
DAI: dai_init() INTMR2 (0x00040000)
DAI: dai_init() INTMR3 (0x00040000)
DAI: dai_init() DAISR (0x00001505)
DAI: dai_init() DAI64FS (0x00000000)
DAI: dai_init() setting PE.1
DAI: dai_init() setting DAI Control Register
DAI: dai_init() clearing DAI status register bits
DAI: dai_init() setting DAIR_DAIEN
DAI: dai_init() DAISR = 0x00009a00
DAI: dai_init() adding routine to task queue
DAI: dai_init() enabling DAI interrupt
PhatNoise Board v1.1
LED: major 13
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Fast Floating Point Emulator V0.9 (c) Peter Teichmann.
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 400 blocks [1 disk] into ram disk... done.
Freeing initrd memory: 1024K
VFS: Mounted root (ext2 filesystem).
Freeing init memory: 44K
-
Plsign? I thought the key used to sign the playlists differs from the one used for the "important" files? We'd already tried that AFAIK...
Para
-
Ok, it may have been tried but tried wrong.
Explain the boot trace if it didn't work.... :D
Better, try it and see what 'ya get.
-
Yep, looks to good to be a hoax :P
-
Bling bling fellas. Finally popped this sucka. Absolutely drooling-on-itself stupid too. After ~25 attempts of hacking phatbox.ini, walking ~800 feet to the car, testing it, walking 800 feet back, and checking the logfile, the solution was dead simple: Just use plsign. Seriously. Replace a player with a shell script, execute plsign on it, add a menu item that executes a file handled by that player. Now that the cat is out of the bag, lets hope PhatNoise doesnt be mean and restrict the keys used to sign the players. If they do that, we will have to actually replace the pubkeys in the disk image...
Would you please post the contents of your shell script and menu file. Also a little more detail on the step by step process would be helpful
RdeR
-
Yeah, that would be helpful.. I'd like to have someone dump the tty settings to a file on the DMS so we know what the TTYS0 is set to so we can get serial access nailed down.
can you show us the contents of hack.sh ? thanks..
-
Argh! You win. ;)
I don't care what they do at this point. Here's the path I want to go down at this point:
1. Dump the rom image
2. Patch the rom image to not check the drive signature (or any other signatures)
3. Find / write a utility to reflash the bios from linux, and do so
4. Patch phatd and 51d to not check signatures
5. ??
6. PROFIT!
Along those lines ... since my board is out and sitting on my workbench, it'll be a couple days before I get a chance to put it back in my car and test this out. Will someone out there do me a HUGE favor?
Page 1-3 of the EP73xx User's Guide (linked to in the FAQ section) gives a memory map that says that the ROM bank 0 should start at 0x00000000 in memory.
With that in mind, can someone get the box to run this command:
dd if=/dev/mem of=/dos/rom.bin bs=1024 count=128
... and email the rom.bin file produced to bushing at gmail.com ?? I'd really appreciate it, and the sooner someone can do that, the sooner I can start working on a packaged solution to reflash and / or upgrade drives.
Ben
-
@ Bushing: I dont have a working linux box to run plsign on.. can you whip up a shell script and plsign that bad boy and send me the plsigned file and the sig.. I have a kenwood FM modulator set up so I can run a phatbox right nex to me and see it work or not. easy to whip the DMS in and out.. hehe :)
-
i am pretty sure that stty command is in the busybox IIRC.. so just run a stty..
maybe
stty -F /dev/ttyS0 -a > /dos/ttyS0
stty -F /dev/ttyS1 -a > /dos/ttyS1
stty -F /dev/ttyAM0 -a > /dos/ttyAM0
stty -F /dev/ttyAM1 -a > /dos/ttyAM1
edit.. also an ls -la /dev would be useful to figure out if any other device names are not present in the ramdisk image.. the post log he shows and the tty names in the ramdisk differ.. so im thinking its stock stuff in there. /dev/console might be redirected to TTYS0 which doesnt exist.. we may need to modify it to /dev/ttyAM0 to reall see the console output.
-
A HOAX?!?!!??! You think I just *MADE UP* a kernel log? WTF. No. Try this:
1) Create a shell script that does something. I called mine hack.sh. The /dos and /dos/Data partitions are mounted r/w, so just run some command and write the output to a file.
2) Rename your shell script to phatwma or oogplay-la or something. Replace one of the players (aadec, phatwma, oggplay*, etc).
3) Use plsign to sign the renamed shell script.
4) Edit PhatBox.ini. Go to the menu and add a new menu item that plays a non-existent file ENDING with the extension that is handled by the player you are backdooring. Make sure you change the menu item count if you didn't before.
5) Plug the box into your car. Browse to the menu item. When it hits it, and tries to play the audio for it, it will run your player.
This is a nice method because you can take an unused extension, replace the player, and make this a generic command handler based on the name of the audio file. From this point, you can run any code on the DMS, jack with the hardware, try to dump the flash, read /proc/kcore, etc, etc.
-
Oh, FYI, you can't use plsign to replace phatd or many of the other utiltiies. I only had luck replacing some of the player commands (oggplay, phatwma, aadec).
-
can you show me an example entry from the phatbox.ini?
-
[ phatbox.ini - under BMW ]
menu.7.text=BACKDOOR FLAC
menu.7.audio=/dos/tts/it_about.flac
menu.7.action=FIRMWARE_VERSION
[ /dos/flacplay ]
#!/bin/sh
/dos/hack.sh >> /dos/hack.log 2>&1
root@slasher mnt # /downloads/phatbox/plsign flacplay
Signature file for the playlist flacplay.sig has been generated.
root@slasher mnt # ls -al flacplay.sig
-rwxr--r-- 1 root root 240 Jun 5 13:14 flacplay.sig
-
BTW, I will do a kcore | /dev/mem dump later this evening, got to run though. Any ideas for adding peripheals to the PB? A working serial port would be nice, but attaching a CF/USB to it would be nicer. I am working on getting the pinouts for BMW GPS... It would rock to make my own voice-nav system... or use serial cable to interface with another box.. say with wifi.. and have audio-driven gps-enabled wardriving kit ;-)
-
Let me say congratulations to Spin for finding and Vince for enabling this avenue of software exploit.
-
if someone could make a copy of spin's posted flacplay script and sign it.. then send me both the flacplay and the .sig file created for it I can do all this stuff pretty quickly. I just tried using a knoppix boot CD to mount my DMS to try using plsign that way but it doesnt like my USB controller I guess. Stupid XPS2 Dell laptop!
Let me say congratulations to Spin for finding and Vince for enabling this avenue of software exploit.
Well, lets not start celebrating yet.. we dont know if this will really work or not, much less that we can use it to crack the phatbox drive security.
BTW, I will do a kcore | /dev/mem dump later this evening, got to run though. Any ideas for adding peripheals to the PB? A working serial port would be nice, but attaching a CF/USB to it would be nicer. I am working on getting the pinouts for BMW GPS... It would rock to make my own voice-nav system... or use serial cable to interface with another box.. say with wifi.. and have audio-driven gps-enabled wardriving kit ;-)
Well, I highly doubt we would be able to get much more than serial access working without significant modifications to the phatbox board which would really mean if we can get the boot loader cracked we could make our own boards with whatever hardware we need (USB / Video etc) and update the kernel source from phatnoise to support it and then boot the system using our new kernel.
The trick will be cracking the boot loader and then finding a source for the parts we need to build a board like that. (would still need to be ARM based.. maybe even Mavrick 7312 based.. depending on what phatd and 51d need to operate. In fact if we crack the boot loader code we may be able to replace the keys and not have to change anything about the software in phatd or 51d to have it keep working. thats cause we can insert a modified hdparm that reports whatever we want it to. hehe)
With all that said, I am not terribly interested in modifying the hardware design, im just pointing out the issues with the idea... I think building / selling boards like that would QUICKLY get us in leagl trouble.
-
Argh! You win. ;)
I don't care what they do at this point. Here's the path I want to go down at this point:
1. Dump the rom image
2. Patch the rom image to not check the drive signature (or any other signatures)
3. Find / write a utility to reflash the bios from linux, and do so
4. Patch phatd and 51d to not check signatures
5. ??
6. PROFIT!
Along those lines ... since my board is out and sitting on my workbench, it'll be a couple days before I get a chance to put it back in my car and test this out. Will someone out there do me a HUGE favor?
Page 1-3 of the EP73xx User's Guide (linked to in the FAQ section) gives a memory map that says that the ROM bank 0 should start at 0x00000000 in memory.
With that in mind, can someone get the box to run this command:
dd if=/dev/mem of=/dos/rom.bin bs=1024 count=128
... and email the rom.bin file produced to bushing at gmail.com ?? I'd really appreciate it, and the sooner someone can do that, the sooner I can start working on a packaged solution to reflash and / or upgrade drives.
Ben
Is DD included with busybox? we may need to complie a version for this box and put it on the phatsys partition...
-
This is the hack.sh I want to try and run first.... Make sure that the directory stuff exists in the phatsys partition...
#!/bin/sh
echo "/bin/stty -F /dev/ttyS0 -a > /dos/stuff/ttyS0.txt"
/bin/stty -F /dev/ttyS0 -a > /dos/stuff/ ttyS0.txt
echo "/bin/stty -F /dev/ttyS1 -a > /dos/stuff/ttyS1.txt"
/bin/stty -F /dev/ttyS1 -a > /dos/stuff/ttyS1.txt
echo "/bin/stty -F /dev/ttyAM0 -a > /dos/stuff/ttyAM0.txt"
/bin/stty -F /dev/ttyAM0 -a > /dos/stuff/ttyAM0.txt
echo "/bin/stty -F /dev/ttyAM1 -a > /dos/stuff/ttyAM1.txt"
/bin/stty -F /dev/ttyAM1 -a > /dos/stuff/ttyAM1.txt
echo "/bin/ls -la /dev > /dos/stuff/devlist.txt"
/bin/ls -la /dev > /dos/stuff/devlist.txt
echo $PATH
set > /dos/stuff/set.txt
echo "dd if=/dev/mem of=/dos/rom.bin bs=1024 count=128"
dd if=/dev/mem of=/dos/rom.bin bs=1024 count=128
-
A HOAX?!?!!??! You think I just *MADE UP* a kernel log? WTF. No.
Hey, no offense Spin :D It's just hard to grasp that we finally make some progress! I appreciate your work mate...
@judb: hope my flacplay works...
-
Well I dont have VIOT on this keg.. so I can get it to work. any ideas?
That means the menuid options are missing for the kenwood headunits.
-
[sent a flacplay script to judb]
Well, I think happened here is that the bootloader (which checks the drive, linux, ramdisk, rc.sh and phatd) uses one key/keys, and phatd (which checks 51d, all of the players, and the playlists) uses another. I certainly didn't see anything in the phatd code that looked like it differentiated between keys.
Once we have patched the BIOS to stop checking those keys, I can patch phatd to stop checking its keys, and that will be the end of that.
Ben
-
Yeah, good old times! I think it's time to reactivate my assembler/reversing styles of coding ;)
-
Okay the setup I have doesnt work.
I tried replacing flacplay and the sig that were sent to me and got nothing. the songs dont play but I cant see whats wrong because I dont have the debug rc.sh on hand. Anyone have that?
-
Yep, same place in a few minutes...
-
Thanks para.. ill check there now.
Hey spin, what firmware version are you using?
Send me your scripts as I am not able to get this to work on my keg and I think its because of the menuid not being there but cant be sure.
-
Oh, and if anyone gets around to doing this (please? :) ), my math was wrong, that dd command should be:
/bin/dd if=/dev/mem of=/dos/rom.bin bs=1024 count=256
(256k, not 128k...)
-b
-
Firmware version is 9.0 BMW. I will add those scripts to the DMS and dump the info soon. Is there a way to upload something to board? I don't feel like linking my main site to this hobby =P For the flacplay thing to work, just make the box play a flac file, somehow. I use the menu system because its easy to try a bunch of different things, in order.
-
i did, it doesnt execute the script... the debug log shows the player (flacplay) exits status 0 ... so its is running it it SEEMS but it doesnt DO anything.
im using the 13.01 kenwood firmware...
just email me the stuff at jud DOT barron AT gmail DOT com and I'll post it to my webserver.. FTP for some reason doesnt work right for most folks.
-
#!/bin/sh
/bin/stty -F /dev/ttyS0 -a >> /dos/data/stuff/ttyS0.txt
/bin/stty -F /dev/ttyS1 -a >> /dos/data/stuff/ttyS1.txt
/bin/stty -F /dev/ttyAM0 -a >> /dos/data/stuff/ttyAM0.txt
/bin/stty -F /dev/ttyAM1 -a >> /dos/data/stuff/ttyAM1.txt
/bin/ls -la /dev >> /dos/data/stuff/devlist.txt
set >> /dos/data/stuff/set.txt
dd if=/dev/mem of=/dos/data/stuff/rom.bin bs=1024 count=256
cp -a /proc /dos/data/stuff/proc_snap
tar cf /dos/data/stuff/proc.tar /proc
Resulted in the following (note that the dd command, among others failed). The proc_snap directory /does/ a kcore file though ;-)
stty: /dev/ttyAM0: No such file or directory
stty: /dev/ttyAM1: No such file or directory
Segmentation fault
cp: cannot create symlink `/dos/data/stuff/proc_snap/ide/hda': Operation not permitted
Data:
-rwxr--r-- 1 root root 3726 Dec 31 1979 devlist.txt
drwxr--r-- 11 root root 32768 Dec 31 1979 proc_snap
-rwxr--r-- 1 root root 0 Dec 31 1979 rom.bin
-rwxr--r-- 1 root root 358 Dec 31 1979 set.txt
-rwxr--r-- 1 root root 0 Dec 31 1979 ttyAM0.txt
-rwxr--r-- 1 root root 0 Dec 31 1979 ttyAM1.txt
-rwxr--r-- 1 root root 1124 Dec 31 1979 ttyS0.txt
-rwxr--r-- 1 root root 1132 Dec 31 1979 ttyS1.txt
[ ttyS0 ]
speed 115200 baud; rows 0; columns 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff
-iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl -echoke
[ ttyS1 ]
speed 115200 baud; rows 0; columns 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts
ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl -echoke
[ DEV ]
drwxr-xr-x 3 0 0 1024 Apr 7 2003 .
drwxr-xr-x 12 500 500 1024 Oct 18 2002 ..
crw------- 1 0 0 14, 1 May 3 2000 audio
lrwxrwxrwx 1 0 0 5 Oct 18 2002 console -> ttyS0
crw------- 1 0 0 14, 1 May 3 2000 dsp
crw-r--r-- 1 0 0 1, 7 Dec 24 1997 full
brw-r----- 1 0 0 3, 0 May 12 2000 hda
brw-r----- 1 0 0 3, 1 May 12 2000 hda1
brw-r----- 1 0 0 3, 2 May 12 2000 hda2
brw-r----- 1 0 0 3, 3 May 12 2000 hda3
brw-r----- 1 0 0 3, 4 May 12 2000 hda4
brw-r----- 1 0 0 3, 5 Sep 13 2001 hda5
brw-r--r-- 1 0 0 0, 250 Dec 30 1997 initrd
crw-r--r-- 1 0 0 1, 2 Dec 24 1997 kmem
crw-r--r-- 1 0 0 13, 1 Apr 7 2003 led
crw-r--r-- 1 0 0 1, 1 Dec 24 1997 mem
crw-r--r-- 1 0 0 1, 3 Dec 24 1997 null
crw-r--r-- 1 0 0 1, 4 Dec 24 1997 port
drwxr-xr-x 2 0 0 1024 Dec 12 1999 pts
brw-r--r-- 1 0 0 1, 1 Dec 24 1997 ram
crw-r--r-- 1 0 0 55, 1 Jan 28 2000 ts
crw-r--r-- 1 0 0 5, 0 Dec 24 1997 tty
crw-r--r-- 1 0 0 4, 0 Dec 16 1997 tty0
crw-r--r-- 1 0 0 4, 1 Dec 11 1997 tty1
crw-r--r-- 1 0 0 4, 2 Jan 16 1998 tty2
crw-r--r-- 1 0 0 4, 3 Jan 16 1998 tty3
crw-r--r-- 1 0 0 4, 4 Jan 16 1998 tty4
crw-r--r-- 1 0 0 4, 64 Dec 11 1997 ttyS0
crw-r--r-- 1 0 0 4, 65 Jan 1 00:00 ttyS1
crw-r--r-- 1 0 0 1, 5 Dec 24 1997 zero
-
Interesting...
I still wonder why I cant get this to work on my keg though. damn! Thanks for the information.
-
so from what I can tell, the modem control signals are enabled on the port.. which means we would need DTR and whatnot to communicate right? However RTS and CTS are disabled it looks like...
if we set -clocal insetad of clocal with an STTY command i think we might be able to get serial access working. Or that might be overkill...
anyone agree or disagree with that?
Also anyone have any ideas what else I could try? I replaced flacplay with a signed script...
Hey Spin, why dont you email me your scripts and sig files so I can see if maybe there is something about the way you did that?
-
HAHA! it does work. for some reason I thought the playlist that PMM generated was right for the flac file but it didnt sync the updated play list. WHOOT! now its working. kickass! now I need to dig out an old laptop that has a serial port on it. this one is USB only.
-
the DD failure generates this in the messages log:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0c24000
*pgd = c0fcb811, *pmd = c0fcb811, *pte = 00000000, *ppte = 00000000
Internal error: Oops: 0
CPU: 0
pc : [<c00e6ff8>] lr : [<c00b1ec8>] Not tainted
sp : c0c29f50 ip : 00000000 fp : c0c29f80
r10: bfffff4d r9 : c0c28000 r8 : 00066000
r7 : 00000400 r6 : c0395ec0 r5 : 00000400 r4 : 00000400
r3 : c0c28000 r2 : 000003fc r1 : 00000000 r0 : 00066000
Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment user
Control: 217D Table: C0C24015 DAC: 00000015
Process dd (pid: 23, stackpage=c0c29000)
Stack: (0xc0c29f40 to 0xc0c2a000)
9f40: c00b1ec8 c00e6ff8 20000013 ffffffff 00000400 00000400 00000400 c0395ec0
9f60: 00000400 c00b1ec8 00000000 ffffffea c0395ea0 c0c29fac c0c29f84 c0070ec0
9f80: c00b1e64 c0c29f90 c00706c4 0000000a 00000400 00066000 00000003 c0043aa0
9fa0: 00000000 c0c29fb0 c0043920 c0070df4 0000000a c0049c90 00000009 00066000
9fc0: 00000400 00000000 0000000a 00000400 00066000 00000009 00000400 bfffff41
9fe0: bfffff4d 00000000 00066000 bffffde0 00033fa0 000460b0 20000010 00000009
Backtrace:
Function entered at [<c00b1e54>] from [<c0070ec0>]
r6 = C0395EA0 r5 = FFFFFFEA r4 = 00000000
Function entered at [<c0070de4>] from [<c0043920>]
r8 = C0043AA0 r7 = 00000003 r6 = 00066000 r5 = 00000400
r4 = 0000000A
Code: 1a00002c e2522004 4282c004 4a00001b (e4913004)
-
this is the environment returned from a set command:
USER='root'
HOME='/'
DEBUG_LEVEL='10'
PS1='# '
OPTIND='1'
PS2='> '
DEBUG_LOG='1'
AAC_DEBUG='1'
TERM='vt102'
PPID='18'
PATH='/usr/bin:/bin:/usr/sbin:/sbin'
SHELL='/bin/sh'
PWD='/'
-
so from what I can tell, the modem control signals are enabled on the port.. which means we would need DTR and whatnot to communicate right? However RTS and CTS are disabled it looks like...
if we set -clocal insetad of clocal with an STTY command i think we might be able to get serial access working. Or that might be overkill...
DCD,DTR, and CTS are pulled low on the EP7312 by external pull down resistors. They are all active low signals, so they are being aserted correctly. the serial driver shoud see the port as ready.
RdeR
-
well, then, if I am reading the stty output correctly ^Q will start the session.. and its 11500, 8, e, 1 with xon/xoff flow control.. is that right? I dont get anything but a smiley face when I try connecting like that.
-
#!/bin/sh
echo "/bin/stty -F /dev/tty -a > /dos/stuff/tty.txt"
/bin/stty -F /dev/tty -a > /dos/stuff/tty.txt
echo "/bin/stty -F /dev/tty0 -a > /dos/stuff/tty0.txt"
/bin/stty -F /dev/tty0 -a > /dos/stuff/tty0.txt
echo "/bin/stty -F /dev/tty1 -a > /dos/stuff/tty1.txt"
/bin/stty -F /dev/tty1 -a > /dos/stuff/tty1.txt
echo "/bin/stty -F /dev/tty2 -a > /dos/stuff/tty2.txt"
/bin/stty -F /dev/tty2 -a > /dos/stuff/tty2.txt
echo "/bin/stty -F /dev/tty3 -a > /dos/stuff/tty3.txt"
/bin/stty -F /dev/tty3 -a > /dos/stuff/tty3.txt
echo "/bin/stty -F /dev/tty4 -a > /dos/stuff/tty4.txt"
/bin/stty -F /dev/tty4 -a > /dos/stuff/tty4.txt
echo "/bin/stty -F /dev/ttyS0 -a > /dos/stuff/ttyS0.txt"
/bin/stty -F /dev/ttyS0 -a > /dos/stuff/ttyS0.txt
echo "/bin/stty -F /dev/ttyS1 -a > /dos/stuff/ttyS1.txt"
/bin/stty -F /dev/ttyS1 -a > /dos/stuff/ttyS1.txt
echo "/bin/stty -F /dev/ttyAM0 -a > /dos/stuff/ttyAM0.txt"
/bin/stty -F /dev/ttyAM0 -a > /dos/stuff/ttyAM0.txt
echo "/bin/stty -F /dev/ttyAM1 -a > /dos/stuff/ttyAM1.txt"
/bin/stty -F /dev/ttyAM1 -a > /dos/stuff/ttyAM1.txt
ls -la /dev > /dos/stuff/devlist.txt
ls -la / > /dos/stuff/rootlist.txt
ls -la /bin > /dos/stuff/binlist.txt
ls -la /sbin > /dos/stuff/sbinlist.txt
ls -la /usr/bin > /dos/stuff/usr_bin_list.txt
ls -la /usr/sbin > /dos/stuff/usr_sbin_list.txt
ls -la /etc > /dos/stuff/etclist.txt
ls -la /etc/init.d > /dos/stuff/etcinitd.txt
ls -la /proc > /dos/stuff/proc.txt
mount > /dos/stuff/mount.txt
ps -aux > /dos/stuff/ps.txt
#dmesg > /dev/ttyS0
#/bin/sync > /dos/stuff/syncoutput.txt
date > /dos/stuff/date.txt
hostname > /dos/stuff/hostname.txt
uname -a > /dos/stuff/uname.txt
/bin/tar cvfh /dos/stuff/proc.tar /proc
/bin/tar cvfhX /dos/stuff/all.tar /dos/stuff/tarexclude.txt /
http://judb.phathack.com/files
files I have gotten off the box.
-
You wrote the output files to the root partition and not the data partition, so you are missing a ton of data:
tar: /proc/ide/ide0/model: input/output error -- No space left on device
tar: /proc/ide/ide0/mate: input/output error -- No space left on device
tar: /proc/ide/ide0/config: input/output error -- No space left on device
-
hmm.. the commands I used were
/bin/tar cvfh /dos/stuff/proc.tar /proc
/bin/tar cvfhX /dos/stuff/all.tar /dos/stuff/tarexclude.txt /
what should I have done ?
Also. i noticed some errors with the paths it sees in the log files that dont match up to what I put in the hack.sh .. its like something is doing substitution on my strings in a few places.
-
FYI, it works for my box :D
I replaced phatwma (who needs this anyway) and put a wma startup_sound into Profiles.ini...
Now everytime I turn on my box the script is executed automatically!
Para
-
what should I have done ?
Write the files to /dos/DATA/stuff instead :-)
-
Theres 253 megs of space on /dos .. I dont think thats the problem Spin.
-
The "No space left on device" error says otherwise =P I ran into the "no space" error until I changed partitions, I think it has more to do with the number of available files on the /dos partition, and not so much the amount of free space (inode starvation, but for vfat or somesuch). My /dos partition was tiny and /proc/kcore has a complete dump of physical memory...
-
I'll try that. I think its trying to write to / instead of /dos for some reason...
-
the DD failure generates this in the messages log:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0c24000
*pgd = c0fcb811, *pmd = c0fcb811, *pte = 00000000, *ppte = 00000000
Internal error: Oops: 0
CPU: 0
pc : [<c00e6ff8>] lr : [<c00b1ec8>] Not tainted
sp : c0c29f50 ip : 00000000 fp : c0c29f80
r10: bfffff4d r9 : c0c28000 r8 : 00066000
r7 : 00000400 r6 : c0395ec0 r5 : 00000400 r4 : 00000400
r3 : c0c28000 r2 : 000003fc r1 : 00000000 r0 : 00066000
Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment user
Control: 217D Table: C0C24015 DAC: 00000015
Process dd (pid: 23, stackpage=c0c29000)
Stack: (0xc0c29f40 to 0xc0c2a000)
9f40: c00b1ec8 c00e6ff8 20000013 ffffffff 00000400 00000400 00000400 c0395ec0
9f60: 00000400 c00b1ec8 00000000 ffffffea c0395ea0 c0c29fac c0c29f84 c0070ec0
9f80: c00b1e64 c0c29f90 c00706c4 0000000a 00000400 00066000 00000003 c0043aa0
9fa0: 00000000 c0c29fb0 c0043920 c0070df4 0000000a c0049c90 00000009 00066000
9fc0: 00000400 00000000 0000000a 00000400 00066000 00000009 00000400 bfffff41
9fe0: bfffff4d 00000000 00066000 bffffde0 00033fa0 000460b0 20000010 00000009
Backtrace:
Function entered at [<c00b1e54>] from [<c0070ec0>]
r6 = C0395EA0 r5 = FFFFFFEA r4 = 00000000
Function entered at [<c0070de4>] from [<c0043920>]
r8 = C0043AA0 r7 = 00000003 r6 = 00066000 r5 = 00000400
r4 = 0000000A
Code: 1a00002c e2522004 4282c004 4a00001b (e4913004)
Try this command instead:
dd if=/dev/mem of=/dos/data/stuff/rom.bin bs=1 skip=1 count=262143
It should solve the null pointer issue, but let Ben know that the first byte is missing...
RdeR
-
Try this command instead:
dd if=/dev/mem of=/dos/data/stuff/rom.bin bs=1 skip=1 count=262143
It should solve the null pointer issue, but let Ben know that the first byte is missing...
RdeR
Ralph, if you don't stop reading my mind, you're going to really freak me out. ;)
Yes, I was going to suggest that ... although this document http://www.embedded-kernel-track.org/2005/porting_to_arm.pdf suggests that 0x0-0xfff are a "null pointer / interrupt vector trap".
So, we might need to use mmap.
I wrote a quick little c-program called readrom. get it here: http://bbyer.mm.st/readrom, source at http://bbyer.mm.st/readrom.c. Put it in a script as "readrom /dos/data/rom.out" or whatever, and let me know if that works, someone ... anyone ... Bueller? ;)
Ben
-
Bushing, thats not working. is it supposed to log any output? contact me via ICQ or AIM or something... I can test stuff in a couple seconds with my test rig.. :)
-
Readrom seg fault info from dmesg:
readrom: unhandled page fault at pc=0x0000b8d8, lr=0x0000ffb4 (bad address=0xfffffffc, code 0)
pc : [<0000b8d8>] lr : [<0000ffb4>] Not tainted
sp : bffffddc ip : bffffe90 fp : 00000000
r10: 00000000 r9 : 000363f0 r8 : 00000002
r7 : bffffe84 r6 : 0003c7ec r5 : 00036670 r4 : 00046384
r3 : 0000f108 r2 : 00046384 r1 : 00000000 r0 : 00000008
Flags: nzCv IRQs on FIQs on Mode USER_32 Segment user
Control: 217D Table: C0C10015 DAC: 00000015
Unable to handle kernel NULL pointer dereference at virtual address 00000001
pgd = c0c10000
*pgd = c0c2c811, *pmd = c0c2c811, *pte = 00000000, *ppte = 00000000
Internal error: Oops: 0
CPU: 0
pc : [<c00e7074>] lr : [<c00b1ec8>] Not tainted
sp : c0c17f50 ip : 00000001 fp : c0c17f80
r10: bfffff48 r9 : c0c16000 r8 : 00066000
r7 : 00000001 r6 : c0c390e0 r5 : 00000001 r4 : 00000001
r3 : c0c16000 r2 : 00000001 r1 : 00000001 r0 : 00066000
Flags: Nzcv IRQs on FIQs on Mode SVC_32 Segment user
Control: 217D Table: C0C10015 DAC: 00000015
Process dd (pid: 19, stackpage=c0c17000)
Stack: (0xc0c17f40 to 0xc0c18000)
7f40: c00b1ec8 c00e7074 80000013 ffffffff 00000001 00000001 00000001 c0c390e0
7f60: 00000001 c00b1ec8 00000001 ffffffea c0c390c0 c0c17fac c0c17f84 c0070ec0
7f80: c00b1e64 c0070c70 c00720b0 0000000a 00000001 00066000 00000003 c0043aa0
7fa0: 00000000 c0c17fb0 c0043920 c0070df4 0000000a c0049c90 00000009 00066000
7fc0: 00000001 00000000 0000000a 00000001 00066000 00000009 00000001 bfffff3c
7fe0: bfffff48 00000000 00066000 bffffde0 00033fa0 000460b0 20000010 00000009
Backtrace:
Function entered at [<c00b1e54>] from [<c0070ec0>]
r6 = C0C390C0 r5 = FFFFFFEA r4 = 00000001
Function entered at [<c0070de4>] from [<c0043920>]
r8 = C0043AA0 r7 = 00000003 r6 = 00066000 r5 = 00000001
r4 = 0000000A
Code: 0affffe0 e33c0000 0a000009 e35c0002 (e4d13001)
-
dd also still segfaults using the updated options.. it creates a 0 byte file first though. readrom does not.
#!/bin/sh
/dos/stuff/readrom /dos/data/stuff/readrom.out
dd if=/dev/mem of=/dos/data/stuff/rom.bin bs=1 skip=1 count=262143
/bin/tar cvfh /dos/data/stuff/proc.tar /proc
/bin/tar cvfhX /dos/data/stuff/all.tar /dos/stuff/tarexclude.txt /
dmesg > /dos/stuff/dmesg.txt
-
Bushing, thats not working. is it supposed to log any output? contact me via ICQ or AIM or something... I can test stuff in a couple seconds with my test rig.. :)
It should have created a little bit of output. *sigh*
Wanna create an IRC channel? I'll go do some research online and post back in like 15 mins...
-b
-
It should have created a little bit of output. *sigh*
Wanna create an IRC channel? I'll go do some research online and post back in like 15 mins...
-b
pm'ed you with a chat room that I have setup.. not IRC.. dont have an IRC client on my box and dont feel like setting it up just for this.
-
dd error "dd if=/dev/mem of=/dos/data/stuff/rom.bin bs=1 skip=32 count=32"
Unable to handle kernel NULL pointer dereference at virtual address 00000020
pgd = c0c18000
*pgd = c0fee811, *pmd = c0fee811, *pte = 00000000, *ppte = 00000000
Internal error: Oops: 0
CPU: 0
pc : [<c00e7074>] lr : [<c00b1ec8>] Not tainted
sp : c0c1ff50 ip : 00000001 fp : c0c1ff80
r10: bfffff4b r9 : c0c1e000 r8 : 00066000
r7 : 00000001 r6 : c0fc80e0 r5 : 00000001 r4 : 00000001
r3 : c0c1e000 r2 : 00000001 r1 : 00000020 r0 : 00066000
Flags: Nzcv IRQs on FIQs on Mode SVC_32 Segment user
Control: 217D Table: C0C18015 DAC: 00000015
Process dd (pid: 18, stackpage=c0c1f000)
Stack: (0xc0c1ff40 to 0xc0c20000)
ff40: c00b1ec8 c00e7074 80000013 ffffffff 00000001 00000001 00000001 c0fc80e0
ff60: 00000001 c00b1ec8 00000020 ffffffea c0fc80c0 c0c1ffac c0c1ff84 c0070ec0
ff80: c00b1e64 c0070c70 c00720b0 0000000a 00000001 00066000 00000003 c0043aa0
ffa0: 00000000 c0c1ffb0 c0043920 c0070df4 0000000a c0049c90 00000009 00066000
ffc0: 00000001 00000000 0000000a 00000001 00066000 00000009 00000001 bfffff3f
ffe0: bfffff4b 00000000 00066000 bffffde0 00033fa0 000460b0 20000010 00000009
Backtrace:
Function entered at [<c00b1e54>] from [<c0070ec0>]
r6 = C0FC80C0 r5 = FFFFFFEA r4 = 00000020
Function entered at [<c0070de4>] from [<c0043920>]
r8 = C0043AA0 r7 = 00000003 r6 = 00066000 r5 = 00000001
r4 = 0000000A
Code: 0affffe0 e33c0000 0a000009 e35c0002 (e4d13001)
devmem2 error "/dos/stuff/devmem2 262136 > /dos/stuff/devmem2.out"
devmem2: unhandled page fault at pc=0x0000ace8, lr=0x00016de0 (bad address=0xfffffffc, code 0)
pc : [<0000ace8>] lr : [<00016de0>] Not tainted
sp : bffffdfc ip : bffffeb0 fp : 00000000
r10: 00000000 r9 : 00036b60 r8 : 00000002
r7 : bffffea4 r6 : 0003d038 r5 : 000390a4 r4 : 00046d50
r3 : 0000e518 r2 : 00046d50 r1 : 00000000 r0 : 00000008
Flags: nzCv IRQs on FIQs on Mode USER_32 Segment user
Control: 217D Table: C0FA4015 DAC: 00000015
-
Let's see if we can bring some more-experienced minds to bear on the problem:
http://lists.arm.linux.org.uk/pipermail/linux-arm/2005-June/010037.html
-
I wonder if we can extract the 128 byte internal boot rom area from the ARM cpu...
-
I wonder if we can extract the 128 byte internal boot rom area from the ARM cpu...
Why?? the full source is in the back of the User manual.
RdeR
-
hmm good point. I never noticed that. apparently the boot rom data is stored at 0x7000.0000 according to the user manual and flash rom is addressed as 0x0... I cant tell where it says if the data at 0x7 is fixed code or if its rewriteable somehow.
-
hmm good point. I never noticed that. apparently the boot rom data is stored at 0x7000.0000 according to the user manual and flash rom is addressed as 0x0... I cant tell where it says if the data at 0x7 is fixed code or if its rewriteable somehow.
I had to read all of the info about those two parts several times to get this, but I think I can explain more simply.
Normally, when you power up the EP7312, it jumps to location 0x0 -- hopefully you have some sort of memory (ram, rom, whatever) sitting there that holds instructions. If not, you're toast.
Now, what this means is that if you want to have a system that boots, you had better make sure your flash rom chips are burned before you solder them down to a board, and if anything ever happened to them, you'd have to desolder / replace them. Or use a socketed ROM chip. All of these are horribly expensive from the point of view of the manufacturer.
OR ... you could do what they did. They provided a 128-BYTE rom bank, actually on the die of the processor. It truly is read-onky -- it will never change. When you boot with it (enabled with a jumper on the PhatBox board), it runs a very, very small program, that does the following:
* turns on UART1, configures to 9600
* outputs one char: "<"
* reads the next 2048 bytes
* outputs one last char: ">"
* copies that 2k chunk of data into internal [cache] sram, and executes it.
So, basically you write a 2k mini "pre-bootloader" loader, and use it to handle all other data transfer, and eventually could reflash that way.
Ben
-
Hoh hoh hoh.....
You know what I said about "Sabots", right? :)
-
dd error "dd if=/dev/mem of=/dos/data/stuff/rom.bin bs=1 skip=32 count=32"
Unable to handle kernel NULL pointer dereference at virtual address 00000020
pgd = c0c18000
*pgd = c0fee811, *pmd = c0fee811, *pte = 00000000, *ppte = 00000000
Internal error: Oops: 0
CPU: 0
pc : [<c00e7074>] lr : [<c00b1ec8>] Not tainted
sp : c0c1ff50 ip : 00000001 fp : c0c1ff80
r10: bfffff4b r9 : c0c1e000 r8 : 00066000
r7 : 00000001 r6 : c0fc80e0 r5 : 00000001 r4 : 00000001
r3 : c0c1e000 r2 : 00000001 r1 : 00000020 r0 : 00066000
Flags: Nzcv IRQs on FIQs on Mode SVC_32 Segment user
Control: 217D Table: C0C18015 DAC: 00000015
Process dd (pid: 18, stackpage=c0c1f000)
Stack: (0xc0c1ff40 to 0xc0c20000)
ff40: c00b1ec8 c00e7074 80000013 ffffffff 00000001 00000001 00000001 c0fc80e0
ff60: 00000001 c00b1ec8 00000020 ffffffea c0fc80c0 c0c1ffac c0c1ff84 c0070ec0
ff80: c00b1e64 c0070c70 c00720b0 0000000a 00000001 00066000 00000003 c0043aa0
ffa0: 00000000 c0c1ffb0 c0043920 c0070df4 0000000a c0049c90 00000009 00066000
ffc0: 00000001 00000000 0000000a 00000001 00066000 00000009 00000001 bfffff3f
ffe0: bfffff4b 00000000 00066000 bffffde0 00033fa0 000460b0 20000010 00000009
Backtrace:
Function entered at [<c00b1e54>] from [<c0070ec0>]
r6 = C0FC80C0 r5 = FFFFFFEA r4 = 00000020
Function entered at [<c0070de4>] from [<c0043920>]
r8 = C0043AA0 r7 = 00000003 r6 = 00066000 r5 = 00000001
r4 = 0000000A
Code: 0affffe0 e33c0000 0a000009 e35c0002 (e4d13001)
Jud / Ben
Try this:
dd if=/dev/mem of=/dos/data/stuff/rom_mirror.bin bs=1024 skip=256 count=256
This will skip the first 256K and then read the next 256k. Since the decoding of the flash is only 18 bits, the flash image should repeat every 256K (or every 512K,1024K etc)
Also run
dd if=/dev/mem of=/dos/data/stuff/rom.bin bs=1024 skip=4 count=252
On a linux box run dd if=rom_mirror.bin of=rom_mir_trim.bin bs=1024 skip=4 count=252
Then compare rom.bin to rom_mir_trim.bin
if they are the same, rom_mirror.bin has the full image.
RdeR
-
Hoh hoh hoh.....
You know what I said about "Sabots", right? :)
Huh?
*confused*
Ben
-
Jud / Ben
Try this:
dd if=/dev/mem of=/dos/data/stuff/rom_mirror.bin bs=1024 skip=256 count=256
This will skip the first 256K and then read the next 256k. Since the decoding of the flash is only 18 bits, the flash image should repeat every 256K (or every 512K,1024K etc)
Also run
dd if=/dev/mem of=/dos/data/stuff/rom.bin bs=1024 skip=4 count=252
On a linux box run dd if=rom_mirror.bin of=rom_mir_trim.bin bs=1024 skip=4 count=252
Then compare rom.bin to rom_mir_trim.bin
if they are the same, rom_mirror.bin has the full image.
RdeR
Well i was able to dump data that time. Anyone want these bin files?
The rom_mirror file dumped 80K .. the rom.bin failed to dump.
both of them seg faulted just one was partway through the dump.
Unable to handle kernel paging request at virtual address 00054000
pgd = c0c18000
*pgd = c0fc8811, *pmd = c0fc8811, *pte = 00000000, *ppte = 00000000
Internal error: Oops: 0
CPU: 0
pc : [<c00e6ff8>] lr : [<c00b1ec8>] Not tainted
sp : c0c1df50 ip : 00000000 fp : c0c1df80
r10: bfffff3f r9 : c0c1c000 r8 : 00066000
r7 : 00000400 r6 : c0fa80e0 r5 : 00000400 r4 : 00000400
r3 : c0c1c000 r2 : 000003fc r1 : 00054000 r0 : 00066000
Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment user
Control: 217D Table: C0C18015 DAC: 00000015
Process dd (pid: 18, stackpage=c0c1d000)
Stack: (0xc0c1df40 to 0xc0c1e000)
df40: c00b1ec8 c00e6ff8 20000013 ffffffff 00000400 00000400 00000400 c0fa80e0
df60: 00000400 c00b1ec8 00054000 ffffffea c0fa80c0 c0c1dfac c0c1df84 c0070ec0
df80: c00b1e64 c004435c c0052194 0000000a 00000400 00066000 00000003 c0043aa0
dfa0: 00000000 c0c1dfb0 c0043920 c0070df4 0000000a c00441a8 00000009 00066000
dfc0: 00000400 00000050 0000000a 00000400 00066000 00000009 00000400 bfffff33
dfe0: bfffff3f 00000000 00066000 bffffdd0 00033fa0 000460b0 80000010 00000009
Backtrace:
Function entered at [<c00b1e54>] from [<c0070ec0>]
r6 = C0FA80C0 r5 = FFFFFFEA r4 = 00054000
Function entered at [<c0070de4>] from [<c0043920>]
r8 = C0043AA0 r7 = 00000003 r6 = 00066000 r5 = 00000400
r4 = 0000000A
Code: 1a00002c e2522004 4282c004 4a00001b (e4913004)
Unable to handle kernel paging request at virtual address 00001000
pgd = c0c18000
*pgd = c0fc8811, *pmd = c0fc8811, *pte = 00000000, *ppte = 00000000
Internal error: Oops: 0
CPU: 0
pc : [<c00e6ff8>] lr : [<c00b1ec8>] Not tainted
sp : c0c1df50 ip : 00000000 fp : c0c1df80
r10: bfffff48 r9 : c0c1c000 r8 : 00066000
r7 : 00000400 r6 : c0395f40 r5 : 00000400 r4 : 00000400
r3 : c0c1c000 r2 : 000003fc r1 : 00001000 r0 : 00066000
Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment user
Control: 217D Table: C0C18015 DAC: 00000015
Process dd (pid: 19, stackpage=c0c1d000)
Stack: (0xc0c1df40 to 0xc0c1e000)
df40: c00b1ec8 c00e6ff8 20000013 ffffffff 00000400 00000400 00000400 c0395f40
df60: 00000400 c00b1ec8 00001000 ffffffea c0395f20 c0c1dfac c0c1df84 c0070ec0
df80: c00b1e64 c0070c70 c00720b0 0000000a 00000400 00066000 00000003 c0043aa0
dfa0: 00000000 c0c1dfb0 c0043920 c0070df4 0000000a c0049c90 00000009 00066000
dfc0: 00000400 00000000 0000000a 00000400 00066000 00000009 00000400 bfffff3c
dfe0: bfffff48 00000000 00066000 bffffde0 00033fa0 000460b0 20000010 00000009
Backtrace:
Function entered at [<c00b1e54>] from [<c0070ec0>]
r6 = C0395F20 r5 = FFFFFFEA r4 = 00001000
Function entered at [<c0070de4>] from [<c0043920>]
r8 = C0043AA0 r7 = 00000003 r6 = 00066000 r5 = 00000400
r4 = 0000000A
Code: 1a00002c e2522004 4282c004 4a00001b (e4913004)
-
Awesome! I'm glad you were finally able to get some data -- thanks for your perserverance.
Unfortunately, it looks like at least part of that data is bogus. It's all code, yes, but part of it looks to be busybox, from the strings. (and some of the code, too.)
I think that linux just happened to load busybox into that address space ... do you want to try using that devmem2 program with similar addresses? (ie > 256k)
Ben
-
perhaps it might be more useful to come up with a list of dd commands to dump out stuff in small (16K?) chunks to see what memory regions we can pull data out of?
perhaps a for loop of dd dumps...
did you get a response on that ARM mailing list?
-
perhaps it might be more useful to come up with a list of dd commands to dump out stuff in small (16K?) chunks to see what memory regions we can pull data out of?
perhaps a for loop of dd dumps...
did you get a response on that ARM mailing list?
#!/bin/sh
i=0
let max=1024 * 2 #dump 2MB
while [ $i -lt $max ]; do
dd if=/dev/mem of=/dos/data/stuff/rom$i.bin bs=1024 skip=$i count=1
let i=$i+1
done
then you can just reassemble the 1k chunks....
-
perhaps it might be more useful to come up with a list of dd commands to dump out stuff in small (16K?) chunks to see what memory regions we can pull data out of?
perhaps a for loop of dd dumps...
did you get a response on that ARM mailing list?
Ehh.. I got a private email from one of the list members. We went back and forth a couple of times, but in the end, his suggestion was to "read the documentation" and use the serial boot-rom interface. sigh.
Apparently, there's more to using /dev/mem than just dd (or, should I say, supposedly?). Check out http://www.google.com/search?q=devmem2. (but that didn't work any better, did it?)
I'm too lazy / busy to set up a proper test rig, but what I do hope to do is set up SkyEye (an ARM emulator) and see if I can figure out why their linux kernel is behaving this way ...
-b
-
You might want to check out qemu-arm as well (part of the qemu package). Pretty sure it can boot a linux kernel these days...
-
#!/bin/sh
i=0
let max=1024 * 2 #dump 2MB
while [ $i -lt $max ]; do
dd if=/dev/mem of=/dos/data/stuff/rom$i.bin bs=1024 skip=$i count=1
let i=$i+1
done
then you can just reassemble the 1k chunks....
I got
let: No such file or directory
[: -lt: argument expected
so I just put in 2048 for the value of max.
However the let statement that increments $i I still need to replace.
I tried
for (( i = 1; i <= 2048; i++ )); do
that didnt work either
-
Try replacing the "let"s with:
max=`expr 1024 \* 2`
and:
i=`expr $i + 1`
-
is expr a shell built in? that command doesnt exist in the ramdisk as far as I can tell.
-
Darn. It's in busybox (or it should be), but there's no symlink for it.
I've got a busybox binary for ARM with it built-in if you want; you could copy it to /dos as expr.
-
that might work. lets try that. how big is it? Can you email it to me at jud dot barron at gmail dot com
-
Erm, it appears the one I have is dynamically linked. I'll have to put together a static one when I get a chance.
-
Seems unlikely, but if 'bc' happens to be available, you could use something like:
max=`echo "1024*2" | bc`
max=`echo "$max+1" | bc`
Matt
-
Nope its not there.. sorry. check the file lists I have made of the contents of the ram disk on this site..
http://judb.phathack.com/files/
-
Now here is a thought.. http://mhonarc.axis.se/dev-etrax/msg00037.html talks about dev mtdblock which happens to be listed in the strings from the aadec which ALSO has a string about checking the flash's checksum.. so what do you want to bet that they are reading the flash contents using some method we havent tried yet to validate the flash against the keys (also listed in the same file strings output)
I am starting to wonder.. does anyone think they chroot jailed us somehow so we cant see the real devices?
-
Or then again the mtd stuff might be in there for the pocket version of the phatbox... I dont really know.
Could somebody complie this example program to break chroot jails? http://www.bpfh.net/simes/computing/chroot-break.html
I'd like to run that and dump a dir of / /etc /dev someplace.. we'd have to run a mount command ot see where /dos really is if we are chrooted and have the program write that data to a txt file on /dos I guess.
Any takers?
-
According to this: http://www.busybox.net/downloads/BusyBox.txt the expr should be included in the busybox exe. Course, it doesn't have to be. Anybody have an ARM compiler to build a complete version of the BusyBox?
Matt
-
Now here is a thought.. http://mhonarc.axis.se/dev-etrax/msg00037.html talks about dev mtdblock which happens to be listed in the strings from the aadec which ALSO has a string about checking the flash's checksum.. so what do you want to bet that they are reading the flash contents using some method we havent tried yet to validate the flash against the keys (also listed in the same file strings output)
I am starting to wonder.. does anyone think they chroot jailed us somehow so we cant see the real devices?
This is very strange.
MTD is what everyone else has told me to use -- the problem being that the kernel on the PhatBox does not have MTD compiled into it, and it does not support loadable kernel modules.
(Besides, the MTD driver that came with that version of the kernel -- 2.4.18 -- did not at the time support the ST Micro flash chip they are using on the board.)
I also don't see any reason to think we're in a chroot jail -- there would have to be something to chroot us into, and if so, we wouldn't have access to any of the executables. Plus I have not seen any calls to chroot().
I haven't ever taken a look at aadec -- but itlooks like it itself does a lot of the checks that I theorize must be in the flash. (I think that it must be in both places...) I'll do some more disassembly.
Ben
-
mtd is in the kernel driver directory for the phatnoise phatbox code we got... however I dont know if its compiled in. Something strange is going on though.
The mtd calls in the aadec make me think its POSSIBLE they read the other key off the flash and we might be able to just dump it. looks like it does some things with temp files in /tmp .. i havent looked in there before.
Anyone know of a way to make a file undeleteable? I was thinking we could have it play an aafile to write whatever its doing into memory or to /tmp and mark tmp where it cant delete the files when the aadec exits so we can use a script + a playlist to copy the contents to /dos maybe?
if we can get the key that way we should be able to figure out what we need to do to replace the keying system to swap our own drives in!
-
the only thing in tmp right now on my box is /tmp/phatsock which is a 0 byte file.. hmmm wonder what they are transfering on that socket.
drwxr-xr-x 2 0 0 1024 Jan 1 00:00 .
drwxr-xr-x 12 500 500 1024 Oct 18 2002 ..
srwxr-xr-x 1 0 0 0 Jan 1 00:00 phatsock
-
I think phatsock is the IPC between 51d and phatd.
-
is it possible that we could using some other daemon type program, connect to the socket and dump the data transfered on it to see what is going on? perhaps we can replicate the functions of phatd that way and bypass the need for the keys by building an unsigned kernel and our own boot loader?
-
Also, strings on 51d mentions /dev/8051 which doesnt exist.. looks like they use that to reset the 8051 controller? any thoughts?
Oh one more thing, from dmesg boot log..
IO_MEMCFG1 = 0x00000080
IO_MEMCFG2 = 0xFFFDBD00
Those are mtd device messages im sure of it. Looks like the first flash parition starts at 0x00000080 and the second ones is at 0xFFFDBD00 ... I wonder what we need to do to dump these?
EDIT: maybe not.. these seem to be refrenced in the ide header file as well as the arm cpu header.. dunno what the deal is now.
hmmm...
also the DAI messages are from the crystal DAC driver..
DAI: Version 1.2
DAI: major 14
DAI: dai_init() initializing stuff
DAI: regs.ARM_ip = 0xff002000
DAI: dai_init() setting fiq handler
FIQ: copying code to 0xFFFF001C
DAI: dai_init() SYSCON1 (0x000401c0)
DAI: dai_init() SYSCON2 (0x00040100)
DAI: dai_init() SYSCON3 (0x00040026)
DAI: dai_init() INTMR1 (0x00040240)
DAI: dai_init() INTMR2 (0x00040000)
DAI: dai_init() INTMR3 (0x00040000)
DAI: dai_init() DAISR (0x00001505)
DAI: dai_init() DAI64FS (0x00000000)
DAI: dai_init() setting PE.1
DAI: dai_init() setting DAI Control Register
DAI: dai_init() clearing DAI status register bits
DAI: dai_init() setting DAIR_DAIEN
DAI: dai_init() DAISR = 0x00009a00
DAI: dai_init() adding routine to task queue
DAI: dai_init() enabling DAI interrupt
-
Those flash messages are very handy. I did a disassembly on the boot dump that was done here and saw a few calls to procedures in the 0xffff.... range.
-
Okay, well I was wrong, those devices are listed in the ide.h as part of the phatnoise mods to the ide driver. they wouldnt be accessing the flash as an IDE device would they?
-
So any ideas on how to dump data from them with the mtd ??
iff you have the driver there, you would be able to use dd to dump /dev/mtdblock/N where N is a number
to flash I think you need the mtd command, but not quite sure... what shell does it have? ash? bash? could try $(($var + 1)) if it's ash
I need to get power to my phatbox so I can play with this, I have a new car w/o interface to it until I get one made and I've been a bit busy
Sam
-
AFAIK its just sh thats linked.. however the busybox docs show that you can run /bin/busybox ash to get it to behave as another shell type.
also it should allow us to do busybox expr ... but they may not have compiled everything into it.
-
AFAIK its just sh thats linked.. however the busybox docs show that you can run /bin/busybox ash to get it to behave as another shell type.
also it should allow us to do busybox expr ... but they may not have compiled everything into it.
busybox runs as a specific type of shell, often ash in imbedded devices. When you compile it you select the default shell, and can enable other shells... bash and ash actually both accept that syntax so there's a good chance it would work
sh will == the default shell
Sam
-
Hey I got an idea. could someone try building a new hdparm exe for me? I need it to return a specific serial number. I have two DMS drives here and I want to see if I can move one onto the other.
The first thing to do would be to see if we can use the plsign method to sign a changed hdparm (like a new build or something that -Q returns this
PhatNoise DMS 10GB X1EXXXXXX where the XXXXXX is my drive ID.. then I'll copy my magic sectors onto another drive and see if that works.
OR, could someone write a shell script that returns that EXACT data, including spaces exactly? then sign it with plsign and perhaps we can replace hdparm.
hmmm
if you can sign it I'll send you a copy of the txt file with the serial number I need.
-
Gonna try to reply to several messages here:
Re: MEMCFG
See EP7312 user's guide page 8-3.
0x00000080 = set CLKENB bit for nCS0 (which is in fact the rom chip). This controls some timing stuff.
MEMCFG2 isn't much more interesting, but you can check the details in the manual.
Re: Kernel config
Here's the config file for the kernel, straight from PhatNoise: (rather, here's only the lines that are set to 'y')
CONFIG_ARM=y
CONFIG_UID16=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_EXPERIMENTAL=y
CONFIG_LOLAT=y
CONFIG_ARCH_CLPS711X=y
CONFIG_ARCH_PHATNOISE=y
CONFIG_ARCH_PHATNOISE11=y
CONFIG_ARCH_EP7212=y
CONFIG_ARCH_EP7312=y
CONFIG_ARCH_EDB7211=y
CONFIG_ARCH_EP7211=y
CONFIG_CPU_32=y
CONFIG_CPU_32v4=y
CONFIG_CPU_ARM720T=y
CONFIG_DISCONTIGMEM=y
CONFIG_PREEMPT=y
CONFIG_ISA=y
CONFIG_NET=y
CONFIG_SYSVIPC=y
CONFIG_SYSCTL=y
CONFIG_FPE_FASTFPE=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_UNIX=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_AUDIO_EP7x12=y
CONFIG_SERIAL_CLPS711X=y
CONFIG_SERIAL_CLPS711X_CONSOLE=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_FAT_FS=y
CONFIG_VFAT_FS=y
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_ISO8859_1=y
CONFIG_CIRRUS_DAI=y
CONFIG_PHATNOISE_BOARD=y
CONFIG_DEBUG_USER=y
MTD would require at LEAST CONFIG_MTD=y. Also, like I said ... the version of MTD in that kernel does not support the ST Micro flash chip on the board. The necessary file would be linux/drivers/mtd/chips/cfi_cmdset_0020.c (because 0x20 is the manufacturer code for ST Micro.) This code was first written in June, 2002:
* 06/21/2002 Joern Engel <joern@wh.fh-wedel.de> and others
15 * - modified Intel Command Set 0x0001 to support ST Advanced Architecture
16 * (command set 0x0020)
... which is, unfortunately, a couple months after 2.4.18 was released.
(No, I don't know why aadec refers to it. See my next post...)
Re: BL 0xFFFF.... calls in rom_mirror.bin
Unfortunately, and it breaks my heart to say this, it looks like that dump is mainly pieces of busybox that just happened to be mapped into that address space. I say this based on:
* Strings in that dump
* The presence of linux syscalls (ie STI 0x9000000E etc)
* Those 0xFFFF.... calls. BL's operand is relative -- ie, it specifies "jump forward [or backward] by x words". 0xFFFF.... indicates a negative / backward jump -- the reason that the disassembler is not properly decoding this is because the destination of the jumps is before the start of that dump. That took me quite a while to puzzle out :(
and judb, I will try to locate the source for that version of hdparm, if you want to pm me the info.
For a little bit of better news, check my new thread...
-b
PS - I just wanted to say this -- thank you all for the most interesting and engaging conversation I've had online in at least the past couple of years. Seriously. Go PhatHax0rz! ;)
-
it may have been lost above but I changed my mind about the MTD.. i think thats code for the Keg2.0 / GM phatbox 2.0 ...
I think those devices are part of the IDE driver from the dmesg code I posted above.
-
okay well hdparm can be replaced by a shell script that echos the drive serial number info. I am going to test swapping a drive with another serial number and see if that works.
-
Has anyone tried using plsign to make a new rc.sh ?
Or how about modifying the ramdisk and resigning it? that might work.
-
Okay that didnt work, the bootloader is checking the serial number against something in the private magic section of the drive, but we already knew that.
Hmm... Doh! keep on trying...
-
With all the disassembly and other stuff going on I'm curious to know if anyone has looked at earlier versions of the software, at least versions that come with the drive key check? It stands to reason that the earlier versions might be less secure. Also, some of the programs are much smaller so disection might be easier.