Using undocumented phone features | developer.brewmp.com Using undocumented phone features | developer.brewmp.com

Developer

Using undocumented phone features

Let's consider that I can access a camera on a phone which doesn't provide appropriate camera API (for example VX6000). Obviously I will have to use phone's hardware directly to achieve that.
Can NSTL reject application/library using such approach? If so, on what basis? Well, obviously, direct access to the hardware doesn't sound completely right, but after all its not malicious and I couldn't find any reason NSTL should reject it.

Any ideas?

Zim

Well, how can you be certain your app will pass in the first place? NSTL may be using a different firmware version...
Quote:Originally posted by ziemowit
Let's consider that I can access a camera on a phone which doesn't provide appropriate camera API (for example VX6000). Obviously I will have to use phone's hardware directly to achieve that.
Can NSTL reject application/library using such approach? If so, on what basis? Well, obviously, direct access to the hardware doesn't sound completely right, but after all its not malicious and I couldn't find any reason NSTL should reject it.
Any ideas?
Zim

Well, how can you be certain your app will pass in the first place? NSTL may be using a different firmware version...
Quote:Originally posted by ziemowit
Let's consider that I can access a camera on a phone which doesn't provide appropriate camera API (for example VX6000). Obviously I will have to use phone's hardware directly to achieve that.
Can NSTL reject application/library using such approach? If so, on what basis? Well, obviously, direct access to the hardware doesn't sound completely right, but after all its not malicious and I couldn't find any reason NSTL should reject it.
Any ideas?
Zim

Yes, firmware may change, but hardware usually stays exactly the same. I am not talking here about calling some internal functions of the underlying os - their addresses will change and the application will crash. Instead I am just accessing the hardware directly. For example VX6000 display hardware provides a few registers to access the screen at fixed addresses and that should never change. It's quite safe.
Zim

Yes, firmware may change, but hardware usually stays exactly the same. I am not talking here about calling some internal functions of the underlying os - their addresses will change and the application will crash. Instead I am just accessing the hardware directly. For example VX6000 display hardware provides a few registers to access the screen at fixed addresses and that should never change. It's quite safe.
Zim

That's very interesting. Are you accessing the hardware from a BREW app.? Are you manipulating memory addresses specific to each register? I would have expected BREW, or the underlying OS, to prevent this from happening.
Are you using the JTAG interface to get a look at the registers or did you find the static memory addresses by trial and error? The latter would seem impracticable.
I'm not expecting much in response, but I'll naively ask the question anyway. How are you doing this, exactly?:rolleyes:
In my opinion, I would expect your app. to pass TBT as long as it passes all the test cases. The carrier, however, might well be concerned about your ability to make your own rules.
Murray

That's very interesting. Are you accessing the hardware from a BREW app.? Are you manipulating memory addresses specific to each register? I would have expected BREW, or the underlying OS, to prevent this from happening.
Are you using the JTAG interface to get a look at the registers or did you find the static memory addresses by trial and error? The latter would seem impracticable.
I'm not expecting much in response, but I'll naively ask the question anyway. How are you doing this, exactly?:rolleyes:
In my opinion, I would expect your app. to pass TBT as long as it passes all the test cases. The carrier, however, might well be concerned about your ability to make your own rules.
Murray

Well, ARM7TDMI doesn't come with MMU and basically everything is placed in flat memory at fixed addresses. This means everyone can access everything. That is, I guess, one of the major reasons for so sophisticated certification process.
Thanks to such unsophisticated architecture it's very easy to dump any BREW API or any part of OS and just to disassemble it to see how it works.

Well, ARM7TDMI doesn't come with MMU and basically everything is placed in flat memory at fixed addresses. This means everyone can access everything. That is, I guess, one of the major reasons for so sophisticated certification process.
Thanks to such unsophisticated architecture it's very easy to dump any BREW API or any part of OS and just to disassemble it to see how it works.

FWIW, the hardware can change too.
Firmware will act as an abstraction layer in case the hardware changes, e.g. a part is no longer available from any supplier sources requiring a different part.
I suppose you can profile the device upon startup and figure out if the hardware has changed. If it has, you could fall back to using the API.
But gosh that's right, the whole reason for this in the first place is the API doesn't support what you want to do. I suspect you'd pass TBT if it works fine in all test cases, but the carrier probably won't accept the app. Especially if they're enjoying revenue from the fact that the handset doesn't support that API in the first place.
--t

FWIW, the hardware can change too.
Firmware will act as an abstraction layer in case the hardware changes, e.g. a part is no longer available from any supplier sources requiring a different part.
I suppose you can profile the device upon startup and figure out if the hardware has changed. If it has, you could fall back to using the API.
But gosh that's right, the whole reason for this in the first place is the API doesn't support what you want to do. I suspect you'd pass TBT if it works fine in all test cases, but the carrier probably won't accept the app. Especially if they're enjoying revenue from the fact that the handset doesn't support that API in the first place.
--t