| View previous topic :: View next topic |
| Author |
Message |
codes02
Joined: 08 Oct 2006
Posts: 12
|
 Posted: Thu Jan 03, 2008 12:43 pm Post subject: Libertas/WLAN hacking as done in DA's MacSpoofer |
 |
|
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? |
|
| Back to top |
|
 |
Art
Joined: 09 Nov 2005
Posts: 647
|
| Posted: Thu Jan 03, 2008 12:52 pm Post subject: |
|
|
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.
_________________
If not actually, then potentially. |
|
| Back to top |
|
|
jimparis
Joined: 10 Jun 2005
Posts: 1179
Location: Boston
|
| Posted: Thu Jan 03, 2008 2:36 pm Post subject: |
|
|
| 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.. |
|
| Back to top |
|
|
danzel
Joined: 04 Nov 2005
Posts: 182
|
| Posted: Thu Jan 03, 2008 6:42 pm Post subject: |
|
|
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_Tourrilhes/Linux/Linux.Wireless.drivers.802.11ag.html#Libertas
Code:
http://lxr.linux.no/linux/drivers/net/wireless/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: | linux/drivers/net/wireless/libertas/hostcmd.h:
struct cmd_ds_get_hw_spec
==
macspoofer.zip/src/macspoofer/libertas.h:
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 |
|
| Back to top |
|
|
moonlight
Joined: 26 Oct 2005
Posts: 567
|
| Posted: Thu Jan 03, 2008 8:06 pm Post subject: |
|
|
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/Firmware-Spec-v5.1-MV-S103752-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. |
|
| Back to top |
|
|
danzel
Joined: 04 Nov 2005
Posts: 182
|
| Posted: Fri Jan 04, 2008 4:13 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
adrahil
Joined: 16 Mar 2006
Posts: 277
|
| Posted: Sat Jan 05, 2008 9:26 am Post subject: |
|
|
| Before anyone starts asking/begging, NO it is NOT POSSIBLE to get the PSP into a promiscuous (monitor) mode with the Marvell commands. :) |
|
| Back to top |
|
|
codes02
Joined: 08 Oct 2006
Posts: 12
|
| Posted: Sun Jan 06, 2008 12:29 pm Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
adrahil
Joined: 16 Mar 2006
Posts: 277
|
| Posted: Sun Jan 06, 2008 10:08 pm Post subject: |
|
|
| 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... |
|
| Back to top |
|
|
digihoe
Joined: 14 May 2005
Posts: 108
|
| Posted: Mon Jan 07, 2008 2:31 am Post subject: |
|
|
What about 54g mode then...? This would be the ultimate BIOS hack...
Best regards! |
|
| Back to top |
|
|
KickinAezz
Joined: 03 Jun 2007
Posts: 328
|
| Posted: Mon Jan 07, 2008 3:04 am Post subject: |
|
|
| 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]
_________________
Intrigued by PSP system Since December 2006.
Use it more for Development than for Gaming. |
|
| Back to top |
|
|
KickinAezz
Joined: 03 Jun 2007
Posts: 328
|
| Posted: Mon Jan 07, 2008 3:18 am Post subject: |
|
|
Update: Marvell chips DO support 54g.
_________________
Intrigued by PSP system Since December 2006.
Use it more for Development than for Gaming. |
|
| Back to top |
|
|
moonlight
Joined: 26 Oct 2005
Posts: 567
|
| Posted: Mon Jan 07, 2008 6:05 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
noquarter
Joined: 23 Jul 2006
Posts: 17
|
| Posted: Mon Jan 07, 2008 6:53 am Post subject: |
|
|
Thanks for the spoofer moonlight :)
Just a quick question,is it possible to make the psp look like another OS to the router? |
|
| Back to top |
|
|
KickinAezz
Joined: 03 Jun 2007
Posts: 328
|
| Posted: Mon Jan 07, 2008 11:17 am Post subject: |
|
|
| 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?
_________________
Intrigued by PSP system Since December 2006.
Use it more for Development than for Gaming. |
|
| Back to top |
|
|
Art
Joined: 09 Nov 2005
Posts: 647
|
| Posted: Mon Jan 07, 2008 11:27 am Post subject: |
|
|
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?
_________________
If not actually, then potentially. |
|
| Back to top |
|
|
moonlight
Joined: 26 Oct 2005
Posts: 567
|
| Posted: Mon Jan 07, 2008 6:13 pm Post subject: |
|
|
| 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 ;) |
|
| Back to top |
|
|
xcript
Joined: 23 Feb 2007
Posts: 1
|
| Posted: Mon Jan 07, 2008 6:13 pm Post subject: |
|
|
| 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. ;) |
|
| Back to top |
|
|
Art
Joined: 09 Nov 2005
Posts: 647
|
| Posted: Tue Jan 08, 2008 3:38 am Post subject: |
|
|
Hehe.. I really forgot about the PC altogether,
I'll have to carry around my coal fired generator :D
_________________
If not actually, then potentially. |
|
| Back to top |
|
|
crazyc
Joined: 17 Jun 2005
Posts: 410
|
| Posted: Tue Jan 08, 2008 7:44 am Post subject: |
|
|
| Quote: | 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. |
|
| Back to top |
|
|
adrahil
Joined: 16 Mar 2006
Posts: 277
|
| Posted: Tue Jan 08, 2008 9:48 am Post subject: |
|
|
| crazyc wrote: | | Quote: | 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: | 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 ;) |
|
| Back to top |
|
|
crazyc
Joined: 17 Jun 2005
Posts: 410
|
| Posted: Wed Jan 09, 2008 12:58 am Post subject: |
|
|
| 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: | 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. |
|
| Back to top |
|
|
adrahil
Joined: 16 Mar 2006
Posts: 277
|
| Posted: Wed Jan 09, 2008 10:15 am Post subject: |
|
|
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 :) |
|
| Back to top |
|
|
crazyc
Joined: 17 Jun 2005
Posts: 410
|
| Posted: Wed Jan 09, 2008 2:13 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
adrahil
Joined: 16 Mar 2006
Posts: 277
|
| Posted: Wed Jan 09, 2008 8:21 pm Post subject: |
|
|
| 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... |
|
| Back to top |
|
|
Jim
Joined: 02 Jul 2005
Posts: 487
Location: Sydney
|
| Posted: Wed Jan 09, 2008 8:41 pm Post subject: |
|
|
It's not a bad abstraction - store = xmit, retrieve = recv, etc. etc.
A bit peculiar though.
Jim
_________________
http://www.dbfinteractive.com |
|
| Back to top |
|
|
adrahil
Joined: 16 Mar 2006
Posts: 277
|
| Posted: Wed Jan 09, 2008 10:27 pm Post subject: |
|
|
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: | int _sceWlanHWInit(SceWlanHal* hal){
int e_status = 0;
if (hal->unk0&1 == 0){
sceSysregMsifResetEnable(1);
sceSysregMsifIoDisable(1);
sceSysregMsifClkDisable(1);
sceSysregMsifBusClockDisable(1);
sceSysregMsifClkSelect(1, 0);
sceSysregMsifDelaySelect(1, 4);
sceSysregMsifResetDisable(1);
if (hal->unk0&1 == 0){
sceSysconCtrlWlanPower(1);
sceKernelDelayThread(0x4E20);
hal->unk0 = hal->unk0 | 1;
}
} else {
_sceWlanCleanupHalBindings(hal);
sceSysregMsifResetEnable(1);
sceSysregMsifIoDisable(1);
sceSysregMsifClkDisable(1);
sceSysregMsifBusClockDisable(1);
sceSysregMsifClkSelect(1, 0);
sceSysregMsifDelaySelect(1, 4);
sceSysregMsifResetDisable(1);
}
sceSysconResetDevice(4,1);
sceKernelDelayThread(0x186a0);
sceSysconResetDevice(4, 0);
sceKernelDisableIntr(8);
sceSysregMsifResetEnable(1);
sceSysregMsifClkSelect(1, 0);
sceSysregMsifDelaySelect(1, 4);
sceSysregMsifBusClockEnable(1);
sceSysregMsifClkEnable(1);
sceSysregMsifIoEnable(1);
sceSysregMsifResetDisable(1);
old_intr = sceKernelCpuSuspendIntr();
*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(old_intr);
sceKernelRegisterIntrHandler(8, 2, _sceWlanIntrHandler, hal, 0x000193F4);
sceKernelRegisterSubIntrHandler(8, 0, _sceWlanSubIntrHandler, hal);
sceKernelEnableIntr(8);
sceKernelEnableSubIntr(8, 0);
sceKernelClearEventFlag(hal->ev_flag, 0);
sceKernelCancelSema(hal->mshostlocksema, 1, 0);
ret = sub_0000B53C(hal);
if (ret < 0){
_sceWlanHWDeinit(hal);
return -1;
}
ret = _sceWlanHalStartThread(hal, 0x27, 0x8000);
if (ret < 0){
_sceWlanHWDeinit(hal);
return -1;
}
sceKernelWaitEventFlag(hal->mshostlockflag, 3, 0x11, &e_status, 0);
if (e_status & 2){
_sceWlanHWDeinit(hal);
return -1;
}
return 0;
} |
|
|
| Back to top |
|
|
crazyc
Joined: 17 Jun 2005
Posts: 410
|
| Posted: Wed Jan 09, 2008 11:48 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
adrahil
Joined: 16 Mar 2006
Posts: 277
|
| Posted: Thu Jan 10, 2008 6:52 am Post subject: |
|
|
| 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) |
|
| Back to top |
|
|
KickinAezz
Joined: 03 Jun 2007
Posts: 328
|
| Posted: Thu Jan 10, 2008 7:52 am Post subject: |
|
|
| 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.
_________________
Intrigued by PSP system Since December 2006.
Use it more for Development than for Gaming. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
