Libertas/WLAN hacking as done in DA's MacSpoofer

codes02 · Post by **codes02** » Thu Jan 03, 2008 12:43 pm

Looking at the source code to the Mac Spoofer, it appears that there is now some understanding of the inner workings of the psp's wlan driver.

But on looking further, no explanation of this new information was offered, though it appears to be quite interesting.

Does anyone have an explanation/commented code/documentation that would make everyones understanding better?

Art · Post by **Art** » Thu Jan 03, 2008 12:52 pm

The MAC address displayed in System Settings is easily changed
in flash, but that doesn't change the MAC address on the wifi card.
Are you sure you're not getting the two mixed up?

I have mine set to all zeros, but it won't be identified by a router that way.
Art.

jimparis · Post by **jimparis** » Thu Jan 03, 2008 2:36 pm

Art, he's referring to DA's mac spoofer, which does change the MAC address on the wifi card. DA might have some info for us..

danzel · Post by **danzel** » Thu Jan 03, 2008 6:42 pm

Just done a bit of investigation into this myself.

Recently linux got a libertas driver (required for the OLPC project)
Background:
http://www.hpl.hp.com/personal/Jean_Tou ... l#Libertas
Code:
http://lxr.linux.no/linux/drivers/net/w ... /libertas/

It looks like DA may of based his code on what he has reverse engineered (to send the commands) and the linux headers for the libertas driver.

Code: Select all

linux/drivers/net/wireless/libertas/hostcmd.h&#58;
struct cmd_ds_get_hw_spec
==
macspoofer.zip/src/macspoofer/libertas.h&#58;
struct LIBERTAS_GET_HW_SPEC_COMMAND

#defines in libertas.h are in linux/drivers/net/wireless/libertas/host.h

Hopefully DA will come fill us in :-)

Needless to say, I expect the psp linux port to get wifi support at some stage :D

moonlight · Post by **moonlight** » Thu Jan 03, 2008 8:06 pm

There are some open source driver for linux, for similar cards. However the card of the psp seems worse, it doesn't support all commands, and there are some unknown commands that the psp driver sends to the card that are not documented anywhere, with the slim having one not implemented in the fat. There is also some difference like the associate command ID.

Here is some doc, but not all info can be applied to the psp card.
http://wiki.laptop.org/images/f/f3/Firm ... 752-00.pdf

Don't worry about the word "Confidential", it was supossed to be given to the OLPC project by Marvell.
There is some more info in the OLPC wiki, although that info is mostly referred to the card that is(or will be) used in that laptop, the 88W8388.

The firmwares used in the psp are in wlanfirm_magpie and voyager prx's, for fat and slim respectively and they are downloaded to the card in each boot.
Before the slim, the firmwares were embedded in the own wlan.prx.
They are in plain text, in the same helper/main format described in http://wiki.laptop.org/go/88W8388

I've reached to the conclusion that nothing interesting can be done hacking the driver, but maybe hacking the bios.
Note that for a real linux (not running inside sce firmware) to have a wifi driver, it would be needed to include the wlan firmware, which is illegal to redistribute, unless the firmware is reversed too.

In 3.71, the SendCommand function is located at address (text_addr+0xF8D0). Commands arrive to this function with endianess reversed. Some unknown data is also sent to this function, not only the commands.
The ReceiveCommand functions is located at address (text_addr+0xF9E4). After the call to this function, the data is already in little endian.
You cannot call these two functions directly without caussing a mess in the driver. To test different commands, I was just changing the ones the driver was sending.

danzel · Post by **danzel** » Fri Jan 04, 2008 4:13 pm

Thanks for the info moonlight.

A full Linux could probably extract the firmware from the relevent prx when installed on the PSP.
For a start, using the SCE firmware to load the firmware should be fine however.

adrahil · Post by **adrahil** » Sat Jan 05, 2008 9:26 am

Before anyone starts asking/begging, NO it is NOT POSSIBLE to get the PSP into a promiscuous (monitor) mode with the Marvell commands. :)

codes02 · Post by **codes02** » Sun Jan 06, 2008 12:29 pm

adrahil wrote:Before anyone starts asking/begging, NO it is NOT POSSIBLE to get the PSP into a promiscuous (monitor) mode with the Marvell commands. :)

Then I'm guessing you've tried already? :-P

adrahil · Post by **adrahil** » Sun Jan 06, 2008 10:08 pm

Yeah, we looked into it with D_A, and the reason is what he told before ;) The marvell firmware used in the PSP's chip is limited...

digihoe · Post by **digihoe** » Mon Jan 07, 2008 2:31 am

What about 54g mode then...? This would be the ultimate BIOS hack...

Best regards!

KickinAezz · Post by **KickinAezz** » Mon Jan 07, 2008 3:04 am

digihoe wrote:What about 54g mode then...? This would be the ultimate BIOS hack...

Best regards!

Yeah. I'm intrested too.

My speculation is Sony capped the hardware to 802.11b Specification VIA SOFTWARE, but hardware still supports 54g aka 802.11g

The reason is the Poor PSP battery life. :D

54mbps vs 11mbps; the difference is mindblowing!

Could all Masterminds kindly look into it? [I wouldnt mind if 3.80 M33 is delayed by a month]

KickinAezz · Post by **KickinAezz** » Mon Jan 07, 2008 3:18 am

Update: Marvell chips DO support 54g.

moonlight · Post by **moonlight** » Mon Jan 07, 2008 6:05 am

The chip of the slim is supossed to be the same one of iphone and some other gadget, that supports 802.11g, but you never know if it is capped via hardware.

Anyways the things I've tried hacking the driver didn't have success, that's why I said it is really the chip firmware what has to be looked.

noquarter · Post by **noquarter** » Mon Jan 07, 2008 6:53 am

Thanks for the spoofer moonlight :)
Just a quick question,is it possible to make the psp look like another OS to the router?

KickinAezz · Post by **KickinAezz** » Mon Jan 07, 2008 11:17 am

moonlight wrote: I've tried hacking the driver didn't have success, that's why I said it is really the chip firmware what has to be looked.

It's currently going on right? Hope so!

1 more question: How can we Kno via software if our WLAN module uses the FW magpie or voyager?

Art · Post by **Art** » Mon Jan 07, 2008 11:27 am

Nice job, I'll have to trust ya.. still too scared to upgrade.

I don't understand how it will bypass MAC filtering of your Neighbour's
router as the readme says would be possible (in theory of course).
Unless it is specific MACs filtered out by the router, rather than only certain MACs allowed.
Otherwise it's an very long bruit force to stumble a correct MAC is it not?

moonlight · Post by **moonlight** » Mon Jan 07, 2008 6:13 pm

KickinAez wrote: 1 more question: How can we Kno via software if our WLAN module uses the FW magpie or voyager?

Atm, all fat's psp use the magpie, and all slim use voyager, so you can just use the sceKernelGetModel/kuKernelGetModel.
The proper way is to check the idstorage key 0x45, which has the hw revision, and it is what wlan.prx actually does.

Art wrote:Nice job, I'll have to trust ya.. still too scared to upgrade.

I don't understand how it will bypass MAC filtering of your Neighbour's
router as the readme says would be possible (in theory of course).
Unless it is specific MACs filtered out by the router, rather than only certain MACs allowed.
Otherwise it's an very long bruit force to stumble a correct MAC is it not?

Well, if you run airodump on the computer, you'll know which mac to use to bypass the filter ;)

xcript · Post by **xcript** » Mon Jan 07, 2008 6:13 pm

Art wrote: I don't understand how it will bypass MAC filtering of your Neighbour's
router as the readme says would be possible (in theory of course).
Unless it is specific MACs filtered out by the router, rather than only certain MACs allowed.
Otherwise it's an very long bruit force to stumble a correct MAC is it not?

You can obtain the MAC address of a legitimately associated client easily with utilities like kismet, airodump.

Edit: Oops, moonlight beat me to it. ;)

Art · Post by **Art** » Tue Jan 08, 2008 3:38 am

Hehe.. I really forgot about the PC altogether,
I'll have to carry around my coal fired generator :D

crazyc · Post by **crazyc** » Tue Jan 08, 2008 7:44 am

In 3.71, the SendCommand function is located at address (text_addr+0xF8D0). Commands arrive to this function with endianess reversed. Some unknown data is also sent to this function, not only the commands.
The ReceiveCommand functions is located at address (text_addr+0xF9E4). After the call to this function, the data is already in little endian.
You cannot call these two functions directly without caussing a mess in the driver. To test different commands, I was just changing the ones the driver was sending.

Calling unexported functions within the driver directly is one thing, but have you figured out how to send command directly to the hardware? Given that most of the work has already been done in the memstk.c code, it shouldn't be that hard.

adrahil · Post by **adrahil** » Tue Jan 08, 2008 9:48 am

crazyc wrote:
In 3.71, the SendCommand function is located at address (text_addr+0xF8D0). Commands arrive to this function with endianess reversed. Some unknown data is also sent to this function, not only the commands.
The ReceiveCommand functions is located at address (text_addr+0xF9E4). After the call to this function, the data is already in little endian.
You cannot call these two functions directly without caussing a mess in the driver. To test different commands, I was just changing the ones the driver was sending.
Calling unexported functions within the driver directly is one thing, but have you figured out how to send command directly to the hardware? Given that most of the work has already been done in the memstk.c code, it shouldn't be that hard.

It's not possible at the moment for three main reasons:
- Using HW directly would interfere with wlan.prx intr handlers, spinlocks,...
- We still need to load magpie/voyager FW from PRXs.
- It does not share the memory stick interface register-wise... For instance, here are all the WLAN registers (from SceWlanHalStruct definition in wlan.prx):

Code: Select all

  hal->reg01 = 0xBD300000;
  hal->reg02 = 0xBD300030;
  hal->reg03 = 0xBD300034;
  hal->reg04 = 0xBD300038;
  hal->reg05 = 0xBD30003C;
  hal->reg06 = 0xBD300040;
  hal->reg07 = 0xBD300002;
  hal->reg08 = 0xBD300000;
  hal->reg09 = 0xBD300004;
  hal->reg10 = 0xBD300008;
  hal->reg11 = 0xBD30000C;
  hal->reg12 = 0xBD300010;
  hal->reg13 = 0xBD300012;
  hal->reg14 = 0xBD300014;
  hal->reg15 = 0xBD300016;
  hal->reg16 = 0xBD300018;
  hal->reg17 = 0xBD30001A;
  hal->reg18 = 0xBD30001C;
  hal->reg19 = 0xBD300020;
  hal->reg20 = 0xBD300024;
  hal->reg21 = 0xBD300028;

As you can see, there is a load of them :) The fact that wlan.prx is written in some cryptic HAL-enabled way doesn't help solve the understanding problems either ;)

crazyc · Post by **crazyc** » Wed Jan 09, 2008 12:58 am

adrahil wrote:It's not possible at the moment for three main reasons:
- Using HW directly would interfere with wlan.prx intr handlers, spinlocks,...

I'm thinking more of a linux driver, but disabling the wlan interrupt and if the uid for the SceWlanHalMsHostLock sema can be found waiting on it could be enough.

adrahil wrote:- It does not share the memory stick interface register-wise...

I'm quite sure it does. Hopefully this works for others, paste these commands into a terminal running psplink:

Code: Select all

memprot off
thsusp @SceWlanMac
thsusp @SceWlanHal

pokew 0xbd300030 0x9007
peekw 0xbd300038
pokew 0xbd300034 0x001000b4
peekw 0xbd300038
pokew 0xbd300034 0x100
peekw 0xbd300038

pokew 0xbd300030 0xa010
peekw 0xbd300038
pokew 0xbd300034 0x4d001000
peekw 0xbd300038
pokew 0xbd300034 0
peekw 0xbd300038
pokew 0xbd300034 0
peekw 0xbd300038
pokew 0xbd300034 0
peekw 0xbd300038

pokew 0xbd300030 0x7001
peekw 0xbd300038
peekw 0xbd300034
peekw 0xbd300034

pokew 0xbd300030 0x9007
peekw 0xbd300038
pokew 0xbd300034 0x001000b3
peekw 0xbd300038
pokew 0xbd300034 0x100
peekw 0xbd300038

pokew 0xbd300030 0x5010
peekw 0xbd300034
peekw 0xbd300034
peekw 0xbd300034
peekw 0xbd300034

thresm @SceWlanMac
thresm @SceWlanHal

paying close attention to the output from the last four peeks. I haven't been able to get the C code working yet because of timing issues, but I don't really care that much because I'm really trying to get something like this running on it.

adrahil · Post by **adrahil** » Wed Jan 09, 2008 10:15 am

Very funky :)
I wouldn't have imagined that both devices would share the same interface... However, how come they don't collide? i-e, why is the downloading speed still not bad? They might share some of the same IO channels, some are probably dedicated to the WiFi chip... There is much research to do :)

crazyc · Post by **crazyc** » Wed Jan 09, 2008 2:13 pm

adrahil wrote:Very funky :)
I wouldn't have imagined that both devices would share the same interface... However, how come they don't collide? i-e, why is the downloading speed still not bad? They might share some of the same IO channels, some are probably dedicated to the WiFi chip... There is much research to do :)

I doubt they share the same IO channels. There are probably two identical but completely separate memory stick host controllers, one connected to the memory stick and mapped at 0xbd20xxxx and the other to the wlan chip mapped at 0xbd30xxxx. If the DMA controller is figured out, that would probably give the definitive answers.

adrahil · Post by **adrahil** » Wed Jan 09, 2008 8:21 pm

But why would there be a memory stick host controller connected to the WLAN chip? It seems strange :) I will look deeper into wlan.prx and I think that the registers 30/34/38 aren't used as much as others...

Jim · Post by **Jim** » Wed Jan 09, 2008 8:41 pm

It's not a bad abstraction - store = xmit, retrieve = recv, etc. etc.
A bit peculiar though.

Jim

adrahil · Post by **adrahil** » Wed Jan 09, 2008 10:27 pm

Well, I think that if they wanted abstraction, they'd use an I2C bus to control it... Memory stick TPC (commands) are notoriously painful to use, with a really painful protocol... I don't think that it makes things "easy" :s

@crazyc
You were right, I didn't notice anything sometime ago, but now that I look through my reverses, there indeed are a lot of references to the memory stick interface, such as the hardware initialization:

Code: Select all

int _sceWlanHWInit&#40;SceWlanHal* hal&#41;&#123;
  int e_status = 0;

  if &#40;hal->unk0&1 == 0&#41;&#123;
    sceSysregMsifResetEnable&#40;1&#41;;
    sceSysregMsifIoDisable&#40;1&#41;;
    sceSysregMsifClkDisable&#40;1&#41;;
    sceSysregMsifBusClockDisable&#40;1&#41;;
    sceSysregMsifClkSelect&#40;1, 0&#41;;
    sceSysregMsifDelaySelect&#40;1, 4&#41;;
    sceSysregMsifResetDisable&#40;1&#41;;
    if &#40;hal->unk0&1 == 0&#41;&#123;
      sceSysconCtrlWlanPower&#40;1&#41;;
      sceKernelDelayThread&#40;0x4E20&#41;;
      hal->unk0 = hal->unk0 | 1;
    &#125;
  &#125; else &#123;
    _sceWlanCleanupHalBindings&#40;hal&#41;;
    sceSysregMsifResetEnable&#40;1&#41;;
    sceSysregMsifIoDisable&#40;1&#41;;
    sceSysregMsifClkDisable&#40;1&#41;;
    sceSysregMsifBusClockDisable&#40;1&#41;;
    sceSysregMsifClkSelect&#40;1, 0&#41;;
    sceSysregMsifDelaySelect&#40;1, 4&#41;;
    sceSysregMsifResetDisable&#40;1&#41;;
  &#125;

  sceSysconResetDevice&#40;4,1&#41;;
  sceKernelDelayThread&#40;0x186a0&#41;;
  sceSysconResetDevice&#40;4, 0&#41;;
  sceKernelDisableIntr&#40;8&#41;;
  sceSysregMsifResetEnable&#40;1&#41;;
  sceSysregMsifClkSelect&#40;1, 0&#41;;
  sceSysregMsifDelaySelect&#40;1, 4&#41;;
  sceSysregMsifBusClockEnable&#40;1&#41;;
  sceSysregMsifClkEnable&#40;1&#41;;
  sceSysregMsifIoEnable&#40;1&#41;;
  sceSysregMsifResetDisable&#40;1&#41;;

  old_intr = sceKernelCpuSuspendIntr&#40;&#41;;
  *hal->reg05 = *hal->reg05 | 0x2020;
  *hal->reg06 = *hal->reg06 | 0x10000;
  hal->unk8  = hal->unk8  | 0x4;
  *hal->reg06 = *hal->reg06 | 0x20;
  hal->unk8  = hal->unk8  | 0x8;
  *hal->reg06 = *hal->reg06 | 0x400;
  sceKernelCpuResumeIntrWithSync&#40;old_intr&#41;;

  sceKernelRegisterIntrHandler&#40;8, 2, _sceWlanIntrHandler, hal, 0x000193F4&#41;;
  sceKernelRegisterSubIntrHandler&#40;8, 0, _sceWlanSubIntrHandler, hal&#41;;
  sceKernelEnableIntr&#40;8&#41;;
  sceKernelEnableSubIntr&#40;8, 0&#41;;
  sceKernelClearEventFlag&#40;hal->ev_flag, 0&#41;;
  sceKernelCancelSema&#40;hal->mshostlocksema, 1, 0&#41;;

  ret = sub_0000B53C&#40;hal&#41;;
  if &#40;ret < 0&#41;&#123;
    _sceWlanHWDeinit&#40;hal&#41;;
    return -1;
  &#125;

  ret = _sceWlanHalStartThread&#40;hal, 0x27, 0x8000&#41;;
  if &#40;ret < 0&#41;&#123;
    _sceWlanHWDeinit&#40;hal&#41;;
    return -1;
  &#125;

  sceKernelWaitEventFlag&#40;hal->mshostlockflag, 3, 0x11, &e_status, 0&#41;;
  if &#40;e_status & 2&#41;&#123;
    _sceWlanHWDeinit&#40;hal&#41;;
    return -1;
  &#125;

  return 0;
&#125;

crazyc · Post by **crazyc** » Wed Jan 09, 2008 11:48 pm

adrahil wrote:But why would there be a memory stick host controller connected to the WLAN chip? It seems strange :) I will look deeper into wlan.prx and I think that the registers 30/34/38 aren't used as much as others...

Take a look at this. It's the memory stick equivalent of SDIO. Unfortunately, the documentation is redacted, but I assume TPC_READ_IO_DATA is 0x5, TPC_WRITE_IO_DATA is is 0xa, CMD_IN_IO_DATA is 0xb3 and CMD_OUT_IO_DATA is 0xb4. Possibly, CMD_IN_IO_FIFO is 0xb2.

adrahil · Post by **adrahil** » Thu Jan 10, 2008 6:52 am

Damn, sony are so lazy :) Well, good for us, I guess... Thanks for the insight on this! I guess I will have to experiment with different commands and especially look at sceWlanSetFirm, as it writes to the Marvell chip's memory... (We might be able to modify the stuff in there then)

KickinAezz · Post by **KickinAezz** » Thu Jan 10, 2008 7:52 am

adrahil wrote:Damn, sony are so lazy :) Well, good for us, I guess... Thanks for the insight on this! I guess I will have to experiment with different commands and especially look at sceWlanSetFirm, as it writes to the Marvell chip's memory... (We might be able to modify the stuff in there then)

Very nice. Looking forward for jaw-dropping hacks and for my request a few posts above.