SPIN: 1 - PhatBox: 0 (PhatBox Successfully Owned)

[judb]

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.

Code: [Select]


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)


Code: [Select]


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)


[bushing]

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

[judb]

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?

[sbingner]

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?

Code: [Select]


#!/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....

[bushing]

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

[spin]

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...

[judb]

Code: [Select]

#!/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

Code: [Select]


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

[RobM]

Try replacing the "let"s with:

max=`expr 1024 \* 2`

and:

i=`expr $i + 1`

[judb]

is expr a shell built in?  that command doesnt exist in the ramdisk as far as I can tell.

[RobM]

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.

[judb]

that might work.  lets try that.  how big is it? Can you email it to me at jud dot barron at gmail dot com

[RobM]

Erm, it appears the one I have is dynamically linked.  I'll have to put together a static one when I get a chance.

[Matt Dralle]

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

[judb]

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/

[judb]

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?

[judb]

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?

[Matt Dralle]

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

[bushing]

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

[judb]

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!

[judb]

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.

Code: [Select]


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