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

[RobM]

I think phatsock is the IPC between 51d and phatd.

[judb]

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?

[judb]

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

Code: [Select]

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

Code: [Select]

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

[RobM]

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.

[judb]

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?  

[sbingner]

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

[judb]

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.  

[sbingner]

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

[judb]

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

Code: [Select]

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.

[bushing]

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')

Code: [Select]


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:

Code: [Select]


* 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!

[judb]

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.

[judb]

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.

[judb]

Has anyone tried using plsign to make a new rc.sh ?

Or how about modifying the ramdisk and resigning it? that might work.

[judb]

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

[A543]

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.