Cellular Network Infrastructure » Core Network (CN) » OsmoHNBGW

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.

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.

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,

I'm thinking about the support of ethernet-CPRI RRHs which is much
more widely available than the eNodeBs and very chip.

The problem is mainly:

• 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

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,

I'm thinking about the support of ethernet-CPRI RRHs which is much
more widely available than the eNodeBs and very chip.

The problem is mainly:

• 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

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"

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.

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.

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?

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_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?

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" 

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.

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_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?

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_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?

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?

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!

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

DPH-151 as the first
Is here somebody who can analyze this?

I hope it will be useful somehow.

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.

The procedure described in Rowley Microcell Bricks is correct for DPH-151.

sshd:nSCV0.l5YF7k2:0:0:root:/root:/bin/sh

Do you know the answer?

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?

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?

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/sh

I 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

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

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.

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

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?

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

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?

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;

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:

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.

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

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.

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)

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

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.

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.

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

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

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

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.

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.

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

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

# 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

export ENV_FIREWALL_DISABLED="TRUE" 

ENV_VERBOSE_CONSOLE_ENABLED="TRUE" 

    # 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

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/

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

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.

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.

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?

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

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.

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

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

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.

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

bash opt/ipaccess/Utils/scripts/getVarVal file valueName
bash opt/ipaccess/Utils/scripts/setVarVal file valueName valueType valueCount values

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

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.

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)

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

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.

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.

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

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.

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

pictures about jumper set

Pinmap

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)

SSH-2.0-dropbear_0.50

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

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

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

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

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

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.

And

# Used to configure different HSDPA data rates for More that 1 PS Rabs. 
HSDPA_MAX_DATA_RATE_KBPS_FOR_MULTI_USER   6000

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

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

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

I read again several times after cleaning the pins. I got this file which has 519 different bytes compared to the previous one.

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

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

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?

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

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.

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

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 

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:

I found some documentation about AD9365