Cellphone software preservation

0 users browsing Discussion. | 9 bots

Main » Discussion » Cellphone software preservation

Pages: 1

tomman	Posted on 19-05-12, 14:09 Hi.
Dinosaur Post: #315 of 1285 Since: 10-30-18 Last post: 16 days Last view: 7 hours	(continued from this) Ah, software preservation. A favorite topic here at the bBoards. A reason to live for some. And... a very sad topic when we talk about modern computing devices, in this case, cellphones. Let's continue the conversation here~ Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™

Duck Penis

Posted on 19-05-12, 15:21

Stirrer of Shit
Post: #276 of 717
Since: 01-26-19

Last post: 1546 days
Last view: 1544 days

-If the encryption block is 8 bytes or more, the encryption block is encrypted using C-CBC mode. The last residual block, if it is less than 8 bytes, is not encrypted

Well, that settles that. I'm not sure if they're using 64-bit blocks (most likely) or 64-byte blocks (512-bit blocks), which seems completely absurd but is what the standard explicitly says:

The size X of each encryption block other than last encryption block is calculated by the following formula referring to the Encryption Block Size Factor E.
X=64*2^E (bytes), E=0, ..., 5
The size of the last encryption block is equal to X or less.

The specification is poorly written, but what I think they're using is "Encrypted object file (with unencrypted header) with residual data block (N=X*n+m+q, m<X, m=8*p, q<8)" (Table 3-7).

I can't find anything about the header format, though. Maybe that's for the underlying application to decide. I think so, based on the following passage:

* If the header part exists, the Unencrypted Header Size Factor H of the optional unencrypted header shall be specified in the corresponding Title Key & Usage Rule Entry of the encrypted object file and shall be used to decrypt the encrypted SD-Binding object file. The size Y of the optional unencrypted header is calculated by the following formula:
Y= 64*2^(H-1) (bytes), H=1, ..., 13

In other words, the Japanese encrypted cell phone backups might be completely different. But it should still be C2, so you could bruteforce it with a modern computer. That's the only way, unless you find some other flaw (e.g. how to read the protected area on an SD card)

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.

tomman

Posted on 19-05-12, 15:28

Dinosaur

Post: #317 of 1285
Since: 10-30-18

Last post: 16 days
Last view: 7 hours

All right, these used to be popular cellphone application platforms prior to the dawn of the modern smartphone. All of them are pretty much dead nowadays, most of the devices are now at landfills (or drawers full of cables and bulged batteries), and we can safely say that most of the software is now lost forever.

- J2ME: By far the most popular platform, based on good ol' Java. SDKs are free, but device implementations vary wildly. Few to no hurdles for deploying your applications (no need to jailbreak on most devices, except maybe for restricted APIs like filesystem access), digital signatures optional. But some OEMs wrapped your downloads in a random coating of DRM, which for almost all implementations out there is uncracked yet. Dumping games requires filesystem access (made much easier if the device has a SD card and does allow to install apps there). My experience solely restricts to Motorola devices, where security goes from "non-existing" (Canadian CDMA firmwares, where the JVM is actually a shoehorned BREW app) to "annoying" (3G phones and its .dmj format for DRM-protected OTA installls). Still, there used to be a rather active piracy scene out there, and there are quite a lot of ripped commercial content available out there. Emulators do exist, from the generic one on the Sun/Oracle SDK to plenty of OEM-specific emulators (there are a few for Android, too). Right now, J2ME is the easiest target for a software preservation project.

- BREW: Chances are you never heard about it, and I won't blame you: a bastard brainchild from the very same people that came up with clever inventions like CDMA and wireless patent lawsuits, Qualcomm. Really used only on CDMA networks (and even then not all of them used BREW - i.e. Sprint, all Canadian CDMA carriers, and Nokia cellphones preferred J2ME over BREW), but sadly important networks like Verizon or KDDI heavily relied on BREW! Apps are native ARM binaries (made in C++) tailored to the specific phone chipset. SDKs were partially free: if you wanted to actually upload and test apps to your phone, you had to become a Licensed Developer™, which was not cheap but allowed you access to the restricted tools part of the SDKs. Several layers of DRM: protected filesystems, restricted memory access, device-specific app signatures tied to your ESN/MEID/IMEI. In the best case (no filesystem locks, early BREW devices), you can dump your apps but can only restore them to the same phone from where these were ripped. Worst case? Short of desoldering those tiny BGA flash memory ICs, you end witn undumpable ROMs via traditional software means. Oh, there are no emulators. AT ALL - the SDK only allows for simulators that (similar to iOS development) only run native x86 binaries. Coding a emulator should not be hard (despite being native, apps don't have access to the underlying phone firmware - they interact with the phone through the BREW API... once again, very similar to what smartphones do), except for the lack of public documentation.

- Symbian: Ol' Nokia glory. Implemented on most mid/high-end Nokia phones (including the infamous N-Gage) and a few select Sony-Ericcson/Motorola models. Native apps made in C++. I've never dealt with Symbian devices so I don't know how easy is to dump those apps, but I do know there is some DRM involved (digital signatures at the very least). Nokia SDKs used to include emulators. Not to be confused with S40 (those only run J2ME apps), although almost all Symbian devices do run J2ME apps anyway. Piracy on Symbian was a thing, although due to restricted APIs, you had to deal with either hacked firmwares or get a developer cert to use some apps on your own devices. Some DoCoMo FOMA (3G) devices used a version of Symbiam, but that has nothing to do with Western versions!

- BlackBerry: Former Canadian pride. Custom J2ME implementation which could run either good ol' J2ME apps or "native" BlackBerry (.cod) apps with full access to the BB APIs. Those phones were aimed at businessmen in suits, not at preteen girls posting junk to Facebook, so this explains why they didn't came with too many restrictions (aside of enterprise policies which CAN heavily lock down your device). Dumping apps is trivial, all you need is a data cable and a suitable copy of the Device Manager software (that most likely shipped with your phone, or could be downloaded for free from ~~RIM~~ BB). Don't know anything about emulators, but naturally there was a SDK. Given all of this, piracy should be trivial, and so is preservation (hopefully!), but then BlackBerry was never known as the go-to platform for serious mobile gaming :/

As for Japanese cellphones...

- i-mode/i-appli (NTT DoCoMo): Custom J2ME implementation (their profile is branded as DoJa). No known way to dump applications, except for phones with SD cards... and even then you get encryption you have to deal with (.sb1 files). SDKs do have emulators, but it's unknown if they support modern devices. Piracy is unheard of, and the .sb1 crypto remains uncracked as of today. Not that Japan is very fond of preserving their (admittedly rich) mobile gaming legacy :/

- EZweb/EZappli (KDDI au): See BREW. Really, there is not much to add - if you can crack BREW, you've cracked EZappli. Otherwise, consider those apps hopelessly lost forever. Qualcomm really wanted it to happen anyway ("intelectual property protection" my ass).

- Whatever Softbank uses: Aside of their infamous "multimedia lock", I know nothing about Softbank (formerly Vodaphone JP/J-Phone) mobile app infrastructure. Expect ugly things from a preservation perspective for this one too.

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™

Duck Penis

Posted on 19-05-12, 16:03

Stirrer of Shit
Post: #277 of 717
Since: 01-26-19

Last post: 1546 days
Last view: 1544 days

Posted by tomman
the .sb1 crypto remains uncracked as of today

The crypto in itself should be relatively easy to crack (in theory, just implementation work), but the format is otherwise undocumented.

Also, .sb1 files aren't self-contained. They store the actual keys in the "protected area" of the SD card, which in turn requires some special sauce to access. Essentially, you can issue the read and write commands freely, but:

Posted by http://read.pudn.com/downloads188/ebook/881633/SD%203.0/Part_3_Security_Specification_Ver3.00_Final_090612.pdf

The (essential) argument of this command as shown below is transferred securely in AKE command (ACMD45) (See Note (2)).

(2) In AKE command (ACMD45), Challenge1 (random number RN1) is generated by encrypting an
(essential) argument of the following “Protected Area Access Command” (shown in Table 2-2). SD Memory Card gets the (essential) argument of the following “Protected Area Access Command” by decrypting received Challenge1. Regarding the generation method of Challenge1, please see 3.2.1 of Content Protection for Recordable Media Specification SD Memory Card Book.

There is no 3.2.1. There is however a 3.4.1.

There, it says that you pass a challenge from the card and the "Media Unique Key" into something called C2_G to pass the SD card's authentication.

How do you get the Media Unique Key? Easy, you pass the Media Key and the Media ID into C2_G. What is the Media ID? Not sure, but you can get it from the SD card. I don't think it's supposed to be secret. And what is the Media Key? Easy, you just process the MKB (Media Key Block, public) with the Device Key.

How do you process it? You pass the applicable Device Key and MKB into Process_MKB, which is defined in Chapter 3 of "Content Protection for Prerecorded Media Specification: Introduction and Common Cryptographic Elements". And that's just C2 decryption and some parsing.

Since C2 decryption is broken, you should be able to get the applicable Device Key (number 11), and then make quick work of the SD card dumping. You'd distribute a pre-packaged application that decrypts any SD card with backups on it you insert. On Linux, you can send raw commands, no idea about Windows but I'd think so.

But it seems much easier to just brute force the ultimate encryption key whenever you want to decrypt a backup than to re-implement some half-baked Japanese DRM scheme. It also makes it easier to dump ('copy this file and upload', vs 'download this program, run it, insert SD, upload the file it saves'), which should be a priority given the lack of enthusiasm they have for preservation.

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.

Duck Penis

Posted on 19-05-12, 17:13 (revision 4)

Stirrer of Shit
Post: #278 of 717
Since: 01-26-19

Last post: 1546 days
Last view: 1544 days

Here's all the specifications: http://www.4centity.com/specification.aspx

The 2008 paper needs arbitrary keys to work, so not applicable.

The 2009 paper's third attack (Key and S-box recovery with chosen ciphertext attack) is what I'm talking about. I think it should be possible to force it to encrypt a specific file (like an image or video, since people apparently had trouble getting those out of the phone), so then you could get the S-boxes that way. And with the S-box known, conventional bruteforce should be fast enough, especially with the GPU. You have some unencrypted homebrew apps (see forum thread) you could take a look at to get an idea of what the first 8 bytes should look like.

But it'd be a lot of implementation work, that's for sure.

EDIT: No, you need to need to get it to decrypt a specific encrypted blob. There's no checksum or anything, so that should be easy, but you need to dump it out of the phone somehow too. Which requires exploits, I presume. Or maybe you can sideload arbitrary J2ME apps onto it as well that can read e.g. camera videos?

EDIT 2: I don't see anything about rate limiting in the SD card spec, so maybe you could brute force the MUK, and then work your way backwards to ~~K_mu~~ the device key. Or, you can ask it to decrypt an arbitrary 64-bit block with the MUK (K_mu) and then return C2_G(K_mu, C2_D(your value)), so that's another possible avenue, assuming C2_D isn't prohibitively expensive. But you still need their mystery meat S-box for all that, which means the requirement for an exploit is still there.

EDIT 3: If it's not rate-limited, you could brute force K_mu by first accepting the SD card's challenge, then trying to verify a constant/random value. If it succeeds, you know that C2_G(K_mu, chall) == your guess. Then you can brute force K_mu offline. But we can't actually do anything just by knowing K_mu, because we don't have the S-box. And we can't brute-force this, because the S-box is 2048 bits. If we could encrypt with an arbitrary key, we could recover the S-box that way, but just known key doesn't really seem to be useful.

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.

Duck Penis

Posted on 19-05-12, 20:35

Stirrer of Shit
Post: #279 of 717
Since: 01-26-19

Last post: 1546 days
Last view: 1544 days

It's even worse than I thought:

The one-way function result is calculated as
C2_G(d_1, d_2) = C2_E(d_1, d_2) ⊕ d_2.

So that, too, requires the S-box.

And apparently, the flowchart is lying. Because the SD card wants you to go first, only then will it authenticate itself to you. So you can't use that to make it compute C2_G(arbitrary, K_mu) for you without you yourself being able to already do that. Maybe you could craft a fake SD card that tries to bait the accessing device into doing it or do MITM, but that's just theoretical.

Also, it doesn't actually return C2_D of anything, it returns C2_G. So you don't have a decryption oracle either.

If you had either an encryption or decryption oracle, you could recover the S-box which makes everything else more or less trivial.

Also, yay, more contradictions:

Each K_mu is 56-bit value and is pre-computed by the manufacturer based on each Media Key and the Media ID using the C2-Oneway function. Here, each Media Key is assigned by the 4C Entity, LLC, and is unique for each application group defined by the SD Association. Figure 3-2 shows the procedure of the Media Unique Key calculation. As shown in Figure 3-2, each Media Unique Key (K_mu) is calculated as
K_mu =[C2_G (Media Key, Media ID)]_{lsb_56}.

However, elsewhere in the standard it says the Media Key is derived from the MKB. That sounds more reasonable, though.

Looking on the bright side, there is one thing: The reference implementation (see "C2 Block Cipher Specification, Revision 1.0, January 1, 2003") is written in C, so most likely it's stored in software/NAND and not burned into a chip. In other words, it's at least theoretically possible to extract it without decap. At any rate, one would need to reverse engineer Japanese phones.

Is it possible to download firmware updates from somewhere other than OTA?

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.

tomman

Posted on 19-05-12, 23:24 (revision 2)

Dinosaur

Post: #318 of 1285
Since: 10-30-18

Last post: 16 days
Last view: 7 hours

In the old times, for some Western phones you used to source your firmwares from several places:

1) Shady forums with links to files of dubious origin hosted at Rapidshare/Megaupload
2) A friend of a friend that worked as a Level 3 (or whatever equivalent) Service technician at $OEM, or maybe a carrier shop that could perform firmware upgrades for customers (usually these two are the sources for 1)
3) Firmware sellers (often with vendor lock-in, as their firmwares would only work with proprietary boxes and not the $OEM flashing tools)
4) If you were lucky, your vendor would have a firmware update tool aimed at end users which interacted with the same server backends as 2), and with some trickery you could pull the updates from a temporary folder (or if you were lucky, a full firmware file)

But then with Japan being Japan, we can't count with such luxuries on their side. HowardForums used to have a dedicated section for Japanese phones, but I don't remember ever having read a post about anyone leaking DoCoMo/Softbank firmwares (unlike the rest of the board, where phone modding and reflashing was commonplace and firmware files were exchanged freely).

UPDATE: I lied. I DO have a couple of DoCoMo firmwares on my archives... but I doubt of its usefulness. Let me explain: As you know, Western-made cellphones were pretty much no competition for the highly superior gara-kei 3G phones from native OEMs. Still, once in a blue moon, local telcos would carry foreign phones for niche customers (dual 3G/GSM compatibility AKA "world mode" being one of such features; Japanese phones often lacked support for 2G GSM networks used outside Japan, as their 2G was a hodgepodge of proprietary junk used nowhere else). Nokia made phones for both DoCoMo and Softbank (this one even sold the N95 at some point... which was pathetic in comparison to your average keitai when you compare features, despite being a full-blown smartphone!). And Motorola also had three models available for DoCoMo's FOMA network:

- M1000: a FOMA-exclusive touchscreen phone.
- M702iG: Japanese version of the Euro RAZR V3x, but with added support for DoCoMo's unique set of UMTS bands and IrDA (a feature curiously absent from most Western Motos)
- M702iS: Same deal as the M702iG, but based off the V3xx. And for some reason, they crippled 2G support on this one!

Years ago, I came across firmware files for the M702iG/S models, and saved them because why not? But then those are ANCIENT FOMA phones, and with the same feature set as any ordinary overseas 3G RAZR. I don't even know if those firmwares would work on a Euro V3x(x) (maybe not, can't test for obvious reasons). From what I do know, those firmwares are standard Motorola fare, but with the (very rare) Japanese language pack, and some DoCoMo-specific customizations (for example, NetFront instead of Opera Mobile or whatever in-house browser Motorola was using at the time, according to this former Motorola engineer resumé). These are ordinary i-mode phones, and (at least for the M702iS) featuring a SD card slot, so MAYBE they could implement that dreaded .sb1 DRM crypto. Or maybe not, and instead you get ordinary Motorola's .dmj protection instead?

Let me know if you want those firmwares for playing - but don't get your hopes high! Those RAZRs are outliers in the island of Galapagos phones. But hey, It's Something™

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™

Duck Penis

Posted on 19-05-12, 23:54 (revision 1)

Stirrer of Shit
Post: #280 of 717
Since: 01-26-19

Last post: 1546 days
Last view: 1544 days

It's not for playing games. ~~Do you know if those phones support SD cards and making encrypted backups to SD?~~ If so, they should have the same S-boxes ("secret constant") as used for all the other backups ("unique per application", as in SD-Binding), which should enable you to decrypt the backups without much trouble, even without the original SD card.

That is, unless it's hidden in a TPM, or on a lower level than the firmware update can encompass, or in whatever microcontroller interacts with the SD card, or the firmware is encrypted with yet another key, etc.

S-box inside SD microcontroller seems likely, but I would think that the OS needs it too, since the backups seem to be done with awareness of individual apps and so.

EDIT: Whoops, my reading comprehension isn't the best. But yeah, it's definitely worth a shot, so please upload them somewhere.

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.

tomman

Posted on 19-05-13, 02:42

Dinosaur

Post: #319 of 1285
Since: 10-30-18

Last post: 16 days
Last view: 7 hours

Heh, apparently someone is still preserving those ancient Motorola firmwares, including the FOMA RAZRs!
https://firmware.center/.zdrive/z_gdrive_viewer.php?ID=1JuMk65l0j4o_kgqaJ0RA4UwJoqNEEzjF

- M702iG = "Scorpius Plus" = roughly a V3x
- M702iS = "Izar" = a crippled V3xx
Both are also internally known as V2000, for whatever reason. These phones are built over Motorola's "Argon" platform (one of their most popular native 3G chipsets instead of the Qualcomm junk they switched later on; my V9x also use it, among others)

These are standard Motorola .SBF firmware images, so you need to unpack them first
History lesson time! Time to dust off my Motorola phone modding workbench...

There are two formats Motorola used for distributing cellphone firmware images in the past:
- SHX: these are S-Record text files. For GSM firmwares you can use SHXCoDec to extract them. CDMA firmwares have a different layout, which I will not discuss this time.
- SBF: "Single Binary File", or something like that. All smartphones (both Android and Windows Mobile) and most UMTS featurephones use this format. Look for a tool called "MotoAndroidDepacker" to unpack those.

Whatever you do, you will end with a bunch of CGxx.smg files - these are known as "code groups" or CGs for short. The number identifies the purpose of the code group, and for those dumbphones here are the relevant CGs:
- CG1: Flash code <= This is the main firmware binary! You do want to dissasemble this one...
- CG2: Flex <= main filesystem, partition /a on P2K phones. You can unpack this one with a tool called "Simple Flex Parser". Look for version 0.4, and since this is a Japanese firmware, you will have to run it through AppLocale or LC_ALL=ja_JP.UTF-8 (if using Wine) as some filenames contain kanas.
- CG4: Language pack <= this contains fonts and localized UI strings. Can be edited, if you find a compatible tool for 3G phones
- CG15: "DRM" <= no, not the EVIL DRM! In this case, DRM is a weird way to say "graphics pack", as in every single menu icon and most other embedded pictures live here. Same as CG4, but you can scavenge this one with your favorite data recovery tool as all images here are in either GIF or JPG format.

CG15 contains a ordinary set of Motorola UI icons and pics, with a few DoCoMo additions - they didn't even bothered making a custom theme for those. CG2 contains a standard Motorola filesystem layout, so no surprises there if you ever messed up with a similar phone on this side of the pond. /a/mobile/kjava/ contains the preloaded J2ME apps... but the similarities ends there!

On a ordinary 3G Moto phone, you will see a bunch of j2meX.*** files (X is a number that increases for each installed app, starting at 0): for each MIDlet you have installed, you will find:
- j2meX.jar: the main JAR file for your app
- j2meX.dmj: If you installed the app over the air (that is, using the phone browser), you will find this encrypted (?) shit, that is tied to your IMEI (for SD installs, it's also tied to your SD card, but I don't know if western phones use the "S" in "Secure Digital", or if it is something more mundane, like the FAT volume ID)
- j2meX.jad: App descriptor, either the downloaded one (if installed from a JAD file OTA/with Java App Loader through a USB cable)
- j2meX.rms: RecordSet (persistent storage, for the MIDlets that use those)
- j2meX.gif/png: Default icon (as declared on the JAD), if present
- Some extra irrelevant files may exist for some apps.

...but this is a DoCoMo phone, therefore they speak DoJa instead of good ol' J2ME:
- JAR files are still there, but they no longer contain a valid JAD on the MANIFEST.MF file! This means you can't run those apps on standard western J2ME phones, much less on J2ME emulators! (They will complain that there is no valid app descriptor, because indeed there is none!)
- JAD files are gone. Instead we get .ADF files, which I guess are the DoJa equivalent of an app descriptor. They're still plain text files, but the structure is different: those can now pass parameters, set the draw area size, and even have a Last Modified date
- Everything else remains more or less the same.

Motorola is no stranger to i-mode, as DoCoMo tried (and failed) to market the platform overseas: there are i-mode versions of the L6/L7, and even a i-mode V3xx (which I don't doubt it borrows some bits from the M702iG/S!)

For completeness, here are the preloaded apps that can be pulled from those firmwares:
- j2me0: an image editor
- j2me1: a video editor
- j2me2: Hungry Fish (a simple game with unremarkable graphics)
- j2me3: OpeItOut (same)
- j2me4: a QR code scanner (M702iG only)
- j2me5: Gガイド番組表リモコン (looks like a TV guide service popular in Japan... which also doubles as a remote controller app! Which makes sense as those phones have an IrDA port. M702iG only)

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™

Duck Penis

Posted on 19-05-13, 20:26 (revision 2)

Stirrer of Shit
Post: #281 of 717
Since: 01-26-19

Last post: 1546 days
Last view: 1544 days

Thank you.

I've downloaded both firmwares, but I can't get MotorolaAndroidDepacker to run under Wine. It wants .NET, but neither Microsoft .NET or Mono 2.10 works. In both cases, nothing happens when I run it:


C:\Program Files\MotoAndroidDepacker-1.2alpha3>dir
Volume in drive C has no label.
Volume Serial Number is 0000-0000

Directory of C:\Program Files\MotoAndroidDepacker-1.2alpha3

 5/13/2019            <DIR>         .
 5/13/2019            <DIR>         ..
 5/13/2019                 109,568  MotoAndroidDepacker.exe
 5/13/2019                     405  MotoAndroidDepacker.xml
       2 files                  109,973 bytes
       2 directories                    bytes free


C:\Program Files\MotoAndroidDepacker-1.2alpha3>MotoAndroidDepacker.exe

C:\Program Files\MotoAndroidDepacker-1.2alpha3>

No errors or anything, but nothing pops up. I'm running in PlayOnLinux, but that shouldn't make a difference - it's still Wine under the hood. Just doing wine ./MotoAndroidDepacker.exe tells me I need to install .NET.

Any pointers?

Also, do you have any advice on the actual reverse-engineering? For instance, some stuff looks to be written in C/C++. What tools would you recommend using for those binaries? And is there such a thing as static analysis for J2ME, or do I have to decompile it and look at the reconstructed "source code"?

Is the firmware signed? Would it as a last resort be theoretically possible to edit it so that one can dump the filesystem to the SD card without encrypting it?

EDIT: It seems like SD-Binding (.sb1 drm) is listed on a feature on all models that have it, and I can't find anything about the M702iS having it. It was listed as an explicit feature for the 902i series (see https://www.nttdocomo.co.jp/english/binary/pdf/corporate/technology/rd/technical_journal/bn/vol7_4/vol7_4_020en.pdf), but it might have been in phones earlier than that too.

Anyway, there's this 2ch browser for FOMA 90x phones, and that seems to have support for SD-binding to save data (?) to SD card. So if you have physical access to e.g. a N902i, then you might be able to force it to encrypt arbitrary data with an unknown key. No idea how much access you get. If it provides an API where you get a key, a function pointer to encrypt(), and get told to go wild, then of course it would be jackpot. But I would think it's something far more mundane, because they should have the good sense not to directly expose the encryption primitives. And if we diff the SD and no-SD versions' .JAM files, we see that the only change (other than "parameter", which seems to be the filename), is this line:


UseStorage = ext

Which makes me think that it just provides wrappers over whatever Java has instead of fwrite and friends in C, and encrypts it in the background.

That has support for the M702i anyway, and it has separate versions for with and without SD. So it's possible that M702iS does get SD-binding, but it's not documented anywhere.

(For some reason, you can only download the files from the actual phone, but you can guess the URL from the filename; the jar is at http://woontai.dip.jp/w2ch041/w2ch_client.jar)

Do you have any old Motorola phones lying around? If so, you could test if it supports SD-binding. If you try to back up a .dmj file to an SD card, and then dd the whole block device to another SD card, that would keep the FAT volume ID and everything, but not the secured parts. So if it still reads it from the new SD card, there isn't any SD-binding support.

EDIT 2: I'm fairly certain M702iS doesn't support SD-binding, because there's this passage in the manual (https://www.nttdocomo.co.jp/binary/pdf/support/trouble/manual/download/m702is/M702iS_J_13.pdf, pg245):

• ファイルによっては、コピー／移動できない� �合があります。
• 本 FOMA 端末に保存されている Flash、キャラ電は、microSDメモリーカードにコピー／移動できません。

Google Translate:

• Some files can not be copied / moved.
• Flash and Chara-den stored in the FOMA terminal can not be copied / moved to microSD memory card.

Chara-den is キャラ電, "a function that allows you to make a call by sending and receiving images of characters". Character in the sense of avatar, not grapheme. Flash is written with romaji, so presumably that's referring to Macromedia Flash and not flash memory.

Also, other phones (e.g. N902i) lists more stuff under spec. Compare:
https://www.nttdocomo.co.jp/support/utilization/product/m702is/spec.html

Note 13 About the data that can be saved:
Captured image / voice etc

https://www.nttdocomo.co.jp/support/utilization/product/n902i/spec.html

Note 5 About the data that can be saved:
Phonebook / sent / received mail / photographed image / bookmark / voice etc

The manual for the M702iS also says that the folder structure is different from other terminals. Compared to what? Who knows. Either for all the Motorola phones, or the G, or the S.

•本FOMA端末で使用したmicroSDメモリーカードは、FOMA M702iGでもご利用になれます。た� し、その他のFOMA端末とはフォルダ構成が異なるため、そのまま他のmicroSDメモリーカード対応のFOMA端末に差し込んでもご利用できません。

• The microSD memory card used on this FOMA terminal can be used on the FOMA M702iG. However, because the folder configuration is different from other FOMA terminals, you can not use it as it is by inserting it into another microSD memory card compatible FOMA terminal.

But anyway, the Motorola track seems like a dead end.

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.

Duck Penis

Posted on 19-05-13, 21:19 (revision 1)

Stirrer of Shit
Post: #282 of 717
Since: 01-26-19

Last post: 1546 days
Last view: 1544 days

Okay, so here's something interesting:
http://www.jollen.org/blog/2006/09/linux_smartphone.html
Apparently, the N902i runs Linux.

And the NEC even open-sourced the software of the N-01G.
http://www.n-keitai.com/gpl/n/list/n-01G.html

And the N-01G supports SD-Binding.

Then that ought to mean one of four things, in reverse order of likelihood.
1) they're utter madmen who open-source stuff they're contractually under NDA to keep secret
2) the C2 algorithm is implemented in hardware
3) they took out the C2 algorithm before open-sourcing it (why not only remove the secret constant?)
4) the C2 algorithm is implemented in software, but at a higher level than the stuff they chose to share

I'd think 4, because there's no references to other strings used in backups either (see https://www.nttdocomo.co.jp/binary/pdf/support/trouble/manual/download/N-01G_J_OP_01.pdf, pg310)

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.

Duck Penis

Posted on 19-05-13, 22:23

Stirrer of Shit
Post: #283 of 717
Since: 01-26-19

Last post: 1546 days
Last view: 1544 days

https://web.archive.org/web/20190314051233/https://www.engadget.com/2010/11/17/windows-phone-7s-microsd-mess-the-full-story-and-how-nokia-ca/

According to this article, both Windows Phone 7 and Symbian support SD card protection.

I found a guide on how to remove the password protection (e.g. nuke the protected area) that WP7 phones automatically set up on all SD cards you insert into them (!), and that had a link to a file named DEV_STORAGELOCK.cab. That contains an file named StorageLockTool.exe. And it has some very interesting strings:

unlock
lock
locked
unlocked
The storage card is currently %s. Do you want to %s it?
SD Card Lock
No storage card detected.
Failed toggling card lock.
Operation successful.

It's too small to actually implement it, so it should call some library or something. And WP7 is fully dumped, right?

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.

tomman

Posted on 19-05-14, 00:58

Dinosaur

Post: #320 of 1285
Since: 10-30-18

Last post: 16 days
Last view: 7 hours

Almost all FOMA phones use a proprietary DoCoMo platform, MOAP. There are both Linux and Symbian-based versions of MOAP (MOAP-L/NOAP-S). Those Motorola phones are a notorious exception, as they are just standard Motorola P2K05/Synergy phones with the i-mode/DoJa bits replacing the usual Opera/JBlend stack.

As for the MotoAndroidDepacker, I just ran it on my ol' XP laptop, where I only have .NET 3.5. But I've just tested on my Debian Stretch laptop:

tomman@himawari:~$ mono --version
Mono JIT compiler version 4.6.2 (Debian 4.6.2.7+dfsg-1)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug 
        LLVM:          supported, not enabled.
        GC:            sgen

...and it runs just fine with that Mono version, FWIW.

Sadly, Argon firmwares are signed, and noone cracked the RSA stuff as it was done for earlier 2G phones (it was pretty much a requirement to get rid of the signed .JAR requirement for accessing restricted APIs, like filesystem access or GPS; for 2G phones on platforms like Neptune LTE all you needed was a hacked bootloader to get rid of the RSA signature crap). Trust me on this one: back when those 3G RAZRs were the hotness, people tried... and all we got were heaps of bricked phones, because Argon was less forgiving than any previous Motorola mobile chipsets. Once the RAZR2 and friends
became old news and Moto led the Android revolution, people just moved on, and our bootloaders remain uncracked as of today. A modified bootloader is a requirement for custom/hacked firmwares, and flashing an improperly modified bootloader is an easy way to get a unrecoverable brick. Same as crossflashing: it's very tempting to just buy an Euro V3xx and apply the M702iS firmware on it. People tried (some just wanted that Japanese langpack), but it was a one-way ticket to Brick City. The only (known) way to revive hard bricks are using very expensive service boxes (the same ones used by those phone unlocking shops), where taking the phone apart and shorting test points is part of the procedure.

My RAZR V9x does the .dmj shit, but sadly the flex cable just broke a month ago and therefore the displays are dead, so the phone is pretty much unusable for those purposes as-is :/ (Mind you, it STILL works as a phone... as long as you have memorized your phone book, or use it as a modem)

IIRC Nokia Symbian phones could password-lock SD cards, but never knew how these phones did it. All I remember is that it was a pain to reuse that cards on other phones should you forget to unlock them on a Nokia phone...

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™

Duck Penis

Posted on 19-05-14, 15:57

Stirrer of Shit
Post: #284 of 717
Since: 01-26-19

Last post: 1546 days
Last view: 1544 days

Posted by tomman
Almost all FOMA phones use a proprietary DoCoMo platform, MOAP. There are both Linux and Symbian-based versions of MOAP (MOAP-L/NOAP-S). Those Motorola phones are a notorious exception, as they are just standard Motorola P2K05/Synergy phones with the i-mode/DoJa bits replacing the usual Opera/JBlend stack.

And that isn't dumped?

IIRC Nokia Symbian phones could password-lock SD cards, but never knew how these phones did it.

That should be SD-Binding, like WP7 and the Japanese phones, or at least something very similar. It should have to implement the same S-box at least, which is all that matters.
Is there anywhere you can download a full firmware dump of them?

All I remember is that it was a pain to reuse that cards on other phones should you forget to unlock them on a Nokia phone...

But it was possible, somehow?

As for the MotoAndroidDepacker, I just ran it on my ol' XP laptop, where I only have .NET 3.5. But I've just tested on my Debian Stretch laptop:

tomman@himawari:~$ mono --version
Mono JIT compiler version 4.6.2 (Debian 4.6.2.7+dfsg-1)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug 
        LLVM:          supported, not enabled.
        GC:            sgen

...and it runs just fine with that Mono version, FWIW.

Right, I was trying to run it in Wine.
Well, it doesn't matter though, since the Motorola firmware is most likely useless.

Sadly, Argon firmwares are signed, and noone cracked the RSA stuff as it was done for earlier 2G phones (it was pretty much a requirement to get rid of the signed .JAR requirement for accessing restricted APIs, like filesystem access or GPS; for 2G phones on platforms like Neptune LTE all you needed was a hacked bootloader to get rid of the RSA signature crap).

How about the Japanese phones? Would they use strong RSA too? I can't find any firmware anywhere, just their tools that download and flash it for you.

My RAZR V9x does the .dmj shit, but sadly the flex cable just broke a month ago and therefore the displays are dead, so the phone is pretty much unusable for those purposes as-is :/ (Mind you, it STILL works as a phone... as long as you have memorized your phone book, or use it as a modem)

Do you have any samples? I can't find anything on Google for "dmj file" or "dmj file motorola". Do they go by another name in specifications and such?

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.

tomman

Posted on 19-05-14, 18:32

Dinosaur

Post: #321 of 1285
Since: 10-30-18

Last post: 16 days
Last view: 7 hours

You should assume that if it runs firmware AND works on Licensed Radio Spectrum™, it HAS to be signed. Sometimes it's even a requirement from carriers too. Things like BREW exist for the benefit of the carriers, not for the OEMs themselves (Nokia particularly hated BREW, and this is a reason of why Verizon rarely sold their phones). And then, there is good ol' "protect MUH IP" paranoia.

"RSA" is commonplace. Except for shit-tier garbage Chinese junkphones, all serious OEMs do sign their firmwares, and those phones often have several layers of security for preventing the run of unsigned/modified firmware. But then, most of the times the security is down to the second stage bootloader: compromise that one and you own the phone. Remember the Wii's signing bug? (Trucha) Well, sometimes that second stage bootloader isn't even signed (this is why hacked bootloaders are a thing), but messing with those is very delicate due to the bricking risks. Sometimes you're lucky and you get a chipset with decent anti-brick measures... but most of the times, a stupid, simple error and it's game over.

Here are a couple .dmj samples pulled from my V9x:
https://mega.nz/#!19sjCAaJ!SVM0xqseQRSb_lssiks9370F2mTqmX_OaO6rgdwSnRU
Device IMEI and SD card (a 4GB Kingston microSDHC) VFAT volume ID are in the "dump_info" file. The apps are versions 4 and 5 of Opera Mini. All phone-generated files are there, including recordsets (.rms), JAD files, icons, and even the original .JAD download URLs. I've also included the J2MEST file, which seems to be a registry of all installed apps on the memory card.

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™

Duck Penis

Posted on 19-05-14, 20:09

Stirrer of Shit
Post: #285 of 717
Since: 01-26-19

Last post: 1546 days
Last view: 1544 days

You should assume that if it runs firmware AND works on Licensed Radio Spectrum™, it HAS to be signed. Sometimes it's even a requirement from carriers too. Things like BREW exist for the benefit of the carriers, not for the OEMs themselves (Nokia particularly hated BREW, and this is a reason of why Verizon rarely sold their phones). And then, there is good ol' "protect MUH IP" paranoia.

"RSA" is commonplace. Except for shit-tier garbage Chinese junkphones, all serious OEMs do sign their firmwares, and those phones often have several layers of security for preventing the run of unsigned/modified firmware.

Yeah, but they can mess up the implementation, e.g. small keys. But Motorola is a serious company, or at least was at that time, so they'd probably use a big enough prime size.

As for the files you sent:
* There appears to be some kind of header. The both .dmj files share their first 16 bytes, but the .jar files only share their first 10. There's no resemblance in the .dmj files after this.
* One .dmj file (j2me1) is 23 bytes larger than its corresponding .jar, the other 29 bytes.
* Both .dmj files' sizes are evenly divisible by 16. (32 if you don't count the "header")
This seems to suggest that 16 bytes were added to the start of the files, then they were padded to the nearest 16-byte increment.

Now, most likely is probably that the files were then encrypted wholesale. Maybe the first 16-byte chunk serves as something like TrueCrypt's "TRUE". That is, not a header, just a known value to compare to to check the decryption succeeded. Then:
1. The files used the same key for encryption
2. The block size of the algorithm is 128 bits
3. CBC mode or similar was used

It could also be that the first 16 bytes are an initialization vector for CBC. But that still would mean a block size of 128 bits, CBC mode.

What I don't think we have is a header as used in SD-Binding. Because that uses 64-bit block sizes and unencrypted headers. Also, the samples I've seen had longer, unencrypted headers.

This should mean Motorola doesn't use C2 encryption. In that case, I don't see why they'd use the SD card's Protected Area. Possibly they'd use the serial number, Media ID, or something like that to get a bit more protection, but that's enough, and it's a lot more implementation work they'd need to do to gain access to the holiest of holies for very little gain.

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.

Duck Penis

Posted on 19-05-16, 19:08

Stirrer of Shit
Post: #290 of 717
Since: 01-26-19

Last post: 1546 days
Last view: 1544 days

Posted by Content Protection for Recordable Media Specification: Introduction and Common Cryptographic Elements
A properly formatted MKB shall have exactly one Verify Media Key Record as its first Record. Bytes 4 through 11 of the Record contain the value
D_v = C2_E(K_m, DEADBEEF₁₆ || XXXXXXXX₁₆)
where K_m is the correct final Media Key value, and XXXXXXXX₁₆ is an arbitrary 4-byte value.
The presence of the Verify Media Key Record in an MKB is mandatory, but the use of the Record by a device is not mandatory.

As an optimization, a device may attempt to decrypt D_v using its current K_m value during the processing of subsequent Records, checking each time for the condition
[C2_D(K_m, D_v)]_{msb_32} == DEADBEEF₁₆
where K_m is the current Media Key value.
If this condition is true, the device has already calculated the correct final K_m value, and may therefore stop processing the MKB.

Reading the MKB (in full) requires no authentication at all. Just send the GET_MKB command a few times.

So offline brute-forcing should get you 2^24 candidates for K_m. With two SD cards, that would enable you to easily get K_m by doing a quick union query.

On my CPU, one C2 encryption operation takes around 12 ns, or 2^26.3 ops/s. (single-threaded, C, -O3, their implementation unmodified, random S-box).
Using all four cores, that'd be about 2500 days of CPU time.
With AVX and elbow grease, I'd reckon you could reduce this number by about 5-25x. With GPU I don't know. Some post on the hashcat forum suggests about 30x, but I don't know if CPU OpenCL is as fast as a proper hand-made AVX implementation. Let's say it is. Then under those ideal conditions, one person could brute-force it in around 80 hours of computer time (worst-case, avg 40h).

If you only get a 10x reduction, no GPUs, and are ten people, it'd take you about a month (worst-case, avg two weeks).

So a brute-force is doable, but hardly a pleasant experience or one you'd want to do more than absolutely necessary.

I think you'd need to do two brute-force operations as above to get Km, then for each Km one brute-force operation per column. I don't know if you'd need all 16 columns, the brute-force attacks mentioned on wikipedia all use col 0, but I don't know why else you'd want to. Maybe it's so if only one device key leaks that can be revoked without having to replace the device?

I would think the easiest way to go at it would be some kind of cloud project (assuming the S-boxes are ever found) where you can submit MKBs, have them checked against a database of previously recovered keys, and contribute to the recovery of device keys. And with the device keys, you could decrypt the protected section of any medium, which is just ordinary FAT12, and Bob's your uncle.

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.

tomman

Posted on 19-05-21, 01:26

Dinosaur

Post: #340 of 1285
Since: 10-30-18

Last post: 16 days
Last view: 7 hours

Just for completeness sake, I took a look at the internal P2K filesystem at my V9x.

This phone came with several preloaded apps, among them, Google Maps. I remember having upgraded it OTA sometime around 2012, which means it should have the .dmj DRM crap. And indeed, there was a .dmj file for it. But after copying it back to my PC, to my surprise the .dmj was completely unencrypted - the phone just changed the .jar extension to .dmj!

This could mean that the phone protects OTA downloaded apps only if stored to the SD card - if installed to the internal memory, it's enough to copy and rename, and there is your preserved .jar. Flaw or by design? Noone cares :P

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™

NaoyaShinota

Posted on 22-05-13, 21:23

Post: #1 of 1
Since: 05-13-22

Last post: 705 days
Last view: 704 days

Some interesting stuff here. I love video game preservation. My main focus has been cell phones as I have joined a discord that focuses on this said subject. Where to start as I have a lot to share about this stuff. I liked how their is a bit more detailed stuff with the M702iS/M702iG on the internet. That is so far the only known Docomo FOMA phone that has some flashing or hacking method available due to the fact that it’s a modified Motorola phone.
Here are some tools that do work with the M702iS/M702iG
MSnap: (Works) this tool takes a screenshot of the screen of your phones screen.

Flash & Back up is able to extract firmware from the phone. And it is able to use it to tell the phone to turn off and reboot.

P2K Commander: this program seems to be the one that just freezes and crashes when it detect the phone. Many versions have been tested on different windows systems and even virtual box. I am still looking into this a bit more.

DataLink: a software made by Docomo which lets you transfer i motion, mld, pictures and other data (except for I-appli) to the phone.

Test Mode: you can access Test Mode on the M702iS/M702iG by using putty and using the command
at+mode=8

Boot Loader Mode: hold down the * and % key while inserting the battery and you will be treated with a screen that provides boot loader info and such. Here is an example of what my M702iS says
Boot Loader
03.03
SW Version
V2000_U_90.21.0C.1I

Battery OK
OK to Program
Connect USB Data Cable
(Even with this I still have problems with P2K Commander)

The M702iS runs DoJa 4.0LE. This was for overseas version. Docomo uses DoJa and Star for their phones depending on what phone you have.

So why am I bothering to hack/flash mod this phone? An outdated phone that you can’t use anymore. I mainly want to make my own i-appli with it as well. The only way to download I-Appli to this phone is through its iMode browser with a iMode subscription. However iMode subscription can no longer be done as it stopped a few years ago and iMode store has shut down in 2021 November 31st. But a small amount of the games have been saved. But not all of them. Due to the lack of access we have to gain knowledge of this subject. I plan on backing up the firmware and all contents possible for the following SW versions of M702iS and M702iG

M702iG
V2000_U_90.21.0C.14I

M702iS
V2000_U_90.21.0C.B2I
V2000_U_90.21.0C.14I

I am still trying to learn more about this phone and find different ways of what you can do to it.

Note that with all of this. This is the first Docomo phone to be able to get this far.

Pages: 1

Main » Discussion » Cellphone software preservation

bboard