Feature #4574
openFemtocell choice in 2020/06
Added by copslock about 4 years ago. Updated 5 months ago.
0%
Description
Recently the AT&T had shutdown its UMTS femto system,thus,result in the Cisco femtocells that operated in their network are widely available on eBay or Amazon platform,it turned out to be the DPH-151/153/154 microcell,But as the Harald noticed,these units are communicated through the Cisco URSL protocal,which is the evolution of the current 2G RSL signaling,and possible someone can add UMTS patch to it.So far it's the best available femtocell rather than the ip.access one.
Files
Updated by laforge about 4 years ago
AFAICT, URSL was originally developed by ip.access for the early version of their "oyster3g" femtocells. Cisco had later acquired/licensed that from ip.access. At least for the ip.access oyster3g, only early firmware versions were USRL, later on they moved to standard Iuh. maybe the same is true for the cisco devices you are looking at?
In any case, USRL is a completely different protocol, so if you wanted to support it, you would have to write a IuCS+IuPS to USRL converter. Given that URSL uses no RANAP, this is likely a much more complex task than the comparatively simple osmo-hnbgw.
Updated by copslock about 4 years ago
- File brkagg-2002 .pdf brkagg-2002 .pdf added
laforge wrote:
AFAICT, URSL was originally developed by ip.access for the early version of their "oyster3g" femtocells. Cisco had later acquired/licensed that from ip.access. At least for the ip.access oyster3g, only early firmware versions were USRL, later on they moved to standard Iuh. maybe the same is true for the cisco devices you are looking at?
In any case, USRL is a completely different protocol, so if you wanted to support it, you would have to write a IuCS+IuPS to USRL converter. Given that URSL uses no RANAP, this is likely a much more complex task than the comparatively simple osmo-hnbgw.
Thank you for reply,Harald,had you tried to reverse-engineering these models before?As far as I know the presentation of Cisco in 2009 showed that it used the URSL stack,but in the later the ASR5000 PPTs showed it seems like support the standard Iuh interface.But don't know whether if these femtocells using the newer Iuh interface.The AT&T may had some modification.There is only one way to verify that,I have just ordered some units from eBay to find this out,if it's based on standard IuH interface,It will be much better choice than the long-disappered ip.access nano3g femotocells.By the way,I'm thinking about the support of ethernet-CPRI RRHs which is much more widely available than the eNodeBs and very chip.don't know whether if its fast enough for x86 to process those real-time I/Q data.
Updated by laforge about 4 years ago
On Tue, Jun 02, 2020 at 02:46:49PM +0000, copslock [REDMINE] wrote:
Thank you for reply,Harald,had you tried to reverse-engineering these models before?
I once played with an Oyster3G, found out some details about URSL and then gave up, as
it's simply too far away from 3GPP stanards.
As far as I know the presentation of Cisco in 2009 showed that it used the URSL stack,but in the later the ASR5000 PPTs showed it seems like support the standard Iuh interface.But don't know whether if these femtocells using the newer Iuh interface.
I guess unless you find different software versions for your specific cell, it is impossible to know.
The AT&T may had some modification.There is only one way to verify that,I have just ordered some units from eBay to find this out,if it's based on standard IuH interface,It will be much better choice than the long-disappered ip.access nano3g femotocells.By the way,
The problem is mainly:I'm thinking about the support of ethernet-CPRI RRHs which is much
more widely available than the eNodeBs and very chip.
- you have to design build a CPRI physical interface card (FGPA, gateware, host drivers, ...)
- you have to reverse engineer the proprietary, verdor/product-specific Command+Control
don't know whether if its fast enough for x86 to process those real-time I/Q data.
For sure it is possible, look at what Amarisoft is doing. It's not open
source, but they do have CPRI interface board and complete eNB / gNB in
x86 software.
Updated by copslock about 4 years ago
laforge wrote:
On Tue, Jun 02, 2020 at 02:46:49PM +0000, copslock [REDMINE] wrote:
Thank you for reply,Harald,had you tried to reverse-engineering these models before?
I once played with an Oyster3G, found out some details about URSL and then gave up, as
it's simply too far away from 3GPP stanards.As far as I know the presentation of Cisco in 2009 showed that it used the URSL stack,but in the later the ASR5000 PPTs showed it seems like support the standard Iuh interface.But don't know whether if these femtocells using the newer Iuh interface.
I guess unless you find different software versions for your specific cell, it is impossible to know.
The AT&T may had some modification.There is only one way to verify that,I have just ordered some units from eBay to find this out,if it's based on standard IuH interface,It will be much better choice than the long-disappered ip.access nano3g femotocells.By the way,
The problem is mainly:I'm thinking about the support of ethernet-CPRI RRHs which is much
more widely available than the eNodeBs and very chip.
- you have to design build a CPRI physical interface card (FGPA, gateware, host drivers, ...)
- you have to reverse engineer the proprietary, verdor/product-specific Command+Control
don't know whether if its fast enough for x86 to process those real-time I/Q data.
For sure it is possible, look at what Amarisoft is doing. It's not open
source, but they do have CPRI interface board and complete eNB / gNB in
x86 software.
I mean some RRHs running on the ethernet interface,and possible CPRI data capsulated in ethernet frame,and can we just using the basic PC ethernet card to communicate with the RRH?I think it might have some issue like real-time I/Q data compressing because i saw FPGA-like stuff on its board,but still it at least runs on the ethernet interface
Updated by copslock about 4 years ago
laforge wrote:
On Tue, Jun 02, 2020 at 02:46:49PM +0000, copslock [REDMINE] wrote:
Thank you for reply,Harald,had you tried to reverse-engineering these models before?
I once played with an Oyster3G, found out some details about URSL and then gave up, as
it's simply too far away from 3GPP stanards.As far as I know the presentation of Cisco in 2009 showed that it used the URSL stack,but in the later the ASR5000 PPTs showed it seems like support the standard Iuh interface.But don't know whether if these femtocells using the newer Iuh interface.
I guess unless you find different software versions for your specific cell, it is impossible to know.
The AT&T may had some modification.There is only one way to verify that,I have just ordered some units from eBay to find this out,if it's based on standard IuH interface,It will be much better choice than the long-disappered ip.access nano3g femotocells.By the way,
The problem is mainly:I'm thinking about the support of ethernet-CPRI RRHs which is much
more widely available than the eNodeBs and very chip.
- you have to design build a CPRI physical interface card (FGPA, gateware, host drivers, ...)
- you have to reverse engineer the proprietary, verdor/product-specific Command+Control
don't know whether if its fast enough for x86 to process those real-time I/Q data.
For sure it is possible, look at what Amarisoft is doing. It's not open
source, but they do have CPRI interface board and complete eNB / gNB in
x86 software.
Long wait before the internation package arrive,but i found something interesting,some engs used to work with the AT&T and Cisco has described it
@Small Cell Test and Verification Engineer (contractor) for ip.access/Cisco
ip.access
Jan 2012 – Jun 2012 6 months
Redmond, WA
• Perform End2End testing of the ip.access/Cisco 3G Microcell solution in AT&T’s test bed according to the Test Object List as agreed with the customer;
• This testing was focused around HNB RAN (i.e. MM, Cell_FACH, CSG, HSPA, Admission and Power Control, Multi-RAB, Handover, etc.) and HNB-GW (IP Sec, HNBAP, RUA, HA, Iu-Flex, etc.) validation including related Statistics, KPIs and Alarms.@
What's the "Iu-Flex"???Maybe another some properitary blob again
Updated by copslock about 4 years ago
- File att_microcell.png att_microcell.png added
Long wait before the internation package arrive,but i found something interesting,some engs used to work with the AT&T and Cisco has described it
@Small Cell Test and Verification Engineer (contractor) for ip.access/Cisco
ip.access
Jan 2012 – Jun 2012 6 months
Redmond, WA
• Perform End2End testing of the ip.access/Cisco 3G Microcell solution in AT&T’s test bed according to the Test Object List as agreed with the customer;
• This testing was focused around HNB RAN (i.e. MM, Cell_FACH, CSG, HSPA, Admission and Power Control, Multi-RAB, Handover, etc.) and HNB-GW (IP Sec, HNBAP, RUA, HA, Iu-Flex, etc.) validation including related Statistics, KPIs and Alarms.@
What's the "Iu-Flex"???Maybe another some properitary blob again,why ip.access called it "Oyster 3G"
Updated by laforge about 4 years ago
On Wed, Jun 17, 2020 at 09:06:53AM +0000, copslock [REDMINE] wrote:
What's the "Iu-Flex"???
As somewhat more dynamic/flexible/scalable way of handling the Iu interface between
RNC/HNBGW and MSC/SGSN. You should find it described in 3GPP specs. Not ip.access specific
at all.
why ip.access called it "Oyster 3G"
Because of the shape of the device? The original nanoBTS for GSM were called "rugby"
Updated by Jarobar about 4 years ago
- File femto_new.jpg femto_new.jpg added
Hi
I disassembled the DPH153-AT unit. Caution the device contains anti-tampering jumpers!
I did not know about them. I can not turn it on now, otherwise the flash will be erased. Is the position of the jumpers the same for all units or is it dependent on the MAC / SN?
Would anyone be willing to tell me the correct jumpers position?
My unit is newer version.
Updated by copslock about 4 years ago
Jarobar wrote:
Hi
I disassembled the DPH153-AT unit. Caution the device contains anti-tampering jumpers!
I did not know about them. I can not turn it on now, otherwise the flash will be erased. Is the position of the jumpers the same for all units or is it dependent on the MAC / SN?
Oh my god,i guess you guys already well-acknowaged that the 151/153 have anti-tamper jumpers,i saw some tips about the jumpers before but i didnt sure whether if its random,i will take another look
Would anyone be willing to tell me the correct jumpers position?
My unit is newer version.
Updated by Jarobar about 4 years ago
- File BH_US_12_Rowley_Microcell_Bricks_WP.pdf BH_US_12_Rowley_Microcell_Bricks_WP.pdf added
- File jtagulator_DPH153.jpg jtagulator_DPH153.jpg added
Fortunately I first looked for some information about this cell before turning it on.
I spent more time looking for information about this cell. It seems to be well researched by the community.
On this web page there are anti-tamper photos from both sides of the PCB for the older version. The photo of the newer version is only on one side unfortunately.
https://rjmendez.github.io/posts/2019/02/Indeed_CTF_Embedded_2
The cell seems to consist of a router and a radio chip. Both are separate systems. Everyone has their RAM and flash. There are also some attempts to extract the firmware from the router part. The radio part is not mentioned as an extraction success. Do you have information that someone succeeded?
Updated by copslock about 4 years ago
Jarobar wrote:
Fortunately I first looked for some information about this cell before turning it on.
I spent more time looking for information about this cell. It seems to be well researched by the community.
On this web page there are anti-tamper photos from both sides of the PCB for the older version. The photo of the newer version is only on one side unfortunately.
https://rjmendez.github.io/posts/2019/02/Indeed_CTF_Embedded_2The cell seems to consist of a router and a radio chip. Both are separate systems. Everyone has their RAM and flash. There are also some attempts to extract the firmware from the router part. The radio part is not mentioned as an extraction success. Do you have information that someone succeeded?
1.someone hackday.io had informed the jumper sets https://hackaday.com/2012/04/12/poking-at-the-femtocell-hardware-in-an-att-microcell/
croze says:
October 5, 2015 at 8:36 pm
The jumper configuration on the DPH153-AT is 0=no continuity fake jumper, 1= continuity real jumper values are read from top to bottom. Front of board side with all the components jumper location near center and offset right 0,1,1. Rear of board the side with no components jumper block in the lower left hand corner 0, 0, 1. USE a VOM sort all the jumpers and plug and play. Have fun"
2.very early comment https://robotskirts.com/2009/12/02/att-3g-microcell-hacking/
RATSANDWICH says:
@robert
Microcell Tamper Switch Jumper Positions:
The current vodoo on this is here: http://i.imgur.com/S7vhi.jpg
and here: http://i.imgur.com/9LArj.jpg
DL pics. Notice the two little nipples on the real jumpers and the lack of any surface features on the others. Solder the nippy ones together and snip the others.
J16=top one real, bottom two fake
j15=top two real, bottom one fake
The idiots= what is top?
Top is where the the letters are Not upside down. That way you can read j15, j16 right side up.
3.basic guide into the DPH-151 which talks about the "Wizard" tool which gets you into the Ralink-side enviroment
https://fail0verflow.com/blog/2012/microcell-fail/
4.deeper exploration https://alexandercwatson.wordpress.com/2013/03/10/all-your-att-microcells-are-belong-to-us/
5.the rjmendez's one
The Ralink RT2150 is responsible for the IPSec negotiation and possible the TR-069 routine that controls the bootup parameters configuration,and it communicates with the Picochip through the Ethernet,you can try to dump the interfaces of the Ralink chip to monitor that,but i think that was useless.The main steps to utilize for OSMO-using are simple,first you should change the IPSec profile to make it connects to your SeGW,then you need to find some way to change the TR-069 server address then push enough parameters to make the NodeB connects to the HNBGW,then it will start broadcast
About the parameters ,you can reference to the Cisco's detailed guide about both basic and advanced parameters
https://www.cisco.com/c/en/us/td/docs/wireless/access_point/small_cell/rms/r4x/admin_guide/b_rms_admin_guide.pdf
https://www.cisco.com/c/dam/en/us/td/docs/wireless/access_point/small_cell/rms/r41/api_guide/BAC_CustomProperties_ReferenceSheet_R41.pdf
If you are quite anxious about the reverse-work,you can follow the guide that provided by RJMENDEZ which gets the dumpflash.bin,and uploads it here,I will try to do some analyse for you ahead.
Updated by copslock about 4 years ago
Jarobar wrote:
Fortunately I first looked for some information about this cell before turning it on.
I spent more time looking for information about this cell. It seems to be well researched by the community.
On this web page there are anti-tamper photos from both sides of the PCB for the older version. The photo of the newer version is only on one side unfortunately.
https://rjmendez.github.io/posts/2019/02/Indeed_CTF_Embedded_2The cell seems to consist of a router and a radio chip. Both are separate systems. Everyone has their RAM and flash. There are also some attempts to extract the firmware from the router part. The radio part is not mentioned as an extraction success. Do you have information that someone succeeded?
You should not focus on "how to hack into the Picochip",but just find the proper way to tune up the parameters,the RRC layer codes wont help you more unless you want to do some bad stuff,but thats not the goal of this project
Jarobar wrote:
Fortunately I first looked for some information about this cell before turning it on.
I spent more time looking for information about this cell. It seems to be well researched by the community.
On this web page there are anti-tamper photos from both sides of the PCB for the older version. The photo of the newer version is only on one side unfortunately.
https://rjmendez.github.io/posts/2019/02/Indeed_CTF_Embedded_2The cell seems to consist of a router and a radio chip. Both are separate systems. Everyone has their RAM and flash. There are also some attempts to extract the firmware from the router part. The radio part is not mentioned as an extraction success. Do you have information that someone succeeded?
Updated by Jarobar about 4 years ago
I bought the device on eBay. I did it without the knowledge of anti-manipulation. Now I am not sure that I will be able to connect the jumpers correctly. I just had the idea that I'd rather order a new piece. Desolder this radio flash then read the content then make it available to the community. Maybe it's just a stupid idea. Do you know that someone has already tried it?
Updated by laforge about 4 years ago
Just wanted to say I'm following this ticke with pleasure (great to see people are hacking on femtocells again!) but I don't have much to contribute. I haven't been playing with any of the devices you're looking into, sorry.
Once you get to Iuh, I'm happy to help regarding interoperability issues in osmo-iuh/msc/sgsn.
Happy hacking!
Updated by copslock about 4 years ago
Jarobar wrote:
I bought the device on eBay. I did it without the knowledge of anti-manipulation. Now I am not sure that I will be able to connect the jumpers correctly. I just had the idea that I'd rather order a new piece. Desolder this radio flash then read the content then make it available to the community. Maybe it's just a stupid idea. Do you know that someone has already tried it?
Above all are what i can find on the internets,no more deep researching about it,these guys,as Harald said,only thinking about how to lock down those devices to make it so-called "secure",but nobody cares about full reusing those hardware instead of becoming e-waste,If you think publish to the public is not suitable,you can send the files to my box
Updated by Jarobar almost 4 years ago
DPH-151 as the first
Is here somebody who can analyze this?
I hope it will be useful somehow.
Updated by Jarobar almost 4 years ago
- File Pc202-Datasheet.pdf Pc202-Datasheet.pdf added
Updated by copslock almost 4 years ago
Jarobar wrote:
DPH-151 as the first
Is here somebody who can analyze this?I hope it will be useful somehow.
Very nice,Analyse will be carried out soon.Sorry I may lost the mail you sent due to I used temporary mail for avoding advertisement.The telnet password is known now.
Updated by Jarobar almost 4 years ago
The procedure described in Rowley Microcell Bricks is correct for DPH-151.
Updated by Jarobar almost 4 years ago
sshd:nSCV0.l5YF7k2:0:0:root:/root:/bin/sh
Do you know the answer?
Updated by laforge almost 4 years ago
Jarobar wrote:
sshd:nSCV0.l5YF7k2:0:0:root:/root:/bin/sh
Do you know the answer?
I don't, but this looks like a classic crypt hash that virtually anyone should be able to crack in reasonable amount of time these days, right?
Updated by Jarobar almost 4 years ago
John says
Loaded 1 password hash (descrypt, traditional crypt(3) [DES 128/128 SSE2-16])
finished with
root:gemtekro:0:0:root:/root:/bin/sh
I can really log in with it.
copslock please what procedure do you use to get FPGA gateware?
Updated by copslock almost 4 years ago
Jarobar wrote:
John says
Loaded 1 password hash (descrypt, traditional crypt(3) [DES 128/128 SSE2-16])finished with
root:gemtekro:0:0:root:/root:/bin/shI can really log in with it.
copslock please what procedure do you use to get FPGA gateware?
What the hell is "FPGA Gateway"?The next job is to find the configuration for the femto-GW,in this case,the HNBGW address,but In the Picochip solution,the IPsec channel is mandatory before the creation of the Iuh link,but I dont sure that will be the same on Gemtek's devices.As long as you have got into the shell enviroment,you should change the IPSec deamon's configuration to make it contact well with the IPSec(e.g strongswan) gateway,make sure it gets the correct subnet,and using CWMP procedure to change the HNBGW address to the OSMO-HNBGW deamon listening interface's IP address,configure the airlink parameters,which can reference to the Cisco's configuration guide book,Then when everything be OK,you will get information from the OSMO-HNBGW gateway log output,after that the authentication and etc can be done like other procedures in OSMO GSM projects
Updated by neggles almost 4 years ago
- File 3gap-cert.pem 3gap-cert.pem added
- File 3gap-key.pem added
- File chain.pem chain.pem added
So I've done a bunch of screwing around with a DPH-153 over the last few days, and the good news is that getting into the Ralink side of things is ridiculously easy
ip route add 192.168.157.184/30 via $femto_wan_ip
telnet 192.168.157.185
username's guest, password's 1qaz@WSX
- if you run
rmm_client 192.168.157.185 cs_cmd "echo 'root::0:0:root:/tmp:/bin/sh' >> /etc/passwd'
you can log out, log in as root with no password, and have a poke around if you want. Run this:
cs_client set sys/console 1 cs_client show
and you'll get something like this https://pastebin.com/eZVyYdYb - If you have a unit that's tamper-locked, it's fairly simple to work out what you need to do to reset tamper.
There's also rmm_client 192.168.157.185 clear_tamper
, assuming it's not talked to the AT&T cloud prov servers and bricked itself, that should fix it
The bad news? The Ralink is basically a dumb router. It's not doing anything of any particular interest or use, that I can find so far - the picochip puppets it via the ipc_server process, and the picochip itself doesn't seem to respond or listen to traffic on any TCP port. It also only reaches out to the outside world over HTTPS (with a smattering of NTP sync) to connect to a TR-069 server at https://femtocell.wireless.att.com, so unless we can impersonate that, or I've missed something obscenely obvious, getting into these might be... difficult?
The NAND dump above does contain its own TLS client cert, which you'll find here: https://pastebin.com/teej6Zs2 and attached to this post. laforge suggested if we can get the private key unlocked, the device might accept a server presenting that same certificate back to it; they're both signed by the CA chain in that paste, so that seems promising, but I'm not remotely good at cracking even DES-encrypted things. Binwalking through that dump revealed a bunch of fun stuff, but since I'm not sure of the partition layout, the files I've extracted are one hell of a mess.
On the plus side, there's a security config file that has a big ole IPSEC_DISABLED option, and from what I can see it definitely speaks Iuh, so we should be able to get it to work if we can get into the thing.
Will keep plugging away at it a bit - there's an RMA mode you can put the whole setup in which might lead somewhere, and it looks like it might be possible to pass the picochip a different TR-069 server URL via DHCP options.
Updated by copslock almost 4 years ago
neggles wrote:
So I've done a bunch of screwing around with a DPH-153 over the last few days, and the good news is that getting into the Ralink side of things is ridiculously easy
..........
Very helpful information,but some of your exploration had been already been by the hackday.io guy i mentioned about,and some info about the binaries can also be fonud in https://rjmendez.github.io/posts/2019/02/Indeed_CTF_Embedded_2/
Bingo!as far as I remember,in some similar solution picochip femtocell,the ralink side is responsible for providing IPsec tunnel before the later CWMP and Iuh connection of the picochip side,and the TR-069 ACS address is configurable in ralink environment(possible router web side or ralink telnet),but sorry idon't remember it clearly now,after that the TR-069 can put this parameter into the picochip which makes it connect to the HNBGW
InternetGatewayDevice.Services.FAPService.1.FAPControl.UMTS.Gateway.SecGWServer1
It's important to find out how this procedure was accomplished in this ATT modified microcell,refer to this guy's exploration
http://dascomputerconsultants.com/Att.htm
the microcell is got configured through that HTTPS proceduce to https://femtocell.wireless.att.com ,without established the IPSec tunnel first,So I guess there might be some procedure like Huawei femto cell that the first one is the public domain HMS server which provides the IPSec adress or whatever other stuff ,then by using those parameters provided form previous procedure,the actually IPSec and Iuh link can be really established.So the possible routine I think is try to modify the parameters that were provided in this procedure or try to simply bypass the fisrt stage that connect to the ATT and directly get it into the IPSec serving routine,But I don't know whether if this was mandatory before the second stage,it might not get into the second the stage without the first stage that configured some who knows parameters to get the second stage works.By this routine,the analyse of the public domain HMS configuration procedure can be bypassed,and as you see in the web above,two units got different endpoint address which means the address possible isn't hardcoded into the firmware.I think the DHCP option could be some breakthrough to set the parameters of picochip side
About the TR-069 CWMP procedure,reference from Cisco ASR5000 HNB-GW may help a lot
https://www.cisco.com/c/dam/en/us/td/docs/wireless/asr_5000/smallcell/USC_Software_Docs/R37/References/UBS-44-57-004_Iuh_Parameter_Guidelines_for_R3_7.pdf
Updated by Jarobar almost 4 years ago
Hi, while extracting the file S29GL512P10FFCR2_151_2, there was probably an error that I can´t repair. The same sequences appear to repeat within the file. The address wire or flash chip may have been damaged. Note, the files marked x_151_x are related to DPH-151.
I can't determine wheather we have enough information obtained from HW or not. Should I try to get more from the picochip?
Updated by copslock almost 4 years ago
Jarobar wrote:
Hi, while extracting the file S29GL512P10FFCR2_151_2, there was probably an error that I can´t repair. The same sequences appear to repeat within the file. The address wire or flash chip may have been damaged. Note, the files marked x_151_x are related to DPH-151.
I can't determine wheather we have enough information obtained from HW or not. Should I try to get more from the picochip?
Yes,picochip also needed,but i strongly suggest that using uboot md to dump flash out instead of using flash programmer
Updated by Jarobar almost 4 years ago
I agree, using a non-invasive approach would be better. So far I´m not able to control the picochip via the serial line. Let me know if you know how to do it.
I'm also thinking about the JTAG approach. I've gathered some documents for that, but it's not enough yet.
A circuit diagram of connecting the picochip and testing points could help. Has anyone tried to create it?
Updated by Jarobar almost 4 years ago
- File mark_151_jtag.jpg mark_151_jtag.jpg added
- File pctoolsstory.pdf pctoolsstory.pdf added
- File PC7302QuickStartGuide.pdf PC7302QuickStartGuide.pdf added
- File picotoolsproductbrief.pdf picotoolsproductbrief.pdf added
Updated by neggles almost 4 years ago
Jarobar wrote:
Hi, while extracting the file S29GL512P10FFCR2_151_2, there was probably an error that I can´t repair. The same sequences appear to repeat within the file. The address wire or flash chip may have been damaged. Note, the files marked x_151_x are related to DPH-151.
I can't determine wheather we have enough information obtained from HW or not. Should I try to get more from the picochip?
This is because of a kinda weird flash layout it has going on; binwalk thinks it's looking at a whole bunch of gzip'd files and empty-ish JFFS2 partitions, but it's actually a lot simpler. If you do a string search on the first couple of 256KB blocks, you can find the u-boot environment variables, which conveniently includes a flash layout;
mtdparts=physmap-flash.0:256K(uBoot),256K(env),2M(kernel1),2M(kernel2),3584K(config),27M(FS1),27M(FS2),256K(oem_divert1),256K(oem_divert2),256K(oem_data1),256K(oem_data2),256K(oem_lib1),256K(oem_lib2),256K(resv),256K(ipa_calib)
Partitions look like this:
Name Filesys Start End Size (b) Size (KB) uBoot raw 0x0000000 0x0040000 0x0040000 256 env raw 0x0040000 0x0080000 0x0040000 256 kernel1 zImage 0x0080000 0x0280000 0x0200000 2048 kernel2 zImage 0x0280000 0x0480000 0x0200000 2048 config jffs2 0x0480000 0x0800000 0x0380000 3584 fs1 cramfs big-endian 0x0800000 0x2300000 0x1B00000 27648 fs2 cramfs big-endian 0x2300000 0x3E00000 0x1B00000 27648 oem_divert1 jffs2 0x3E00000 0x3E40000 0x0040000 256 oem_divert2 jffs2 0x3E40000 0x3E80000 0x0040000 256 oem_data1 jffs2 0x3E80000 0x3EC0000 0x0040000 256 oem_data2 jffs2 0x3EC0000 0x3F00000 0x0040000 256 oem_lib1 jffs2 0x3F00000 0x3F40000 0x0040000 256 oem_lib2 jffs2 0x3F40000 0x3F80000 0x0040000 256 reserved jffs2 0x3F80000 0x3FC0000 0x0040000 256 ipa_calib jffs2 0x3FC0000 0x4000000 0x0040000 256
I've carved up that image into what I think are the correct chunks & extracted out the cramfs/jffs2 partitions - all of the oem_* partitions come out blank, not sure if they actually are blank or they're hidden by the SoC's secure boot nonsense or something else. Repo on GitHub here: https://github.com/neg2led/dph151-binwalk
There are also GPL source tarballs available to download on Cisco's site here: https://www.cisco.com/c/en/us/about/legal/open-source-documentation-responsive.html
I've not looked much at the sources for the DPH-151, but the DPH-153 sources seem fairly complete - it looks relatively simple to build a functional, bootable image for the PC312 from them. I'm working on dumping the flash chip on a partially-dead DPH-153 I have (the ralink doesn't even enter uboot, but the pico seems to be alive so hopefully I can dump via JTAG) and putting together a buildroot environment for the 153, but I am by no means good at embedded linux development so it'll probably take some time/effort.
copslock: I think all of the information about the ralink being the one to initiate the IPSec tunnel is just straight-up wrong - even the PC202 is a far more powerful processor than the ralink's MIPS chip, which would struggle to handle the IPSec traffic of even the 3.6Mbps-limited DPH-151. I am 100% certain that the ralink on the DPH-153 is not handling IPSec, at the very least - I've dumped the kernel images from mine via uboot md.b and it lines up with what this guy found on his: http://cholla.mmto.org/electronics/femto/ - the whole thing runs almost entirely out of RAM, and the Pico puppets it over IPC to monitor operating modes / tamper detect / pass it firmware images to upgrade.
I did catch the pico trying to upgrade the ralink to a newer firmware version - it's running 1.0.8 and the image it tried to install was 1.1.2 - but I killed the power before it could flash, and it's not tried again since.
All that said, it looks like they're using route-based IPSec tunneling - it tunnels the whole 172.26.0.0/16 subnet, and if you allow the pico to set up its IPSec tunnel back to AT&T then terminate the tunnel, it doesn't uninstall the static route even though the tunnel is down and starts sending SCTP INIT packets to the IP address of whichever IPSec gateway it chose. Conveniently, it also appears to be almost entirely unfirewalled from that subnet, so I'm going to poke around some more and see if I can get in.
Hashes of the root passwords from the two fs images in Jarobar's flash dump:
$1$isyt1CdO$EGKPzGwOlNGqNUf7wcgov/
$1$NIr1CEcI$EBJd/wfEGjxjm74hujvCN.
I'm trying to crack the passphrase on that certificate key at the moment, but if anyone feels like having a go at those, that'd be a good idea I'd say.
Updated by copslock almost 4 years ago
neggles wrote:
Jarobar wrote:
Hi, while extracting the file S29GL512P10FFCR2_151_2, there was probably an error that I can´t repair. The same sequences appear to repeat within the file.
........
keep moving,I think you should find where these parameters are stored,or analyse the TR-069 deamon,i am too busy to spare time for deeper reverse job recently
Updated by Jarobar almost 4 years ago
This file for 153 was created using the same method. The file is empty at the beginning. It is possible that the tamper has been activated. The error caused by a bad contact is also possible.
Updated by neggles almost 4 years ago
Sure - my gmail address is the same as my GH username :)
I don't think it's tamper-related; the flash map in the u-boot environment variables is different to the DPH-151, first 256KB appear blank but they're a partition called 'fsroot' which it doesn't seem to actually use. Have attached a JTAG flashdump from one of my DPH-153s, a unit with a bad ralink chip - the pico still boots fine, but the ralink's u-boot appears to be corrupt - it matches up with your dump in terms of binwalk reported partition starts, though I can't extract fs2 out of your image - cramfsck segfaults, which is weird.
I'm tossing the DPH-153 binwalk extracted stuff into another git repo here: https://github.com/neg2led/dph153-binwalk - Repo root has a couple of files with the two uboot environment var blocks in. Appears mtd part numbers are not sequential in terms of address range on these ones, which is what's got me a bit confused.
mtdparts=physmap-flash.0:384K@0x03e00000(uBoot),256K@0x40000(env),2M(kernel1),2M(kernel2),3584K(config),27M(FS1),27M(FS2),256K@0(fsboot),128K@0x03e60000(oem_divert2),256K(oem_data1),256K(oem_data2),256K(oem_lib1),256K(oem_lib2),256K(resv),256K(ipa_calib)
Updated by Jarobar almost 4 years ago
For completeness, here is a file for Ralink from 153.
Tamper configurations 151 versus 153 vary.
Provided that the GPS antenna is at the bottom and the power connector at the top, the inscriptions J15 and J16 are also oriented correctly. 1 - means horizontally connected, 0 - means not connected.
For DPH-151
J15 (TOP side, where Ralink and Picochip is)
1
1
0
J16 (BOTTOM side)
1
0
0
For DPH-153
J15 (TOP side, where Ralink and Picochip is)
0
1
1
J16 (BOTTOM side)
0
1
0
Updated by neggles almost 4 years ago
Jarobar wrote:
For completeness, here is a file for Ralink from 153.
Tamper configurations 151 versus 153 vary.
Provided that the GPS antenna is at the bottom and the power connector at the top, the inscriptions J15 and J16 are also oriented correctly. 1 - means horizontally connected, 0 - means not connected.
My DPH-153 units are 1,1,0 on J15 and 1,0,0 on J16 - which matches your DPH-151 layout. The ralink config dump from my good unit shows a few different options for settings
[ tamper_proof ]--[ 010110 ]
[ bad_tamper ]--[ 0 ]--[ 111111 ]
[ 1 ]--[ 111111 ]
[ 2 ]--[ 111111 ]
[ 3 ]--[ 111111 ]
[ 4 ]--[ 111111 ]
[ 5 ]--[ 010111 ]
[ 6 ]--[ 010111 ]
[ 7 ]--[ 010111 ]
[ 8 ]--[ 010110 ]
[ 9 ]--[ 010110 ]
[ 10 ]--[ 010110 ]
[ 11 ]--[ 010110 ]
[ 12 ]--[ 010110 ]
[ 13 ]--[ 010110 ]
[ 14 ]--[ 111111 ]
[ 15 ]--[ 111111 ]
[ bad_tamper_index ]--[ 14 ]
Not entirely sure what the index etc. is referring to, but it looks like they did do some amount of randomization in the tamper patterns, though not much. Pretty easy to reset, though, since the Ralink is in charge of that & the pico doesn't seem to save tamper status, it just pesters the ralink every minute to see if it's tripped.
Updated by Jarobar almost 4 years ago
- File picoChip-designs.pdf picoChip-designs.pdf added
- File LTE_TurboEncoder.pdf LTE_TurboEncoder.pdf added
- File OFDMRxSynchronization.pdf OFDMRxSynchronization.pdf added
- File PC312.pdf PC312.pdf added
- File PC7302QuickStartGuide.pdf PC7302QuickStartGuide.pdf added
Neggles is making progress, great!
I decided to search Internet resources once again. I discovered information on osmocom.org that I didn't know about.
https://osmocom.org/projects/cellular-infrastructure/wiki/Accelerate3g5_--_blobb
http://people.osmocom.org/laforge/ipaccess-nano3G/GPL/
LaForge´s tweet, he looks for information on picochip. Unfortunately, he writes that he did not find it.
https://twitter.com/LaF0rge/status/683301186481614848
This page contains information about picotools, even something like a license key. Unfortunately, the download links point to the non-existent site support.picochip.com
https://sites.google.com/site/pctwiki1/
I ask anyone who has a document, tools, or anything relevant to put it here or link to it.
Updated by Jarobar almost 4 years ago
- File App1-picoChip.pdf App1-picoChip.pdf added
Updated by copslock almost 4 years ago
Jarobar wrote:
Neggles is making progress, great!
.....
Some research of Ralink side binaries
cfg_flash
cfg_flash -[rsd] -n name [-v value] -r: Read, -s: Set, -d: Delete -n: name to operate, -v value to set
eg:
cfg_flash -s -n backdoor -v 0
bw_client
bw_client <cmd> <cmd> : IP time_int
nvram
Usage: nvram <command> -f file_name -c index command: show - display config content gen - gen a config file renew - using given config file to restore settings clear - clear all config content. index: 0 - Config 1 - Config2 file_name: - file name for renew command
rmm_client
ipc_client ip command command list: reset factory_reset clear_tamper do_software_download get_software_status set_bandwidth get_bandwidth switch_fw_boot set_telnetd set_port_fwd get_uptime cs_cmd sleep crash
eg:
rmm_client 192.168.157.185 do_software_download tftp://$tftp_site/$firmware
The router topology
+----------------+ +-----------------+ +----------------+ UE <-->|192.168.157.186 | <-------> | 192.168.157.185 | <-------> | 0.0.0.0 | UE <-->| Pico PC202 | eth2.X | Ralink SoC | eth2.2 | WAN | | | | | | | +----------------+ +-----------------+ +----------------+
Output from these commands can verify if the IPSec config are stored on ralink side NVRAM or not
cfg_flash -r
nvram show -c 0
ipc_client
ipc_client ip command command list: reset factory_reset tamper download_finished
ipc_client seems been used to work with the remote Picochip deamon
ipc_client 192.168.157.186 download_finished
Still trying to find the deamon binary in Picochip
Updated by copslock almost 4 years ago
neggles wrote:
Sure - my gmail address is the same as my GH username :)
I don't think it's tamper-related; the flash map in the u-boot environment variables is different to the DPH-151, first 256KB appear blank but they're a partition called 'fsroot' which it doesn't seem to actually use. Have attached a JTAG flashdump from one of my DPH-153s, a unit with a bad ralink chip - the pico still boots fine, but the ralink's u-boot appears to be corrupt - it matches up with your dump in terms of binwalk reported partition starts, though I can't extract fs2 out of your image - cramfsck segfaults, which is weird.
I'm tossing the DPH-153 binwalk extracted stuff into another git repo here: https://github.com/neg2led/dph153-binwalk - Repo root has a couple of files with the two uboot environment var blocks in. Appears mtd part numbers are not sequential in terms of address range on these ones, which is what's got me a bit confused.
[...]
Yep,by digging into the filesystem of Picochip,It's obviously configured through Cisco HMS,but it's TLS endpoint,the cert will become problem,it's astonishing that ipaccess choose to run OAM/IPSEC/3G all on the Picochip,I think there might be something like hash verification to the filesystem,hope will find some way to log into the pico side
Updated by neggles over 3 years ago
- File openocd-dph153.cfg openocd-dph153.cfg added
A quick update for you all; I'm in
It was a chore to get write access to the NOR flash over JTAG, but once I did, it was pretty simple; for the DPH-153, PL1 is the JTAG connector with this pinout:
|------|---|----|------| | ? | 1 | 2 | tRST | | GND | 3 | 4 | tCK | | KEY | 5 | 6 | tMS | | ? | 7 | 8 | tDI | | VCC? | 9 | 10 | tDO | |------|---|----|------| (the 'KEY' pin is also GND, but it's not connected on the IPA boards this is based off)
nSRST is not on this header - solder a wire to "TP186" on the rear of the board, just below where the radio RF isolation can is located and connect that to your JTAG interface's nSRST/RESET output. It's not correct, but it does work.
Modify the attached OpenOCD config file to match your adapter, back up your u-boot environment partition with dump_image oem-env.bin 0x40040000 0x40000
in OpenOCD, and either modify it somehow (mount using mtdram & edit with fw_setenv?) or make a replacement with u-boot's mkenvimage
.
Changes to env vars:
1. Remove silent=yes
entirely
2. Change consoledev
to 'ttyS0'
3. Change bootdelay
to '99'
Once you've programmed this to the flash with flash_image
in OpenOCD - which will be slow - you'll find u-boot's console on J3, 115200/8N1. Pinout is the same as the ralink and GPS headers (JP1/GCON1);
1 = 3.3v 2 = device TX 3 = device RX 4 = GND
where pin1 = the white silkscreened notch on the PCB.
Once you're into u-boot, press any key to interrupt, run setenv othbootargs "panic=1 init=/bin/bash"
& run bootflash
. This will get you to a pre-init root shell.
Run mount -a
to mount the various filesystems.
cd to /var/ipaccess/root_home/
and use vi to add your choice of SSH key to authorized_keys
use vi to edit /var/ipaccess/nv_env.sh
to look like this:
export ENV_VERBOSE_CONSOLE_ENABLED="TRUE" export ENV_FIREWALL_DISABLED="TRUE" export FS_VARIANT="224A" export FS_LETTER=${FS:3:1} export DEFAULT_UNHARDENED="TRUE"
run sync && mount -o remount,ro /var/ipaccess
and reboot. After reboot, you should be able to SSH to root@<IP address of DPH-153> - probably a good idea to firewall it off from internet access first - and have a poke around. This will also enable the regular serial console on the device, if SSH doesn't work, but the rootfs is read-only (cramfs) & we only have access to /var/ipaccess; I don't have the root password cracked just yet, either, but you can probably abuse the fact that /var/ipaccess/nv_env.sh gets run several times per boot to overwrite the rootfs overlay each boot. Have fun!
For those of you without a clue what JTAG is or how to use one, there will be further developments to come once I can extract an SSL private key from this thing.
Updated by copslock over 3 years ago
neggles wrote:
A quick update for you all; I'm in
.....
excellent progress!But still trying to find some ways to configure the device without opening the sheild,I found many interesting binaries in picochip's filesystem,some of them even tries connect back to the 192.168.157.185:3001,which listened by the ipc_server deamon,dont know if possible to make some command injection with that.
Updated by copslock over 3 years ago
neggles wrote:
A quick update for you all; I'm in
......
Hey guys!Can you check which deamon listens to the 3001 port on picochip,after couple of days digging,I still cannot find the right one.Youcan check this out by
netstat -nlp
Updated by copslock over 3 years ago
After analyzed the deamons inside picochip filesystem,I can sure that these Cisco microcell is merely based on ip.access femtocells,they have ip.access DMI deamon listens to port 8090,which can accept commands for coufiguration like other generic ip.access femtocells.Some of the commands can be found in
https://osmocom.org/projects/cellular-infrastructure/wiki/Configuring_the_ipaccess_nano3G
The biggest problem is the iptables firewall,the Cisco modified firewall rules
# TCP incoming external from router $IPTABLES -A INPUT -i $EXTIF -p tcp -m state --state NEW -s 192.168.157.185 -m multiport --dports 3001 -j ACCEPT # UDP incoming external for TFTP requests from router $IPTABLES -A INPUT -i $EXTIF -p udp -m state --state NEW -s 192.168.157.185 -m multiport --dports 69,1024:65535 -j ACCEPT
makes it only can be accessed through ipc_client 3001 or TFTP protocals,the key switch to turn iptables off is the
export ENV_FIREWALL_DISABLED="TRUE"
marco that you found in /config/nv_env.sh
for the remote access the
ENV_VERBOSE_CONSOLE_ENABLED="TRUE"
marco found in the same file decides the sshd deamon can be access from outside or not
# If consoles are enabled, then listen to port 22 on any interface # If console is disabled, only listen on lo interface to support reverse ssh if [ "$ENV_VERBOSE_CONSOLE_ENABLED" == "TRUE" ]; then LISTEN_ON=22 else LISTEN_ON=127.0.0.1:22 fi
The password for remote SSH login is definitely a problem,hope have some good luck on john or hashcat
So,how to modified this file without opening the shield?I think the only way to accomplish that is through MIMT to the Cisco modified CMHS procedure,but it looks like has the SSL problem
Device.DeviceInfo.ModelName=DPH151-AT V1 Device.Services.FAPService.1.X_00000C_MHS.Config.StatusParameterNames=Device.Services.X_00000C_FAPService.Radio.Status,Device.Services.X_00000C_FAPService.Radio.ErrorDetails,Device.Services.X_00000C_FAPService.FGW.Fqdn,Device.Services.FAPService.{i}.Transport.Tunnel.IKESA.{i}.IPAddress,Device.DeviceInfo.X_00000C_3GModuleVersion,Device.DeviceInfo.X_00000C_GpsModuleVersion,Device.DeviceInfo.X_00000C_RouterModuleVersion,Device.DeviceInfo.ModelName Device.Services.FAPService.1.X_00000C_MHS.Config.DefaultServerURLs=cmhsse-decatur.wireless.att.com,cmhsse-lake-mary.wireless.att.com,cmhsne-rochelle-park.wireless.att.com,cmhsne-columbia.wireless.att.com,cmhsce-carrollton.wireless.att.com,cmhsce-hazelwood.wireless.att.com,cmhswe-santa-clara.wireless.att.com,cmhswe-santa-ana.wireless.att.com Device.Services.FAPService.1.X_00000C_MHS.Config.UpperHeartbeatInterval=120 Device.Services.FAPService.1.X_00000C_MHS.Config.MaxStatsInterval=60 Device.Services.FAPService.1.X_00000C_MHS.Config.XMPPDomainName= Device.Services.FAPService.1.X_00000C_MHS.Conn.ConnectionAttmeptsBeforeUnavailable=5 Device.Services.FAPService.1.X_00000C_MHS.Conn.GracefulShutdownWaitTime=10000 Device.Services.FAPService.1.X_00000C_MHS.Config.StartupScriptConfigWaitTime=10000 DscpAcs=10 Device.Services.FAPService.1.X_00000C_MHS.Conn.TCPConnectionTimeout=10000 Device.Services.FAPService.1.X_00000C_MHS.Conn.TCPReadTimeout=10000 Device.Services.FAPService.1.X_00000C_MHS.Conn.TCPWriteTimeout=10000 Device.ManagementServer.X_00000C_CDPBaseURL=https://femtocell.wireless.att.com:443/file/
Updated by copslock over 3 years ago
- File architecture.pdf architecture.pdf added
Updated by copslock over 3 years ago
cisco manual that related to DPH-153-LA
https://www.cisco.com/c/en/us/td/docs/wireless/access_point/small_cell/rms/r4x/admin_guide/b_rms_admin_guide.pdf
Updated by neggles over 3 years ago
Yeah, it's essentially a nano3G S8 with some extra Cisco stuff added. DMI can be enabled by another env variable; my current nv_env.sh looks like this:
export ENV_VERBOSE_CONSOLE_ENABLED="TRUE" export ENV_FIREWALL_DISABLED="TRUE" export ENV_CRL_BASE_SERVER="" export ENV_CRASH_REPORT_URL="" export TZ="" export DSCP_ACS="10" export ENV_BASICOAM_DISABLED="FALSE" export ENV_START_DMI_TELNET="TRUE" if ! grep -q mysshkey /var/ipaccess/root_home/.ssh/authorized_keys then echo "ssh-rsa your_ssh_key_here mysshkey" >> /var/ipaccess/root_home/.ssh/authorized_keys echo "added custom ssh key" fi
That last little bit will add your SSH key to authorized_keys on the device at every boot, as long as you don't trigger a complete factory reset. Make sure to leave the 'mysshkey' comment, since that's what it checks for before adding it. This way the unknown root password doesn't really matter.
It won't be much trouble to make this work if we can find a way in without using JTAG - I am building a hybrid firmware image from the device's original firmware, and a Nano3G S16 firmware image with the same major/minor versions, and right now it happily connects to osmo-hnbgw (yay!) but my current networking setup is causing it some trouble (I think it doesn't like being behind NAT) and the GPS control system is linked into the Cisco watchdog software, so I need to do some more digging and testing to work out what bits of that I can safely re-enable while making sure it won't factory reset itself / connect out to AT&T.
Once this behaves, I'll probably post an image of the modified root partition & maybe a custom recovery/alternative root partition that's set up to make it never speak to AT&T again.
Then it just comes down to getting into the thing without JTAG. Unfortunately the device will not accept its own certificate when it tries to connect to the AT&T Cisco Management Heartbeat Service, which means we would need to crack the rsa2048/sha1 CA certificate it uses - this isn't impossible, but would cost something on the order of US$80,000-100,000 in AWS GPU processing time, so it's not exactly cost-effective.
I am hoping to find a back way in through the RMA mode / IPC client function on the ralink; the pico listens on TCP/3001 for an IPC/RMM connection, but so far it's rejected all the connection attempts I've made from the ralink's rmm client other than "trigger factory reset", so I'll have to go digging through the disassembly to find out what it is or isn't happy to accept. The executable is Dslg_SysRegistry or DslmSsp, I'm not sure exactly which. The pico only runs a tftp server when it has a firmware update ready for the ralink, and it runs it out of tmpfs, so we can't easily use that to modify the nv_env.sh file.
Updated by copslock over 3 years ago
neggles wrote:
Yeah, it's essentially a nano3G S8 with some extra Cisco stuff added. DMI can be enabled by another env variable; my current nv_env.sh looks like this:
[...]
That last little bit will add your SSH key to authorized_keys on the device at every boot, as long as you don't trigger a complete factory reset. Make sure to leave the 'mysshkey' comment, since that's what it checks for before adding it. This way the unknown root password doesn't really matter.
Yep,by adding ssh-rsa key into root_home in /config filesystem,it will work flawlessly,but the major usage of the gotten shadow root password is for modifiless command injection through some way to get access to the picochip environment
It won't be much trouble to make this work if we can find a way in without using JTAG - I am building a hybrid firmware image from the device's original firmware, and a Nano3G S16 firmware image with the same major/minor versions, and right now it happily connects to osmo-hnbgw (yay!) but my current networking setup is causing it some trouble (I think it doesn't like being behind NAT) and the GPS control system is linked into the Cisco watchdog software, so I need to do some more digging and testing to work out what bits of that I can safely re-enable while making sure it won't factory reset itself / connect out to AT&T.
It's great if you can run the S16 filesystem from ip.access on the cisco oem hardware,but I think it's more important to make the original firmware running up for compatibility and stability,the original binaries inside ipacess folder already had support of standard RNANP and RUA,the Iuh mode control value is the IUH_ENABLE boolean in the config file,besides they also had the support of ip.access's Iu+(BSMIS URSL SOIP SABP APDiag),which occupied quite a lot of code segments in those binaries.I think the abnormal mainly came from the binaries from /opt/cisco directories,most of them have access to /sbin/reboot wihch mean the watchdog function,As the CMHS procedure didn't take place properly,these deamons may try to reboot the machine as they were programed,it will need a lot of Ghidra work to find out those routines and switches to turn those thing completely off.
Once this behaves, I'll probably post an image of the modified root partition & maybe a custom recovery/alternative root partition that's set up to make it never speak to AT&T again.
Most of the deamons located in /opt/cisco,the only thing should be worried about is the binaries in /opt/ipacess will connect or listen to cisco deamons or not
Then it just comes down to getting into the thing without JTAG. Unfortunately the device will not accept its own certificate when it tries to connect to the AT&T Cisco Management Heartbeat Service, which means we would need to crack the rsa2048/sha1 CA certificate it uses - this isn't impossible, but would cost something on the order of US$80,000-100,000 in AWS GPU processing time, so it's not exactly cost-effective.
It's no surprise the SSL will not work,and try to crack the SSL certificate private key is neither a good idea
I am hoping to find a back way in through the RMA mode / IPC client function on the ralink; the pico listens on TCP/3001 for an IPC/RMM connection, but so far it's rejected all the connection attempts I've made from the ralink's rmm client other than "trigger factory reset", so I'll have to go digging through the disassembly to find out what it is or isn't happy to accept. The executable is Dslg_SysRegistry or DslmSsp, I'm not sure exactly which. The pico only runs a tftp server when it has a firmware update ready for the ralink, and it runs it out of tmpfs, so we can't easily use that to modify the nv_env.sh file.
It's because you used the wrong client,the right client is ipc_client not the rmm_client,rmm_client is used to connect to the ralink local ipc_server(very confused about its exsistence).You can find the correct deamon by netstat -nlp command to find the right deamon who listen to 3001,In this stage,skiils of exploit will required,we should try to find some cache overflow bug or somethings else inside the deamon message process functions and manage to do some shellcode or ROP stuff.The software upgrade routine may be a breakthrough by uploading some agents to spwan a reverse shell but the problem is it will only be triggered by CMHS procedure binaries.
Updated by copslock over 3 years ago
I think another strange behave you should care about is one of the deamon in /opt/cisco tries connect back to the ralink .185:3001,does it means there are some backdoors?
Updated by copslock over 3 years ago
In FUN_0002020C v5 = "ipa-soiprouter"; v6 = "ipa-mgr_app"; v7 = "ipa-rrm"; v8 = "picolibRouter"; v9 = "uplayerapp"; v10 = "Dslg_SysRegistr"; j_sprintf(&s, "pgrep -x %s", (&v5)[v1]); ++v1; if ( system_0(&s) ) break; if ( v1 == 6 ) return 0; } syslog_0(6, " The process <%s> is DEAD \n", v2); j_sprintf((char *)v0, "Process %s crashed", v2); } else { syslog_0(3, "ssp_CheckForIPARMMProcessAlive: Failed to allocate memory \n"); } return v0
these deamons will be monitored by DslmSsp
Updated by neggles over 3 years ago
copslock wrote:
Yep,by adding ssh-rsa key into root_home in /config filesystem,it will work flawlessly,but the major usage of the gotten shadow root password is for modifiless command injection through some way to get access to the picochip environment
I have a couple of graphics cards working on it, but since Cisco were likely the ones to set that password, it'll probably be a bit difficult to crack. I've had an RTX2080 running hashcat with various wordlists for ~3 days without getting anywhere yet :(
It's great if you can run the S16 filesystem from ip.access on the cisco oem hardware,but I think it's more important to make the original firmware running up for compatibility and stability,the original binaries inside ipacess folder already had support of standard RNANP and RUA,the Iuh mode control value is the IUH_ENABLE boolean in the config file,besides they also had the support of ip.access's Iu+(BSMIS URSL SOIP SABP APDiag),which occupied quite a lot of code segments in those binaries.I think the abnormal mainly came from the binaries from /opt/cisco directories,most of them have access to /sbin/reboot wihch mean the watchdog function,As the CMHS procedure didn't take place properly,these deamons may try to reboot the machine as they were programed,it will need a lot of Ghidra work to find out those routines and switches to turn those thing completely off.
I am using the original filesystem, but I've copied in some files from the S16 firmware to add back the web interface & remove some dependency on cisco stuff. There's no trouble making Iuh work - the factory firmware already connects to a HNBGW just like a Nano3G, and I have mine connected right now:
OsmoHNBGW# show hnb all HNB (r=10.61.1.191:29169<->l=10.61.1.10:29169) "34BDFA-0019497289@cisco.com" MCC 001 MNC 01 LAC 10422 RAC 99 SAC 2028 CID 1 SCTP-stream:HNBAP=0,RUA=0 IuCS: 10 contexts: inactive-reserved:3 inactive-discard:7 1 HNB connected
It's proving to be a bit difficult to get it to consistently behave, but I'm sure I'm just not starting everything in the correct order at the moment.
Most of the deamons located in /opt/cisco,the only thing should be worried about is the binaries in /opt/ipacess will connect or listen to cisco deamons or not
They don't, really, but the GPS is managed by the cmhs daemon, which is... inconvenient.
It's no surprise the SSL will not work,and try to crack the SSL certificate private key is neither a good idea
...
You can check that by netstat -nlp command to find the right deamon who listen to 3001,In this stage,skiils of exploit will required,we should try to find some cache overflow bug or somethings else inside the deamon message process functions and manage to do some shellcode or ROP stuff.The software upgrade routine may be a breakthrough by uploading some agents to spwan a reverse shell but the problem is it will only be triggered by CMHS procedure binaries.
cmhs, Dslg_SysRegistry and DslmSsp are the ones that trigger reboots / config overwrites / etc.
the TCP/3001 server is Dslg_SysRegistry, I believe, but I'm not sure & I don't want to start them up and risk wiping out all the work I've done so far.
Whichever of them it is, it talks to the IPC server at 3001 on the ralink on a regular basis (once a minute or so) to check/recheck tamper status etc, and handles software updates. DslmSsp is the one that's responsible for triggering reboots and generally keeping an eye on things, I think. There's also swdl_client which handles the actual software upgrade process.
copslock wrote:
I think another strange behave you should care about is one of the deamon in /opt/cisco tries connect back to the ralink .185:3001,does it means there are some backdoors?
There would be a backdoor in some earlier firmwares, maybe, but it appears that in recent firmwares the IPTables rules don't permit inbound connections from ralink to pico to prevent this exact problem :( that or they've removed the commands you can run from the ralink side to control the pico side. Not sure which just yet.
Updated by copslock over 3 years ago
neggles wrote:
I am using the original filesystem, but I've copied in some files from the S16 firmware to add back the web interface & remove some dependency on cisco stuff. There's no trouble making Iuh work - the factory firmware already connects to a HNBGW just like a Nano3G, and I have mine connected right now:
In /opt/cisco/bsp,there are bunches of web pages which seems to be the web configuration pages,but it seems provided by the Cisco,I suspect the HTTP service were turned off at some point before,possibly when those guys found the access to the ralink side.As the iptables forward rules show that 80 8080 22 20000 ports are forward to the picochip.
There would be a backdoor in some earlier firmwares, maybe, but it appears that in recent firmwares the IPTables rules don't permit inbound connections from ralink to pico to prevent this exact problem :( that or they've removed the commands you can run from the ralink side to control the pico side. Not sure which just yet.
I analyzed the traffic,the request is extremely simple,just RAW number value packed in TCP packet,which makes it quite hard to locate the function in the picohip's deamon,the connect back function inside the ssp deamon seems trying to get version info don't know if possible to craft the response of ralink,but still haven't located the actual function position,the IPC routine possible will not be helpful
Updated by copslock over 3 years ago
neggles wrote:
I have a couple of graphics cards working on it, but since Cisco were likely the ones to set that password, it'll probably be a bit difficult to crack. I've had an RTX2080 running hashcat with various wordlists for ~3 days without getting anywhere yet :(
I have the hashcat running for weeks already,but on the slow Intel iGPU,the only parallel computing device I can running for weeks so far
OsmoHNBGW# show hnb all HNB (r=10.61.1.191:29169<->l=10.61.1.10:29169) "34BDFA-0019497289@cisco.com" MCC 001 MNC 01 LAC 10422 RAC 99 SAC 2028 CID 1 SCTP-stream:HNBAP=0,RUA=0 IuCS: 10 contexts: inactive-reserved:3 inactive-discard:7 1 HNB connected
very nice,if the ipaccess deamons can run smoothly without the cisco deamons,it will be a very good news
Updated by neggles over 3 years ago
copslock wrote:
In /opt/cisco/bsp,there are bunches of web pages which seems to be the web configuration pages,but it seems provided by the Cisco,I suspect the HTTP service were turned off at some point before,possibly when those guys found the access to the ralink side.As the iptables forward rules show that 80 8080 22 20000 ports are forward to the picochip.
...
I analyzed the traffic,the request is extremely simple,just RAW number value packed in TCP packet,which makes it quite hard to locate the function in the picohip's deamon,the connect back function inside the ssp deamon seems trying to get version info don't know if possible to craft the response of ralink,but still haven't located the actual function position,the IPC routine possible will not be helpful
The DslmSsp request to the ralink is quering the ralink's config_server process - you can get the same data from the ralink serial console by running "cs_client show" or checking /etc_ro/default_config, I'm not sure what the data format is but it seems to be some kind of tree. There's a missing value it won't let us set - sys/manufacture_mode - which is somewhat promising as the pico checks it every time it boots.
Mostly it appears that DslmSsp is just checking to make sure nobody's messed with the config of the ralink; leaving it in RMA mode flagged my device as tampered with Cisco after half an hour or so.
copslock wrote:
I have the hashcat running for weeks already,but on the slow Intel iGPU,the only parallel computing device I can running for weeks so far
hopefully one of us gets somewhere with that...
copslock wrote:
very nice,if the ipaccess deamons can run smoothly without the cisco deamons,it will be a very good news
Yeah, they seem to work fine - my SGSN is being a bit finicky about allowing data tunnels to connect, but it's working fine - there's some throttling going on in the DPH-153, so I need to tweak those settings, but yeah. If we can get in, this is easy.
Updated by copslock over 3 years ago
neggles wrote:
The DslmSsp request to the ralink is quering the ralink's config_server process - you can get the same data from the ralink serial console by running "cs_client show" or checking /etc_ro/default_config, I'm not sure what the data format is but it seems to be some kind of tree. There's a missing value it won't let us set - sys/manufacture_mode - which is somewhat promising as the pico checks it every time it boots.
Yep,there are some manufacture mode marco stuff in ralink side,but I guess it works just for the bootup procedure previous,will these have some interesting effect on picochip?Besides,ralink has also included some GPIO related stuff,but most seem related to factory reset.
Yeah, they seem to work fine - my SGSN is being a bit finicky about allowing data tunnels to connect, but it's working fine - there's some throttling going on in the DPH-153, so I need to tweak those settings, but yeah. If we can get in, this is easy.
the max HSDPA rate is configured in UPlayerapp.cfg.
# Used to configure different HSDPA data rates. # Maximum is 3600 kbps for all UEs combined # Uncomment out this line to configure HSDPA Data rate HSDPA_MAX_DATA_RATE_KBPS 3600
But I think you still have to walk through those configuration file which related to the airinterface,beacause the PS rate in UMTS is limited by multi factors
Tools to modify the parameter manaully
bash opt/ipaccess/Utils/scripts/getVarVal file valueName bash opt/ipaccess/Utils/scripts/setVarVal file valueName valueType valueCount values
Updated by Jarobar over 3 years ago
- File DPH-154_top.JPG DPH-154_top.JPG added
- File DPH-154_bot.JPG DPH-154_bot.JPG added
Great!
I disassembled the DPH-154 package. So far I have only two photos. There seem to be a lot of things different from the 151 and 153. The dimensions of the board are much smaller. It has only one ethernet and wifi (SiRF GSD4e-9333F). Anti tampers are only on one side. It seems to have only one flash chip (S34ML02G100TF100) and one RAM chip (K4B2G16460-BCKO). Picochip is a MNDSPEED PC3008-oxc, now it is Intel GMPC3008 SR1Z8. The transceiver is AD9365BBCZ. The J5 connector could possibly be a 20-pin JTAG. I hope the J4 connector is similar to the Ralink serial console.
Anti tampers (TPX4) are on the top side (there are the main chips and the CISCO logo). Provided that the board is oriented so that the ethernet connector is in the lower right corner and the CISCO logo is correctly oriented, 0 - means not connected, 1 - connected.
The sequence (on my board) from left to right is this
000111
Updated by neggles over 3 years ago
Jarobar wrote:
I disassembled the DPH-154 package. [...] There seem to be a lot of things different from the 151 and 153. The dimensions of the board are much smaller. It has only one ethernet and wifi (SiRF GSD4e-9333F).
Nice! I did not expect the DPH-154 to be based on a newer chip, but here we are. The SiRF chip is the GPS - SiRFstar IV 4e - not wifi, for the record
It seems to have only one flash chip (S34ML02G100TF100) and one RAM chip (K4B2G16460-BCKO). Picochip is a MNDSPEED PC3008-oxc. The transceiver is AD9365BBCZ.
Single flash chip etc. is expected, since this only has the one SoC - here's the GPL tarball in a GitHub repo since Cisco require you to email them for a copy (even though they post the 151 and 153 tarballs...). Looks like they've bumped it from 64MB of flash + 2x128MB of RAM (one chip for ARM, one chip for picoArray) to 128MB of flash and a single shared 512MB DDR3 (!) RAM
The J5 connector could possibly be a 20-pin JTAG. I hope the J4 connector is similar to the Ralink serial console.
J5 does have the same connected/unconnected pins that I'd expect for a JLink/ARM 20pin JTAG, so that's promising. J4 is probably the Picochip serial console, but if it's anything like the 151 and 153, it won't be accessible without overwriting the u-boot environment variables first...
The PC3008 chip should be capable of much faster uplink and downlink data rates than the PC202/PC302-based units; ipa appear to limit all of their PC302-based units (including this one) to 1.9Mbps downlink, based on the contents of rrm_resources.cfg in the default DPH-153 config files.
Updated by Jarobar over 3 years ago
Thank you for correcting of my assumptions.
I focused on J4 and was looking for a serial line. It is really there and you can see the boot process. The layout of J4 is this:
Pin 1 is marked by arrow and number 1
1 - GND (low impedance to shield)
2 - probably input with pull up (impedance is around 3k, measured 2.6 V)
3 - VCC (3.3 V, low impedance to 3.3 V source)
4 - Tx (115200.8, N, 1)
5 - GND (low impedance to shield)
I connected the Tx of computer to pin 2 and tried to stop booting by sending a character sequence. So far without success.
I captured this on Tx:
U-Boot 2012.04 (Feb 28 2014 - 16:02:06)
DRAM: 128 MiBNAND: 256 MiB
In: serial
Out: serial
Err: serial
MAC: 74:54:01:02:03:04
Net: macb0
Hit any key to stop autoboot: 0
Creating 1 MTD partitions on "nand0":
0x000000c80000-0x000001780000 : "mtd=8"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI: attached mtd1 to ubi0
UBI: MTD device name: "mtd=8"
UBI: MTD device size: 11 MiB
UBI: number of good PEBs: 88
UBI: number of bad PEBs: 0
UBI: max. allowed volumes: 128
UBI: wear-leveling threshold: 4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 1
UBI: available PEBs: 0
UBI: total number of reserved PEBs: 88
UBI: number of PEBs reserved for bad PEB handling: 2
UBI: max/mean erase counter: 590/341
UBIFS: recovery needed
UBIFS: recovery deferred
UBIFS: mounted UBI device 0, volume 0, name "rwstore"
UBIFS: mounted read-only
UBIFS: file system size: 9269248 bytes (9052 KiB, 8 MiB, 73 LEBs)
UBIFS: journal size: 1015809 bytes (992 KiB, 0 MiB, 6 LEBs)
UBIFS: media format: w4/r0 (latest is w4/r0)
UBIFS: default compressor: LZO
UBIFS: reserved for root: 458093 bytes (447 KiB)
Loading file 'default_bank' to addr 0x00200000 with size 4 (0x00000004)...
Done
Active is fs2, Standby is fs1
Unmounting UBIFS volume rwstore!
UBI: mtd1 is detached from ubi0
Creating 1 MTD partitions on "nand0":
0x000009f80000-0x00000ff80000 : "mtd=11"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI: attached mtd1 to ubi0
UBI: MTD device name: "mtd=11"
UBI: MTD device size: 96 MiB
UBI: number of good PEBs: 768
UBI: number of bad PEBs: 0
UBI: max. allowed volumes: 128
UBI: wear-leveling threshold: 4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 1
UBI: available PEBs: 0
UBI: total number of reserved PEBs: 768
UBI: number of PEBs reserved for bad PEB handling: 7
UBI: max/mean erase counter: 89/41
UBIFS: recovery needed
UBIFS: recovery deferred
UBIFS: mounted UBI device 0, volume 0, name "fs2"
UBIFS: mounted read-only
UBIFS: file system size: 94851072 bytes (92628 KiB, 90 MiB, 747 LEBs)
UBIFS: journal size: 4698112 bytes (4588 KiB, 4 MiB, 37 LEBs)
UBIFS: media format: w4/r0 (latest is w4/r0)
UBIFS: default compressor: LZO
UBIFS: reserved for root: 4687619 bytes (4577 KiB)
Loading file 'images/kernel.bin' to addr 0x00200000 with size 3039136 (0x002e5fa0)...
Done
- Booting kernel from Legacy Image at 00200000 ...
Image Name: Linux-3.0.0-ip30xxff-xc-245.0
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3039072 Bytes = 2.9 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
␂Uncompressing Linux... done, booting the kernel.
Updated by copslock over 3 years ago
Jarobar wrote:
Thank you for correcting of my assumptions.
..........
The DPH-153/154 are manufactured by different vendors,other approach to the MINDSPEED chip will be needed.
Updated by Jarobar over 3 years ago
copslock, are you sure? I thought that changing the name of the chip is just the result of an acquisition.
neggles, would a cheap version of J-LINK EDU be enough to work with JTAG? I have Bus Blaster v4.1a but it doesn't seem to be working properly. The project Bus Blaster seems to be dead.
Updated by copslock over 3 years ago
Jarobar wrote:
copslock, are you sure? I thought that changing the name of the chip is just the result of an acquisition.
I am not very sure,but the circuit design is obivously completely different
neggles, would a cheap version of J-LINK EDU be enough to work with JTAG? I have Bus Blaster v4.1a but it doesn't seem to be working properly. The project Bus Blaster seems to be dead.
J-LINK works for most scenario,many pwn guys recommend it
Updated by neggles over 3 years ago
copslock wrote:
The DPH-153/154 are manufactured by different vendors,other approach to the MINDSPEED chip will be needed.
Jarobar wrote:
copslock, are you sure? I thought that changing the name of the chip is just the result of an acquisition.
Jarobar is correct - Mindspeed bought Picochip, then Intel bought Mindspeed. The PC3008 is the fourth-generation Picochip femtocell SoC, with the PC3x2 being the third-generation - it runs the same underlying software even, as you can see from the GPL tarball I posted.
The kernel version confirms it was also made by ip.access - Linux-3.0.0-ip30xxff-xc-245.0
in the DPH-154, Linux-2.6.34-ip3xxff-xc-240.0-pi
in the DPH-153. From what I remember of the info I was able to find about the PC3008, it's very similar to the PC312 except it runs the ARM at 1GHz and has an improved PHY capable of 21/5Mbps HSPA+ instead of just 7.2Mbps HSDPA/HSUPA.
I'm going to have to buy one of these, aren't I? :P
Jarobar wrote:
neggles, would a cheap version of J-LINK EDU be enough to work with JTAG? I have Bus Blaster v4.1a but it doesn't seem to be working properly. The project Bus Blaster seems to be dead.
I've been using a J-Link EDU for all the work I've done so far - if I hadn't bought it already, I would probably go with a Blackmagic Probe v2.1 ( USA store and EU store ) but I can't be totally sure it'd work. Either should work just fine for OpenOCD & GDB purposes, but J-Links do have the benefit of being very widely-used and well-documented.
Updated by copslock over 3 years ago
neggles wrote:
Jarobar is correct - Mindspeed bought Picochip, then Intel bought Mindspeed. The PC3008 is the fourth-generation Picochip femtocell SoC, with the PC3x2 being the third-generation - it runs the same underlying software even, as you can see from the GPL tarball I posted.
The kernel version confirms it was also made by ip.access -
Linux-3.0.0-ip30xxff-xc-245.0
in the DPH-154,Linux-2.6.34-ip3xxff-xc-240.0-pi
in the DPH-153. From what I remember of the info I was able to find about the PC3008, it's very similar to the PC312 except it runs the ARM at 1GHz and has an improved PHY capable of 21/5Mbps HSPA+ instead of just 7.2Mbps HSDPA/HSUPA.I'm going to have to buy one of these, aren't I? :P
Yes,refering to the tarball,it seems that the MINDSPEED chip based on ip.access code base either,but I didn't find such way to locate the chipset when I can only merely find some DPH-151 circuit board pictures which from EDN teardown and the failoverflow blog,It's completely a coincidence to come by the DPH-151 circuit board picture when I searching the ip.access nano 3g board picture.Then I found it's based on the familiar picochip+ralink chipset,I guess it might have a chance to re-utilize these massively available microcells from cisco/AT&T.But as the harald said,most of them were deeply locked down,so I posted this topic to get some help.About the chipset,I think the MAXIM RF frontend performance in 151/153 design is obviously much better than generic ADI ones,because it's designed specifically to work with the UMTS standard.About the HSDPA rate,I saw some reports about PC202 which introduced HSDPA rate of 7.2Mbps,but refering to the configuration file it's 3.6Mbps obviously,the 153's PC312,which is the same SoC used in nano 3g s8,provides HSDPA rate of 14.4Mbps refering to the datasheet,in this case ip.access limited it to 13Mbps
Updated by copslock over 3 years ago
neggles wrote:
The DslmSsp request to the ralink is quering the ralink's config_server process - you can get the same data from the ralink serial console by running "cs_client show" or checking /etc_ro/default_config, I'm not sure what the data format is but it seems to be some kind of tree. There's a missing value it won't let us set - sys/manufacture_mode - which is somewhat promising as the pico checks it every time it boots.
..................
AT&T had turned off the sshd access to picochip at some time
this guy's nmap scanning results from 2009 showed that
Nmap scan report for 10.0.1.101 Host is up (0.00081s latency). PORT STATE SERVICE VERSION *22/tcp open ssh Dropbear sshd 0.50 (protocol 2.0)* MAC Address: 48:44:87:2D:xx:xx (Unknown)
The dropbearmulti deamon inside picochip filesystem is
SSH-2.0-dropbear_0.50
Which perfectly proved the change to the picochip setting,god damn hackers,if these annoying guys doesn't do some so call "hack shit",it will be much easier to reuse these precious hardware
Updated by copslock over 3 years ago
laforge wrote:
AFAICT, URSL was originally developed by ip.access for the early version of their "oyster3g" femtocells. Cisco had later acquired/licensed that from ip.access. At least for the ip.access oyster3g, only early firmware versions were USRL, later on they moved to standard Iuh. maybe the same is true for the cisco devices you are looking at?
In any case, USRL is a completely different protocol, so if you wanted to support it, you would have to write a IuCS+IuPS to USRL converter. Given that URSL uses no RANAP, this is likely a much more complex task than the comparatively simple osmo-hnbgw.
Hi!Harald,can you give me edit_own_issues permission to update the issue description,some of the links inside dead
Updated by Jarobar over 3 years ago
I tried to find out the electrical properties of connector J5 (JTAG). It was measured the presence of a pull up / down resistor without power and voltage after switching on. Useful signals are currently marked by question mark. I guess it should be a classic 20-pin JTAG. I got this spreadsheet:
J5
2 ? PU 4 6 8 10 12 14 16 18 20 |3.3V|GND |GND |GND |GND |GND |GND |GND |GND |GND | |____|____|____|____|____|____|____|____|____|____| |VCC |TRST|TDI |TMS |TCK |? PU|TDO | NC | NC | NC | |3.3V|0.5V|3.3V|3.3V|3.3V|0.1V|3.3V| | | | 1 3 5 7 9 11 13 15 17 19 GND - ground NC - not connected PD - pull down (resistor 10k to GND) PU - pull up (resistor 10k to VCC) ? - unknown signal
NSRST / RESET does not appear to be present again (pin 15).
Updated by copslock over 3 years ago
Jarobar wrote:
I tried to find out the electrical properties of connector J5 (JTAG). It was measured the presence of a pull up / down resistor without power and voltage after switching on. Useful signals are currently marked by question mark. I guess it should be a classic 20-pin JTAG. I got this spreadsheet:
J5
[...]NSRST / RESET does not appear to be present again (pin 15).
Great!But if logical analyzer was used,it will be much easier to find these out
Updated by neggles over 3 years ago
Jarobar - Yup, that looks how I'd expect JTAG to look, though pin 2 is usually not connected, so it might be nSRST? Have you tried bridging various pins to ground to see if it resets the board?
If regular 20-pin pinout doesn't work, and you have a Raspberry Pi floating around, you should be able to identify the pinout with go-jtagenum - in fact if you have a Pi 2 or newer, OpenOCD and urJTAG can use their GPIOs to interface directly with JTAG ports. It's not the fastest, but it does work.
copslock wrote:
Which perfectly proved the change to the picochip setting,god damn hackers,if these annoying guys doesn't do some so call "hack shit",it will be much easier to reuse these precious hardware
Yeah, if they hadn't gotten so much attention, they might not have locked them down as much - but at the same time, all the attention they got is what made it possible for us to get in at all, so there's that.
While the PC312 does support up to 14.4Mbps HSPA, the firmware on the DPH-153 is configured to limit individual MSes to 1.6Mbps;
RRM_HSUPA_UL_BIT_RATES_10_MS #No Of UE's BitRate 0 1600 1 1600 2 1600 3 1500 4 1400 5 1600 6 1400 7 1200 8 1200 RRM_HSUPA_UL_BIT_RATES_2_MS #No Of UE's BitRate 0 1600 1 1600 2 1400 3 1200 4 1000 5 1000 6 1000 7 800 8 800
This is the same in the 8-user Nano3G firmware images I have access to. They also limit total throughput to 6Mbps:
#FirstRabLoad NextRabLoad SameUE Load MaxHsRate 0 0 0 900 0 0 0 1500 0 0 0 2100 0 0 0 2700 0 0 0 3300 0 0 0 3900 0 0 0 4500 0 0 0 5100 0 0 0 5700 0 0 0 6300
Again, this is the same in the Nano3G, so it's not just an artificial restriction they put in place for the AT&T units.
Guess I'll try turning the numbers up. I do not know enough about how this works to know if that's a good idea, but I can always change it back...
Updated by laforge over 3 years ago
On Mon, Nov 30, 2020 at 08:43:07AM +0000, copslock [REDMINE] wrote:
Hi!Harald,can you give me edit_own_issues permission to update the issue description,some of the links inside dead
done.
Updated by copslock over 3 years ago
laforge wrote:
On Mon, Nov 30, 2020 at 08:43:07AM +0000, copslock [REDMINE] wrote:
Hi!Harald,can you give me edit_own_issues permission to update the issue description,some of the links inside dead
done.
Ops,still doesn't work,the redmine really have some terrible UI logical desgin....
Updated by copslock over 3 years ago
neggles wrote:
While the PC312 does support up to 14.4Mbps HSPA, the firmware on the DPH-153 is configured to limit individual MSes to 1.6Mbps;
[...]
This is the same in the 8-user Nano3G firmware images I have access to. They also limit total throughput to 6Mbps:
[...]
Again, this is the same in the Nano3G, so it's not just an artificial restriction they put in place for the AT&T units.
Guess I'll try turning the numbers up. I do not know enough about how this works to know if that's a good idea, but I can always change it back...
I think you had mixed these stuff up,It's RRM_HSUPA_UL_BIT_RATES_10_MS,you see?the HSUPA_UL means it's about the uplink,not the downlink.The GSM/UMTS link is somehow called "HARD RESOURCE",which mean the channel resources are divided into many logical link paritions,and the link rate is highly related with the Uu parameters,like TTI or something etc.It's really complicated when compared to the IP systems because these standards were runinng on ATM transport rather than IP/Ethernet before.You have to carefully tweak those Uu parameters in RRM config file.If you didn't understand these magic very well,you can strings the DSLMSSP out to get a detail guide book about these parameters.The real throttle magic is the HSDPA_MAX_DATA_RATE_KBPS mentioned above in UPlayerapp.cfg.
Updated by copslock over 3 years ago
And
# Used to configure different HSDPA data rates for More that 1 PS Rabs. HSDPA_MAX_DATA_RATE_KBPS_FOR_MULTI_USER 6000
But i thought you might tested the speed with only 1 device,so i didn't mention it before
BTW,you can use this to detect whether if you got the maximum resource allocation
![](https://gadget.hrksv.com/wp-content/uploads/2018/06/DgTkWxXVMAApUu9_R.jpg)
Updated by Jarobar over 3 years ago
- File S34ML02G100TF100_154_1_p.bin.gzaa S34ML02G100TF100_154_1_p.bin.gzaa added
- File S34ML02G100TF100_154_1_p.bin.gzab S34ML02G100TF100_154_1_p.bin.gzab added
This time 154.
The original file was gziped and splitted to fit the maximum.
gzip -c S34ML02G100TF100_154_1.bin | split -b 40000000 - S34ML02G100TF100_154_1_p.bin.gz
Updated by copslock over 3 years ago
Jarobar wrote:
This time 154.
The original file was gziped and splitted to fit the maximum.gzip -c S34ML02G100TF100_154_1.bin | split -b 40000000 - S34ML02G100TF100_154_1_p.bin.gz
Awesome,but I think JTAG probally still will needed,the Cisco CMHS procedure seems complete undefeatable
Updated by neggles over 3 years ago
copslock wrote:
I think you had mixed these stuff up,It's RRM_HSUPA_UL_BIT_RATES_10_MS,you see?the HSUPA_UL means it's about the uplink,not the downlink.The GSM/UMTS link is somehow called "HARD RESOURCE",which mean the channel resources are divided into many logical link paritions,and the link rate is highly related with the Uu parameters,like TTI or something etc.It's really complicated when compared to the IP systems because these standards were runinng on ATM transport rather than IP/Ethernet before.You have to carefully tweak those Uu parameters in RRM config file.If you didn't understand these magic very well,you can strings the DSLMSSP out to get a detail guide book about these parameters.The real throttle magic is the HSDPA_MAX_DATA_RATE_KBPS mentioned above in UPlayerapp.cfg.
[...]
But i thought you might tested the speed with only 1 device,so i didn't mention it before
BTW,you can use this to detect whether if you got the maximum resource allocation
Thanks for that app link, I don't have a rooted device at the moment though, and I don't really want to root my LG V50... It's odd that I am only seeing 1.6Mbps down and ~800k up, but I am sure I am missing something.
Right now i'm trying to get DslmSsp working (without it messing with everything) so that the GPS can work properly, even though it doesn't seem to be strictly necessary.
I'll post some scripts to modify the dumped cramfs image and build a replacement jffs2 boot image that you can flash once environment variables have been overwritten via JTAG - much faster this way, since it's about an hour to reflash the filesystem over JTAG :(
copslock wrote:
Awesome,but I think JTAG probally still will needed,the Cisco CMHS procedure seems complete undefeatable
Probably, but JTAG isn't really that far out of reach these days - all you need is a Raspberry Pi, or even an ESP8266 module - and I can make a script that'll handle the entire rooting process.
On the DPH-154, it should be easier - just need to find out what string u-boot is looking for to interrupt booting...
Here's the MTD partition layout:mtdparts=mtdparts=denali-nand:512K(fsbl),2M@1M(uboot1),1M(ubootenv),2M(uboot2),512K(factdata),512K(prodcerts),512K(testcerts),5M(reserved),11M(rwstore),40M(logs),96M(fs1),96M(fs2)
Looks like it's using ubifs for the rwstore, which makes things more annoying to deal with...
Updated by Jarobar over 3 years ago
- File S34ML02G100TF100_154_2_p.bin.gzaa S34ML02G100TF100_154_2_p.bin.gzaa added
- File S34ML02G100TF100_154_2_p.bin.gzab S34ML02G100TF100_154_2_p.bin.gzab added
I read again several times after cleaning the pins. I got this file which has 519 different bytes compared to the previous one.
Updated by copslock over 3 years ago
Jarobar wrote:
I read again several times after cleaning the pins. I got this file which has 519 different bytes compared to the previous one.
The programmer indeed had some problem,the DPH-153 image you provided before had fs2 cramfs CRC error like neggles said,the cramfsck will complain about that
Updated by Jarobar over 3 years ago
When I use neggles openocd-dph153.cfg script I get this.
This applies to 154.
openocd -f openocd-dph153.cfg Open On-Chip Debugger 0.10.0 Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html adapter speed: 9600 kHz adapter_nsrst_assert_width: 100 adapter_nsrst_delay: 225 trst_and_srst separate srst_gates_jtag trst_push_pull srst_push_pull connect_deassert_srst Info : No device selected, using first device. Info : VTarget = 3.335 V Info : clock speed 9600 kHz Info : JTAG tap: pc302.cpu tap/device found: 0x07b763a9 (mfg: 0x1d4 (Picochip Designs Ltd), part: 0x7b76, ver: 0x0) Info : found ARM1176 Info : pc302.cpu: hardware has 6 breakpoints, 2 watchpoints Info : JTAG tap: pc302.cpu tap/device found: 0x07b763a9 (mfg: 0x1d4 (Picochip Designs Ltd), part: 0x7b76, ver: 0x0) Info : found ARM1176 Warn : pc302.cpu: ran after reset and before halt ... target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x200000d3 pc: 0x07f9e678 breakpoint set at 0x06011004 Error: timed out while waiting for target halted
Using UrJTAG
jtag> cable jlink J-Link initial read failed, don't worry (result=0) Vref = 3.335 TCK=1 TDI=0 TDO=1 TMS=0 TRES=1 TRST=1 J-Link JTAG Interface ready jtag> jtag> detect IR length: 5 Chain length: 1 Device Id: 00000111101101110110001110101001 (0x07B763A9) Unknown manufacturer! (00111010100) (/usr/local/share/urjtag/MANUFACTURERS) jtag> discovery Detecting IR length ... 5 Detecting DR length for IR 11111 ... 1 Detecting DR length for IR 00000 ... warning: TDO seems to be stuck at 1 -1 Detecting DR length for IR 00001 ... 1 Detecting DR length for IR 00010 ... 5 Detecting DR length for IR 00011 ... 1 Detecting DR length for IR 00100 ... 1 Detecting DR length for IR 00101 ... 1 Detecting DR length for IR 00110 ... 1 Detecting DR length for IR 00111 ... 1 Detecting DR length for IR 01000 ... 1 Detecting DR length for IR 01001 ... 1 Detecting DR length for IR 01010 ... 1 Detecting DR length for IR 01011 ... 1 Detecting DR length for IR 01100 ... warning: TDO seems to be stuck at 1 -1 Detecting DR length for IR 01101 ... 1 Detecting DR length for IR 01110 ... 1 Detecting DR length for IR 01111 ... 1 Detecting DR length for IR 10000 ... 1 Detecting DR length for IR 10001 ... 1 Detecting DR length for IR 10010 ... 1 Detecting DR length for IR 10011 ... 1 Detecting DR length for IR 10100 ... 1 Detecting DR length for IR 10101 ... 1 Detecting DR length for IR 10110 ... 1 Detecting DR length for IR 10111 ... 1 Detecting DR length for IR 11000 ... 1 Detecting DR length for IR 11001 ... 1 Detecting DR length for IR 11010 ... 1 Detecting DR length for IR 11011 ... 1 Detecting DR length for IR 11100 ... 1 Detecting DR length for IR 11101 ... 33 Detecting DR length for IR 11110 ... 32 jtag>
What next?
Updated by copslock over 3 years ago
Jarobar wrote:
When I use neggles openocd-dph153.cfg script I get this.
This applies to 154.
[...]
Using UrJTAG
[...]What next?
I am not familiar with coding on bare-metal,but this seems like some good progress
Updated by neggles over 3 years ago
Jarobar wrote:
When I use neggles openocd-dph153.cfg script I get this.
This applies to 154.
[...]
Using UrJTAG
[...]What next?
Ooh, okay, urJTAG works, that's interesting! Unfortunately it requires a lot of effort to make urJTAG support a device like this, since we don't have a BSDL file for it :(
Anyway, I replied to your email with some more details, which i'll repeat here for posterity:
The OpenOCD script won't work without a reset pin, it relies on resetting the chip & then catching it early on in the boot process (before u-boot has switched the MMU out of its initial mode)
If you can find a reset pin, then that breakpoint might still work if the DPH-154 is loading u-boot at 0x06000000 - the first few kB of a u-boot binary are usually pretty much the same, even across versions. Otherwise, you need to find an instruction that's executed before u-boot has set up the MMU, from memory the one I used there is the beginning of the "copy u-boot to another part of RAM" loop, not quite sure.
Updated by Jarobar over 3 years ago
- File DPH-154_RESET_disc_top.png DPH-154_RESET_disc_top.png added
- File DPH-154_RESET_disc_bot.png DPH-154_RESET_disc_bot.png added
I found a point that works as a reset if it is grounded. It is the gate (top image, arrow number 1) of the U6 chip which is located under the picochip shield. This gate is led through a resistor R248, 100 Ohm (picture top, arrow number 2) to a via which is on the bottom side near C599 (picture bot, arrow number 4).
I connected this point to pin 15 on the JTAG header.
If I use OpenOCD with the openocd-dph 153.cfg script, two resets are performed in a row.
It does not stop booting, the OpenOCD output looks same with the error at end.
U-Boot 2012.04 (Feb 28 2014 - 16:02:06) DRAM: 128 MiB NAND: 256 MiB U-Boot 2012.04 (Feb 28 2014 - 16:02:06) DRAM: 128 MiB NAND: 256 MiB In: serial Out: serial Err: serial MAC: Net: macb0 Hit any key to stop autoboot: 0 Creating 1 MTD partitions on "nand0": 0x000000c80000-0x000001780000 : "mtd=8" UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 126976 bytes UBI: smallest flash I/O unit: 2048 UBI: sub-page size: 512 UBI: VID header offset: 2048 (aligned 2048) UBI: data offset: 4096 UBI: attached mtd1 to ubi0 UBI: MTD device name: "mtd=8" UBI: MTD device size: 11 MiB UBI: number of good PEBs: 88 UBI: number of bad PEBs: 0 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold: 4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 1 UBI: available PEBs: 0 ........ same as in past
Updated by Jarobar over 2 years ago
- File openocd-dph154.cfg openocd-dph154.cfg added
- File stepper.py stepper.py added
A small step forward. I changed the break point address according to the relocation address of text (found here dph154-gpl/blob/main/src/579.11.123/u-boot-1.3.4-picochip-3.2.4-patch.gz).
Works TEXT_BASE = 0x07FD0000 or TEXT_BASE = 0x06000000.
Booting stops when these addresses are used. Stepping in OpenOCD is possible. With a large number of steps, the sending of individual characters to the serial line can be seen.
openocd -f openocd-dph154.cfg Open On-Chip Debugger 0.10.0 Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html adapter speed: 9600 kHz adapter_nsrst_assert_width: 100 adapter_nsrst_delay: 225 trst_and_srst separate srst_gates_jtag trst_push_pull srst_push_pull connect_deassert_srst Info : No device selected, using first device. Info : J-Link V11 compiled Aug 14 2019 16:21:09 Info : Hardware version: 11.00 Info : VTarget = 3.335 V Info : clock speed 9600 kHz Info : JTAG tap: pc302.cpu tap/device found: 0x07b763a9 (mfg: 0x1d4 (Picochip Designs Ltd), part: 0x7b76, ver: 0x0) Info : found ARM1176 Info : pc302.cpu: hardware has 6 breakpoints, 2 watchpoints Info : JTAG tap: pc302.cpu tap/device found: 0x07b763a9 (mfg: 0x1d4 (Picochip Designs Ltd), part: 0x7b76, ver: 0x0) Info : found ARM1176 Warn : pc302.cpu: ran after reset and before halt ... target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x400000f3 pc: 0x200109da breakpoint set at 0x07fd0000 target halted in ARM state due to breakpoint, current mode: Supervisor cpsr: 0x600000d3 pc: 0x07fd0000
U-Boot 2012.04 (Feb 28 2014 - 16:02:06) DRAM: 128 MiB NAND: 256 MiB U-Boot 2012.04 (Feb 28 2014 - 16:02:06) DRAM: 128 MiB NAND:
After finish of script stepper.py
U-Boot 2012.04 (Feb 28 2014 - 16:02:06) DRAM: 128 MiB NAND: 256 MiB U-Boot 2012.04 (Feb 28 2014 - 16:02:06) DRAM: 128 MiB NAND: 256
Updated by bcm61670 over 1 year ago
Jarobar wrote in #note-78:
I read again several times after cleaning the pins. I got this file which has 519 different bytes compared to the previous one.
Hello,
Did anybody figured what nand ecc algorithm is used in DPH-154?
I made dump of my dph154, but I can't find what ecc is used.
Updated by Jarobar about 1 year ago
Hello,
What do you expect from the ECC algorithm? The quoted section refers to errors caused by poor pin contact in the programmer socket or damage to the chip during soldering. I believe that no ECC algorithm in the world can fix such significant damage to the data (missing one or more bits or a complete section of the address space).
In fact, I am uncertain if any ECC is used in this context, apart from the standard file system properties. There might be something implemented prior to the introduction of u-boot. I would rather expect a CRC check or something similar. The use of a convolutional code is practically ruled out since there are blocks with readable text strings, and the convolutional code would obscure them.
It would be great if you could post the image that was read out somewhere for comparison.
Any discoveries are welcome, of course.
Updated by bcm61670 about 1 year ago
- File S34ML02G1@TSOP48.BIN_2.7z.001 S34ML02G1@TSOP48.BIN_2.7z.001 added
- File S34ML02G1@TSOP48.BIN_2.7z.002 S34ML02G1@TSOP48.BIN_2.7z.002 added
Jarobar wrote in #note-86:
Hello,
What do you expect from the ECC algorithm? The quoted section refers to errors caused by poor pin contact in the programmer socket or damage to the chip during soldering. I believe that no ECC algorithm in the world can fix such significant damage to the data (missing one or more bits or a complete section of the address space).In fact, I am uncertain if any ECC is used in this context, apart from the standard file system properties. There might be something implemented prior to the introduction of u-boot. I would rather expect a CRC check or something similar. The use of a convolutional code is practically ruled out since there are blocks with readable text strings, and the convolutional code would obscure them.
It would be great if you could post the image that was read out somewhere for comparison.
Any discoveries are welcome, of course.
I'm sure some ECC algorithm is used in this femtocell, because we can see 64 bytes of ECC data after every 2048 bytes of data.
And this matches what S34ML02G1 datasheet says:
"– Page Size:
– x8 = 2112 (2048 + 64) bytes; 64 bytes is spare area"
For example if you at empty page filled with 0x00 you can see ECC "FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF FF" and this ECC is the same in every empty page in dump from this femtocell.
Every ECC in this femtocell starts with "FF FF" and ends with "00 FF FF FF FF FF FF".
I found very similar ECC is used in some TI devices: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/468600/evm-using-8-bit-nand-ecc-uncorrectable-when-reading-block-0/1683785#1683785 it also starts with "FF FF" and ends with "00 FF FF FF FF FF FF".
My femtocell image:
Updated by dezorder about 1 year ago
- File ad9365.pdf ad9365.pdf added
I found some documentation about AD9365
Updated by Kira about 1 year ago
Hi, I bought an ip.access nano3G S8 femtocell, but it turned out to be blocked (I can not connect via telnet, ssh and web interface). Is there any way to unlock it? Or should I buy another cell for 3G?
Updated by laforge 5 months ago
would be great to get all this content converted into a wiki page below Femtocell-specific_information