Hopefully this file is what you’re looking for.
I don’t see anything that says Flag 0xEF is needed, or how to enable it.
You just turn on the flag in an event, with an event command. Just like how you use event commands to load units or display dialogue.
1 Like
All you have to do is enable flag 0xEF.
There was a discussion about this the other day.
How will adding a command in Event Editor help me install the MGC For SkillSystems patch?
…actually, nevermind. Don’t worry about it. I’m not trying to do this for a mod myself - I just saw something that looked like it was broken, so I reported it. If it’s not broken, that’s all I need to know 
Thanks anyway!
After looking into it a bit more, I don’t get the issue when playtesting via the builder, but then I get the issue when playing through it normally.
I’ve sent the report on discord.
A major update of FEBuilderGBA was performed.
The ROM pointer constants have been modified.
This will allow FEBuilderGBA to open ROMs that are not readable by FEBuilderGBA or that intentionally do not let him read them.
ROMs have not one but multiple pointers.
For example, the Unit pointer is not only in 0x10108, but also in 0x104EC and 0x10538.
Until now, only 0x10108 has been used, but if this cannot be obtained, other pointers are looked for.
This allows us to open ROMs even if a particular pointer is damaged.
Allow users to define pointers directly for cases where there is only one pointer or where the above methods cannot be used to track it down.
If a file named YOURROMNAME.custom_pointer.txt is created with the same name as the ROM, its contents will be referenced.
This content is a tab-delimited key value type definition file.
For example, if portrait_pointer is moved to 0xA59B08 instead of the default 0x005524, you would define the following
portrait_pointer 0xA59B08
class_pointer 0x17ADC
YOURROMNAME.custom_pointer.txt for YOURROMNAME.gba, and so on.
Creating this file is a bit more difficult because of the knowledge of the FEBuilderGBA source code and the knowledge of ASM.
Please refer to this file to see what constants are available.
You can use C# reflection to rewrite all uint type constants.
4 Likes
If an author wants to hide something to prevent FEB find it, it means that he does not want the corresponding module to be misappropriated or modified by others. Sorry that such a comment might be a bit mean, but I don’t think it would be wise to force the author’s encrypted part to unpack.
If that is the case, I recommend developing more stronger encryption.
When a new format is developed, I would like to develop another routine for it.
In this case, the routine was requested about a year ago, and I had advance notice of its development.
However, it was a pain to create, so I kept it on hold for a long time, but this routine became absolutely necessary, so I implemented it.
That was when I was erasing unnecessary routines to save space on Kaitou.
When I erased all the debug routines, the menu definition pointer also disappeared, and I could no longer access the menu from FEBulderGBA.
By the time I realized this, I had already stored other data in that area, so it was a hassle to change it.
Therefore, I needed a routine that could keep track of the menu pointer even if it had been destroyed.
Without it, I would have to manually enter the address each time, which is inconvenient.
To implement it efficiently, it was necessary to modify the structure of the FEBulderGBA constants.
And if I were going to make it anyway, I aimed for a general-purpose routine that could handle ROMs with pointer corruption.
I think this method of using reflection is very convenient because it allows us to deal with more complex structures just by who makes the definition in custom_pointer.txt.
The recommended obfuscation routine for now is to swap the contents of the structure.
For example, the zeroth of the Unit structure contains the string ID of the name in the short type.
If you swap this with other data, it will not be recognized correctly by FEBuilderGBA.
If it is a BG, you can swap the lz77 data with the TSA data.
Just change ldr a little.
However, the side effects of this routine are extensive and may be troublesome to create.
FEBuilderGBA is strongly dependent on the contents of the structure, so I believe it would be quite difficult to deal with this.
Not impossible, of course, but …
In fact, this has led to the leakage of a lot of material that is not expected to be published. Including battle animation, and portrait and so on.
Not everyone wants their work F2U or even F2E. The leak of the material caused by the update of the new version has dampened the enthusiasm of many authors who contributed non-open source GBAFE materials. And forcing hackers who know programming have to rewrite encryption patches to fight thieves who use FEB to steal material. However, even so, those encrypted works that have been released cannot be recovered because of this update.
These are not assumptions I’m talking about, it’s what’s happening.
I strongly disapprove of FEB’s forcible re-exposure of the author’s actively encrypted parts to others. Suppose such a scenario, I made my own material that none open sourced, then you tell me, “ok, I have the right to decrypt even the actively encrypted material for anyone to steal since I think it should be open sourced” ？？ What do non-open source authors think about this approach?
Let me take two examples,
FE10RE, after you open it with FEB, you can’t see the materials such as battle animes, etc. Guess why? Is it because the author’s level is too poor, which leads to a bug, or is it because they actively avoided FEB recognition?
Another example, such an battle animation, have you found it in the public F2E repo? No, because it is not open sourced. However, such a material is indeed under development. The original author stated that the project will not continue to develop until they find the effective way to prevent thieves dump them through FEB.
¯_(ツ)_/¯
I agree with you. It is our work, our efforts and we want to keep it with in secret.
Firstly, if there are any animations in the Repo that have been dumped from roms that the devs don’t want, I’m right here. You can tell me to remove them if they’re illegitimate.
Secondly, @explosionwolf, isn’t this your game?
That looks like an animation from the repo, one by Khrene Kleaver. I’m not saying you guys can’t have your secret animations or whatever, but it never fails to amuse me when people take things from the community and use tools made by the community but also have strict “Nobody can use my toys!” rules.
“The community helped me out. But will I give back to them? No!”
That’s the common attitude I see.
What leakage? What animations have been illegitimately used or put in the repo so far?
I’m ambivalent about decrypting intentionally encrypted roms, by the way. I just shake my heads at people who take-take-take but never give back, but I’ve no interest in stealing their work, either.
5 Likes
Trying to fight art theft by trying to develop stronger encryption is frankly a losing game, especially when the material is not being kept secret in the slightest; it’s put on display for anyone to see if they play the hack. The only reliable way to make sure no one else uses something you made is to not put it into a public release in the first place.
More generally, art theft is a cultural/societal level issue, so approaching it from a technical standpoint is unoptimal. The best way to deal with it is by creating an atmosphere where it’s not tolerated. For communities to require properly credited and properly permissioned usage of resources to host projects, and removing projects that break those rules.
5 Likes
I understand that you want to hide it.
But I want to see the data.
The more it is hidden, the more I want to see the data.
Whether or not you then decide to steal it is they decision, not mine.
2 Likes
I’m not talking about our common repo. If people can directly dump animes from other works and insert to their own rom, uploading to repo is not profitable for them.
At the same time, I’m not advocating for people to stop contributing to the public community. The existence of a large number of non-open source authors is an objective fact. They do not agree that their resources are misappropriated by others, and that’s just the fact.
Both properly credit to the open source material, and respecting the encryption behavior of non-open source authors, the goal are the same, which is to inspire more people to participate in the FE Hack cause. And the work you mentioned is not my game. What I’m working on is just c-SkillSys.
1 Like
A resource that is dumped by skilled hackers, or it is exposed to anyone who has the FEB, these are not the same thing. Especially when you take into account the difference in the numbers of these two groups of people and the difficulty of obtaining encrypted resources.
1 Like
My point is to respect the needs of non-open source authors, not take away their rights.
1 Like
Anyone who’s intent on stealing from someone’s ROM has already been able to do so, and this update doesn’t make a major difference. The most this update does is skip a few steps in the reverse engineering process; a thief still needs to perform that reverse engineering themselves for a number of things. This doesn’t crack anything wide open, it just makes FEBuilder able to apply what someone’s reverse engineered.
7743 may have oversold the feature and other people may have overreacted as a result. The technological impact to FEBuilder’s internal structure is major, but the practical effects on asset theft is small and niche. The thieves still need to find pointers themselves.
2 Likes