tomman |
Posted on 19-05-08, 15:48 in Mozilla, *sigh* (revision 3)
|
Dinosaur
Post: #301 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Repeat after me: CRYPTOJUNK IS NOT REAL MONEY. In particular, I don't get your ire against crypto. People are buying bitcoins for VES, so wouldn't it be a good way to make money? Even if you remain steadfast in the conviction that it's outright fraud, it should be extremely profitable. Yeah right, next you're going to tell me that becoming a bank robber should be extremely profitable too, nevermind the fact it's also extremely illegal (i.e. a crime). Sorry but no. Those Venezuelans "buying" into the cryptocraze are nothing but a tiny TINY minority that are well aware they're walking on quicksands (but anyone over here is so desperate to eat they're willing to do whatever weird/shady acts they can, as long as they can eat, damned be the consequences later). I can't believe I have to say this again, but I've met people that actually have dealt with cryptojunk. Close friends of mine, even! They all left the business after making a tiny profit (or even nothing at all9 because it's too volatile (win $100 in a day, then lose $400 in one hour - what the hell is this, Vegas?!) and too shady (I guess you don't read the news about those LOLcryptoexchanges going bust or taking the money and run away) to become a full-time job. And then you have the commies that are trying to use cryptojunk as the vehicle to commit outright fraud legally. Hey, I heard the local crypto authority (yes, what a fine waste of our national budget: backing smelly buttcoins that not even scammers want) is hiring, why not apply there?! But hey, saying "poor starving Venezuelans are buying buttcoins like crazy" sure works for the headlines of whatever they want to pass as "journalism" nowadays, right? Nevermind the fact we don't even have working Internet connections with enough stability to do a good ol' fashioned ELECTRONIC FUNDS TRANSFER, much less for waiting to the blockchain to do the same. Cryptocurrencies are a fad. Cryptocurrencies are a scam. Cryptocurrencies are an easy way to get fools parted from their money. Cryptocurrencies are far worse than Wall Street sharks. And cryptocurrencies really hit the shitter when either Big Money and/or the gub'mints try to take a slice of the pie. Repeat after me: CRYPTOJUNK IS NOT REAL MONEY. I'll stick to ol' smelly USD, shiny new EUR, or failing that, good ol' worthless VES, thanks. If you run a website, you can find other ways to get your shit funded. Internet has always found a way, from postcards to Kickstarters, all of them on the legit side. Don't waste your time, my position is already set in stone. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 19-05-08, 16:35 in I have yet to have never seen it all. (revision 1)
|
Dinosaur
Post: #302 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Orrible® in its neverending war against its own users, just found a way to ensure noone will use Java for any future project, enterprisey or not: https://headcrashing.wordpress.com/2019/05/03/negotiations-failed-how-oracle-killed-java-ee/ What's the point of opensourcing something if you're going to demand that said code can't be touched after you release it!? Basically they're a trojan at the Eclipse Foundation right now, and they tried to pull one of their world class famous business stunts to drive Eclipse (the foundation AND the IDE) right into the ground. Naturally, they refused. This now means that the opensource edition of J2EE is DOA, because they will be forced to rename every single package (basically everything that lives at javax.*, which is... everything!), change APIs, and the like. Noone is insane enough to rewrite perfectly working enterprisey apps (how do you explain to a bank or big corp that Orrible is forcing them to do a total refactoring of everything just to please Larry's tantrums?!), so for all purposes, Java EE is now confined to legacy applications. Ah right, that's why One Raging Asshole Called Larry Ellison is too busy trying to sue Google for the right to copyright APIs (and fuck up the entire software development industry as we know it, be it proprietary or FOSS) As a J2EE developer that has yet to touch the gory bits (nevermind the really gory bits like JAX-RS or JCA), all I can feel is rage and sorrow. What a great way to ruin a perfectly fine (if painful at times) enterprise application development framework. All of this just because someone took a dump over one of lil' Larry precious boats and he has now to pay the boat cleanup service bill. Someone please suggest me a image which encompasses one hundred times :linusfinger: But hey, Javascript is there to save the day! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 19-05-08, 17:19 in I have yet to have never seen it all. (revision 1)
|
Dinosaur
Post: #303 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Posted by sureanem Why not quote the full comment? This would work only if nobody ever adds new interfaces or more methods and parameters to existing ones, because the application needs to compile agains an interface-only API jar in the original javax namespace, which must not get produced due to Oracle’s trademark restrictions. If the trick shall be used even in the compile (not the runtime) phase, you need to recompile the application so it explicitly loads the classloader, which still means, Java EE is dead, as existing software fails to run unchanged. Anyways in the “unchanged” case, Oracle allows to keep the javax namespace anyways, so the trick is not needed. The result still would be that Java EE is dead, as nobody could add new features. This may work for your average outsourced overbudget piece of junk, but not for anyone that actually cares about their sanity (and software audits!). I myself won't be walking that minefield, and certainly I'm not alone on this. But all Orrible wants for you us to buy Java EE could have had a bright future as opensource, considering the competition. Hell, I don't even mind a renaming of the project (they settled with Jakarta EE) to make sure people could distinguish between the closed Orrible flavor and the open community edition. They even correctly choose Eclipse over Apache (where unloved Orrible software goes to die), as those guys actually know their Java mojo. But the devil is on the details, and well... that's where Larry's corporation shines, and not in a good way. Noone serious would want to go through a Rube-Goldberg-esque fragile solution so they can continue doing business as usual, much less taking with Oracle's proposals. One thing is dealing with deprecations every now and then (old, horrible APIs should be shot dead on the spot, and sane replacements built in place), or new stuff that can actually make your life easier. But having to rewrite large portions of your code for no practical advantage AT ALL (this is not Python 2->3 or PHP5->7) just due to licensing BS thanks to greedy lawyers!? That's a sure way to drive away your most devote developers, and to ensure that noone would want to touch your platform EVER AGAIN. Java has a bad rep, but MOST of it is thanks to Oracle, not due to its flaws/quirks as a language/platform. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 19-05-08, 19:28 in Mozilla, *sigh*
|
Dinosaur
Post: #304 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
All right, here is n-gate's take on the whole situation:All extensions disabled due to expiration of intermediate signing cert I love how the nerdsphere likes to "solve" browser problems: - Is Mozilla flipping the finger at you? Switch to Chrome! - Is Google too evil for your pure soul? Switch to Firefox! And now, with IE dead (well, almost!), Edge/Opera being reskinned Chrome, and with all other minor players mostly being also Webkit derivatives... damn. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 19-05-09, 01:01 in Mozilla, *sigh* (revision 1)
|
Dinosaur
Post: #305 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Posted by CaptainJistuce You... can do that? ...apparently yes! Well, time to revive my Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 19-05-09, 02:24 in I have yet to have never seen it all.
|
Dinosaur
Post: #306 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Posted by Nicholas Steel Fun fact: the DVD sets for the first 3 books of Korra do have the LA Spanish dub. For whatever reason, Nickelodeon/Viacom/Paramount/whatever decided to forgo it on the fourth book set. Which is a shame, and since Korra died an uneventful death on Nick LA (the last 2 books were streaming-only, and the Nick LA website is/was a steaming pile of donkey excrement), that means those episodes are now lost for us at the south of the border... Coupled with the removal from the Platinum Games-made Korra game (which I've heard it was good, albeit short) from all sales channels due to some publisher BS, well... it's suffering to be a unwanted IP aimed at the "wrong" demographics :/ I never liked Avatar (found it utterly boring). Paradoxically I really liked Korra, so go figure. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 19-05-09, 02:43 in Mozilla, *sigh*
|
Dinosaur
Post: #307 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Posted by Nicholas Steel I was there when GMail happened. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 19-05-09, 11:33 in I have yet to have never seen it all.
|
Dinosaur
Post: #308 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Posted by CaptainJistuce Good ol' executive meddling. The Men In Expensive Suits didn't wanted a Female Protagonist show like Korra for whatever reason (can't remember the real excuse right now, but it could have been something down the lines of "we're targeting 12yo boys, so Korra is an ill-suited character for them" or something stupid like that). They half-heartedly greenlit the show, but expected to flop after a single season (this also explains why the animation was done by Studio Pierrot in a tight budget, rather than continuing with Studio Mir, which already excelled with Avatar). They got wrong. Korra was a hit just like Avatar was. Still, they continued with their goal to doom the project, although they had to acknowledge that they had to up the production values (this is why for the second book they switched back to Studio Mir for the animation work). They started screwing up with the scripts, denying TV slots to the show (it's streaming-only for most locales), and finally axing the show after 4 seasons. Man, fuck Nickelodeon. Reminds me a bit of the fate of other classic Nicktoons like Rocko's Modern Life and Invader Zim: get off-target-demographics (even slightly) and you're dead, instead of moving the show to another, more suitable content block. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 19-05-09, 16:31 in Board feature requests/suggestions
|
Dinosaur
Post: #309 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Time to migrate to PostgreSQL. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 19-05-10, 02:28 in I have yet to have never seen it all.
|
Dinosaur
Post: #310 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Totally innocent game cover: (Also: the idea of playing Puyo Puyo on a monochrome display is... strange, to say the least) Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 19-05-10, 11:39 in Board feature requests/suggestions
|
Dinosaur
Post: #311 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Oh, so it's not my horrible connection then. THIS TIME. Been noticing the same delays at random, but dismissed those as "ugh, not again...". Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 19-05-10, 16:27 in Board feature requests/suggestions (revision 2)
|
Dinosaur
Post: #312 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Open main page (instant)->enter Discussion board(~0.01sec)->go to the last post to this thread:Page rendered in 10.723 seconds with 28 MySQL queries. Edit this post(1 sec)->post(1.1 sec)->edit again (1 sec). Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 19-05-11, 00:07 in Games You Played Today REVENGEANCE
|
Dinosaur
Post: #313 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
AFAIK there is no preservation project aimed at cellphone games of ANY era, much less from the pre-iPhone/Android age. Then there is the issue that, just like BREW, J2ME games were mostly phone-specific. If you stick to the very basic stuff, you can achieve a universal MIDlet... but as soon as you want to use the action buttons of your phone, display sizes (and extended canvas modes: do you want to hide EVERYTHING, even the status bar? That's very OEM-dependant!), among other things, you need model/manufacturer-specific targets. For example, years ago I downloaded a pirate version of Sega Puzzle Pack (the MIDlet said "BiNPDA", which it seems it was a warez group for the cellphone "scene"). Apparently it was for some Nokia or Sony-Ericcson model, as the both the input and canvas size were completely screwed up on my Motorola V9x. There were tools you could use to work around these incompatibilities (a well-known one was Java Adapter for Mobile, which hacked the MIDlets to modify keycodes and inject some extra Java classes to deal with the canvas modes), but even then the results were very YMMV (in my case the softbutton labels were partially off-bounds, rendering those unreadable) Noone really cared about cellphone games in the early dumbphone era. Just imagine all those sophisticated Japanese i-mode games that are now lost forever because there simply was no cellphone app piracy scene in Japan (or even a homebrew scene, for that matter). Western J2ME was a low-hanging fruit, but even then noone gave a damn :/ At least I managed to archive the two games I bought for my V9x (Gameloft's Block Breaker Deluxe 2, Glu/Sony LocoRoco Hi) way back when Movistar ran their own local appstore for dumbphones: the download links were completely unprotected; all you needed was to know the exact URL for your game, and your favorite download tool would do the rest (WTF Telefonica?!). In the case of Motorola phones, filesystem access was trivial, allowing me to dump the Opera Mobile cache... where the links were waiting for you on a cached HTML file :) But then, those wouldn't work properly on any other phone than a V9(x), mainly due to the different keycodes (the games will run, but you will be unable to properly interact with the menus, much less to play a game!). If you were curious: No, you couldn't simply copy the .JAR from your filesystem: those Moto phones DID protected OTA-downloaded MIDlets with some unknown DRM that turned those into encrypted .DMJ files that would be tied to your IMEI (and the volume ID of your SD card, if you choose to store your apps there... which meant that if you upgraded the storage on your phone, you HAD to download your apps again!). MIDlets installed over Bluetooth or USB weren't protected by this anticonsumer bullshittery. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 19-05-12, 03:52 in Games You Played Today REVENGEANCE (revision 2)
|
Dinosaur
Post: #314 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Posted by sureanem Fair warning: EZweb = BREW (KDDI au is CDMA, thus their cellphones are Qualcomm-based by force), hence undumpable. Also, didn't knew i-mode games could stop working if your phone didn't had an active service (I already expected DRM/crypto, but this is completely nuts). I DO know that Softbank locks out pretty much every cool feature on their phones (except for making calls) if they don't have an active Softbank SIM card - this is better known as "multimedia lock", ensuring that your phone only works as a PHONE (and nothing else) if you're not chained to an active phone service. Gross. Holy shit, the fixation of Japanese carriers with DRM is unreal. It's like Verizon/Qualcomm, but one hundred times worst. If anything, it's a blessing that they're finally embracing Android, where ripping .APKs is mostly trivial. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 19-05-12, 14:09 in Cellphone software preservation
|
Dinosaur
Post: #315 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 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™ |
tomman |
Posted on 19-05-12, 14:10 in Games You Played Today REVENGEANCE
|
Dinosaur
Post: #316 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
I've opened this thread for discussing the cellphone perservation stuff, so let's continue there~ Note to myself: attack my endless VN backlog! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 19-05-12, 15:28 in Cellphone software preservation
|
Dinosaur
Post: #317 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 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 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™ |
tomman |
Posted on 19-05-12, 23:24 in Cellphone software preservation (revision 2)
|
Dinosaur
Post: #318 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 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™ |
tomman |
Posted on 19-05-13, 02:42 in Cellphone software preservation
|
Dinosaur
Post: #319 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 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™ |
tomman |
Posted on 19-05-14, 00:58 in Cellphone software preservation
|
Dinosaur
Post: #320 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 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:
...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™ |